Почему телеметрия и метрики не должны влиять на работу приложения?

Что проверяют

Понимаете ли вы, что наблюдаемость это подсистема со своими отказами, и умеете ли отделить её от пути запроса. Ждут конкретики: где буфер, что происходит при недоступном приёмнике, чем платим за трассировку.

Как отвечать

Два требования. Первое: сбор не должен становиться причиной отказа. Второе: он не должен искажать то, что измеряет.

Как это делается:

• метрики в память, выгрузка отдельно: увеличение счётчика это операция в памяти, а не сетевой вызов. Наружу отдаётся срез по запросу сборщика или пачкой из фонового потока;
• логи и трассы через очередь с пределом: в Python это QueueHandler и QueueListener, иначе медленный обработчик логов блокирует поток, а в асинхронном сервисе и весь цикл событий;
• сэмплирование: писать спаны на каждый запрос дорого и по процессору, и по хранилищу. Обычно берут долю трафика, оставляя все ошибочные и медленные;
• таймауты и отказ без бесконечных повторов: экспортёр не должен ждать недоступный приёмник и копить данные без предела;
• контроль кардинальности: идентификатор пользователя или путь с номером в метке метрики порождает отдельный временной ряд на каждое значение.

Отдельно стоит сказать про измерение времени: time.perf_counter вместо календарных часов, и понимание, что сама трассировка добавляет накладные расходы, поэтому её цену измеряют, а не предполагают.

Где спотыкаются

Отвечают, что сделают сбор асинхронным, и на этом останавливаются. Очередь без предела при упавшем приёмнике съедает память и роняет процесс не хуже блокировки, поэтому у неё должен быть размер и осознанное поведение при переполнении.

Второе: кладут в метки метрик всё подряд. Каждое сочетание значений это новый ряд, и счётчик с идентификатором в метке превращается в утечку памяти сначала в приложении, потом в хранилище метрик.

Третье: заворачивают вызов экспортёра в перехват исключений и считают вопрос закрытым. Исключение поймано, но ожидание сетевого вызова осталось внутри обработки запроса, и деградация мониторинга становится ростом времени ответа сервиса.