Выкатить мало — нужно видеть последствия. Это живой дашборд: сервис шлёт метрики, Prometheus их собирает, Grafana рисует. Устрой инцидент — всплеск трафика, деплой с багом или утечку памяти — и смотри, как загорается алерт, а откат возвращает всё в норму.
Финал пути «с нуля до DevOps». Откуда берутся метрики и деплои → конструктор CI/CD. Незнакомые слова → словарь внизу.
Стабильная работа: ~100 req/s, быстрый отклик, почти нет ошибок.
✓ Всё в норме — порогов никто не превысил.
Метрики сервиса Prometheus «скрейпит» по расписанию (pull), Grafana их рисует. Превысил порог дольше «for» — Alertmanager будит дежурного. Сломал «деплоем с багом» → откати → метрики восстановятся. Это и есть цикл обратной связи после деплоя.
Числа во времени: RPS, задержка, ошибки, CPU. Дёшево хранить, удобно строить графики и пороги.
Отвечает: СКОЛЬКО и КАК БЫСТРО — «что-то не так прямо сейчас».
Инструмент: Prometheus + Grafana
Текстовые записи событий: что именно произошло, с какой ошибкой, по какому запросу.
Отвечает: ЧТО конкретно случилось — детали инцидента.
Инструмент: Loki / ELK
Путь одного запроса через все сервисы с таймингами каждого шага.
Отвечает: ГДЕ по пути запроса застряло — какой сервис тормозит.
Инструмент: Jaeger / Tempo
Сам ходит к сервисам и СОБИРАЕТ метрики (pull-модель), хранит как временные ряды, считает правила алертов.
Рисует дашборды по метрикам из Prometheus и других источников — одним взглядом видно состояние.
Получает сработавшие алерты, группирует и шлёт в Telegram/почту/дежурному; гасит шум (silence).
Централизованный сбор и поиск логов — лёгкий, дружит с Grafana.
Распределённая трассировка: видно путь запроса через микросервисы и где задержка.
📖 Словарь: простыми словами
Встретил незнакомое слово выше — найди его здесь. Коротко — суть; разверни — подробное объяснение с аналогией.
Наблюдаемость (observability)способность понять, что внутри системы, по её сигналам
Не просто «мониторинг включён», а возможность ответить на новый вопрос о поведении системы по метрикам, логам и трейсам — даже на тот, который заранее не предусмотрели.
Три столпаметрики (сколько), логи (что), трейсы (где)
Метрики ловят «что-то не так» и дёшевы; логи объясняют детали конкретного события; трейсы показывают путь запроса через сервисы. Вместе дают полную картину.
Метрика / временной рядчисло, измеряемое регулярно во времени
Например «запросов в секунду» каждые 15с. Хранится как ряд точек (time series) — по нему строят графики, считают перцентили и пороги.
Скрейпинг (pull)Prometheus сам периодически опрашивает сервисы
Сервис отдаёт метрики на /metrics, а Prometheus сам ходит и забирает их по расписанию (pull). Не сервис «пушит», а монитор «вытягивает» — проще управлять и обнаруживать упавшие цели.
Перцентиль p95/p99задержка, хуже которой лишь 5%/1% запросов
Среднее обманчиво: пара медленных запросов теряется в нём. p95 = «95% запросов быстрее этого». По хвостам (p95/p99) видно реальную боль пользователей.
Правило алерта (alert rule)условие, при котором будит дежурного
Например «ошибки > 5% в течение 1 минуты». Важно условие «в течение» — чтобы единичный всплеск не поднимал ложную тревогу. Сработало → Alertmanager уведомляет.
SLI / SLOпоказатель качества и цель по нему
SLI — измеримый показатель (доля успешных запросов, задержка). SLO — целевое значение (99.9% успешных за месяц). По SLO выбирают, какие алерты действительно важны для пользователя.
Цикл обратной связидеплой → наблюдай → реагируй → следующий деплой
Наблюдаемость замыкает CI/CD: после выката метрики показывают эффект; плохо — откат/фикс; данные из прода питают следующие изменения. Без неё деплой — это «выкатил и молись».
Дальше по теме
Эти инструменты связаны с текущим — так задачи стыкуются на практике.
Все инструменты — в каталоге.