Comments 15
У Brian Brazil был хороший блог по поводу мониторинга (с уклоном на Prometheus конечно).
И в книге он неоднократно упоминал что собрать миллионы метрик - много ума не надо, а вот как с этим работать - отдельная головная боль, и просто "давайте на всё настроим alert" - плохая идея.
Да и сама по себе книга "Prometheus Up & Running" содержит немало идей для раздумья
Можно еще посмотреть в сторону https://opentelemetry.io как попытку это все стандартизировать.
OpenTelemetry и т.п. закрывают малую часть задач мониторинга, в основном это всё крутится вокруг inject'а либ в приложение и сбора данных (транзакции, логи, метрики).
Но сбор/обработка трапов от сетевого оборудования или парсинг произвольных файлов для получения данных мониторинга никуда не денутся...
Попадалась статья про VictoriaMetrics. Как она в лучшую сторону отличается от того же Prometheus. Вот думаю попробовать хотя бы в качестве концепта.
Виктория прекрасно и стабильно работает, при этом сильно экономит место засчет сжатия и дедупликации и умеет в отказоустойчивость, чего чистый Прометей не умеет.
Я прям удивился почему Cortex и Thanos в статье есть, а Виктории нет.
В статье много чего нет, например, Elastic Common Schema или Loki.
Victoria вообще в продакшне у многих уже давно.
Но в целом основные проблемы мониторинга подсвечены - сложно, нужно все продумывать. От себя добавлю, что между опенсорс тулами и платным софтом - пропасть. Нет опенсорс CMDB, нет коррелятора событий нормального, да даже простого поиска аномалий нет (opensearch не в счёт).
никогда не приносит компании денег
Зато его отсутствие часто помогает деньги потерять :)
А такие решения как zabbix, nagios, icinga уже совсем не модные что ли?
Как-то вообще не подсвечено, где им место в этих схемах.
А я сталкиваюсь с такими системами постоянно. Prometheus - это же больше для контейнеров всяких, но не всё же строится на них.
Nagios и Icinga помирают медленно, но верно. В Европе распространён, правда, check_mk, который продолжает nagios-традиции.
А Zabbix - агентский/безагентский мониторинг, развивается и довольно широко применяется (хотя за пределами восточной европы не особо популярен кмк).
Не все задачи удобно/возможно закрыть Prometheu's ом.
Логи дают понять, что в точности происходит
По-моему, это фундаментальное заблуждение, которое и привело нас к тем системам мониторинга, которые мы имеем. Логи очень редко (почти никогда) дают понять, что “в точности происходит”. Даже сама суть слова “лог” прямо говорит — это исторические факты, а не песня акына об окружающей действительности. То есть, логи дают понять, что когда-то произошло, а не происходит здесь и сейчас. Они — форенсик-инструмент в руках расследователя (в действующей системе), или отладочный инструмент в руках разработчика (в создаваемой/развивающейся системе).
SIEM-системы не должны использоваться для мониторинга.
А мониторинговые системы должны опираться на такие средства, как, например, SNMP в сетях. Только вот единого набора OID, MIB и метрик для приложений до сих пор никто не придумал.
Так и метрики по snmp - это тоже о том, что происходило n времени назад. Выже не собираете снмп в реальном времени? А скорее циклом за н времени, с подсчетом того, что происходило между этими циклами. В логи в этом плане более стихийны и моментальны, и могут показать что происходит быстрее, при условии, что данные визуализирубися/подсчитываются достаточно "быстро"
Мониторинг через парсинг логов - это прямо типовой антипаттерн какой-то. Логи придуманы для отладки программистами. Для мониторинга - счётчики и системы трассировки. В последние можно, в том числе, и строки пихать, но обычно это не нужно, ещё в компонентах всё можно выразить через счётчики и не гонять через текст.
Мониторинг — это боль