Перейти к содержанию

Kubernetes — наблюдаемость

В Kubernetes наблюдаемость строится на стандартных инструментах: метрики — через Prometheus Operator (ServiceMonitor), логи — через сборщик кластера, здоровье — через пробы.

Метрики (Prometheus Operator)

Каждый сервис отдаёт метрики в формате Prometheus на эндпоинте /metrics (у api-gateway — на отдельном порту 9090). Вместо ручного scrape-конфига (как в пилоте на Compose) для обнаружения целей Prometheus Operator'ом включается ServiceMonitor — флагом metrics.serviceMonitor.enabled: true в values соответствующего сервиса. Объект ServiceMonitor создаётся в namespace сервиса и размечен лейблами, по которым его подхватывает Prometheus Operator.

Полный перечень метрик и их смысл — Справочник: Метрики; настройка дашбордов Grafana, алерты и PromQL-рецепты — Мониторинг и метрики.

Пробы здоровья

  • livenessProbe → GET /healthz (всегда 200, без зависимостей).
  • readinessProbe → GET /readyz (проверяет критичные зависимости — БД, Redis, брокер; 503 при недоступности).
  • Для ML-сервисов — startupProbe → GET /startupz (загрузка модели).

readinessProbe (/readyz) проверяет критичные зависимости и возвращает 503 при недоступности БД, Redis или MinIO — под при этом выводится из балансировки, но не перезапускается. У ML-сервисов (threat-detector, content-safety, translation-service) загрузка модели занимает время, поэтому startupProbe (/startupz) задаётся с высоким failureThreshold (порядка 10 минут) — пока он не пройдёт, liveness/readiness не активируются и под не убивается за «медленный» старт.

Логи

Все сервисы пишут структурированные JSON-логи в stdout — их собирает стандартный агрегатор кластера (Loki, ELK или аналог), без дополнительной настройки на стороне приложения. Поля контракта:

  • event — текст события;
  • level — уровень (info/warning/error/…);
  • service — имя сервиса-источника;
  • timestamp — отметка времени в UTC;
  • trace_id / span_id — корреляция с трассировкой.

Поля trace_id/span_id позволяют связать запись лога с распределённой трассой (см. ниже).

Трассировка (OpenTelemetry)

Распределённая трассировка включается двумя переменными окружения на каждом сервисе:

  • OTEL_ENABLED=true — активирует экспорт трейсов;
  • OTEL_EXPORTER_OTLP_ENDPOINT — адрес OTLP-коллектора (например, OpenTelemetry Collector или Tempo), куда сервисы отправляют спаны.

Коллектор и бэкенд трейсов разворачиваются на стороне кластера; идентификаторы trace_id/span_id совпадают с полями JSON-логов, что даёт сквозную корреляцию логов и трасс.

Дашборды и алерты

Готовые дашборды Grafana и правила алертов поставляются в комплекте — см. Мониторинг и метрики. Импортируйте их в свою Grafana и подключите правила к Prometheus.