Самый популярный вопрос на собеседованиях DevOps:  “Как у вас устроен мониторинг в проекте?”

И многие отвечают слишком коротко:  

Prometheus, Grafana, CloudWatch.

Ответ вроде правильный.  

Но для сильного собеседования этого мало.

Интервьюеру обычно важно понять не просто названия инструментов, а всю цепочку:

– как собираются логи  

– куда они попадают дальше  

– как долго хранятся  

– как собираются метрики  

– как считается SLA  

– и почему архитектура сделана именно так  

Именно это показывает разницу между человеком, который просто пользовался готовым стеком, и тем, кто реально поднимал мониторинг в production.

Например, в enterprise-проекте на EKS мониторинг может выглядеть так:

Есть два типа нагрузок:

– микросервисы на Fargate  

– stateful-приложение в StatefulSet  

И подход к ним разный.

Для Fargate удобно использовать OpenTelemetry add-on.  

Он автоматически собирает логи со всех Fargate-подов и отправляет их в CloudWatch. Это простой и удобный вариант, когда не хочется отдельно городить сбор логов внутри каждого сервиса.

Для StatefulSet чаще нужен более гибкий контроль.  

Тут можно использовать Fluent Bit как sidecar-контейнер:

он читает логи из общего тома, фильтрует их, форматирует и отправляет в CloudWatch.

Это особенно важно в банках и других регулируемых системах, где есть требования к структуре логов, аудиту и хранению данных.

Дальше пайплайн может быть таким:

CloudWatch → Lambda для форматирования → Kinesis Firehose → OpenSearch

Зачем это нужно:

– Lambda может нормализовать и обогащать логи  

– Firehose умеет батчить и стабильно доставлять данные  

– OpenSearch удобен для поиска и анализа  

– S3 подходит для долгого и дешёвого хранения  

Пример хранения:

– 7 дней в OpenSearch  

– 30 дней в CloudWatch  

– полный архив в S3  

С метриками история другая.

Обычно используют Prometheus, который ходит в `/metrics` каждого приложения, например каждые 30 секунд.

Чтобы Prometheus понимал, что именно скрейпить в Kubernetes, для сервисов настраивают `ServiceMonitor`.

Дальше Grafana показывает всё в дашбордах.

Хорошая практика – свести в Grafana сразу несколько источников:

– Prometheus для технических метрик  

– CloudWatch для инфраструктуры и логов  

– OpenSearch для поиска по событиям и ошибкам  

Тогда в одном месте можно увидеть:

– CPU и memory  

– latency и error rate  

– логи по времени инцидента  

– состояние сервиса по SLA  

И вот тут начинается взрослая часть мониторинга.

SLA – это не абстрактная цифра на слайде.  

Это конкретный лимит простоя.

Например, 99.1% uptime в месяц означает, что сервис может быть недоступен примерно 6.4 часа за месяц.

Если это вынесено в Grafana, то и команда, и бизнес видят состояние системы в реальном времени, а не узнают о проблеме постфактум.

Поэтому на собеседовании лучше рассказывать не просто набор инструментов, а целую историю:

не “у нас Prometheus и Grafana”,  

а “вот как у нас собираются логи, вот куда они идут, вот почему выбран именно такой маршрут, вот как мы храним данные, вот как считаем SLA и что видит бизнес”.

Именно такой ответ звучит как опыт production-уровня.