h1. Для чего нужен nas_event_daemon
Демон отправки событий *nas_event_daemon* забирает из стека(таблица базы "events_stack") команды для отправки и вызывает функции [session|CarbonBilling:Интеграция оборудования интернет] скрипта, передавая в него параметры абонента и NAS
h1. Описание работы
nas_event_daemon работает следующим образом:
# В настройке оборудования можно указать количество потоков, это по сути сколько [учетных записей|CarbonBilling:Учетная запись. Создание и изменение.] будет обрабатываться одновременно
# Форк берет первые 1000 событий по учетной записи, при этом в первую очередь обрабатывается user_info
# Если скрипт отправки события возвращает код ошибки 143 или 254 значит событие откладывается на 0.017 умноженное на номер попытки, всего может быть 10 попыток, т.е. обязательно обратите внимание на дату события и счетчик попыток
# После форка всех потоков демон просто ждет: usleep 50000 (время указано в микросекундах, что равно 0.05 секунды)
# И снова форкает пока не закончатся события в стеке
Можно настроить количество потоков чтобы ускорить процесс но надо помнить несколько вещей:
* Если на каждую учетку очень много событий и отклик у оборудования долгий то вы просто наспамите демонов, которые скорее всего еще и транзакций навешают друг на друга т.к. один не успеет завершиться за 50000 милисекунд
* Если на учетку по 1 событию и учеток очень много, то увеличение потоков не очень поможет.
Если увеличили потоки обязательно проверьте что они успевают обрабатывать:
{code}ps aux |grep nas{code}
Не должно со временем расти.
{note}* При управлении оборудованием по CoA средствами radiclient не должно возникать проблем с параллельной отправкой команд
* При управлении оборудованием по ssh или telnet могут возникать проблемы: ssh может работать недостаточно быстро, telnet часто имеет ограничение на одновременное количество сессий{note}
h1.Настройка
Переходим на вкладку "ОБОРУДОВАНИЕ", выбираем нужный NAS.
Дополнительно > "Количество потоков для отправки команд на оборудование".
Указываем необходимое количество форков, нажимаем сохранить.
Будут автоматически запускаться новые форки nas_event_daemon. Количество процессов не должно превышать "количество форков" + 1 процесс "родитель".
При уменьшении количества форков значение не будет изменяться моментально т.к. процессы должны завершить свои задачи.
Контролируем обработку команд с помощью ps aux. Например для микротика:
{code}ps aux |grep send_mikrotik_cmd
root 27122 2.0 0.0 748333 8230 ? SN 15:47 0:00 /usr/bin/python2.7 /usr/local/bin/send_mikrotik_cmd -s 10.0.0.1 carbon carbon /ip firewall address-list remove numbers=192.168.1.10_crb_blocked{code}
Процессы не должны обрабатываться не более 50 секунд. Если Вы наблюдаете эту ситуацию изменении количества форков не окажет положительного влияния. Необходимо решать проблему с обработкой команд со стороны оборудования.
h1. Отладка
Узнать количество команд в стеке с группировкой по типу команды можно выполнив скрипт *event_count.sh*:
{code}chroot /app/asr_billing/ event_count.sh{code}
Вывод будет приблизительно следующий:
{code}# compact stack
TOTAL
COUNT
0
# main stack
COUNT EVENT_TYPE
52 b_negbal
4 b_sys
44 u_b_negbal
207 user_accept
75 user_add
16 user_del
50 user_drop
73 user_edit
1 user_rate_set_cancel
168 user_redirect
89 user_redirect_cancel
122 usluga_activated
28 usluga_add
3 usluga_deactivated
4 usluga_del
1 usluga_disabled
28 usluga_recalc
TOTAL
COUNT
965{code}
Скрипт смотрит два стека:
# *compact stack*
# *main stack*
После сгруппированного списка по каждому стеку можно увидеть суммарное количество команд.
Структура таблиц:
# *compact stack* (таблица базы данных EVENTS_STACK_COMPACT) - изначально команды для отправки на оборудование добавляются в compact stack, его наполняют различные подсистемы (radiusd, sync_nasd) базовыми данными по событию которое нужно отправить на оборудование и обработчик абонентов переносит их в main stack дополняя нужными данными:
#* *ABONENT_ID* - ID абонента
#* *USER_ID* - ID учетной записи
#* *CMD* - [Команда для выполнения|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51708843|] (как в примере выше, названия команд в основном и компактном стеке одинаковы)
#* *USER_IP* - IP абонента
#* *NAS_IP* - IP NAS/BRAS
#* *USLUGA_ID* - ID услуги (указывается при изменении статусов услуг абонента в событиях usluga_add, usluga_activated и т.д.)
#* *ACCT_SESSION_ID* - Acct-Session-ID (уникальный ID сессии, используется при авторизации по RADIUS)
# *main stack* (таблица базы данных EVENTS_STACK) - этот стек формируется из compact stack, к нему добавляются расширенные данные для передачи в скрипт управления оборудованием, после чего они обрабатываются демоном nas_event_daemon и удаляются из стека
#* *ABONENT_ID* - ID абонента
#* *USER_ID* - ID учетной записи
#* *EVENT_TYPE* - [Команда для выполнения|CarbonBilling:Состояния пользователей, услуг и команды управления] (то же что CMD в compact stack)
#* *NAS_TYPE* - ID [типа NAS или OSS схемы|CarbonBilling:Интеграция оборудования интернет]
#* *EVENT_DATE* - дата добавления события в main stack
#* *PARAMS* - набор переменных, передаваемый в скрипт событий
#* *OWNER_SCRIPT* - подсистема [воркера|CarbonBilling:Worker] добавившая событие в стек
#* *OWNER_FUNCTION* - функция этой под системы в которой вызвано добавление события в стек
#* *NAS_ID* - ID NAS/BRAS
#* *TRY_COUNT* - количество выполненных попыток отправки команд
Демон отправки событий *nas_event_daemon* забирает из стека(таблица базы "events_stack") команды для отправки и вызывает функции [session|CarbonBilling:Интеграция оборудования интернет] скрипта, передавая в него параметры абонента и NAS
h1. Описание работы
nas_event_daemon работает следующим образом:
# В настройке оборудования можно указать количество потоков, это по сути сколько [учетных записей|CarbonBilling:Учетная запись. Создание и изменение.] будет обрабатываться одновременно
# Форк берет первые 1000 событий по учетной записи, при этом в первую очередь обрабатывается user_info
# Если скрипт отправки события возвращает код ошибки 143 или 254 значит событие откладывается на 0.017 умноженное на номер попытки, всего может быть 10 попыток, т.е. обязательно обратите внимание на дату события и счетчик попыток
# После форка всех потоков демон просто ждет: usleep 50000 (время указано в микросекундах, что равно 0.05 секунды)
# И снова форкает пока не закончатся события в стеке
Можно настроить количество потоков чтобы ускорить процесс но надо помнить несколько вещей:
* Если на каждую учетку очень много событий и отклик у оборудования долгий то вы просто наспамите демонов, которые скорее всего еще и транзакций навешают друг на друга т.к. один не успеет завершиться за 50000 милисекунд
* Если на учетку по 1 событию и учеток очень много, то увеличение потоков не очень поможет.
Если увеличили потоки обязательно проверьте что они успевают обрабатывать:
{code}ps aux |grep nas{code}
Не должно со временем расти.
{note}* При управлении оборудованием по CoA средствами radiclient не должно возникать проблем с параллельной отправкой команд
* При управлении оборудованием по ssh или telnet могут возникать проблемы: ssh может работать недостаточно быстро, telnet часто имеет ограничение на одновременное количество сессий{note}
h1.Настройка
Переходим на вкладку "ОБОРУДОВАНИЕ", выбираем нужный NAS.
Дополнительно > "Количество потоков для отправки команд на оборудование".
Указываем необходимое количество форков, нажимаем сохранить.
Будут автоматически запускаться новые форки nas_event_daemon. Количество процессов не должно превышать "количество форков" + 1 процесс "родитель".
При уменьшении количества форков значение не будет изменяться моментально т.к. процессы должны завершить свои задачи.
Контролируем обработку команд с помощью ps aux. Например для микротика:
{code}ps aux |grep send_mikrotik_cmd
root 27122 2.0 0.0 748333 8230 ? SN 15:47 0:00 /usr/bin/python2.7 /usr/local/bin/send_mikrotik_cmd -s 10.0.0.1 carbon carbon /ip firewall address-list remove numbers=192.168.1.10_crb_blocked{code}
Процессы не должны обрабатываться не более 50 секунд. Если Вы наблюдаете эту ситуацию изменении количества форков не окажет положительного влияния. Необходимо решать проблему с обработкой команд со стороны оборудования.
h1. Отладка
Узнать количество команд в стеке с группировкой по типу команды можно выполнив скрипт *event_count.sh*:
{code}chroot /app/asr_billing/ event_count.sh{code}
Вывод будет приблизительно следующий:
{code}# compact stack
TOTAL
COUNT
0
# main stack
COUNT EVENT_TYPE
52 b_negbal
4 b_sys
44 u_b_negbal
207 user_accept
75 user_add
16 user_del
50 user_drop
73 user_edit
1 user_rate_set_cancel
168 user_redirect
89 user_redirect_cancel
122 usluga_activated
28 usluga_add
3 usluga_deactivated
4 usluga_del
1 usluga_disabled
28 usluga_recalc
TOTAL
COUNT
965{code}
Скрипт смотрит два стека:
# *compact stack*
# *main stack*
После сгруппированного списка по каждому стеку можно увидеть суммарное количество команд.
Структура таблиц:
# *compact stack* (таблица базы данных EVENTS_STACK_COMPACT) - изначально команды для отправки на оборудование добавляются в compact stack, его наполняют различные подсистемы (radiusd, sync_nasd) базовыми данными по событию которое нужно отправить на оборудование и обработчик абонентов переносит их в main stack дополняя нужными данными:
#* *ABONENT_ID* - ID абонента
#* *USER_ID* - ID учетной записи
#* *CMD* - [Команда для выполнения|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51708843|] (как в примере выше, названия команд в основном и компактном стеке одинаковы)
#* *USER_IP* - IP абонента
#* *NAS_IP* - IP NAS/BRAS
#* *USLUGA_ID* - ID услуги (указывается при изменении статусов услуг абонента в событиях usluga_add, usluga_activated и т.д.)
#* *ACCT_SESSION_ID* - Acct-Session-ID (уникальный ID сессии, используется при авторизации по RADIUS)
# *main stack* (таблица базы данных EVENTS_STACK) - этот стек формируется из compact stack, к нему добавляются расширенные данные для передачи в скрипт управления оборудованием, после чего они обрабатываются демоном nas_event_daemon и удаляются из стека
#* *ABONENT_ID* - ID абонента
#* *USER_ID* - ID учетной записи
#* *EVENT_TYPE* - [Команда для выполнения|CarbonBilling:Состояния пользователей, услуг и команды управления] (то же что CMD в compact stack)
#* *NAS_TYPE* - ID [типа NAS или OSS схемы|CarbonBilling:Интеграция оборудования интернет]
#* *EVENT_DATE* - дата добавления события в main stack
#* *PARAMS* - набор переменных, передаваемый в скрипт событий
#* *OWNER_SCRIPT* - подсистема [воркера|CarbonBilling:Worker] добавившая событие в стек
#* *OWNER_FUNCTION* - функция этой под системы в которой вызвано добавление события в стек
#* *NAS_ID* - ID NAS/BRAS
#* *TRY_COUNT* - количество выполненных попыток отправки команд