av
5501384cdc
- 11 записей типа goal закрыты с причиной, называющей задачи-наследники; ROADMAP.md удалён, индекс остался один — BACKLOG.md; - 33 записи переписаны: ссылка «Двигает пункты N «Завершения» цели» уступила место прямому утверждению — без целей номера пунктов вели в никуда; - шапка BACKLOG.md размечена парой <!-- стадия -->, порядок строк теперь объявлен зависимостью, а не важностью.
2.6 KiB
🔬 Стоит ли брать OpenTelemetry вместо голого Prometheus
- Тип: research
- Категория: Очередь — Сопровождение: словарь метрик выбирается до того, как метрик станет втрое больше.
- Зачем: Метрик одиннадцать штук на пять счётчиков, трассировки нет вовсе: путь одной записи по конвейеру собирается только чтением логов глазами.
Эндпоинт /metrics остаётся и развивается — это решено. Вопрос в том, чем его
развивать: дописывать счётчики в internal/metrics напрямую через
client_golang или перевести на OpenTelemetry и получить заодно трассировку.
Сегодня у записи есть путь длиной в минуты через четыре внешних сервиса и три
воркера, и связать его звенья можно только по job_id в логах. Трассировка
отвечает на это прямо, но приносит коллектор — процесс, которого в выкладке нет.
Вопрос
Даёт ли OpenTelemetry на этом проекте больше, чем стоит: коллектор в выкладке,
переписанные метрики и словарь имён, — или дешевле остаться на client_golang и
дописать недостающие счётчики.
Куда ляжет ответ
docs/research/opentelemetry.md — с числами: сколько зависимостей приносит,
что появляется в выкладке, сколько метрик переписывается. Решение и причина
отказа — в docs/adr/, если берём: переход на другой словарь метрик ломает
собранные ряды и обратной правкой не откатывается.
Рамки
Метрики Prometheus и путь /metrics из ответа не исчезают ни при каком исходе:
OpenTelemetry рассматривается как источник тех же метрик, а не как замена
эндпоинта. Своего хранилища метрик и своих панелей не поднимаем — это отдельная
работа.