BiTel

Хочется обсудить, кто как и чем мониторит работу BGBilling и его компонентов.
А также узнать у разработчиков, планируется ли реализация единой системы сбора статистики о работе биллинга (встроенный SNMP-агент/JMX?)

Начну с себя:
Мы сейчас пользуемся Cacti, мониторим:
- JMV memory usage - через SNMP
- DB connections - скриптом, TCP-соединие на админский порт, команда status
- Radius sessions (dialup) - скриптом, TCP-соединие на админский порт, команда status

В будущем хочется перейти на zabbix, но пока руки не доходят.

Что ещё хотелось бы мониторить?
- Radius Sessions для Access и Accounting модуля Inet
- Статистика Embedded Tomcat - можно уже сейчас через JMX
- Статистика ActiveMQ (по очередям, например) - можно через JMX, только нужно писать и контрибьютить шаблон для zabbix
- Статистика BGScheduler (размер очереди, количество активных задач)
- Платежи MPS (количество, сумма)

шедулер по snmp если падет, то смс мне шлется, остальное продажниками ))

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Я за JMX, т.к. не сложно добавлять новые данные (методы/интерфейсы).

Не дождался разработчиков, запилил мониторинг радиуса модуля Inet через JMX:
http://wiki.bgbilling.ru/index.php/%D0% ... %D0%B7_JMX
Всё просто.

зы.
Неплохо бы собраться всем коммунити и сделать набор шаблонов zabbix для биллинга с графиками, триггерами и блекджеком.

Клево. Мне не понравилось, что нужно делать интерфейсы в стандартной реализации - т.к. они довольно специфичны, не получится один интерфейс к нескольким бинам прикрутить. Поэтому хотел сделать через указание аннотации для произвольного метода, но пока так и не добрался...

С jmx шикарно получилось. респект.

Про zabbix, я замучился что-то с ним. Сейчас мигрирую на riemann, оно как-то проще для моего мозга, ну и плюс возможность прицепить его в любом месте кода для отсылки ивента, ну и быстрый он.

Если кому интересно - как изменилось потребление памяти BGinetAccounting после заворачивания в него Netflow (и рестарта):


Радиус - 276 update per second, 2200 родительских коннекшенов, примерно столько же дочерних.

По картинке немного непонятно - сразу после полного запуска так стало или еще через какое-то время?
Как настроена привязка netflow?

???

!!!!




Я так понимаю, Амир вышел из отпуска

Запилил шаблон Zabbix для ActiveMQ: https://gist.github.com/Cromeshnic/6316503
Правда без напильника не заработает.

Кстати, голосуем за Low-Level Discovery для JMX в Zabbix: https://support.zabbix.com/browse/ZBXNEXT-1223
Нам потом тоже может пригодиться.

Добавили атрибуты для IP-ресурсов.

Хочу сделать шаблон Zabbix для биллинга.
Вопрос:


$2 здесь не случайно? оно может измениться?

А, всё - нашёл. Это анонимный внутренний класс. Зависит от типа flow-агента. Блин, придётся все перечислять.

"netflow" - ru.bitel.bgbilling.modules.inet.collector:type=InetFlowListener$2
"netflow9" - ru.bitel.bgbilling.modules.inet.collector:type=InetFlow9Listener
"sflow" - ru.bitel.bgbilling.modules.inet.collector:type=InetFlowListener$5

Всё же имхо лучше для JMX использовать неанонимные классы, т.к. анонимные могут поменяться номерами в будущем.
мм?

Также, круто было бы мониторить через JMX количество коннектов к master/slave/trash - базам.
У меня сейчас в cacti берётся скриптами через ***_status.sh, что довольно затратно:

(сверху на картинке - мастер акт/ожидание, снизу - slave)

Done.

6.0

Подскажите, что и как мониторить, чтобы знать живо то или иное приложение или нет. Сейчас использую Nagios.

Хочется вовремя знать, что например повисло что-то из: bgbilling, bgdataloader, bgscheduler, bginet_access, bginet_accounting ну и ActiveMQ в догонку.

Как мониторить БД я в документации видел, с этим проблем возникнуть не должно.

мы мониторим заняты ли порты, если заняты - все норм, если свободны, то смс на полифон

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

А какие порты? java-SNMP или 8080 и NetFlow. Если можно расскажите поподробнее, как организованно.

да способов то море, кажись каким то стандартным средством на питоне. все это дело писалось на питоне. мониторим радиус, (1812 1813) сервер не мониторим как таковой, для авторизации неважен, а кто работает и так скажет что он умер. нетфлоу - это 1813(аккаунтинг) если работает то и считаем что флоу собирается. отправляется через старенький SE телефон, посредствам консольной програмки и передачи параметров

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Сделал на тестовом сервере java management.snmp
./server.sh

Насколько оно корректно?

SNMP опрашивается. Может знающие люди подскажут, какой OID мониторить, чтобы знать живо оно или мертво.

Дык, перестало выводить инфу==мертвый

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Кстати, исследовал эту проблему гораздо позже, забыл сюда отписать. Это буферы flowListener.threadCount * datalog.flow.chunk.size. Аналогично для DHCP и для RADIUS.
Наткнулись, когда при стандартном datalog.dhcp.chunk.size у клиента было 500-1000 DHCP-релей-устройств. Получалось что буферы могли забрать от (500 до 1000) * dhcpListener.threadCount * datalog.dhcp.chunk.size, но обычно было гораздо меньше максимума, но все же много.