nas_event_daemon

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (52)

просмотр истории страницы
...
nas_event_daemon работает следующим образом:

# В настройке [оборудования|Справочник NAS] можно указать количество потоков, это по сути сколько [учетных записей|CarbonBilling:Учетная запись. Создание и изменение.] будет обрабатываться одновременно
# Форк берет первые 1000 событий по учетной записи, при этом в первую очередь обрабатывается user_info
# Если скрипт отправки события возвращает код ошибки 143 или 254 значит событие откладывается на 0.017 умноженное на номер попытки, всего может быть 10 попыток, т.е. то есть обязательно обратите внимание на дату события и счетчик попыток
# После форка всех потоков демон просто ждет: usleep 50000 (время указано в микросекундах, что равно 0.05 секунды)
# И снова форкает пока не закончатся события в стеке

Можно настроить количество потоков чтобы ускорить процесс, но надо помнить несколько вещей:

* Если на каждую учетку очень много событий и отклик у оборудования долгий то вы просто наспамите демонов, которые скорее всего еще и транзакций навешают друг на друга т.к. один не успеет завершиться за 50000 милисекунд
* Если на учетку по 1 событию и учеток очень много, то увеличение потоков не очень поможет.
* Если на каждую учетную запись очень много событий и отклик у оборудования долгий, то вы запуститите излишнее количество демонов. Это может наоборот замедлить отправку команд.
* Если на учетную запись пиходится по 1 событию и учётных записей много, то увеличение потоков поможет слабо.

Если увеличили потоки обязательно проверьте, что они успевают обрабатывать:
{code}ps aux |grep nas{code}
{code}
ps aux | grep nas
{code}

Не должно со временем расти.
Не должно расти со временем.

{note}
{note}* * При управлении оборудованием по CoA средствами radiclient не должно возникать проблем с параллельной отправкой команд
* При управлении оборудованием по ssh или telnet могут возникать проблемы: ssh может работать недостаточно быстро, telnet часто имеет ограничение на одновременное количество сессий{note}
{note}

h2. Еще немного технических деталей
...
h3. Конструктор отчетов

Используемые таблицы: EVENTS_STACK_COMPACT, EVENTS_STACK.
Для отладки проблем вы можете использовать [конструктор отчётов|Конструктор отчетов]. Данные в таблицах постоянно перезаписываются, так что данные будут видны только при нагрузке. Используются таблицы:
* *Events_Stack_Compact*
* *Events_Stack*

Вряд ли Вам потребуется их использовать в конструкторе отчетов, стеки динамические, но это может быть полезно при отладке из командной строки.

h3. API

Используемые модели: EventsStackCompact, EventsStack.
Для отправки событий вы можете использовать [API|API REST v2.0], используются модели:
* *EventsStackCompact*
* *EventsStack*

h1.Настройка

Переходим на вкладку "ОБОРУДОВАНИЕ", выбираем нужный NAS.
Дополнительно > "Количество потоков для отправки команд на оборудование".
Указываем необходимое количество форков, нажимаем сохранить. (На текущий момент количество форков ограничено, максимум 100.)
# Перейдите на вкладку [оборудования|Справочник NAS], выбите нужный NAS. Укажите в поле Дополнительно - *Количество потоков для отправки команд на оборудование" укажите необходимое количество форков, нажимите сохранить
# Максимальное количество форков 100
Будут # После сохранения будут автоматически запускаться новые форки 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}

{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 секунд. Если вы процессы обрабатываются дольше, то изменение количества форков не окажет положительного влияния. Необходимо решать проблему с обработкой команд со стороны оборудования.

Процессы не должны обрабатываться не более 50 секунд. Если Вы наблюдаете эту ситуацию, изменение количества форков не окажет положительного влияния. Необходимо решать проблему с обработкой команд со стороны оборудования.

h1. Отладка

...
#* *USLUGA_ID* - ID услуги (указывается при изменении статусов услуг абонента в событиях usluga_add, usluga_activated и т.д.)
#* *ACCT_SESSION_ID* - Acct-Session-ID (уникальный ID сессии, используется при авторизации по RADIUS)
# *main stack* (таблица базы данных EVENTS_STACK) - этот стек формируется [ядром биллинга|Worker (ядро биллинга)] из compact stack, к нему добавляются расширенные данные для передачи в скрипт управления оборудованием, после чего они обрабатываются демоном nas_event_daemon и удаляются из стека
#* *ABONENT_ID* - ID абонента
#* *USER_ID* - ID учетной записи
...
В зависимости от ситуации и схемы интеграции с NAS, нормальным можно считать следующее количество событий:
* Штатная работа - до 200 событий суммарно в events_stack и events_stack_compact
* Массовая авторизация на NAS (например, после перезагрузки) - до 5 событий на абонента в абонента, суммарно в events_stack и events_stack_compact.
Например, на NAS 1000 абонентов. Сразу после перезагрузки NAS может скопиться до 5000 событий из-за большого количества авторизаций в короткий срок.

Если при выполнении проверки в стеке событий *compact stack* наблюдается большое количество команд, и их число не уменьшается (растет) остаётся прежним или растет с каждой последующей проверкой, как указано в примере:
{code}
{code}# # compact stack
COUNT CMD
7774 rad_acc_start
...
TOTAL
COUNT
27647{code}
{code}

нНеобходимо сделать следующее:
* Проверить текущую нагрузку на биллинге командой top;
* Проверить, что сервер выполнял перезагрузку несколько минут назад, так как после перезагрузки может наблюдаться массовая авторизация абонентов;
* Проверить сервер на соответствие [системным требованиям|CarbonBilling:Системные требования];
{code}
uptime
{code}
* Проверить [быстродействие биллинга|Биллинг медленно работает#Как понять почему биллинг работает медленно?];
* Убедиться, что в последнее время не вносили изменения в настройки NAS и в некоторых случаях проверить, что опция "Не посылать user_disconnect при получении Radius Stop" включена, для предотвращения зацикливания обработки radius-пакетов биллингом, получаемых от NAS.

При скоплении событий в стеке *main stack*, они должны отправляться на оборудование со скоростью около 1000 за 5 минут.
Если медленней, то:
* Выясните с каким НАС проявляется проблема, для этого выполните [отчёт|Конструктор отчетов]:
{code}
select
n.name,
count(1)
from events_stack es left join nas n on es.nas_id=n.id
group by 1
{code}
* Попробуйте увеличить количество форков (описано выше в статье) [количество потоков отправки команд|nas_event_daemon#Настройка]
* Посмотрите [лог отправки событий|nas_event_daemon#Проверьте логи], возможно NAS слишком долго выполняет полученные команды. Отправьте команду вручную и проверьте скорость ответа программой *time*.
На примере Mikrotik:
{code}
{code}# # time send_mikrotik_cmd -s 10.90.185.2 admin servicemode /queue simple remove comment=crb_10.88.0.15
ERROR: UnknownParameter message: 'unknown parameter', command: '/queue/simple/remove =comment=crb_10.88.0.15' exit code: 249

real 0m0.096s
user 0m0.031s
sys 0m0.008s{code}
{code}
Время +real+ не должно превышать 300 милисекунд.
* Возможно БД билинга находится на медленном носителе или прочие аппаратные проблемы мешают работе биллинга. Проведите диагностику по статье "[CarbonBilling:Проблемы с оборудованием]"
...
* Получите данные абонентов и учетных записей по заданным параметрам [SQL-запросом командой sqlexec|CarbonBilling:Конструктор отчетов] и передайте полученные данные (ID абонентов, учетных записей, IP-адреса и тд) в команду которой управляется оборудование (SSH, RADIUS CoA и тд)
* Так же получить данные с sqlexec и передайте их по API создавая объекты в моделе EventsStackCompact, например так: \\ \\
{code}#/bin/bash
#!/bin/bash

sqlexec "set list; select id from users u where nas_id=1112" | awk '$2{print $2}' | while read user_id; do
...
done

exit 0{code} 0
{code}

h2. NAS не инициализирован или не выбрана схема, но назначены абоненты
...