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