Привет! Прочитал и рекомендую книгу "Изучаем 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 для выявления коллеряций и прогнозирования. Или строить архитектурные диаграммы, соответствующие продакшену. Стандарт здесь помогает ⁉️Поделитесь в комментариях опытом работы с телеметрией/трейсингом, как у вас в компании обстоят дела, какие есть сложности, или кейсы когда телеметрия выручала 🙏