Что узнать о конфигурации OpenElemetry GotChas
15 августа 2025 г.На прошлой неделе я описалНесколько подходов к Opentelemetry на JVM, их требования и их разные результаты. На этой неделе я хочу выделить несколько GotChas, найденных в стеках в инструментах с нулевым кодом.
Обещание Opentelemetry
С момента своего создания OpenElemetry объединила 3 столпа наблюдения. В распределенном пространстве трассировки он заменил запатентованные протоколы Zipkin и Jaeger. ИМХО, он достиг такого успеха по нескольким причинам:
- Во -первых, огромное отраслевое давление для работы между проприетарными инструментами
- Инструментация с нулевым кодом, позволяющая разработчикам не заботиться с Opentelemetry
- Легкий и унифицированный механизм конфигурации через переменные среды.
Последнее является благом для команды OPS, так как им не нужно знать основные фреймворки (или стека!). Им нужно только проверитьСпецификация переменной среды, и они сделаны.
Вот простой фрагмент, чтобы проиллюстрировать мою точку зрения:
environment:
OTEL_EXPORTER_OTLP_ENDPOINT: http://collector:4317 #1
OTEL_SERVICE_NAME: foobar #2
- Настройка конечной точки для отправки данных на
- Установите имя компонента
Из вышесказанного вы не можете догадаться, что такое базовый стек.
На стороне Opentelemetry разные разработчики вносят вклад в различные языковые библиотеки.Разработчики агента Javaотличаются отте из библиотеки PythonПолем Более того, каждый стек имеет определенные подходы и ограничения.
Это естественно создает различия в различных реализациях.
Gotchas
Вот пара GotChas, которые я узнал, но список не исчерпывает.
Путь или нет пути?
Давайте начнем с легкого с Gotcha, которая существует в стеках.
Opentelemetry предлагает некоторые параметры конфигурации для конечных точек.
- Общий, для использования для коллекционера Opentelemetry, который принимает все сигналы:
OTEL_EXPORTER_OTLP_ENDPOINT - Параметры, специализирующиеся на одном сигнале,напримерВ
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
В последнем случае можно установить корневой путь к конечной точке,напримерВhttp://collector:4317Полем SDK автоматически добавит путь по умолчанию, в зависимости от типа сигнала. Например, он добавляет/v1/tracesдляOTEL_EXPORTER_OTLP_TRACES_ENDPOINTПараметр конфигурации.
В качестве альтернативы можно установитьполныйпуть к конечной точке,напримерВhttp://collector:4317/v1/tracesПолем
Gotcha поймает вас, когда Opentelemetry развивается в V2, если вы не использовали пути. Потому что библиотека автоматически добавляет/v1/<xxx>; вам придется убедиться, что бэкэнд предлагает оба/v1и/v2конечные точки.
Руков питона
Чтобы открыть список, вот первый Gotcha: По умолчанию библиотека Python не отправляет данные журнала. Это должно быть включено явно!
environment:
OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED: true #1
OTEL_EXPORTER_OTLP_ENDPOINT: http://collector:4317
OTEL_SERVICE_NAME: foobar
- Включить журналы
Разработчики также должны быть вовлечены:
В отличие от следов и метрик, нет эквивалентных журналов API. Есть только SDK. Для Python вы используете Python
loggerБиблиотека, а затем OTEL SDK прикрепляет обработчик OTLP к корневому регистратору, превращая регистратор Python в логист OTLP. Один из способов выполнить это задокументирован в примере журналов в репозитории Python Opentelemetry.-Журнал пример авто-инструментации
Прослеживание микрометра
Перед Opentelemetry Jaeger и Zipkin правят Supreme в распределенной области трассировки. В великой весенней традиции проект создал Spring Cloud Sleath, чтобы предложить фасад над Зипкиным. Со временем он эволюционировал, чтобы быть совместимым с Opentracing, одним из родителей Openelemetry, наряду с Opencensus.
Я не могу быть уверен, была ли причина Opentelemetry, но Spring Cloud Sleath превратилась в (плохо названное)Прослеживание микрометрабиблиотека. Прослеживание микрометраСначала нацеливается на Зипкин, но также поддерживает Opentelemetry. Я нахожу добавление запрошенных библиотеков немного сложным, но это управляемо.
Тем не менее, конфигурация не соответствует переменным среды Opentelemetry. Он приносит свои переменные:
environment:
MANAGEMENT_OTLP_TRACING_ENDPOINT: http://jaeger:4318/v1/traces #1-2
OTEL_SERVICE_NAME: foobar #3
- Имя переменной среды Nonopentelemetry
- ДОЛЖЕНустановить полный путь
- Соответствовать спецификации OpenteLemetry, так какВесенний ботинок 3.5Полем Перед этим он использовалSpring.application.name
Quarkus
Сравните сQuarkus, который префиксирует регулярные переменные среды OpenElemetry сQUARKUS_:
environment:
QUARKUS_OTEL_EXPORTER_OTLP_TRACES_ENDPOINT: http://jaeger:4317
QUARKUS_OTEL_SERVICE_NAME: foobar
Это последовательно. И все же, в инструментах Quarkus есть еще одна Gotcha:
ТолькотрассировкаСигнал включен по умолчанию. Чтобы включитьметрикиижурналы, добавьте следующую конфигурацию в ваше приложение. Properties File:
-Quarkus Instrumentation
Между тем, если вы эксперт в эксплуатации Opentelemetry, эти значения удивления удивит вас. В Opentelemetry они регулируются другими параметрами конфигурации:
environment:
OTEL_METRICS_EXPORTER: none
OTEL_LOGS_EXPORTER: none
Краткое содержание
OpenElemetry сталаде -фактоСтандарт через несколько лет. Тем не менее, обещание повсеместной конфигурации, если когда -либо было такой вещи, не сдерживается. Операторы Opentelemetry не могут рассматривать услуги как черные ящики. Они должны рассмотреть базовый стек и структуру и научиться их соответствующей настройке.
На JVM я бы порекомендовал придерживаться агента Java как можно больше, но если вам нужно пересечь стеки, магического решения нет.
Идти дальше:
- Maven - Введение в механизм зависимости
- Эффективная ржавчина - Пункт 25: Управляйте графиком зависимости
Первоначально опубликовано вJava Geek10 августа 2025 года
Оригинал