Как следить за работой оркестратора и какие метрики использовать для проверки корректности

Что проверяют

Умеете ли вы отличить «сервис жив» от «сервис работает правильно». Для оркестратора это разные вещи: процесс может отвечать на health check и при этом терять задачи. Следом спрашивают, какие алерты вы бы завели и что делать, если задача зависла.

Как отвечать

Сначала уточните, о каком оркестраторе речь: о своём Go-сервисе, который раздаёт задачи воркерам, или о Kubernetes. На Go-собеседовании чаще имеют в виду первое.

Для своего оркестратора метрики отдаются через prometheus/client_golang и эндпоинт /metrics с promhttp.Handler():

• поток задач: Counter принятых, завершённых, упавших и повторённых задач с лейблом статуса;
• очередь: Gauge длины очереди и возраст самой старой ожидающей задачи. Возраст ловит зависание лучше длины;
• длительность: Histogram времени выполнения и ожидания, по нему считают p95 и p99;
• воркеры: число живых воркеров по heartbeat и задач, закреплённых за пропавшими;
• рантайм Go: стандартный коллектор уже отдаёт go_goroutines и метрики памяти. Рост горутин без роста нагрузки означает утечку.

Корректность проверяется инвариантами: каждая задача за разумное время приходит в терминальный статус, принятых столько же, сколько завершённых плюс упавших плюс висящих, одна задача не выполняется дважды. Под это заводят алерты в Alertmanager и периодическую сверку. Логи структурированные через log/slog с task_id, трассировка через OpenTelemetry, чтобы пройти путь задачи по сервисам.

Если речь про Kubernetes, назовите kube-state-metrics (kube_pod_container_status_restarts_total, поды в Pending), метрики нод и cAdvisor. kubectl top берёт данные из metrics-server и годится для быстрого взгляда, а не для истории.

Где спотыкаются

Кладут task_id или user_id в лейблы Prometheus. Каждое значение лейбла порождает отдельный временной ряд, и хранилище раздувается.

Мониторят только CPU и память. Оркестратор, который молча перестал брать задачи из очереди, по этим графикам выглядит здоровым.

Путают liveness и readiness. Liveness перезапускает контейнер, и если положить в неё проверку базы, падение базы превратится в цикл рестартов всех подов.