Про книгу OpenTelemetry

Дочитал наконец-таки книгу Теда Янга и Остина Паркера "Изучаем OpenTelemetry: современный мониторинг систем". Эта книга описывает новый и все более популярный стандарт по сбору телеметрии для целей мониторинга - OpenTelemetry (OTEL). Книга получилась не мануалом по использованию, не декларацией подхода, а чем-то средним с перевесом во вторую сторону. Авторы рассказали про предпосылки появления стандарта, про него в целом, про его внутреннее устройство и надавали советов по внедрению в своей компании. В своей работе я часто сталкиваюсь с OTEL, поэтому мне хотелось изучить тему "с основ".

Какие идеи заинтересовали больше всего:
1. Прикольный подход с разделением API и SDK.
Хоть это и не что-то новое, ребята из OTEL заложили такой подход, при котором на этапе разработки с помощью OTEL API разработчик может описать логику сбора телеметрии, не заботясь о том, куда она в итоге будет отправляться. Для того, чтобы данные телеметрии начали реально отправляться, нужно подключить OTEL SDK, который и будет отвечать за отправку в настроенную локацию. Без подключенного SDK телеметрия, которую описывали в API, не будет генерироваться. Этот маневр выглядит избыточным, если пишешь приложение с нуля самостоятельно. Но такой подход начинает сиять, когда в твоем проекте используется много разных сторонних библиотек - благодаря тому, что многие популярные либы переходят на использование OTEL API, подключая OTEL SDK к своему проекту разработчик получается всю телеметрию всех используемых библиотек. Благодаря этому любую проблему с приложением найти будет гораздо проще, даже если она кроется в коде сторонней либы. С другой стороны, конечно, это создает дополнительную работу по первоначальной настройке фильтров того, какая телеметрия вам интересна, а какая не оч.

2. Интересный подход с трейсингом в виде стержня телеметрии
Я привык, что есть 3 столпа телеметрии - логи, метрик и трейсы. И, как правило, все они независимы друг от друга. Это создает проблему, которую авторы описали как "три вкладки в бразуере": для каждого вида телеметрии есть отдельный UI, по которому человек должен сам искать корреляции - по id сессии, по времени или еще как-то. В противовес этому OTEL предлагает использовать трейсы как основную сущность телеметрии - логи предлагают аттачить к спанам (спан это выполнение одной операции, а трейс это вся цепочка таких операций), метрики считать на основе спанов и добавлять к ним иногда трейсы. В итоге получится, что вся телеметрия строится вокруг трейсинга, и просматривая его, инженер будет видеть сразу все - трейсы, логи и метрики через exemplars (это когда иногда к показаниям метрик можно добавить traceId, чтобы получить пример операции, которая выполнялась во время таких-то показаний метрик)

3. OTEL предлагает использовать собственный коллектор для сбора телеметрии
В индустрии наблюдаемости уже есть разного рода коллекторы (сборщик данных), которые себя хорошо показали "в бою". Но ребята разработали новый, который ориентирован сразу на все типы телеметрии и умеет работать в разных режимах (типа как сборщик данных или как промежуточный агрегатор). Надо признать, что на текущий момент их коллектор вполне неплох и по функциям и стабильности показывает себя не хуже конкурентов.

В общем, книга мне показалась интересной, хоть и многое оттуда было уже известно из-за того, что я сам работаю в этом домене. По ходу чтения мне не хватило "кишков" реализации, но за этим авторы предлагают идти в документацию.

P.S. Кстати, это одна из первых технических книг, когда меня напрягал перевод на русский - местами было прям сложновато читать, приходилось прикидывать как это можно сказать на англ. и становилось чуть понятнее.