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

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

Версия 12:07, 7 мая 2008 (просмотреть исходный код) Admin (Обсуждение | вклад) ← Предыдущая правка		Текущая версия на 12:31, 23 ноября 2009 (просмотреть исходный код) Admin (Обсуждение | вклад)
(1 промежуточная версия не показана)
Строка 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>

---

Текущая версия на 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, т.к. постоянное подробное логирование очень сильно снижает скорость обработки.