Документация NetAMS (Автор) - страница 81
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, входящй с дистрибутив. Как им пользоваться — очевидно из его интерфейса. Пара скриншотов:
