Post #2136

🔥Что на самом деле хотят услышать на DevOps собесе На собеседованиях по 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-уровня. https://uproger.com/samyj-populyarnyj-vopros-na-sobesedovaniyah-devops-kak-u-vas-ustroen-monitoring-v-proekte/