Методика определения причины отсутствия трафика в отчете договора
Материал из BiTel WiKi
Admin (Обсуждение | вклад) (Новая: Исходные данные - на клиента добавлены некоторые адреса, но отчет по трафику упорно пуст. 1. Необходим...) |
Admin (Обсуждение | вклад) |
||
(2 промежуточные версии не показаны) | |||
Строка 17: | Строка 17: | ||
log4j.logger.dataloader=ALL, A1 | log4j.logger.dataloader=ALL, A1 | ||
.... | .... | ||
+ | </pre> | ||
+ | Для версии 4.6 и старше: правим файл log4j-collector-ipn.xml | ||
+ | <pre> | ||
+ | <root> | ||
+ | <priority value="DEBUG" /> | ||
+ | <appender-ref ref="ASYNC" /> | ||
+ | </root> | ||
</pre> | </pre> | ||
Строка 43: | Строка 50: | ||
Обратите внимание на фразу '''Found receive client''', она означает попытку поиска адреса с интерфейсом ANY. При обработке каждого пакета, согласно алгоритму из документации, | Обратите внимание на фразу '''Found receive client''', она означает попытку поиска адреса с интерфейсом ANY. При обработке каждого пакета, согласно алгоритму из документации, | ||
сначала ищется клиент-отправитель пакета а затем клиент-получатель. Причем при каждом поиске сначала ищется клиент на конкретном интерфейсе, а затем, если он не найден, на интефейсе ANY. | сначала ищется клиент-отправитель пакета а затем клиент-получатель. Причем при каждом поиске сначала ищется клиент на конкретном интерфейсе, а затем, если он не найден, на интефейсе ANY. | ||
+ | |||
+ | {| | ||
+ | |- valign=top | ||
+ | | [[Изображение:Ipn_process_alg.png|thumb|300px|Алгоритм обработки трафика]] | ||
+ | |} | ||
+ | |||
Исходя из этого по данному логу можем сказать, что клиент-отправитель не был найден ни на конкретном интефрейсе ни на ANY. А вот получатель привязан к источнику с конкретным | Исходя из этого по данному логу можем сказать, что клиент-отправитель не был найден ни на конкретном интефрейсе ни на ANY. А вот получатель привязан к источнику с конкретным |
Текущая версия на 12:31, 23 ноября 2009
Исходные данные - на клиента добавлены некоторые адреса, но отчет по трафику упорно пуст.
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.6 и старше: правим файл log4j-collector-ipn.xml
<root> <priority value="DEBUG" /> <appender-ref ref="ASYNC" /> </root>
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, т.к. постоянное подробное логирование очень сильно снижает скорость обработки.