Explorando o OpenTelemetry Collector

O OpenTelemetry Collector está no centro da arquitetura do OpenTelemetry, mas não está relacionado ao W3C Trace Context. No meu demo de rastreamento, utilizo o Jaeger em vez do Collector. No entanto, é onipresente, como em cada post relacionado ao OpenTelemetry. Eu queria explorá-lo mais a fundo.

Neste post, explorarei os diferentes aspectos do Collector:

  • O tipo de dados: logs, métricas e rastreamentos
  • Modelos de push e pull
  • Operações: leituras, transformações e escritas

Primeiros Passos

A long time ago, observability as we know it didn’t exist; what we had instead was monitoring. Back then, monitoring was a bunch of people looking at screens displaying dashboards. Dashboards themselves consisted of metrics and only system metrics, mainly CPU, memory, and disk usage. For this reason, we will start with metrics.

Prometheus é uma das principais soluções de monitoramento. Funciona com um modelo baseado em pull: o Prometheus raspia endpoints compatíveis de seu aplicativo(s) e armazena-os internamente.

Utilizaremos o OTEL Collector para raspar um endpoint compatível com o Prometheus e imprimir o resultado no console. A Grafana Labs oferece um projeto que gera métricas aleatórias para brincar. Por simplicidade, usarei o Docker Compose; a configuração é a seguinte:

YAML

 

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. Não há imagem Docker disponível para o projeto de métricas falsas; portanto, precisamos criá-la
  2. Versão mais recente do OTEL Collector no momento da redação deste texto
  3. Parametrizar o seguinte arquivo de configuração
  4. Tudo acontece aqui

Como mencionei acima, o OTEL Collector pode fazer muito. Portanto, a configuração é tudo.

YAML

 

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" ]                                              #10

  1. Lista de receptores. Um receptor lê dados; pode ser baseado em push ou pull.
  2. Utilizamos o receptor pré-definido prometheus
  3. Definir trabalhos de pull
  4. Configuração do trabalho
  5. Lista de exportadores. Em contraste aos receptores, um exportador escreve dados.
  6. O exportador mais simples é escrever dados no standard out
  7. Pipelines montam receptores e exportadores
  8. Definir um pipeline relacionado a métricas
  9. O pipeline obtém dados do receptor prometheus previamente definido e os envia para o exportador logging, ou seja, imprime-os

Aqui está um exemplo do resultado:

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)

Além da Impressão

O que foi mencionado é um excelente primeiro passo, mas há mais do que apenas imprimir no console. Vamos expor as métricas para serem raspadas por uma instância regular de Prometheus; podemos adicionar um painel do Grafana para visualizá-las. Embora possa parecer inútil, tenha paciência, pois é apenas um passo.

Para alcançar o que foi mencionado, basta alterar a configuração do OTEL Collector:

YAML

 

exporters:
  prometheus:                                                               #1
    endpoint: ":${env:PROMETHEUS_PORT}"                                     #2

service:
  pipelines:
    metrics:
      receivers: [ "prometheus" ]
      exporters: [ "prometheus" ]                                           #3

  1. Adicionar um exportador prometheus
  2. Expor um ponto final compatível com o Prometheus
  3. Substituir impressão por exposição

É isso. O OTEL Collector é muito flexível.

Note que o Collector é multi-entrada, multi-saída. Para imprimir dados e expor-se através do ponto final, adicionamos-os ao pipeline:

YAML

 

exporters:
  prometheus:                                                               #1
    endpoint: ":${env:PROMETHEUS_PORT}"
  logging:                                                                  #2
    loglevel: debug

service:
  pipelines:
    metrics:
      receivers: [ "prometheus" ]
      exporters: [ "prometheus", "logging" ]                                #3

  1. Expor dados
  2. Imprimir dados
  3. A pipeline irá imprimir dados e expor-los

Com o exportador do Prometheus configurado, podemos visualizar métricas no Grafana.

Note que os receptores e exportadores especificam seu tipo e cada um deles deve ser único. Para cumprir com o último requisito, podemos adicionar um qualificador para distinguir entre eles, por exemplo, prometheus/foo e prometheus/bar.

Processamento de Dados Intermediário

A valid question would be why the OTEL Collector is set between the source and Prometheus, as it makes the overall design more fragile. At this stage, we can leverage the true power of the OTEL Collector: data processing. So far, we have ingested raw metrics, but the source format may not be adapted to how we want to visualize data. For example, in our setup, metrics come from our fake generator, “business,” and the underlying NodeJS platform, “technical.” It is reflected in the metrics’ name. We could add a dedicated source label and remove the unnecessary prefix to filter more efficiently.

Você declara processadores de dados na seção processadores do arquivo de configuração. O coletor os executa na ordem em que são declarados. Vamos implementar a transformação acima.

O primeiro passo para atingir nosso objetivo é entender que o coletor possui duas versões: uma “básica” e uma contrib que se baseia nela. Os processadores incluídos na primeira são limitados, tanto em número quanto em capacidades; portanto, precisamos mudar para a versão contrib.

YAML

 

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. Use o sabor contrib
  2. Para adicionar diversão, o arquivo de configuração está em outro caminho

Neste ponto, podemos adicionar o próprio processador:

YAML

 

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
# Faça o mesmo com as métricas geradas pelo NodeJS

  1. Chame o processador de transformação de métricas
  2. Lista de transformações aplicadas em ordem
  3. Corresponde a todas as métricas com o regexp definido
  4. Lista de operações aplicadas em ordem
  5. Adicione a etiqueta
  6. Renomeie a métrica removendo o prefixo do grupo de regexp
  7. Coisas divertidas: a sintaxe é $${x}

Finalmente, adicionamos o processador definido à pipeline:

YAML

 

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

Aqui estão os resultados:

Conectando Receptores e Exportadores

A connector is both a receiver and an exporter and connects two pipelines. The example from the documentation receives the number of spans (tracing) and exports the count, which has a metric. I tried to achieve the same with 500 errors — spoiler: it doesn’t work as intended.

Primeiro, vamos adicionar um receptor de logs:

YAML

 

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

Em seguida, adicionamos um conector:

YAML

 

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

Por fim, conectamos o receptor de logs e o exportador de métricas:

YAML

 

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

A métrica é nomeada como log_record_count_total, mas seu valor permanece em 1.

Manipulação de Logs

Os processadores permitem a manipulação de dados; os operadores são processadores especializados que trabalham com logs. Se você está familiarizado com a pilha ELK, eles são equivalentes ao Logstash.

Até agora, o timestamp do log é o timestamp de ingestão. Vamos mudá-lo para o timestamp de criação.

YAML

 

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. O log está no formato JSON; podemos usar o parser JSON fornecido
  2. Atributos de metadados a serem definidos
  3. Campos a serem lidos
  4. Padrão de parsing
  5. Tabela de mapeamento
  6. Aceitar uma faixa, por exemplo, 501-599. O operador tem um valor interpretado especial 5xx (e similares) para status HTTP.
  7. Remover dados duplicados

Logs

Neste ponto, podemos enviar os logs para qualquer componente de agregação de logs. Vamos permanecer no ecossistema Grafana Labs e usar o Loki.

YAML

 

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

Também podemos usar logs do próprio coletor:

YAML

 

service:
  telemetry:
    logs:

Finalmente, vamos adicionar outra pipeline:

YAML

 

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

O Grafana também pode visualizar os logs. Escolha o Loki como fonte de dados.

Conclusão

Neste post, exploramos o coletor OpenTelemetry. Embora não seja um componente obrigatório da arquitetura OTEL, é uma ferramenta suíça útil para todos os seus processamentos de dados. Caso você não esteja preso a uma pilha específica ou não queira, isso é de grande ajuda.

O código-fonte completo deste post pode ser encontrado no GitHub.

Para Ir Além

Source:
https://dzone.com/articles/exploring-the-opentelemetry-collector