Углубляемся в сборщик OpenTelemetry

Сборщик OpenTelemetry находится в центре архитектуры OpenTelemetry, но не связан с контекстом трассировки W3C. В своей демонстрации трассировки я использую Jaeger вместо Collector. Тем не менее, это повсеместно, как и в каждом сообщении, связанном с OpenTelemetry. Я хотел изучить это дальше.

В этом посте я рассматриваю различные аспекты Collector:

• Тип данных: журналы, метрики и трассировки.
• Модели «толкай и тяни»
• Операции: чтение, преобразование и запись.

Первые шаги

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

Prometheus — одно из основных решений для мониторинга. Он работает по модели извлечения: Prometheus очищает совместимые конечные точки вашего приложения (приложений) и сохраняет их внутри себя.

Мы будем использовать OTEL Collector для очистки конечной точки, совместимой с Prometheus, и распечатки результата в консоли. Grafana Labs предлагает проект , который генерирует случайные метрики для экспериментов. Для простоты я буду использовать Docker Compose; установка выглядит следующим образом:

 version: "3" services: fake-metrics: build: ./fake-metrics-generator #1 collector: image: otel/opentelemetry-collector:0.87.0 #2 environment: #3 - METRICS_HOST=fake-metrics - METRICS_PORT=5000 volumes: - ./config/collector/config.yml:/etc/otelcol/config.yaml:ro #4

1. Для проекта поддельных метрик нет образа Docker; следовательно, нам нужно его построить
2. Последняя версия OTEL Collector на момент написания статьи.
3. Параметризируйте следующий файл конфигурации
4. Все происходит здесь

Как я уже упоминал выше, OTEL Collector может многое. Следовательно, конфигурация — это все.

 receivers: #1 prometheus: #2 config: scrape_configs: #3 - job_name: fake-metrics #4 scrape_interval: 3s static_configs: - targets: [ "${env:METRICS_HOST}:${env:METRICS_PORT}" ] exporters: #5 logging: #6 loglevel: debug service: pipelines: #7 metrics: #8 receivers: [ "prometheus" ] #9 exporters: [ "logging" ] #9

1. Список получателей. Получатель считывает данные; он может быть либо на основе push, либо на основе pull.
2. Мы используем предопределенный приемник prometheus
3. Определение заданий извлечения
4. Конфигурация задания
5. Список экспортеров. В отличие от получателей, экспортер записывает данные.
6. Самый простой экспортер — запись данных на стандартный выход
7. Трубопроводы собирают приемники и экспортеры
8. Определите конвейер, связанный с метриками
9. Конвейер получает данные от заранее определенного приемника prometheus и отправляет их экспортеру logging , т. е . печатает их.

Вот пример результата:

 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 83.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #1 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__embrace_world_class_systems: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(extranet) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(challenge) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(support) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__strategize_strategic_initiatives: Str(internet_solution) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__whiteboard_innovative_partnerships: Str(matrices) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 53.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #2 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__expedite_distributed_partnerships: Str(approach) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(policy) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(algorithm) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 16.440000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #3 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(extranet)

Помимо печати

Вышеупомянутое — отличный первый шаг, но это нечто большее, чем просто вывод на консоль. Мы предоставим метрики для очистки обычным экземпляром Prometheus; мы можем добавить панель управления Grafana для их визуализации. Хотя это может показаться бессмысленным, терпите, поскольку это всего лишь ступенька.

Для достижения вышеизложенного мы лишь меняем конфигурацию OTEL Collector:

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3

1. Добавьте экспортер prometheus
2. Предоставление конечной точки, совместимой с Prometheus
3. Замените печать экспонированием

Вот и все. OTEL Collector очень гибок.

Обратите внимание, что коллектор имеет несколько входов и несколько выходов. Чтобы распечатать данные и предоставить их через конечную точку, мы добавляем их в конвейер:

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3

1. Раскрыть данные
2. Распечатать данные
3. Конвейер будет как печатать данные, так и предоставлять их.

Настроив экспортер Prometheus, мы можем визуализировать метрики в Grafana.

Обратите внимание, что получатели и экспортеры указывают свой тип , и каждый из них должен быть уникальным. Чтобы соответствовать последнему требованию, мы можем добавить квалификатор, чтобы различать их, например , prometheus/foo и prometheus/bar.

Посредническая обработка данных

Правильный вопрос: почему OTEL Collector устанавливается между исходником и Prometheus, поскольку это делает общую конструкцию более хрупкой. На этом этапе мы можем использовать истинную мощь OTEL Collector: обработку данных. На данный момент мы получили необработанные метрики, но исходный формат может быть не адаптирован к тому, как мы хотим визуализировать данные. Например, в нашей настройке метрики берутся из нашего поддельного генератора «бизнес» и базовой платформы NodeJS «технические». Это отражено в названии метрики. Мы могли бы добавить специальную метку источника и удалить ненужный префикс, чтобы фильтровать более эффективно.

Обработчики данных объявляются в разделе processors файла конфигурации. Сборщик выполняет их в том порядке, в котором они объявлены. Давайте реализуем вышеуказанное преобразование.

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

 collector: image: otel/opentelemetry-collector-contrib:0.87.0 #1 environment: - METRICS_HOST=fake-metrics - METRICS_PORT=5000 - PROMETHEUS_PORT=8889 volumes: - ./config/collector/config.yml:/etc/otelcol-contrib/config.yaml:ro #2

1. Используйте вкус contrib
2. Для большего удовольствия файл конфигурации находится по другому пути.

На этом этапе мы можем добавить сам процессор:

 processors: metricstransform: #1 transforms: #2 - include: ^fake_(.*)$ #3 match_type: regexp #3 action: update operations: #4 - action: add_label #5 new_label: origin new_value: fake - include: ^fake_(.*)$ match_type: regexp action: update #6 new_name: $${1} #6-7 # Do the same with metrics generated by NodeJS

1. Вызов процессора преобразования метрик
2. Список преобразований, примененных по порядку
3. Соответствует всем метрикам определенному регулярному выражению.
4. Список операций, применяемых по порядку
5. Добавить ярлык
6. Переименуйте метрику, удалив префикс группы регулярных выражений.
7. Забавная штука: синтаксис: $${x}

Наконец, мы добавляем определенный процессор в конвейер:

 service: pipelines: metrics: receivers: [ "prometheus" ] processors: [ "metricstransform" ] exporters: [ "prometheus" ]

Вот результаты:

Подключение ресиверов и экспортеров

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

Давайте сначала добавим получатель журнала:

 receivers: filelog: include: [ "/var/logs/generated.log" ]

Затем добавляем соединитель:

 connectors: count: requests.errors: description: Number of 500 errors condition: [ "status == 500 " ]

Наконец, подключаем приемник журналов и экспортер метрик:

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "count" ] metrics: receivers: [ "prometheus", "count" ]

Метрика называется log_record_count_total , но ее значение остается равным 1.

Манипулирование журналами

Процессоры позволяют манипулировать данными; операторы — это специализированные процессоры, работающие с журналами. Если вы знакомы со стеком Elasticsearch Logstash Kibana, они являются эквивалентом Logstash.

На данный момент временная метка журнала является временной меткой приема. Мы изменим его на временную метку его создания.

 receivers: filelog: include: [ "/var/logs/generated.log" ] operators: - type: json_parser #1 timestamp: #2 parse_from: attributes.datetime #3 layout: "%d/%b/%Y:%H:%M:%S %z" #4 severity: #2 parse_from: attributes.status #3 mapping: #5 error: 5xx #6 warn: 4xx info: 3xx debug: 2xx - id: remove_body #7 type: remove field: body - id: remove_datetime #7 type: remove field: attributes.datetime - id: remove_status #7 type: remove field: attributes.status

1. Журнал ведется в формате JSON; мы можем использовать предоставленный парсер JSON
2. Атрибуты метаданных для установки
3. Поля для чтения
4. Шаблон синтаксического анализа
5. Таблица сопоставления
6. Примите диапазон, например 501-599 . Оператор имеет специальное интерпретируемое значение 5xx (и подобное) для статусов HTTP.
7. Удалить дублированные данные

Журналы

На этом этапе мы можем отправлять журналы в любой компонент агрегирования журналов. Мы останемся в сфере Grafana Labs и будем использовать Loki.

 exporters: loki: endpoint: "http://loki:3100/loki/api/v1/push"

Также мы можем использовать логи самого сборщика:

 service: telemetry: logs:

Наконец, давайте добавим еще один конвейер:

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "loki" ]

Grafana также может визуализировать журналы. Выберите Локи в качестве источника данных.

Заключение

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

Полный исходный код этого поста можно найти на GitHub .

Чтобы пойти дальше:

• Сборщик OpenTelemetry
• Операторы OpenTelemetry