История страницы

В модуле Inet возможно переобработать логи. В результате переобработки меняется количество трафика на сессиях. Эта необходимость может возникнуть в тех случаях, когда что-то было настроено неверно, например привязка трафиков и нужно это исправить задним числом. Обработать можно radius и netflow-логи. Сделать это можно на вкладке "Логи":

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

Есть данные - означает наличие логов за конкретный час;

...

Удалить задание на пересоздание сессий(текущее устройство) - удаление задания на пересоздание сессий для выбранного дня.

Оперировать (добавлять и удалять из обработки ) можно только дниднями. Это связанно связано с особенностью работы модуля inet. Следует учитывать, что обработка текущего дня приостанавливает процессы обсчета текущих сессий и , поэтому , стоит прибегать к этому только тогда, когда это действительно необходимо. При этом, если произойдет split сессий во время переобработики переобработки (split сессий происходит на границе суток и например при активации тарифной опции на договоре ), то детализация сессии может потеряться и чтобы ее получить потребуется повторная переобработка. Поэтому лучше дождаться следующего дня и запустить сегодняшний день задним числом.

...

1) Один собирающий логи accounting-сервер. netflow Netflow и radius Radius могут идти с разных устройств, могут с одного . Если netflow и radius идет с одного устройства, то типы трафика должны быть различными для netflow и radius (иначе они будут перетирать друг - друга). Для разных устройств можно заводить одинаковые типы трафика.

2) 2 accounting-сервера, собирающих логи ( например, один собирает netflow, другой radius) . netflow Netflow и Radius обязательно идут с разных устройств, причем коренные устройства этих accounting-серверов (значение параметра rootDeviceId в xml-конфигурации приложений) должны указывать у каждого на разные объединяющиеся устройства, которые не являются предками друг друга друга. Типы трафика для устройств netflow и radius могут быть разными, могут одинаковыми, это значения не имеет, так как в случае разных устройств они не пересекаются. В этом случае каждый accouning-сервер обрабатывает только те задачи, которые добавлены для устройств, являющихся предками его корня ( значение параметра rootDeviceId в xml-конфигурации приложений ). Тут важно, чтобы не было пересечений, иначе чужой accounting-сервер может удалить всю детализацию по устройству, если логи этого устройства находятся на другом accounting- сервере.

В общем случае еще могут быть accounting сервера, не собирающие логи. В этом случае у них в настройке должно стоять:

<param name="processLogs" value="false" /> 

По умолчанию там true. Аналогично так можно пометить сервера, собирающие логи, но игнорирующие задания на их переобработку. Схема с общим устройством для netflow и radius и 2-ми мя accounting-серверами, собирающими логи (один собирает netflow, другой radius)- не поддерживается. В этом случае результаты переобработки логов не предсказуемынепредсказуемы (возможно, что один accountig-сервер будет перетирать работу другого). Такая схема запрещена к настройке.

...

<!-- обрабатывать radius-логи >
<param name="processRadiusLogs" value="true" />
<!-- обрабатывать netflow-логи >
<param name="processFlowLogs" value="true" />

По умолчанию эти опции имеет имеют значение true. Рассмотрим случай: Accounting accounting-сервер собирает radius-логи и , считает по ним сессии , и у него подключена папочка директория с netflow-логами ( другого коллектора ) для детализации. Тогда имеет смысл отключить обработку netflow-логов. Ну и вообще желательно Желательно отключать все лишнее. Если, если например, какие-то логи не собираются вообще, то нужно их отключить. 

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