Методика определения причины отсутствия трафика в отчете договора

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

(Различия между версиями)
Перейти к: навигация, поиск
(Новая: Исходные данные - на клиента добавлены некоторые адреса, но отчет по трафику упорно пуст. 1. Необходим...)
 
(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, т.к. постоянное подробное логирование очень сильно снижает скорость обработки.

Личные инструменты