Микросервисы дают гибкость и масштабируемость. Но они также превращают мониторинг из простой задачи («один сервер, один health check») в многомерную: 20 сервисов, 50 inter-service connections, 5 баз данных, 3 очереди. Что-то сломалось — но что именно, и какое влияние на пользователей?
Здесь разбираем, как построить мониторинг для микросервисной архитектуры: от health check endpoints каждого сервиса до end-to-end synthetic checks, от distributed tracing до status page mapping.
Четыре слоя мониторинга
Полноценный мониторинг микросервисов работает на четырёх уровнях. Каждый отвечает на свой вопрос.
Слой 1: Health каждого сервиса
Вопрос: каждый отдельный сервис работает?
Как: health check endpoint в каждом сервисе (/health/live + /health/ready)
Что проверяет: процесс жив, зависимости (БД, кеш) доступны, сервис готов принимать трафик
Инструменты: Kubernetes probes (внутренние), внешний мониторинг (AtomPing HTTP checks с JSON path assertions)
Слой 2: Inter-service communication
Вопрос: сервисы могут общаться друг с другом?
Как: метрики на каждом service boundary — request rate, error rate, latency (p50, p95, p99)
Что ловит: network partitions, timeout cascades, serialization errors, circuit breaker trips
Инструменты: Prometheus + Grafana (internal metrics), Istio/Linkerd service mesh (automatic telemetry), OpenTelemetry SDK (manual instrumentation)
Слой 3: Infrastructure
Вопрос: хватает ли ресурсов?
Как: CPU, memory, disk, network I/O для каждого контейнера/пода
Что ловит: memory leaks, CPU throttling, disk exhaustion, noisy neighbors
Инструменты: Kubernetes metrics-server, Prometheus node_exporter, cloud provider metrics (CloudWatch, GCP Monitoring)
Слой 4: End-to-end user flows
Вопрос: пользователь может выполнить своё действие?
Как: synthetic monitoring — внешние HTTP checks, которые проходят через всю цепочку
Что ловит: всё, что слои 1-3 могут пропустить: DNS issues, TLS problems, CDN failures, load balancer misconfigurations
Инструменты: AtomPing (HTTP, DNS, SSL, API monitoring с assertions), PageSpeed monitoring
Health check patterns для микросервисов
Паттерн 1: Aggregate health endpoint
API Gateway или BFF (Backend-for-Frontend) сервис предоставляет единый /health endpoint, который проверяет критичные downstream сервисы. Мониторинг опрашивает один URL, который покрывает всю цепочку.
# API Gateway health check
GET /health/ready
{
"status": "healthy",
"services": {
"user-service": {"status": "healthy", "latency_ms": 12},
"order-service": {"status": "healthy", "latency_ms": 8},
"payment-service": {"status": "healthy", "latency_ms": 23},
"notification-service": {"status": "degraded", "latency_ms": 450}
}
}Когда использовать: у вас есть API Gateway. Позволяет мониторить всю систему одним check. Ограничение: не покрывает сервисы, которые не проходят через Gateway.
Паттерн 2: Per-service monitoring
Каждый сервис имеет свой health endpoint, каждый endpoint мониторится отдельно. Больше monitors, но точнее диагностика: сразу видно, какой сервис упал.
Monitors:
user-service.internal:8080/health/ready → HTTP check + JSON assertion
order-service.internal:8080/health/ready → HTTP check + JSON assertion
payment-service.internal:8080/health/ready → HTTP check + JSON assertion
Когда использовать: когда внешний мониторинг имеет доступ к внутренним endpoint (VPN, private network). Или когда сервисы exposed через subdomains/paths.
Паттерн 3: Critical path monitoring
Вместо мониторинга каждого сервиса отдельно — мониторинг критичных user flows end-to-end. Один check проходит через 3-5 сервисов в цепочке.
Пример: «Login flow» check:
POST /api/auth/login → проходит через API Gateway → auth-service → user-service → token-service
Assertion: response contains $.access_token
Если любой сервис в цепочке падает — check fails. Один monitor покрывает 4 сервиса.
Когда использовать: вместе с per-service мониторингом. Critical path ловит end-to-end проблемы, per-service — помогает локализовать.
Cascading failures: обнаружение и предотвращение
Каскадный отказ — главная угроза в микросервисах. Один медленный сервис может утопить всю систему.
Как возникает каскад
1. Payment-service начинает отвечать за 10 секунд вместо 100ms (БД перегружена)
2. Order-service ждёт ответа от payment-service — его потоки/горутины заняты
3. Order-service перестаёт отвечать на новые запросы (thread pool exhaustion)
4. API Gateway получает timeouts от order-service — retry нагружает его ещё больше
5. Пользователь видит 502/504 на checkout page
Мониторинг каскадов
Latency p99: первый сигнал деградации. Если p99 payment-service вырос с 100ms до 5s — каскад начинается.
Error rate spikes: 5xx от payment-service → 5xx от order-service → 5xx на API Gateway. Если ошибки «поднимаются» по цепочке — это каскад.
Circuit breaker state: если circuit breaker сработал — зафиксируйте это как событие в мониторинге.
End-to-end check: AtomPing HTTP check на POST /api/orders с response time threshold — поймает end-user impact, даже если внутренние метрики неоднозначны.
Предотвращение каскадов
Timeouts: каждый inter-service call должен иметь явный timeout (1-5 секунд). Нет timeout = бесконечное ожидание = thread leak.
Circuit breakers: после N consecutive failures к downstream сервису — прекратить попытки на M секунд. Hystrix/Resilience4j/Polly.
Bulkheads: изолировать thread pools для разных downstream сервисов. Медленный payment-service не должен исчерпать потоки, предназначенные для user-service.
Retry budget: ограничить ретраи до 10-20% от общего трафика. Если 50% запросов — ретраи, вы усугубляете перегрузку, а не решаете проблему.
Distributed tracing
Distributed tracing позволяет отследить один запрос через все сервисы. Запрос пользователя получает trace ID, который передаётся между сервисами. Каждый сервис записывает span — своё время обработки.
Инструменты: Jaeger, Zipkin, Tempo (Grafana), Datadog APM, New Relic
Стандарт: OpenTelemetry (W3C Trace Context) — единый SDK для metrics, traces, logs
Что даёт: «запрос пользователя занял 3.2s → из них 2.8s — ожидание ответа от payment-service → payment-service потратил 2.7s на SQL-запрос». Без трейсинга вы знаете, что slow — но не знаете почему.
Distributed tracing — complementary к внешнему мониторингу. Мониторинг отвечает «что сломалось и когда». Трейсинг отвечает «почему и где именно». AtomPing обнаруживает, что checkout endpoint отвечает за 5 секунд. Jaeger показывает, что bottleneck — SQL-запрос в payment-service.
Status page mapping
В микросервисной архитектуре status page требует маппинга internal services → public components.
Status page component «API» ← api-gateway, auth-service, rate-limiter
Status page component «Dashboard» ← frontend, user-service, analytics-service
Status page component «Payments» ← payment-service, billing-service, Stripe integration
Status page component «Notifications» ← notification-service, email-service, webhook-service
В AtomPing каждый монитор привязывается к компоненту на status page. Если check на payment-service/health fails — компонент «Payments» автоматически переходит в degraded/down, status page обновляется, subscribers получают уведомление.
Alerting strategy
С 20+ сервисами alert fatigue — реальная проблема. Если каждый сервис шлёт alerts независимо, on-call инженер получает 15 уведомлений одновременно при каскадном отказе.
Правило 1: Alert on user impact, not service failure. Alert на «checkout endpoint returns 503» важнее, чем «payment-service pod restart». Первое — симптом, второе — одна из возможных причин.
Правило 2: Grouping. Один alert «3 services degraded in payment chain», а не три отдельных alert. AtomPing группирует инциденты по target.
Правило 3: Severity by business impact. P1 — checkout flow down (revenue impact). P3 — analytics-service degraded (no immediate user impact).
Правило 4: Quorum. Не алертить на одиночную failure. AtomPing quorum confirmation (2/3 агентов подтверждают) предотвращает ложные срабатывания из-за сетевых glitches.
Практический план мониторинга
Для типичной микросервисной архитектуры с 10-20 сервисами:
Шаг 1: Каждый сервис — /health/live + /health/ready. Kubernetes probes настроены.
Шаг 2: 3-5 AtomPing HTTP monitors на critical user flows (login, API, checkout). JSON path assertions на response body. 30s interval.
Шаг 3: AtomPing DNS monitor + SSL monitor на каждый public domain.
Шаг 4: Status page с компонентами, маппинг monitors → components.
Шаг 5: Prometheus/Grafana для internal metrics (CPU, latency, error rates). Alerts через AlertManager.
Шаг 6: OpenTelemetry tracing через все сервисы для root cause analysis.
Шаги 1-4 покрывают 80% потребностей и занимают 1-2 часа. AtomPing free tier (50 monitors) достаточен для большинства микросервисных архитектур. Шаги 5-6 — для зрелых команд с dedicated SRE.
Связанные материалы
Health Check Endpoint Design — как проектировать /health endpoints
Internal vs External Monitoring — зачем нужны оба подхода
API Monitoring Guide — мониторинг REST API endpoints
Incident Management Guide — detection, response, post-mortem
Как сократить ложные срабатывания — quorum confirmation в распределённых системах
FAQ
Why is monitoring microservices harder than monitoring monoliths?
In a monolith, one health check covers the whole app. In microservices, you have dozens of independent services communicating over the network. Failure modes multiply: service A calls B, which calls C — a timeout in C can cascade through B to A. You need monitoring at every layer: individual service health, inter-service communication, and end-to-end user flows.
What should I monitor in a microservices architecture?
Four layers: (1) Individual service health — health check endpoints for each service, (2) Inter-service communication — latency and error rates between services, (3) Infrastructure — CPU, memory, network for containers/pods, (4) End-to-end user flows — external synthetic checks that verify the complete user journey works.
How do I detect cascading failures in microservices?
Monitor error rates and latency at service boundaries. If Service B's error rate spikes, check if Service A (which calls B) also degrades. Distributed tracing (Jaeger, Zipkin) shows the full request path. External monitoring catches the end-user impact even when internal metrics are ambiguous.
Should each microservice have its own status page component?
Group by user-facing capability, not by internal service. Users don't care about 'user-service' or 'payment-service' — they care about 'Login', 'Checkout', 'API'. Map multiple services to one status page component. If user-service and auth-service both fail, the user sees 'Login: Degraded', not two separate incidents.
What's the role of external monitoring in a microservices setup?
External monitoring verifies the end-to-end system works from the user's perspective. Internal monitoring (Prometheus, Grafana) tells you which service is slow. External monitoring (AtomPing) tells you the user is actually affected. You need both — internal for diagnosis, external for detection.
How many monitors do I need for microservices?
Rule of thumb: one health check per service (N services = N monitors), plus 3-5 synthetic checks for critical user flows (login, checkout, API), plus DNS and SSL monitoring. A typical 20-service architecture needs 25-30 monitors. AtomPing's free plan (50 monitors) covers most microservice architectures.