monitor. В комплекте поставки NeTAMS идет «недоразвитый» скрипт, позволяющий как–то просматривать собранную информацию.
Как включить
Собрать и поставить новую версию NeTAMS
Скачать, как обычно, дистрибутив, распаковать, скомпилировать, установить. При компиляции по умолчанию сборка будет вестись с ключом–DLAYER7_FILTER. Не забудьте установить новые CGI–скрипты, особенно monitor.cgi.
Настроить сервис data–source
Пропишите в конфигурацию нужного сервиса новый параметр: layer7–detect urls
Создать новую политику учета
В конфигурации сервиса processor добавьте описание новой политики:
policy name urls target layer7–detect
Указать политику учета для тех юнитов, которые надо отслеживать
В конфигурации сервиса processor для нужных юнитов добавьте новую политику учета:
unit host name pupkin ip 172.16.1.3 acct–policy urls
или, для всех юнитов
default acct–policy urls
Настроить сервис мониторинга
Как описано в этом документе. Дополнительных действий не требуется. Специально указывать юниты, которые хочется мониторить на layer7, не требуется. Если же вас интересует полный мониторинг какого–то юнита (по–старому), тогда такой юнит указывать все же необходимо.
(Опционально) обновить SQL–таблицу сервиса monitor
Если вы использовали мониторинг ранее (таблица monitor уже существует), ее необходимо обновить:
mysql netams
alter table monitor add column layer7 varchar(80);
Запустить NeTAMS
Проверка работы
Работоспособность механизма мониторинга ссылок можно проверить командами:
#netamsctl show ds
host: localhost port: 20001 login: anton password: aaa
cmd: show ds
Data–source ID=1 type LIBPCAP source xl1:0 loop 82356480 average 35 mcsec
Perf: average skew delay 2676 mcsec, PPS: 1060, BPS: 904985
IP tree: 258 nodes [12] + 4 dlinks [1024] + 254 unodes [20] = 12272 bytes
Flows: 1644/2507 act/inact entries (796992 bytes), 3332872 flows sent
HASH: size=65536, 1644 flows hashed, 1622 nodes used, max chain= 2
FIFO: 0/1871 used/ready messages, each 152, total 284392 bytes
Libpcap xl1 : EN10MB: 83735013 packets received, 488394 dropped
Эта команда показывает, что data–source действительно получает трафик и выдает сервису processor информацию о прошедших потоках.
#netamsctl show monitor
host: localhost port: 20001 login: anton password: aaa
cmd: show monitor
service monitor 1
Monitoring to storage: 1
Units:
Packets monitored: 1985769
Эта команда показывает, что сервис мониторинга получает информацию о потоках и пишет ее в базу.
debug ds_ip
debug monitor
Покажет, определяются ли ссылки в проходящем трафике и идет ли присвоение атрибута LAYER7 информации о потоках.
mysql netams
select count(*) from monitor where layer7 != NULL;
Показывает, сколько строк собралось в таблице мониторинга с информацией о ссылках.
Проблемы
• Мониторинг в SQL базу активно пожирает дисковое пространство! Например, за неделю работы программы, при общем количестве прошедшего трафика порядка 40 гигабайт (82 миллиона пакетов), в таблице мониторинга образовалось 2 миллиона записей). Размер SQL–таблицы и индекса составляет 240 мегабайт.
• Статистика по трафику для записанных в мониторинге ссылок относится не с скаченной информации, а к запросам на скачивание. Т.е. не надо обращать на цифры большого внимания. К сожалению, это обусловленно нессимитричностью хэш–функции преобразования данных IP–заголовка в индекс потока, т.е. трафик «запроса» и «ответа» попадет в разные потоки и длина «ответа», т.е. фактически скаченной по данному запросу информации, в таблице мониторинга не учтется. Изменить такое поведение технически очень непросто.
Отображение статистики
Отображением статистики занимается скрипт monitor.cgi, входящй с дистрибутив. Как им пользоваться — очевидно из его интерфейса. Пара скриншотов:
