cacto
17af76c159
Тикер офлайн-детекции (internal/healthcheck) переехал из device-control-service в новый самостоятельный Go-сервис — как и планировалось с самого начала (см. изначальный README-заглушку). Детекция online остаётся в device-control-service: она происходит как побочный эффект уже имеющейся там MQTT-подписки на devices/+/telemetry и devices/+/ack, заводить для этого отдельный сервис с дублирующей MQTT-подпиской избыточно. health-check-service — свой Go-модуль (без зависимости от proto/, сборка из собственного контекста), читает только узкое read+offline-подмножество Device Shadow keyspace в Redis (devices:known, status, last_seen) — полный Shadow API с записью desired/reported state остаётся только в device-control-service. Метрика device_control_health_transitions_total переименована в device_health_transitions_total и теперь публикуется с этим именем из ДВУХ сервисов (device-control-service — direction=online, health-check-service — direction=offline): Prometheus агрегирует одноимённые метрики с разных таргетов прозрачно, поэтому Grafana- дашборд адаптирован простой сменой имени метрики в запросе, без переделки панели. Проверено вживую через docker compose: реальный online→offline переход (публикация тестовой телеметрии + ожидание таймаута) корректно долетает до Redis и RabbitMQ (device.status_changed), Prometheus видит новый scrape-таргет как up.
3.1 KiB
health-check-service (Go)
Статус: реализован.
Изначально жил как горутина-тикер внутри device-control-service (см. его README/git-историю) — выделен в отдельный сервис по мере роста проекта, как и планировалось с самого начала.
Зона ответственности:
- Периодически (по тикеру,
HEALTH_CHECK_INTERVAL) обходит все известные устройства из Redis-множестваdevices:knownи проверяетlast_seenкаждого. - Когда устройство превышает таймаут офлайна (
HEALTH_CHECK_TIMEOUT), переводит егоstatusвofflineв том же Redis (Device Shadow keyspace, который device-control-service читает/пишет) и публикуетdevice.status_changedв RabbitMQ.
Не входит в зону ответственности:
- Детекция перехода в online. Это происходит как побочный эффект
MQTT-подписки device-control-service на
devices/+/telemetryиdevices/+/ack(там уже есть открытое соединение и подписка ради reported_state) — заводить для этого отдельный сервис с собственной MQTT-подпиской избыточно. health-check-service работает только "в одну сторону": online → offline. - Хранение/интерпретация телеметрии — это ingest-service.
- Знание о существовании устройств из PostgreSQL — этот сервис, как и
device-control-service, не подключается к Postgres: список устройств для
сканирования берётся из того же Redis-множества
devices:known(пополняется device-control-service).
Метрики
GET /metrics на HEALTH_CHECK_METRICS_PORT. Счётчик
device_health_transitions_total{direction="offline"} — намеренно та же
метрика (по имени), что device-control-service публикует для
direction="online": Prometheus агрегирует одноимённые метрики с разных
таргетов прозрачно, так что дашборд Grafana не пришлось переделывать под
разделение на два сервиса.
Запуск
cd services/health-check-service
go test ./...
go build ./cmd/health-check-service
Конфигурация — через переменные окружения (секция health-check-service в
корневом .env.example). Не зависит от proto/ — работает только с Redis
и RabbitMQ, поэтому в отличие от device-control-service/rule-engine-service
сборка Docker-образа идёт из собственного контекста (не корня репозитория).