Project type: work
AI tags: work, ais, backend, metrics, rest-api, monitoring
Description
Реализовать новый REST endpoint, который будет предоставлять базовые метрики сервиса в формате, совместимом со стандартными системами мониторинга (например, Prometheus). Endpoint должен содержать счётчики обработанных пакетов, ошибок, задержек и другие операционные метрики из модуля core/stats.py.
Endpoint GET /api/v1/metrics доступен и возвращает HTTP 200
Ответ содержит базовые счётчики: обработанные AIS пакеты, GPS фиксы, ошибки парсинга, дропы очередей
Ответ содержит калибры: размер state (количество сосудов), uptime сервиса, версия
Формат ответа документирован в docs/API.md
Существует тест в tests/ проверяющий структуру и доступность метрик
Code notes
В src/ais_hub/core/stats.py уже определен класс Stats с счётчиками; проверить, покрывает ли он необходимые метрики
В src/ais_hub/publish/rest.py находятся все существующие REST handlers; добавить новый handler по аналогии с health() или stats_handler()
docs/API.md содержит полный контракт; обновить таблицу эндпоинтов и привести пример ответа
tests/test_rest_smoke.py показывает паттерн тестирования REST endpoints через TestClient; следовать этому стилю
README.md указывает, что /api/v1/stats уже существует; возможно, metrics может быть дополнением или переименованием
Questions
Нужно ли экспортировать метрики в формате Prometheus (text/plain; version=0.0.4) или достаточно простого JSON?
Какие именно счётчики и калибры считать базовыми? Нужно ли дублировать содержимое /api/v1/stats или сделать более компактное подмножество?
Требуется ли аутентификация/авторизация для endpoint metrics, или он открыт как /api/v1/health?
Нужна ли дополнительная точка экспорта (например, UDP или другой протокол) или только HTTP?
Должны ли метрики включать per-source breakdown (AIS UDP vs AIS-catcher vs GPS vs radio отдельно) или только агрегированные значения?
Linked Taiga story: #43
Suggested branch:
`feature/taiga-43-dobavit-endpoint-api-v1-metrics-dlya-bazovyh-metrik-servisa`
Project type: `work`
AI tags: work, ais, backend, metrics, rest-api, monitoring
## Description
Реализовать новый REST endpoint, который будет предоставлять базовые метрики сервиса в формате, совместимом со стандартными системами мониторинга (например, Prometheus). Endpoint должен содержать счётчики обработанных пакетов, ошибок, задержек и другие операционные метрики из модуля core/stats.py.
Taiga: https://tasks.grigowashere.ru/project//us/43
## Acceptance criteria
- Endpoint GET /api/v1/metrics доступен и возвращает HTTP 200
- Ответ содержит базовые счётчики: обработанные AIS пакеты, GPS фиксы, ошибки парсинга, дропы очередей
- Ответ содержит калибры: размер state (количество сосудов), uptime сервиса, версия
- Формат ответа документирован в docs/API.md
- Существует тест в tests/ проверяющий структуру и доступность метрик
## Code notes
- В src/ais_hub/core/stats.py уже определен класс Stats с счётчиками; проверить, покрывает ли он необходимые метрики
- В src/ais_hub/publish/rest.py находятся все существующие REST handlers; добавить новый handler по аналогии с health() или stats_handler()
- docs/API.md содержит полный контракт; обновить таблицу эндпоинтов и привести пример ответа
- tests/test_rest_smoke.py показывает паттерн тестирования REST endpoints через TestClient; следовать этому стилю
- README.md указывает, что /api/v1/stats уже существует; возможно, metrics может быть дополнением или переименованием
## Questions
- Нужно ли экспортировать метрики в формате Prometheus (text/plain; version=0.0.4) или достаточно простого JSON?
- Какие именно счётчики и калибры считать базовыми? Нужно ли дублировать содержимое /api/v1/stats или сделать более компактное подмножество?
- Требуется ли аутентификация/авторизация для endpoint metrics, или он открыт как /api/v1/health?
- Нужна ли дополнительная точка экспорта (например, UDP или другой протокол) или только HTTP?
- Должны ли метрики включать per-source breakdown (AIS UDP vs AIS-catcher vs GPS vs radio отдельно) или только агрегированные значения?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Linked Taiga story: #43
Suggested branch:
feature/taiga-43-dobavit-endpoint-api-v1-metrics-dlya-bazovyh-metrik-servisaProject type:
workAI tags: work, ais, backend, metrics, rest-api, monitoring
Description
Реализовать новый REST endpoint, который будет предоставлять базовые метрики сервиса в формате, совместимом со стандартными системами мониторинга (например, Prometheus). Endpoint должен содержать счётчики обработанных пакетов, ошибок, задержек и другие операционные метрики из модуля core/stats.py.
Taiga: https://tasks.grigowashere.ru/project//us/43
Acceptance criteria
Code notes
Questions