Методика определения причины отсутствия трафика в отчете договора
Материал из BiTel WiKi
Исходные данные - на клиента добавлены некоторые адреса, но отчет по трафику упорно пуст.
1. Необходимо выгрузить первичный NetFlow лог источника к которому привязан клиент за какой-либо час. Для примера код источника 10, час - 12 первого мая 2008 года.
./netflow.sh save 10 2008-05-01-12 /tmp/log_spica
2. С помощью команды grep выделяем записи, относящиеся к нашему клиенту.
cat /tmp/log_spica | grep "X\.X\.X\.X"
Убеждаемся, что записи в исходных данных есть. Если их нет - следует проверить источник данных (настройки экспорта на роутере).
3. Переводим обработчик коллектора в DEBUG режим, правим файл log4j_netflow_ipn.properties таким образом (меняется INFO на ALL):
log4j.logger.dataloader=ALL, A1 ....
4. Инициируем обработку лога:
./netflow.sh isload 10 2008-05-01-12
5. Смотрим dataloader.log, ищем там сообщения по нашему адресу (перевести адрес в десятичный формат можно утилитой Утилиты=>IP калькулятор): Вместо A1,2 I1,2 P1,2 в логе будут конкретные адреса интерфейсы и порты отправителя и получателя пакета из исходного лога. 96 - количество переданных байт (для примера)
DEBUG 07.05.2008 20:20:17 Process line I1 A1 P1 I2 A2 P2 96 DEBUG 07.05.2008 20:20:17 Find any iface list DEBUG 07.05.2008 20:20:17 addr=A1; range.start=0; range.end=-1 DEBUG 07.05.2008 20:20:17 addr=A2; range.start=0; range.end=0 DEBUG 07.05.2008 20:20:17 Found receive client DEBUG 07.05.2008 20:20:17 LINE 46813;20;101;96 DEBUG 07.05.2008 20:20:17 addAmount 125647_853_101 => 96
Для данного пакета найден клиент - получатель пакета (Found receive client). Строка LINE 46813;20;101;96 означает, что согласно 46813 строке исходного лога по 20 правилу из привязок услуг сопоставлена 101 услуга в объеме 96 байт. Далее addAmount 125647_853_101 => 96 обозначает, что договору с кодом 125647 и его диапазону адресов с кодом 853 сопоставлена услуга с кодом 101 в количестве 96 байт.
Обратите внимание на фразу Found receive client, она означает попытку поиска адреса с интерфейсом ANY. При обработке каждого пакета, согласно алгоритму из документации, сначала ищется клиент-отправитель пакета а затем клиент-получатель. Причем при каждом поиске сначала ищется клиент на конкретном интерфейсе, а затем, если он не найден, на интефейсе ANY.
Исходя из этого по данному логу можем сказать, что клиент-отправитель не был найден ни на конкретном интефрейсе ни на ANY. А вот получатель привязан к источнику с конкретным интерфейсом, раз фраза Find any iface list отстутсвует.
Теперь мы можем найти клиенту, на которого начислен трафик запросом в Сервис=>SQL Редактор:
SELECT * FROM contract WHERE id=125647
6. В заключении не забудьте перевести лог dataloader.log обратно в режим INFO, т.к. постоянное подробное логирование очень сильно снижает скорость обработки.
