Комментарии

Классная статья! Спасибо!
Чего не хватает:


  1. Блок-схема мониторинга в целом. Прометеус, сентри, графана — это уже не так интересно, все есть у самих ) А почему icinga? Почему, скажем, не Graphite поверх КХ, как в Контуре? У вас все в k8s? Т.е. все сервисы инструментированы? Или все-таки приходится тащить пачку экспортеров (ну, например, для мониторинга легаси сервисов или самих железок)?
  2. long-term prometheus. Очень плохое решение для долговременных данных, кмк, как решили проблему? Переливаете в заббикс/graphite/etc.? Или выделили отдельный инстанс прома, чтобы он отдавал данные в grafana?
  3. metrics-as-(a)-code и dashboards-as-(a)-code? Внедрили? Каков жизненный цикл метрики? Я сталкиваюсь с такой проблемой, что, например, сначала метрику неправильно назвали, а потом переименовали — все, исторический тренд по ней не сделать. Как решаете? Или то, что в процессе работы поняли, что метрика, например, не в тех единицах?

Что-то еще было, надо подумать )

Спасибо за комментарий и вопросы)
icinga — это из блока «так исторически сложилось», она появилась задолго до миграции в k8s и команда devops предпочла её как сравнительно простой инструмент для нотификаций.
Так что сервисы высыпают свои данные в prometheus либо он забирает их, а icinga уже наводит панику.

Про «long-term»: для этого используется ceph, проблем не испытываем уже очень давно.

По жизненному циклу метрик и корректировке вопрос отличный, но на моей памяти такого опыта не было: процесс создания новых метрик проходит такой же code review, как и любые другие изменения в коде, и если есть сомнения по наименованию, то они решаются до ввода в прод. Поэтому изменения почти всегда относятся к двум типам: правка трешхолдов в icinga (warning / alert / critical) и удаление метрики в случае если она утратила смысл.
Решать проблемы, а не затыкать тылы одеялом
Самая важная мысль, полностью поддерживаю
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.