При разработке нового эндпоинта нужно решить, как отличать ожидаемый отказ по правилам продукта от технического сбоя. Если сбор и хранение телеметрии поддерживает другая команда, кто определит, какие события считать и что записывать в логи?
В разных компаниях задачи backend, DevOps и SRE распределены по-разному. Прикладные сигналы стоит проектировать вместе с разработчиками сервиса: для этого нужно знать логику операций и условия их выполнения.
📋Вот что полезно согласовать до релиза:
✔️Смысл метрик.
Определите, что считается успешным выполнением, ожидаемым отказом и технической ошибкой. Если есть повторные попытки, явно обозначьте, считает метрика отдельные попытки или операции целиком: эти значения отвечают на разные вопросы.
✔️Точки инструментирования.
Проверьте, какие этапы обработки уже видны в телеметрии. Если важный участок прикладной логики не измеряется отдельно, можно добавить span или метрику длительности. Выбор зависит от того, какой вопрос о работе этого участка нужно исследовать.
✔️Состав логов и диагностический контекст.
Согласуйте поля для типа операции, ее результата и категории ошибки, чтобы записи можно было последовательно фильтровать. Request ID помогает находить связанные события, а trace ID в записи - сопоставлять ее с трейсом. Нужный контекст должен быть доступен в тех местах кода, где создаются эти записи.
✔️Ограничения на данные.
Уникальный request ID не стоит добавлять в labels метрик Prometheus: каждая новая комбинация значений меток создаёт отдельный временной ряд и увеличивает расход ресурсов. Состав логов тоже требует проверки - пароли и токены доступа нужно исключить из записей.
Эти решения определяют, какие данные получит команда для диагностики после релиза. На курсе Observability эта работа входит в практику с Go-приложением: вы создаете и экспортируете собственные метрики, настраиваете структурированное логирование, интегрируете OpenTelemetry и анализируете задержки и ошибки по трейсам.
Такая практика полезна backend-разработчику и при готовой инфраструктуре мониторинга: она помогает связать решения в коде с возможностями расследования. Посмотрите программу курса Observability, чтобы оценить, какие из этих задач вам нужно отработать.