# ✨ Считать вызовы, отказы и длительность по каждому внешнему сервису

- **Тип:** feature
- **Категория:** Очередь — Метрики внешних сервисов пишутся в выбранном словаре, а не переписываются потом.
- **Зачем:** Ни у Telegram, ни у Object Storage, ни у SpeechKit нет ни одной метрики: отказ внешнего сервиса виден только строкой в журнале контейнера.

У каждого внешнего сервиса появляются вызовы, отказы и длительность, а расход на
платные сервисы становится виден числом.

Внешних сервисов сегодня четыре — Telegram, Object Storage, SpeechKit и
`ffmpeg`/`ffprobe` как внешний процесс; пятым станет языковая модель. Метрика
заводится одной формой на все, чтобы шестой сервис не приносил шестого способа
считать.

## Затрагивает

- `internal/metrics` — форма метрики внешнего вызова: имя сервиса, операция,
  исход, гистограмма длительности;
- адаптеры `internal/adapter/*` — место, где вызов оборачивается замером;
- `docs/architecture.md`, раздел эксплуатации — перечень метрик;
- `docs/conventions/` — правило: новый внешний вызов приходит со своей меткой,
  а не со своей метрикой.

## Критерии приёмки

- У каждого из четырёх внешних сервисов есть счётчик вызовов, счётчик отказов и
  гистограмма длительности. Оракул — тест: прогнать по одному вызову каждого
  адаптера с подставным собеседником и снять `/metrics`.
- Отказ внешнего сервиса виден отдельно от успеха и не теряется в общем счётчике.
  Оракул — тест: подставной собеседник отвечает отказом, метка исхода в метрике
  отличается.
- Минуты распознавания и объём заливки видны числом. Оракул — тест: после шага
  распознавания счётчик минут вырос на длительность записи, а после заливки в
  Object Storage счётчик объёма — на размер файла.

## Рамки

Трассировку здесь не заводим — чем развивать наблюдаемость, решает разведка
`opentelemetry-fit`; эта задача остаётся в том словаре, который она выберет.
Учёт по пользователям — задача `usage-accounting`, здесь метрики сервисные.