Какие системы мониторинга использовали?
Что проверяют
Не список названий, а понимание, что мониторинг это метрики, логи и трассировки, и что за каждым инструментом стоит своя модель данных.
Как отвечать
Разложите по слоям и скажите, что использовали лично.
Метрики. Prometheus с Grafana. Плюсы: своя модель pull, PromQL, дешёвое хранение числовых рядов, стандарт для Kubernetes. Минусы: одна нода без федерации или Thanos, долгое хранение неудобно, высокая кардинальность меток убивает память.
Логи. Loki или ELK. Loki дешевле, потому что индексирует только метки, а не содержимое, и хорошо ложится на Grafana. ELK мощнее в поиске, но заметно тяжелее по ресурсам и требует ухода за индексами.
Трассировки. Jaeger или Tempo поверх OpenTelemetry. Отвечают на вопрос, где именно в цепочке сервисов ушло время, чего метрики не показывают.
Алерты. Alertmanager: группировка, подавление, дежурства. Главное правило, алерт должен требовать действия, иначе на него перестают смотреть.
> «У нас Prometheus и Grafana на четыре сервиса, алерты по симптомам, а не по причинам: пятисотки и задержка на девяносто девятом перцентиле. После перехода с алертов по загрузке процессора число ночных срабатываний упало втрое».
Где спотыкаются
Перечисляют инструменты, но не могут сказать, чем pull отличается от push и почему это важно.
Настраивают алерты по ресурсам вместо симптомов и получают шум, который все игнорируют.
Не знают про кардинальность меток, а это главная причина, по которой Prometheus падает по памяти.
Смешивают мониторинг и наблюдаемость: первый отвечает на известные вопросы, вторая помогает задавать новые.