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.
52 lines
3.1 KiB
Markdown
52 lines
3.1 KiB
Markdown
# 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 не пришлось переделывать под
|
|
разделение на два сервиса.
|
|
|
|
## Запуск
|
|
|
|
```bash
|
|
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-образа идёт из собственного контекста (не корня репозитория).
|