(Опционально) обновить 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–заголовка в индекс потока, т.е. трафик «запроса» и «ответа» попадет в разные потоки и длина «ответа», т.е. фактически скаченной по данному запросу информации, в таблице мониторинга не учтется. Изменить такое поведение технически очень непросто.