Привет! Прочитал и рекомендую книгу "Изучаем OpenTelemetry: современный мониторинг систем" (далее OT - OpenTelemetry). Особенно, если:
- вы планируете работать над развитием наблюдаемости в своих сервисах
- вы занимаетесь разработкой библиотек
- занимаетесь платформенной разработкой и стандартизацией
- проектируете инфраструктуру под сбор телеметрических данных
- или в вашей компании поддерживается несколько несвязанных друг с другом инструментов (для сбора метрик/логов/трейсов/ошибок и тд), например Sentry vs OpenTracing

Отмечу несколько моментов, которые меня заинтересовали:

1️⃣Авторы рассказывают о концепциях современной телеметрии, как и куда развивается стандарт OpenTelemetry и для чего он нужен. Для меня откровением стала масштабность решения. К примеру, OpenTelemetry заточен не только под сбор трейсов (раньше это был OpenTracing), стандарт гибкий позволяет в перспективе перейти на сбор метрик и логов одинаковым способом. Это определенное новшество, ведь обычно это делается по-разному. Делать по разному визионеры OT называют "текущим положением дел", намекая, что мы уйдем от этого 😄

2️⃣Авторы описывают архитектуру сбора телеметрии (трейсы, логи, метрики), точнее сказать возможные варианты архитектур, которые можно построить на базе стандарта (OT Collector). Стандартизации протокола с коллектором (приемник метрик) позволяет строить различные пайплайны сбора, фильтрации и агрегации данных.

3️⃣Отдельная глава посвящена инструментированию (организации сбора телеметрии из кода) библиотек и приложений, и как его лучше готовить. Авторы сетуют на пока еще небольшой процент поддержки OSS-библиотеками OT.
Как один из разработчиков общего платформенного тулинга - подтверждаю, и платформе приходится посполнять этот пробел.

Авторы (они же и участники движения OT) делают огромную работу, чтобы привести большинство библиотек базовых OT-библиотек разных стеков к общему знаменателю (к примеру, унифицированные настройки через одинаковые ENV-переменные).


💡Я раньше считал, что наблюдаемость библиотеки - это дополнительная фича, которую стоит реализовать в отдельно, заложив возможность расширения поведения, например, через механизм Middleware (промежуточный слой). На деле же рекомендуется делать сбор трейсов нативно, прямо из кода библиотеки. Именно для этого вся OT-инструментация во всех стеках при подключении не активириется по-дефолту (это тоже стандарт). Такой подход снимает массу проблем (зависимости, неактуальности, изменения, актуализация).

4️⃣Отдельная глава посвящена демонстрационной системе, состоящей из нескольких сервисов, иллюстрирующей OT в действии. Запустив все в докере одной командой - можно поэкспериментировать с телеметрией, посмотреть дэшобрды с метриками, логами и трейсами, а так же комбинацией фича-флагов симулировать внештаную ситуацию в системе, чтобы понять как наблюдаемость помогает ее отобразить.

За OT однозначно будущее, потому что:
- системы становятся сложней и нужна интроспекция, чтобы понимать как все работает
- повсеместно используются различные приложения/сервисы/форматы. OT призвана стандартизовать формат. К примеру, Sentry уже поддерживает OT
- при этом стандарт не накладывает органичений на способы применения телеметрии, а скорее помогает. К примему, вы возможно захотите использовать ML для выявления коллеряций и прогнозирования. Или строить архитектурные диаграммы, соответствующие продакшену. Стандарт здесь помогает

⁉️Поделитесь в комментариях опытом работы с телеметрией/трейсингом, как у вас в компании обстоят дела, какие есть сложности, или кейсы когда телеметрия выручала 🙏