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

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

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

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

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

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

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

Коллеги, приветствую!

Сегодня пятница, а значит, время историй. На прошлой неделе я рассказывал вам про конференцию и доклад, который я для нее готовлю. В процессе подготовки я решил, что будет полезно сходить на дополнительное обучение (и, собственно, пошел на него).

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

Что скажете?

Сегодня на Deckhouse Conf, пришел узнать, как поживает отечественный кубернетес, послушать про безопасность и другие интересные вопросы.

Кто тоже тут, ставьте 🔥

Нашел интересное: Deckhouse Prom++, отечественный форк прометеуса, который потребляет намного меньше ресурсов. Очень хочу попробовать.

Слушаю доклад Дмитрия Евдокимова про про стандарт безопасности NIST. Наверное, один из самых интересных докладов на конфе.