Inet FAQ

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

Версия 09:48, 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 долгое время не был запущен или повис из-за какого-то сбой и см. первую причину;
• ошибка в 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.

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))