Что такое OpenTelemetry и как она может улучшить качество вашей серверной части?

Раньше, когда мы говорили о бэкэнде, мы обычно имели в виду одно большое приложение с одной большой базой данных, и для мониторинга было достаточно журналирования. Теперь, благодаря таким технологиям, как Kubernetes , микросервисы стали стандартом. Приложения стали более многочисленными и распределенными, а традиционного журналирования уже недостаточно для отладки и диагностики проблем в наших приложениях.

Отличным решением для организации мониторинга является OpenTelemetry — современный набор инструментов, который можно использовать для отладки и анализа производительности распределенных систем.

Эта статья предназначена для ИТ-специалистов, желающих расширить свои знания в области серверной оптимизации. Ниже мы подробно опишем, что такое OpenTelemetry, его ключевые концепции и проблемы, которые он помогает решить. Если вас интересует, как OpenTelemetry может изменить ваш подход к мониторингу и отладке серверных систем, повысив их надежность и эффективность — читайте дальше.

Краткая история OpenTelemetry

Крупные технологические компании впервые столкнулись с проблемой распределенного журналирования и отслеживания в конце 2000-х годов. В 2010 году Google опубликовал статью, Dapper, инфраструктура отслеживания крупномасштабных распределенных систем , который заложил основу для инструмента отслеживания Twitter Zipkin, выпущенного в 2012 году.

В 2014 году появился Kubernetes, существенно упростивший разработку микросервисов и других облачно-распределенных систем. Это привело к тому, что многие компании столкнулись с проблемами распределенного ведения журналов и трассировки в микросервисах. Для стандартизации распределенной трассировки был создан стандарт OpenTracing, принятый CNCF, и проект Google OpenCensus.

В 2019 году проекты OpenTracing и OpenCensus объявили о слиянии под названием OpenTelemetry. Эта платформа сочетает в себе лучшие практики, накопленные за многие годы, позволяя плавно интегрировать трассировку, журналирование и метрики в любую систему, независимо от ее сложности.

Сегодня OpenTelemetry — это не просто проект; это отраслевой стандарт сбора и передачи телеметрических данных. Он разрабатывается и поддерживается сообществом специалистов и ведущих компаний на рынке, таких как Google и Microsoft. Проект продолжает развиваться, приобретая новые возможности для упрощения процесса интеграции и использования.

Что внутри?

OpenTelemetry — это комплексный набор практик и инструментов, определяющих, какие сигналы может генерировать приложение для взаимодействия с внешним миром, а также то, как эти сигналы можно собирать и визуализировать для мониторинга состояния приложений и системы в целом. Тремя основными типами сигналов являются трассировка, регистрация и сбор метрик .

**Давайте подробнее рассмотрим каждый компонент: \

Контексты

OpenTelemetry представляет концепцию контекстов операций. Контекст в первую очередь включает в себя такие атрибуты, как `trace_id` (идентификатор текущей операции) и `span_id` (идентификатор подзапроса, причем каждая повторная попытка подзапроса имеет уникальный `span_id` ).

Кроме того, контекст может содержать статическую информацию, например имя узла, на котором развернуто приложение, или имя среды (prod/qa). Эти поля, известные как ресурсы в терминологии OpenTelemetry, прикрепляются к каждому журналу, метрике или трассировке для облегчения поиска. Контексты также могут включать в себя динамические данные, такие как идентификатор текущей конечной точки ( `http_path: "GET /user/:id/info"` ), которые можно выборочно прикреплять к группам журналов, метрик или трассировок.

Контексты OpenTelemetry могут передаваться между различными приложениями с использованием протоколов распространения контекста. Эти протоколы состоят из наборов заголовков, которые добавляются к каждому запросу HTTP или gRPC или к заголовкам сообщений для очередей. Это позволяет нижестоящим приложениям восстанавливать контекст операции на основе этих заголовков.

Вот несколько примеров распространения контекста:

1. B3-Propagation Это набор заголовков ( x-b3-* ), изначально разработанный для системы трассировки Zipkin. Он был адаптирован в OpenTracing и использовался многими инструментами и библиотеками. B3-Propagation несет в себе trace_id / span_id и флаг, указывающий, необходима ли выборка.

   
   

2. Контекст трассировки W3C. Этот стандарт, разработанный рабочей группой W3C, объединяет различные подходы к распространению контекста в единый стандарт и используется по умолчанию в OpenTelemetry. Хорошим примером применения этих стандартов является отслеживание выполнения запроса, проходящего через микросервисы, реализованные с использованием различных технологий, без ущерба для точности мониторинга и отладки.

Отслеживание

Трассировка — это процесс записи и последующей визуализации временной шкалы пути запроса через несколько микросервисов.

В визуализации каждый столбец называется «промежутком» и имеет уникальный «span_id» . Корневой диапазон называется «трассировкой» и имеет «trace_id» , который служит идентификатором всего запроса.

Этот тип визуализации позволяет:

• Анализируйте время выполнения запросов в различных системах и базах данных, чтобы выявить узкие места, требующие оптимизации.
• Обнаружение циклических зависимостей между сервисами.
• Найдите повторяющиеся запросы. Используя данные трассировки, вы также можете построить дополнительную аналитику, например создать карту микросервисов или распределить время по разным системам при обработке операций. Даже если вы не используете данные трассировки для визуализации временных шкал, OpenTelemetry по-прежнему trace_id и span_id для использования в других сигналах.

Журналы

Несмотря на кажущуюся простоту, ведение журнала остается одним из самых мощных инструментов диагностики проблем. OpenTelemetry расширяет возможности традиционного ведения журналов, добавляя контекстную информацию. В частности, если присутствует активная трассировка, атрибуты «trace_id» и «span_id» автоматически добавляются в журналы, связывая их с временной шкалой трассировки. Более того, атрибуты журнала могут включать статическую информацию из контекста OpenTelemetry, такую как идентификатор узла, а также динамическую информацию, такую как текущий идентификатор конечной точки HTTP (`http_path: "GET /user/:id"`).

Используя «trace_id», вы можете найти журналы всех микросервисов, связанных с текущим запросом, а «span_id» позволяет различать подзапросы. Например, в случае повторных попыток журналы разных попыток будут иметь разные `span_id`. Использование этих идентификаторов позволяет быстро анализировать поведение всей системы в режиме реального времени, ускоряя диагностику проблем и повышая стабильность и надежность.

Метрики

Сбор метрик предоставляет количественные данные о производительности системы, такие как задержка, частота ошибок, использование ресурсов и многое другое. Мониторинг метрик в режиме реального времени позволяет оперативно реагировать на изменения производительности, предотвращать сбои и исчерпание ресурсов, а также обеспечивать высокую доступность и надежность приложения для пользователей.

Интеграция с системами хранения и визуализации показателей, такими как Prometheus и Grafana, упрощает визуализацию этих данных, что значительно упрощает мониторинг.

Метрические коллекторы

Сборщики метрик OpenTelemetry совместимы со стандартами Prometheus и OpenMetrics, что позволяет легко перейти к решениям OpenTelemetry без существенных изменений. Пакет SDK OpenTelemetry позволяет экспортировать примеры трассировки_id вместе с метриками, что позволяет сопоставлять метрики с примерами журналов и трассировками.

Корреляция сигналов

Вместе журналы, метрики и трассировка создают комплексное представление о состоянии системы:

• Журналы предоставляют информацию о системных событиях, что позволяет быстро выявлять и устранять ошибки.
• Метрики отражают качественные и количественные показатели производительности системы, такие как время отклика или частота ошибок.
• Трассировка дополняет это представление, показывая путь выполнения запроса через различные компоненты системы, помогая понять их взаимосвязи. Четкая корреляция между журналами, трассировками и метриками — отличительная особенность OpenTelemetry. Например, Grafana позволяет пользователям видеть соответствующие метрики трассировки и запросов при просмотре журнала, что значительно повышает удобство и эффективность использования платформы.

В дополнение к трем основным компонентам OpenTelemetry включает в себя концепции отбора проб, багажа и управления контекстом операций.

Выборка

В высоконагруженных системах объем журналов и трассировок становится огромным, что требует значительных ресурсов для инфраструктуры и хранения данных. Чтобы решить эту проблему, стандарты OpenTelemetry включают выборку сигналов — возможность экспортировать только часть трассировок и журналов. Например, вы можете экспортировать подробные сигналы по проценту запросов, длительным запросам или запросам с ошибками. Этот подход позволяет получить достаточную выборку для построения статистики, экономя при этом значительные ресурсы.

Однако если каждая система самостоятельно решает, какие запросы отслеживать детально, мы получаем фрагментированное представление каждого запроса. Некоторые системы могут экспортировать подробные данные, тогда как другие могут экспортировать только частично или не экспортировать вообще.

Чтобы решить эту проблему, механизмы распространения контекста OpenTelemetry передают флаг выборки вместе с `trace_id`/`span_id`. Это гарантирует, что если первоначальная служба, получающая запрос пользователя, решит, что запрос следует тщательно отслеживать, все остальные системы последуют этому примеру. В противном случае все системы должны частично или не экспортировать сигналы для экономии ресурсов. Этот подход называется «Head Sampling» — решение, принимаемое в начале обработки запроса либо случайным образом, либо на основе некоторых входных атрибутов.

Кроме того, OpenTelemetry поддерживает «хвостовую выборку», при которой все приложения всегда подробно экспортируют все сигналы, но существует промежуточный буфер. После сбора всех данных этот буфер решает, следует ли сохранить полные данные или сохранить только частичную выборку. Этот метод позволяет получить более репрезентативную выборку каждой категории запросов (успешные/долгие/ошибочные), но требует дополнительной настройки инфраструктуры.

Багаж

Механизм Baggage позволяет передавать произвольные пары ключ-значение вместе с trace_id / span_id , автоматически проходя между всеми микросервисами во время обработки запроса. Это полезно для передачи дополнительной информации, необходимой по всему пути запроса, например информации о пользователе или настройках среды выполнения.

Пример заголовка для передачи багажа по стандарту W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Вот несколько примеров использования багажа:

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

• Настройки конкретных параметров конфигурации для SDK или инфраструктуры.

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

  
  

Реализация инфраструктуры

Реализация OpenTelemetry на уровне инфраструктуры включает интеграцию серверных частей OpenTelemetry в архитектуру приложения и настройку инфраструктуры для агрегирования данных.

Процесс состоит из четырех этапов:

1. Интеграция приложений На первом этапе пакеты OpenTelemetry SDK напрямую интегрируются в приложения для сбора метрик, журналов и трассировок, обеспечивая непрерывный поток данных о производительности каждого компонента системы.

   
   

2. Настройка экспортеров Собранные данные передаются из приложений через экспортеры во внешние системы для дальнейшей обработки, например, в системы регистрации, мониторинга, отслеживания или анализа, в зависимости от ваших потребностей.

   
   

3. Агрегация и хранение. Этот этап может включать в себя нормализацию данных, обогащение их дополнительной информацией и объединение данных из разных источников для создания единого представления о состоянии системы.

   
   

4. Визуализация данных Наконец, обработанные данные представлены в виде информационных панелей в таких системах, как Grafana (для метрик и трассировок) или Kibana (для журналов). Это позволяет командам быстро оценивать состояние системы, выявлять проблемы и тенденции, а также настраивать оповещения на основе сгенерированных сигналов.

Реализация приложения

Для интеграции с приложением вам необходимо подключить соответствующий пакет OpenTelemetry SDK для используемого языка программирования или использовать библиотеки и платформы, которые напрямую поддерживают OpenTelemetry. OpenTelemetry часто реализует широко используемые интерфейсы из известных библиотек, допуская их замену. Например, библиотека Micrometer обычно используется для сбора метрик в экосистеме Java. OpenTelemetry SDK предоставляет свои реализации интерфейсов Micrometer, позволяющие экспортировать метрики без изменения основного кода приложения. Более того, OpenTelemetry предлагает реализации старых интерфейсов OpenTracing и OpenCensus, что облегчает плавный переход на OpenTelemetry.

Заключение

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