Кризис мониторинга микросервисов

Традиционный мониторинг uptime спрашивает: «Отвечает ли ваш сайт?»

Современная микросервисная архитектура спрашивает: «Отвечают ли все 47 микросервисов и корректно ли отвечают друг другу?»

Микросервисная платформа состоит из десятков взаимосвязанных сервисов:

API Gateway → Auth Service → User Service → Database
             → Payment Service → Stripe
             → Notification Service → SendGrid
             → Reporting Service → Data Warehouse
             → Search Service → Elasticsearch
             → Cache → Redis

Если ЛЮБОЙ из них падает:

Auth Service лежит = никто не может войти
Payment Service лежит = клиенты не могут платить
Search Service лежит = клиенты не могут найти продукты
Redis-кэш лежит = система замедляется (каскадный сбой)

Традиционный uptime-мониторинг полностью пропускает эту сложность.

Почему мониторинг микросервисов отличается

1. Распределённые сбои

В монолитах сбой бинарный: работает или нет.

В микросервисах сбои частичные и каскадные:

Сценарий 1: Search Service медленный
  - Запросы к поиску занимают 10 секунд (обычно 200ms)
  - Frontend-запросы таймаутят, ожидая результаты поиска
  - Latency API-запросов вырастает в 10 раз
  - Пользователи видят «страница медленно грузится»
  - Не ловится простыми uptime-проверками (API технически отвечает)

Сценарий 2: Cache Service деградировал
  - Hit-rate Redis падает с 90% до 20%
  - БД получает в 4 раза больше запросов
  - CPU БД скачет до 100%
  - Все запросы замедляются (даже несвязанные)
  - Каскадный сбой по всей системе

Сценарий 3: сбой коммуникации между сервисами
  - Auth Service работает
  - User Service работает
  - Но сетевая проблема мешает связи Auth → User
  - Пользователи не могут войти
  - Оба сервиса показаны «работающими» в мониторинге

2. Специфические для Kubernetes сбои

Kubernetes добавляет сложности:

Цикл рестарта пода:
  - Под крэшится из-за утечки памяти
  - Kubernetes автоматически перезапускает под
  - Под перезапускается, не отвечает на трафик
  - Выглядит «работающим» (под существует), но не обслуживает запросы

Сбой ноды:
  - Нода Kubernetes падает
  - Шедулер переносит поды на другие ноды
  - Поды нормальные, но временно недоступны во время миграции
  - Кратковременные сбои запросов в переходе

Проблема деплоя:
  - В новом деплое баг при старте
  - Поды не запускаются
  - Существующие поды всё ещё обслуживают запросы
  - Система деградирует, но не полностью лежит

3. Сложность service mesh

С service mesh (Istio, Linkerd):

Service mesh добавляет ещё один слой:
  - Сервис → Sidecar → Сеть → Sidecar → Сервис
  - Sidecar может инжектить сбои (rate-limit, таймауты)
  - Circuit breaker может срабатывать (предотвращая запросы)
  - Балансировка может быть неравномерной (часть инстансов получает больше)

Мониторинг должен включать:
  - Здоровье sidecar
  - Статус circuit breaker
  - Распределение балансировки
  - Здоровье control plane service mesh

Архитектура мониторинга микросервисов

Уровень 1: доступность сервиса#

Мониторьте каждый сервис отдельно:

Auth Service:
  - Работает ли сервис? (количество подов > 0)
  - Отвечает ли на health-check? (GET /health возвращает 200)
  - Какое время отклика? (P95 &lt; 100ms)
  - Какая доля ошибок? (&lt; 0.1%)

Payment Service:
  - Работает ли сервис?
  - Отвечает? (GET /health)
  - Может ли связаться со Stripe? (Stripe отвечает)
  - Какой latency? (P95 &lt; 500ms)

Уровень 2: коммуникация между сервисами#

Мониторьте service-to-service связь:

Auth Service → User Service:
  - Может ли Auth достучаться до User? (сетевая связность)
  - Какой latency? (P95 &lt; 50ms)
  - Какая доля ошибок? (&lt; 0.01%)

User Service → БД:
  - Может ли User достучаться до БД? (здоровье пула соединений)
  - Исчерпан ли пул соединений? (ожидание соединений)
  - Какой latency запросов? (P95 &lt; 100ms)

Уровень 3: распределённое трейсирование транзакций#

Мониторьте полные потоки запросов:

Поток логина пользователя:
  1. API Gateway получает запрос логина
  2. Маршрутизирует в Auth Service (latency: 10ms)
  3. Auth Service запрашивает User Service (latency: 15ms)
  4. User Service запрашивает БД (latency: 20ms)
  5. Auth Service подписывает JWT (latency: 5ms)
  6. API Gateway возвращает ответ (latency: 2ms)

Общий latency: 52ms (приемлемо)

Если запрос к User Service занимает 500ms вместо 20ms:
  - Общий latency скачет до 532ms
  - Пользователь видит медленный логин
  - Производительность приложения деградирует
  - Мониторинг ловит корневую причину (медленный запрос User Service)

Уровень 4: мониторинг специфики Kubernetes#

Мониторьте инфраструктуру Kubernetes:

Здоровье подов:
  - Счётчик рестартов пода (алерт при > 5 за 24ч)
  - Использование памяти подом (алерт при приближении к лимитам)
  - Использование CPU подом (алерт при стабильном > 80%)

Здоровье нод:
  - Статус ноды (Ready, NotReady, Unknown)
  - Disk pressure ноды (алерт при заполнении > 85%)
  - Memory pressure ноды (алерт при доступной &lt; 10%)

Здоровье деплоя:
  - Желаемые vs готовые реплики (алерт при несовпадении)
  - Latency создания пода (алерт при > 30 секунд)
  - Ошибки image pull (алерт, если поды не стартуют)

Реальный кейс провала мониторинга микросервисов

Организация: FinTech-платформа с 30+ микросервисами, 50 подами Kubernetes

Архитектура:

API Gateway (5 реплик)
Auth Service (3 реплики)
Payment Service (5 реплик)
Notification Service (3 реплики)
Data Pipeline (2 реплики)
Кэш (Redis-кластер)
БД (PostgreSQL)

Инцидент: медленная обработка платежей

Хронология:

14:00: поды Notification Service рестартуют (утечка памяти)
14:05: создание подов Notification медленное (шедулер K8s перегружен)
14:10: запросы Payment → Notification таймаутят (сервис не отвечает)
14:10: Payment внедряет client-side retry (экспоненциальный backoff)
14:15: retry-storm каскадирует на API Gateway
14:15: API Gateway перегружен, очередь запросов растёт
14:20: все пользовательские запросы таймаутят
14:20: объявлен инцидент, дежурный инженер вызван

Что бы поймал мониторинг:

14:01: алерт «счётчик рестартов Notification превысил порог»
14:06: алерт «latency создания подов Notification > 30 сек»
14:07: алерт «health-check Notification падает»
14:08: алерт «скачок latency Payment → Notification»
14:09: алерт «скачок error rate Payment»

Ранние алерты могли бы предотвратить каскад: вручную перезапустить Notification или скорректировать retry-стратегию в Payment.

Реализация мониторинга микросервисов

Опция 1: DIY на Prometheus + Grafana#

Prometheus:
  - Скрейпит /metrics-эндпоинт каждого сервиса
  - Хранит метрики в time-series БД
  - Запускает alert-правила (если метрика превысила порог — алерт)

Grafana:
  - Визуализирует метрики из Prometheus
  - Дашборды на сервис
  - Per-service и cross-service дашборды

Реализация: open-source, бесплатно, требует знаний DevOps
Стоимость: низкая (только инфраструктура), высокая (инженерное время)
Подходит: командам с экспертизой DevOps

Опция 2: managed-сервис (Datadog, New Relic)#

Агент Datadog/New Relic:
  - Работает как sidecar в каждом поде
  - Собирает метрики, логи, трейсы
  - Шлёт в managed-сервис

Дашборд:
  - Готовые дашборды для Kubernetes
  - APM для коммуникации сервисов
  - Distributed tracing встроен

Реализация: вендорский инструмент, сложная конфигурация, мощно
Стоимость: высокая (per-host/per-GB), низкая (инженерное время)
Подходит: командам с бюджетом, меньшей ops-экспертизой

Опция 3: service mesh со встроенным мониторингом#

Istio/Linkerd:
  - Sidecar-прокси перехватывает всю коммуникацию
  - Автоматически трекает latency, ошибки, трафик
  - Даёт observability без изменений кода

Мониторинг:
  - Дашборды service mesh показывают зависимости сервисов
  - Статус circuit breaker
  - Распределение трафика
  - Latency запросов на маршрут

Реализация: изменение на уровне инфры, мощно, но сложно
Стоимость: накладные расходы инфры (CPU/память sidecar)
Подходит: крупным организациям с большим числом сервисов

Чек-лист мониторинга микросервисов

По каждому сервису

☐ Реализован health-check эндпоинт (/health возвращает 200, когда здоров)
☐ Эндпоинт метрик открыт (/metrics для Prometheus-скрейпа)
☐ Доступность сервиса мониторится (под работает, health-check проходит)
☐ Время отклика мониторится (отслеживается P95 latency)
☐ Доля ошибок мониторится (4xx, 5xx)
☐ Логи централизованы (ELK, Splunk и т. п.)

По каждой service-коммуникации#

☐ Latency между сервисами (сервис A → сервис B)
☐ Доля ошибок per service-коммуникация
☐ Статус circuit breaker (если есть)
☐ Обработка таймаутов проверена (правильная retry-логика)

По каждому Kubernetes-кластеру#

☐ Здоровье подов (счётчик рестартов, память, CPU)
☐ Здоровье нод (статус, диск, память)
☐ Здоровье деплоя (желаемые vs готовые реплики)
☐ Здоровье persistent volume (доступное место, I/O-ошибки)
☐ Использование ресурсов namespace (CPU, лимиты памяти)

Distributed tracing#

☐ Трейсы запросов собираются (request ID пропагируется через сервисы)
☐ Доступна визуализация трейсов (видно поток запроса)
☐ Видна разбивка latency трейса (какой сервис медленный?)
☐ Детекция ошибок трейса (какой сервис упал?)

Лучшие практики мониторинга микросервисов

1. Correlation ID для distributed tracing

У каждого запроса должен быть уникальный ID, пропагируемый через все сервисы:

Запрос пользователя:
  Header: X-Request-ID: 12345

Сервис A:
  логи: «Request 12345: Started»
  вызывает Сервис B с заголовком X-Request-ID: 12345

Сервис B:
  логи: «Request 12345: Received from Service A»
  вызывает Сервис C с заголовком X-Request-ID: 12345

Сервис C:
  логи: «Request 12345: Processing complete»

Позже извлеките все логи по запросу 12345, чтобы увидеть полный поток

2. Структурированное логирование

Не логируйте: «Произошла ошибка» Логируйте: JSON с контекстом

{
  "timestamp": "2026-02-20T14:32:15Z",
  "request_id": "12345",
  "service": "payment-service",
  "level": "error",
  "message": "Payment authorization failed",
  "error_code": "STRIPE_AUTH_FAILED",
  "attempt": 1,
  "latency_ms": 2500,
  "status_code": 503
}

3. Паттерн circuit breaker

Внедрите circuit breaker для предотвращения каскадных сбоев:

Норма:
  Payment Service → вызывает Stripe API
  Stripe возвращает 200 (успех)
  Запрос продолжается

Режим отказа (circuit open):
  Stripe API возвращает 503 (сервис лежит)
  После 5 сбоев circuit breaker открывается
  Последующие запросы быстро падают (без попытки звонка в Stripe)
  Latency вызовов Stripe падает с 2с до 50ms
  Система деградирует gracefully вместо каскадного сбоя

Восстановление:
  Circuit breaker в half-open (тестируем 1 запрос)
  Если успешно — постепенно увеличиваем запросы к Stripe
  Если падает — circuit возвращается в open

Специфические гочи Kubernetes-мониторинга#

Гоча 1: IP пода меняется при рестарте#

При рестарте пода его IP меняется. DNS-записи должны обновляться.

Мониторинг должен это учитывать:

Мониторьте по имени сервиса, а не IP пода
Используйте Kubernetes DNS (service-name.namespace.svc.cluster.local)
Мониторьте Kubernetes service endpoints (зарегистрированы ли поды?)

Гоча 2: задержки init-контейнеров#

Init-контейнеры Kubernetes запускаются перед основным контейнером. Если init-контейнер медленный:

Статус пода: «Running» (технически верно)
Но на самом деле: init-контейнер ещё работает, сервис не готов
Health-check может падать (сервис ещё не отвечает)

Решения:

Не алертите на провалы health-check в первые 60 секунд
Используйте startup probes (отличаются от liveness probes)
Мониторьте latency завершения init-контейнера

Гоча 3: лимиты ресурсов влияют на производительность#

Если CPU-лимит пода слишком низкий:

Статус пода: Running
Но на самом деле: CPU throttle, скачок latency
Мониторинг показывает скачок latency, а CPU usage показывает 100% throttle

Решение: мониторьте и CPU usage, И CPU throttling
Алерт, если CPU throttle > 20% времени

Nova Uptime для мониторинга микросервисов#

Бесплатный тариф Nova Uptime может мониторить микросервисы:

Health-check сервисов: мониторинг health-эндпоинтов каждого сервиса
Мониторинг API: отслеживание времени отклика и доли ошибок
Мониторинг вебхуков: верификация service-to-service коммуникации
Мониторинг email: проверка, что Notification Service доставляет письма
Мониторинг публичного API: если сервисы экспонируют публичные API

Для исчерпывающего мониторинга микросервисов используйте специализированные инструменты (Prometheus, Datadog, New Relic). Но Nova Uptime может дополнять их, мониторя здоровье внешних сервисов и публичных API клиентского уровня.

Итог: мониторинг микросервисов за пределами простого uptime#

Микросервисы требуют более изощрённого мониторинга, чем традиционные системы.

Ваш план действий:

Реализуйте health-check эндпоинты в каждом микросервисе
Откройте метрики (/metrics-эндпоинт для Prometheus)
Добавьте correlation ID во все потоки запросов
Внедрите circuit breaker для предотвращения каскадных сбоев
Используйте структурированное логирование с контекстом запроса
Мониторьте коммуникацию между сервисами (latency, ошибки)
Мониторьте инфраструктуру Kubernetes (поды, ноды, деплои)
Настройте distributed tracing (видеть полный поток запроса)
Создайте per-service дашборды (видимость в каждый сервис)
Алертите на деградацию (а не только полные сбои)

Начните с Nova Uptime для мониторинга публичных API. Добавьте мониторинг health-check. Дополните Prometheus/Grafana или managed-сервисом для более глубокого мониторинга инфры.

Ваши микросервисы сложны. Ваш мониторинг должен соответствовать этой сложности.

Мониторинг микросервисов и Kubernetes: за пределами простых uptime-проверок