Зачем DevOps-инженеру настраивать мониторинг?

Вчера на вебинаре немного коснулись вопроса инструментов мониторинга.

На курсе мы разбираем мониторинг на приеме Prometheus, Grafana и EFK (кстати, как раз вчера был разбор практики). Я считаю, что это вполне выглядит как стандарт для индустрии DevOps, хотя нельзя сказать, что использование Victoria Metrics этому противоречит.

Хорошая практика — попробовать поработать с каждым инструментом и, хотя они достаточно совместимы, узнать особенности каждого из них. В каких случаях следует использовать VM стек? При какой нагрузке получится получить экономию ресурсов? А может просто использовать Victoria Mertrics как хранилище, в котором агрегируются метрики с нескольких Prometheus?

Также невозможно обойти стороной следующее: в проектах вопросы мониторинга часто откладываются на потом. Сначала запускается MVP, а потом уже надо искать способы реализации мониторинга, выполнять проработку архитектуры решения. Я думаю, что, с большой вероятностью, система логирования тоже не будет работать так, как хочется — от разного формата логов и его детализации.

Все эти процессы, может, и настраиваются в последнюю очередь, но по важности они точно одни из первых. Имеет значение сам процесс: мы делаем мониторинг и логирование не для того, чтобы узнать о проблеме ночью и быстрее починить, а для того чтобы коллеги SRE и разработчики быстрее получали фидбек о том, что приложение изменило свое поведение.

Что именно следует смотреть — это уже отдельная тема, о ней Кирилл Борисов в своем канале рассказывает, а я читаю и соглашаюсь с ним. Мониторинг — это не просто сбор метрик, а основа для процесса разработки и построения надежной инфраструктуры. Обязанность DevOps-инженера — знать, как правильно построить такие решения и как связать разные команды работой с инструментами мониторинга, чтобы в итоге система работала лучше.