Inet FAQ

Материал из BiTel WiKi

Версия 14:24, 3 февраля 2014

Глючит, абонентов не пускает, команды на коммутаторах не выполняет

Возможно в ActiveMQ накопилось большое кол-во сообщений и нет возможности их корректно обработать. Проверьте, если в /opt/activemq/data/kahadb большое кол-во файлов *.log (например, больше 5-ти), то скорее всего причина в этом.

В ActiveMQ копятся и в итоге не обрабатываются сообщения

Для того, чтобы быстрее узнать, почему ActiveMQ копит сообщения лучше включить web-консоль ActiveMQ. Для этого в /opt/activemq/conf/activemq.xml расскомментируйте ветку <import resource="jetty.xml"/> и перезапусите ActiveMQ.

<!--                                                                                                                                                                             
    Enable web consoles, REST and Ajax APIs and demos                                                                                                                            
    It also includes Camel (with its web console), see ${ACTIVEMQ_HOME}/conf/camel.xml for more info                                                                             
 
    Take a look at ${ACTIVEMQ_HOME}/conf/jetty.xml for more details                                                                                                              
-->                                                                                                                                                                              
    <import resource="jetty.xml"/>

Откройте в браузере web-консоль http://адрес:8161/admin, перейдите в Queues. Number Of Pending Messages - это кол-во сообщений, которые ActiveMQ получил, но еще не успел или не смог передать приложениям биллинга. При нормальной работе среднее значение 0 или небольшое, т.е. при увеличении очень быстро уменьшается обратно.

Если web-консоль не открывается, при этом activemq.xml поправили корректно и порт 8161 открыт - возможно проблема в дистрибутиве activemq (например, файлы дистрибутива повреждены), попробуйте заменить его.

Если значения Number Of Pending Messages у каких-либо очередей большие у не уменьшаются, то на это может быть несколько причин:

• произошел какой-то сбой (например, ниже), очередь переполнилась и теперь не может отработать корректно;
• одно из устройств (NAS' или коммутатор) очень долгое время не отвечало при попытках синхронизации, таким образом сообщения для него постепенно копились и см. первую причину, нужно посмотреть логи Access;
• Access долгое время не был запущен или повис из-за какого-то сбой и см. первую причину;
• конфигурация Access некорректна, например, значения rootDeviceId или accounting.deviceTypeIds неправильные.
• ошибка в ServiceActivator при синхронизации с NAS'ом или коммутатором, нужно смотреть логи Access (возможно нужно перекомпилировать динамические классы);
• одно из устройств удалили, но к нему были привязаны активные сервисы Inet, в итоге Accounting генерирует сообщения, которые Access не может обработать.

Можно открыть конкретную очередь в web-консоли и посмотреть, какие там сообщения, для каких устройств (поле deviceId).

Решение:

1. Если в Access постоянные ошибки с синхронизацией для всех устройств (т.е. даже если очередь заработает - функциональность не восстановится), попробуйте их исправить.
2. Попробуйте перезапустить Access и Accounting.
3. Если после перезапуска Access не начал выполнять синхронизацию или начал выполнять нормально, но очень и очень медленно, т.е. Number Of Pending Messages не уменьшается, можно попробовать очистить очередь, нажав на ссылку Purge для очереди в web-интерфейсе.
4. Если Purge не выполняется вообще или выдает ошибку, можно попробовать удалить очередь через ссылку Delete, но после успешного удаления очереди или очередей нужно будет перезапустить BGBillingServer, BGInetAccess и BGInetAccounting.
5. Если Delete тоже не выполняется или web-интерфейс не открывается, можно попробовать очистить данные activeMQ. Для этого нужно остановить BGBillingServer, Accounting, Access, ActiveMQ, переименовать папку /opt/activemq/data/kahadb (чтобы осталась резервная копия), запустить ActiveMQ, BGBillingServer, Access, Accounting.
6. Если после очистки очередь все равно набирается - возможно проблемы с конфигурацией Access.
7. Если с Access все в порядке, а за ActiveMQ замечены еще какие-то проблемы - возможно проблема в дистрибутиве activemq (например, файлы дистрибутива повреждены), попробуйте заменить его.

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

Не совпадает состояние сервиса Inet с тем, что должно быть

После сбоя или после ручного добавления платежей в БД состояние сервисов может не совпадать с необходимым. При этом при пересохранении сервиса состояние меняется на нормальное. Если это произошло по неизвестной причине, следует ее выяснить. Например, при проблеме c обработкой сообщений необходимо сначала устранить ее. Или есть скрипт добавления платежей, который не создает необходимые события - необходимо сначала его исправить.

Для того, чтобы заставить биллинг синхронизировать состояние сервисов согласно балансу нужно добавить в "Глобальные скрипты поведения" - "Классы Java" класс ru.bitel.bgbilling.modules.inet.dyn.access.InetServStateSync. Перед запуском этого скрипта нужно перезапустить BGBillingServer, чтобы синхронизация гарантировано запустилась для всех договоров.

Access и/или Accounting потребляют много памяти, постепенно после старта.

Возможно задействовано много источников логов (NAS'ы, которые посылают пакеты RADIUS, коммутаторы, которые посылают DHCP-пакеты, flow-агенты). При получения, обработки и записи DHCP/Radius/Netflow/sFlow пакетов используются буферы. Максимальное кол-во памяти, которые могут забрать буферы - threadCount * datalog.chunk.size * (кол-во устройств-источников данных), где threadCount - кол-во потоков слушателя (InetRadiusListener/DhcpListener/InetFlowListener).

В этом случае не стоит указывать большое кол-во потоков для слушателя threadCount и при большом кол-ве источников логов имеет смысл уменьшить chunk.size:

# Общее для всех значение, используется, если не указано специально для типа лога
datalog.chunk.size=131072
# DHCP
datalog.dhcp.chunk.size=65536
# RADIUS
datalog.radius.chunk.size=65536
# Netflow/sFlow
datalog.flow.chunk.size=262144

<!-- Параметры сохранения radius-пакетов в файлы логов -->
<!-- Директория, в которую сохранять radius логи -->
<param name="datalog.radius.dir" value="data/radius" />
<!-- Размер блока данных в файле лога, также размер буфера на поток слушателя -->
<param name="datalog.radius.chunk.size" value="524288" />
<!-- Сжимать radius логи: 0 - не сжимать, 1 - zlib -->
<param name="datalog.radius.compression.type" value="1" />
<!-- Параметры сохранения flow-пакетов в файлы логов -->
<!-- Директория, в которую сохранять flow логи -->
<param name="datalog.flow.dir" value="data/flow" />
<!-- Размер блока данных в файле лога, также размер буфера на поток слушателя -->
<param name="datalog.flow.chunk.size" value="524288" />
<!-- Сжимать flow логи: 0 - не сжимать, 1 - zlib -->
<param name="datalog.flow.compression.type" value="1" />

Как SQL запросом посмотреть IP-адрес, MAC-адрес из inet_serv varbinary(64)?

SELECT HEX(macAddress) FROM inet_serv

SELECT INET_NTOA(CONV(HEX(ipAddress), 16, 10)) FROM inet_connection
SELECT * FROM inet_connection WHERE ipAddress=UNHEX(CONV(INET_ATON('10.0.0.1'), 10, 16))