Слушатель InetFlowListener

Для того, чтобы принимать и обрабатывать flow-пакеты (netflow/netflow v9/sflow) в inet-accounting.xml должен быть прописан соответствующий слушатель. Если необходимо приходящие пакеты перед обработкой сохранять на диск, в слушатель нужно передать dataLogger. Объект dataLogger описывается один раз и передается всем flow-слушателям, с которых нужно сохранять данные.

У слушателя необходимо указать параметры:

  • type - его тип: netflow, netflow9, sflow;

  • host - хост (интерфейс), на котором будет открыт сокет, по умолчанию на всех интерфейсах;

  • port - порт, на котором будет открыт сокет;

  • recvBufferSize - размер буфера приема слушателя;

  • soRCVBUF - рекомендуемый размер буфера приема сокета (SO_RCVBUF);

  • threadCount - количество потоков-обработчиков;

  • agentDeviceIds - id устройств, источников flow-потоков, если на данном порту нужно обрабатывать данные только у определенных источников;

  • dataLogger - dataLogger, с помощью которого приходящие пакеты будут записываться в лог файлы.

Код
<!-- Служебный ScheduledExecutorService, необходимый для dataLogger -->
<scheduledExecutorService name="hrlydtlggr" corePoolSize="1"/>

<!-- Cоздание dataLogger, сохраняющего flow-пакеты на диск (только один экземпляр) -->
<bean name="flowDataLogger" class="ru.avantis.abilling.modules.inet.collector.IPHourlyDataLogger">
    <param name="scheduledExecutor">hrlydtlggr</param>
</bean>

<!-- Cоздание слушателя flow-пакетов на порту с передачей ему dataLogger -->
<bean name="flowListener" class="ru.avantis.abilling.modules.inet.collector.InetFlowListener">
    <constructor factoryMethod="newInstance">
        <!-- Тип слушателя, netflow, netflow9 или sflow -->
        <param name="type" value="netflow"/>
        <!-- Хост (интерфейс), на котором будет открыт сокет. Если пусто - на всех -->
        <param name="host" value=""/>
        <!-- Порт, на котором будет открыт сокет -->
        <param name="port" value="2001"/>
        <!-- Размер буфера приема слушателя -->
        <param name="recvBufferSize">4 * 1024 * 1024</param>
        <!-- Рекомендуемый SO_RCVBUF сокета -->
        <param name="soRCVBUF">512 * 1024</param>
        <!-- Количество потоков-обработчиков -->
        <param name="threadCount" value="10"/>
        <!-- id устройств-источников, если на данном порту нужно получать пакеты только c определенных источников -->
        <param name="agentDeviceIds" value=""/>
        <!-- id устройств-источников, если на данном порту нужно обрабатывать пакеты только c определенных источников -->
        <param name="processAgentDeviceIds" value=""/>
        <!-- 1 - если нужно запретить сохранять и обрабатывать пакеты, в которых нет записей с IP-адресами из IP-ресурсов,
             2 - с учетом периодов IP-ресурсов -->
        <param name="ipResourceFilter" value=""/>
        <!-- Передача dataLogger -->
        <param name="dataLogger">flowDataLogger</param>
    </constructor>
</bean>
Каждый слушатель использует буферы памяти в direct memory, которая не находится в обычном heap java, общий размер которых можно расчитать как recvBufferSize (+ recvBufferSize) + threadCount * datalog.flow.chunk.size(datalog.chunk.size). Direct memory может использоваться также другими слушателями, а также при обработке логов. При превышении доступной памяти произойдет ошибка java.lang.OutOfMemoryError: Direct buffer memory. В старых билдах JRE MaxDirectMemorySize по умолчанию ограничен 64МБ, в новых - ограничен размером свободной оперативной памяти. Для того, чтобы указать конкретное значение, используется параметр в строке запуска -XX:MaxDirectMemorySize.

Обычно достаточно оставить параметр agentDeviceIds пустым, что будет означать, что поток будет приниматься со всех устройств-источников, начиная от корневого устройства Accounting-сервера. Однако в ситуации, когда с одного IP-адреса приходит два потока с разных источников, чтобы Accounting корректно разделял данные на два источника, необходимо создать два устройства-источника с одним и тем же IP-адресом и добавить два слушателя на двух разных портах и в agentDeviceIds одного прописать первый источник, во втором - второй. Таким образом трафик, идущий с одного и того же адреса на один порт будет считаться как трафик с одного источника, на другой порт - с другого источника.

В конфигурации типа устройства-источника (или в конфигурации устройства) необходимо указать какой поток идет с источника:

#Тип источника, netflow, netflow9(IPFIX/Next Gen NetFlow) или sflow
#по умолчанию - netflow
flow.agent.type=netflow
Для тарификации по Netflow9/IPFIX/Next Gen NetFlow в шаблоне должны присутствовать следующие поля:
IN_BYTES, PROTOCOL, SRC_TOS, L4_SRC_PORT, IPV4_SRC_ADDR, INPUT_SNMP, L4_DST_PORT, IPV4_DST_ADDR, OUTPUT_SNMP, IPV4_NEXT_HOP, LAST_SWITCHED, FIRST_SWITCHED, IPV6_SRC_ADDR, IPV6_DST_ADDR

Когда сессия стартует на каком-либо устройстве, по умолчанию считается, что это устройство и есть источник flow потока для данной сессии. Например, когда устройство одновременно является NAS’ом и источником netflow.

В схеме, когда flow-сенсор находится выше, необходимо указать для каждого устройства (например, NAS’а) привязку к источнику. Например, источник - это устройство с кодом 3. В конфигурации устройства-NAS’а прописываем, что трафик с любого интерфейса источника 3 может принадлежать сессии с данного NAS’а:

flow.agent.link=3:-1

Или, трафик с интерфейсов 1 или 2 может принадлежать сессии с данного NAS’а. Т.е. flow пакеты даже с таким же IP-адресом, как у сессии, но с другим интерфейсом, привязаны к ней не будут.

flow.agent.link=3:1,2

Для того, чтобы указать, что устройство является источником для всех своих дочерних устройств, достаточно в конфигурации типа устройства-источника прописать:

flow.agent.link={@deviceId}:-1
При использовании InetFlowListener возможна схема, когда будет множество устройств-коммутаторов с интерфейсами, которые никак не связаны с Flow-агентом и поэтому у них не указан в конфигурации flow.agent.link. Исторически сложилось, что если параметр flow.agent.link не указан, то устройство само считается Flow-агентом с указанными интерфейсами. Для экономии памяти рекомендуется указать для таких устройств flow.agent.link={@deviceId}:-1.

Если необходимо исключить из сохранения и обработки пакеты, в которых отсутствуют записи с IP-адресами, принадлежащими одному из заведенных диапазонов IP-ресурсов, в inet-accounting.xml для слушателя нужно указать параметр <param name="ipResourceFilter" value="1"/>, или же глобально (т.е. для всех слушателей) - в конфигурации модуля:

# Фильтр flow пакетов:
# 0 (по умолчанию) - не фильтровать, 1 - не сохранять и не обрабатывать пакеты, в которых нет записей с IP-адресами из IP-ресурсов,
# 2 - то же самое, что 1, но с учетом периодов IP-ресурсов.
flow.ipResourceFilter=1

Экспорт данных в CSV (Netflow/sFlow, NAT logging)

Для проверки, отладки или других целей существует возможность экспортировать данные по трафику из лог-файлов .bgdl/.data. Для этого необходимо выполнить консольную команду ./accounting.sh flowExport, например:

./accounting.sh flowExport -s 2 -h 2013-10-17-22 -tFmt "dd.MM.yyyy HH:mm:ss" -f flows.csv

Возможные параметры:

  • -s - ID устройства - источника данных (source_ID);

  • -h - фильтр по одному часу, формат ГГГГ-ММ-ДД-ЧЧ, например, 2013-10-17-22;

  • -tFrom - фильтр по периоду, начало периода, формат ГГГГ-ММ-ДДTЧЧ:ММ:СС, символ T - латинский;

  • -tTo - фильтр по периоду, конец периода, формат ГГГГ-ММ-ДДTЧЧ:ММ:СС, символ T - латинский;

  • -i - фильтр по интерфейсам, через запятую, например 1,4,7,41;

  • -r - фильтр по одному IP-адресу или диапазону IP-адресов, например, 192.168.0.1 или 192.168.0.1-192.168.0.24;

  • -f - имя файла, в который будет сохранен вывод;

  • -tFmt - формат времени в выводе, например, dd.MM.yyyy HH:mm:ss;

  • -dir - корневая директория с flow-логами, по умолчанию используется значение параметра datalog.flow.dir, т.е. та директория, в которую сохраняет логи InetAccounting;

  • -maxSort - кол-во выбранных записей для одного лог-файла, когда сортировку по времени нужно прекратить (для экономии памяти);

  • -writeIfaces - будет ли выводиться значения интерфейсов в CVS (1 или 0);

  • -tZone - зона (если данные сохранены в одной зоне, а запускаете flowExport с машины в другой зоне).

Минимально необходимые для выполнения параметры - id источника данных (-s) , фильтр по времени (-h или -tFrom/-tTo), путь до файла результата (-f), например:

./accounting.sh flowExport -s 2 -tFrom 2014-01-01T00:00:00 -tTo 2014-01-31T23:59:59 -f 2014-01.csv -tFmt "yyyy-MM-dd HH:mm:ss"

Копия класса, производящего экспорт также находится в динамических классах - ru.avantis.abilling.modules.inet.dyn.accounting.detail.FlowExport. Его можно модифицировать под свои нужды и запустить командной:

./accounting.sh dynClassRun ru.avantis.abilling.modules.inet.dyn.accounting.detail.FlowExport -s 1 -h 2013-11-20-13 -f 2013-11-20-13.csv

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

Команды, указанные выше, запускают экспорт внутри запущенного процесса InetAccounting. При необходимости Вы можете запустить экспорт отдельным процессом:

${JAVA_HOME}/bin/java -cp lib/app/*:lib/ext/* ru.avantis.abilling.modules.inet.accounting.detail.FlowExport -dir /dir/to/netflow/logs -s 2 -tFrom 2014-01-01T00:00:00 -tTo 2014-01-31T23:59:59 -f 2014-01.csv -tFmt "yyyy-MM-dd HH:mm:ss"

В этом случае также необходимо указать параметр -dir, т.к. значение параметра datalog.flow.dir при таком запуске недоступно.

Cisco NAT high-speed logging (HSL), Ericsson (Redback) SmartEdge NAT logging и MikroTik NAT log

Модуль Inet поддерживает логирование NAT Cisco NAT HSL, SE NAT logging и MikroTik NAT log, осуществляющееся с помощью Netflow9/IPFIX/Next Gen NetFlow. Для сохранения NAT-логов достаточно настроить прием/сохранение Netflow9.

Для получения информации по NAT-логам необходимо выполнить консольную команду ./accounting.sh natLogExport, например:

./accounting.sh natLogExport -s 1320 -tFrom 2014-08-09T14:02:00 -tTo 2014-08-09T16:03:00 -a 95.94.51.35 -f flow_nat.csv -tFmt "dd.MM.yyyy HH:mm:ss.SSS"

Возможные параметры:

  • -s - ID устройства - источника данных (source_ID);

  • -h - фильтр по одному часу, формат ГГГГ-ММ-ДД-ЧЧ, например, 2013-10-17-22;

  • -tFrom - фильтр по периоду, начало периода, формат ГГГГ-ММ-ДДTЧЧ:ММ:СС, символ T - латинский;

  • -tTo - фильтр по периоду, конец периода, формат ГГГГ-ММ-ДДTЧЧ:ММ:СС, символ T - латинский;

  • -a - внешний IP-адрес;

  • -p - внешний порт;

  • -f - имя файла, в который будет сохранен вывод;

  • -tFmt - формат времени в выводе, например, dd.MM.yyyy HH:mm:ss;

  • -dir - корневая директория с flow-логами, по умолчанию используется значение параметра datalog.flow.dir, т.е. та директория, в которую сохраняет логи InetAccounting;

  • -tZone - зона (если данные сохранены в одной зоне, а запускаете flowExport с машины в другой зоне).

Минимально необходимые для выполнения параметры - -s, -h или -tFrom/-tTo, -f, например:

./accounting.sh natLogExport -s 1320 -h 2014-08-09-15 -f flow_nat.csv

При необходимости Вы можете запустить экспорт отдельным процессом:

${JAVA_HOME}/bin/java -cp lib/app/*:lib/ext/* ru.avantis.abilling.kernel.network.datalog.netflow.nat.NatLogProcessor -dir /dir/to/netflow/logs -s 1320 -tFrom 2014-08-09T14:02:00 -tTo 2014-08-09T16:03:00 -a 95.94.51.35 -f flow_nat.csv -tFmt "dd.MM.yyyy HH:mm:ss.SSS"

В этом случае также необходимо указать параметр -dir, т.к. значение параметра datalog.flow.dir при таком запуске недоступно.