Comments 4
Несколько минут тупил, пытаясь понять логику работы «всего в целом». Понял следующее:
1. Периодически запускаем скрипт, который скачивает фрагмент данных из Интернета.
2. Параллельно с п. 1 на этом же хосте запускаем tshark для определения количества ошибок/аномалий tcp.
3. Выводим эти данные на графики посредством Cacti.
Вижу один минус — сайт в п. 1 всякий раз один и тот же. Можно сделать несколько разных, но сути не меняет — нерепрезентативно.
Я бы, наверное, вместо скрипта из п. 1 оборудовал зеркальный порт для всего трафика нашей сети и периодически снимал бы с него данные тем же tshark-ом. Дальше — как в статье.
И вопросы: на картинках реальные графики? Какие выводы можно из них делать (типа, какие значения должны быть в нормальной ситуации, а когда уже пора чинить сеть)?
1. Периодически запускаем скрипт, который скачивает фрагмент данных из Интернета.
2. Параллельно с п. 1 на этом же хосте запускаем tshark для определения количества ошибок/аномалий tcp.
3. Выводим эти данные на графики посредством Cacti.
Вижу один минус — сайт в п. 1 всякий раз один и тот же. Можно сделать несколько разных, но сути не меняет — нерепрезентативно.
Я бы, наверное, вместо скрипта из п. 1 оборудовал зеркальный порт для всего трафика нашей сети и периодически снимал бы с него данные тем же tshark-ом. Дальше — как в статье.
И вопросы: на картинках реальные графики? Какие выводы можно из них делать (типа, какие значения должны быть в нормальной ситуации, а когда уже пора чинить сеть)?
— Максим почему всякий раз один и тот же сайт? В данном случае с GUI Cacti при добавлении нового графика указывается адрес страницы вот скрин — https://hsto.org/web/654/316/0e5/6543160e5282454b95b26133d4cfe004.jpg. Каждый график — свой сайт.
— Графики реальные, по TCP ошибкам пока в стадии наблюдения, не было возможности проверить при каких то негативных событиях. По web speed, как раз таки на графике видно снижение скорости, админ сайта подтвердил снижение производительности ввиду проводимых работ.
— по зеркалированию всего трафика, идея интересная, если трафика не много и коррелировать данные по скорости и ошибкам не нужно.
— Графики реальные, по TCP ошибкам пока в стадии наблюдения, не было возможности проверить при каких то негативных событиях. По web speed, как раз таки на графике видно снижение скорости, админ сайта подтвердил снижение производительности ввиду проводимых работ.
— по зеркалированию всего трафика, идея интересная, если трафика не много и коррелировать данные по скорости и ошибкам не нужно.
Вот этот момент я и хотел уточнить — на графике мы видим не число TCP-ошибок в сети вообще, а число ошибок при доступе к данному конкретному сайту.
Если мы хотим получить картину «по Интернету в целом» — нужно волевым решением определить несколько сайтов в разных локациях, и отрисовать по ним графики. В нашей компании мы мониторим работу операторов приблизительно так же.
Если мы хотим получить картину «по Интернету в целом» — нужно волевым решением определить несколько сайтов в разных локациях, и отрисовать по ним графики. В нашей компании мы мониторим работу операторов приблизительно так же.
Открывая статью, ожидал снятие счётчиков из sysfs/procfs, трассировку perf/ftrace, на крайняк парсинг выхлопа утилит показа статистики. Но к такому меня жизнь не готовила :-)
Sign up to leave a comment.
Автоматизация IP-сети. Часть3 – Мониторинг TCP аномалий