Configuração

É possível configurar o OpenTelemetry Collector para atender às necessidades de observabilidade. Antes de aprender como a configuração do Collector funciona, familiarize-se com o seguinte conteúdo:

• Conceitos de coleta de dados, para entender os repositórios aplicáveis ao OpenTelemetry Collector.
• Orientações de segurança para usuários finais
• Orientações de segurança para desenvolvedores de componentes

Localização

Por padrão, a configuração do Collector está localizada em /etc/<otel-directory>/config.yaml, onde <otel-directory> pode ser otelcol, otelcol-contrib ou outro valor, dependendo da versão do Collector ou da distribuição do Collector utilizada.

É possível fornecer uma ou mais configurações usando a opção --config. Por exemplo:

otelcol --config=customconfig.yaml

A flag --config aceita um caminho de arquivo ou valores na forma de uma URI de configuração "<scheme>:<opaque_data>". Atualmente, o OpenTelemetry Collector suporta os seguintes provedores para scheme:

• file - Lê a configuração de um arquivo. Ex.: file:path/to/config.yaml.
• env - Lê a configuração de uma variável de ambiente. Ex.: env:MY_CONFIG_IN_AN_ENVVAR.
• yaml - Lê a configuração de uma string YAML, com :: delimitando subcaminhos. Ex.: yaml:exporters::debug::verbosity: detailed.

• http - Lê a configuração de uma URI HTTP. Ex.: http://www.example.com
• https - Lê a configuração de uma URI HTTPS. Ex.: https://www.example.com

Também é possível fornecer múltiplas configurações usando múltiplos arquivos em caminhos diferentes. Cada arquivo pode ser uma configuração completa ou parcial, e os arquivos podem referenciar componentes uns dos outros. Se a combinação dos arquivos não constituir uma configuração completa, o usuário recebe um erro, pois componentes obrigatórios não são adicionados por padrão. Passe múltiplos caminhos de arquivo na linha de comando da seguinte forma:

otelcol --config=file:/path/to/first/file --config=file:/path/to/second/file

Também é possível fornecer configurações usando variáveis de ambiente, URIs HTTP ou caminhos YAML. Por exemplo:

otelcol --config=env:MY_CONFIG_IN_AN_ENVVAR --config=https://server/config.yaml
otelcol --config="yaml:exporters::debug::verbosity: normal"

Para validar um arquivo de configuração, use o comando validate. Por exemplo:

otelcol validate --config=customconfig.yaml

Estrutura da configuração

A estrutura de qualquer arquivo de configuração do Collector consiste em quatro classes de componentes de pipeline que acessam dados de telemetria:

• Receivers
• Processors
• Exporters
• Connectors

Após cada componente de pipeline ser configurado, é necessário habilitá-lo usando as pipelines na seção service do arquivo de configuração.

Além dos componentes de pipeline, também é possível configurar extensions, que fornecem capacidades que podem ser adicionadas ao Collector, como ferramentas de diagnóstico. Extensions não exigem acesso direto aos dados de telemetria e são habilitadas por meio da seção service.

A seguir, um exemplo de configuração do Collector com um receiver, um processor, um exporter e três extensions.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlp_grpc:
    endpoint: otelcol:4317
    sending_queue:
      batch:

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_grpc]
    metrics:
      receivers: [otlp]
      exporters: [otlp_grpc]
    logs:
      receivers: [otlp]
      exporters: [otlp_grpc]

Note que receivers, processors, exporters e pipelines são definidos por meio de identificadores de componente seguindo o formato type[/name], por exemplo otlp ou otlp/2. É possível definir componentes de um mesmo tipo mais de uma vez, desde que os identificadores sejam únicos. Por exemplo:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  otlp/2:
    protocols:
      grpc:
        endpoint: 0.0.0.0:55690

exporters:
  otlp_grpc:
    endpoint: otelcol:4317
    sending_queue:
      batch:
  otlp_grpc/2:
    endpoint: otelcol2:4317
    sending_queue:
      batch:

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_grpc]
    traces/2:
      receivers: [otlp/2]
      exporters: [otlp_grpc/2]
    metrics:
      receivers: [otlp]
      exporters: [otlp_grpc]
    logs:
      receivers: [otlp]
      exporters: [otlp_grpc]

A configuração também pode incluir outros arquivos, fazendo com que o Collector os combine em uma única representação em memória da configuração YAML:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters: ${file:exporters.yaml}

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp_grpc]

Sendo o arquivo exporters.yaml:

otlp_grpc:
  endpoint: otelcol.observability.svc.cluster.local:443

O resultado final em memória será:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  otlp_grpc:
    endpoint: otelcol.observability.svc.cluster.local:443

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp_grpc]

Receivers

Receivers coletam telemetria de uma ou mais fontes. Eles podem ser baseados em pull ou push, e podem suportar uma ou mais fontes de dados.

Receivers são configurados na seção receivers. Muitos receivers vêm com configurações padrão, de modo que especificar o nome do receiver é suficiente para configurá-lo. Caso seja necessário configurar um receiver ou alterar a configuração padrão, isso pode ser feito nesta seção. Qualquer configuração especificada sobrescreve os valores padrão, se presentes.

Configurar um receiver não o habilita. Receivers são habilitados ao serem adicionados às pipelines apropriadas na seção service.

O Collector exige um ou mais receivers. O exemplo a seguir mostra vários receivers no mesmo arquivo de configuração:

receivers:
  # Fontes de dados: logs
  fluentforward:
    endpoint: 0.0.0.0:8006

  # Fontes de dados: métricas
  host_metrics:
    scrapers:
      cpu:
      disk:
      filesystem:
      load:
      memory:
      network:
      process:
      processes:
      paging:

  # Fontes de dados: rastros
  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      thrift_binary:
      thrift_compact:
      thrift_http:

  # Fontes de dados: rastros, métricas, logs
  kafka:
    protocol_version: 2.0.0

  # Fontes de dados: rastros, métricas
  opencensus:

  # Fontes de dados: rastros, métricas, logs
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: cert.pem
          key_file: cert-key.pem
      http:
        endpoint: 0.0.0.0:4318

  # Fontes de dados: métricas
  prometheus:
    config:
      scrape_configs:
        - job_name: otel-collector
          scrape_interval: 5s
          static_configs:
            - targets: [localhost:8888]

  # Fontes de dados: rastros
  zipkin:

Para configuração detalhada de receivers, consulte o README de receivers.

Processors

Processors recebem os dados coletados pelos receivers e os modificam ou transformam antes de enviá-los aos exporters. O processamento de dados ocorre de acordo com regras ou configurações definidas para cada processor, que podem incluir filtrar, descartar, renomear ou recalcular telemetria, entre outras operações. A ordem dos processors em uma pipeline determina a ordem das operações de processamento que o Collector aplica ao sinal.

Processors são opcionais, embora alguns sejam recomendados.

Processors podem ser configurados usando a seção processors do arquivo de configuração do Collector. Qualquer configuração especificada sobrescreve os valores padrão, se presentes.

Configurar um processor não o habilita. Processors são habilitados ao serem adicionados às pipelines apropriadas na seção service.

O exemplo a seguir mostra vários processors padrão no mesmo arquivo de configuração. A lista completa de processors pode ser encontrada combinando a lista do opentelemetry-collector-contrib com a lista do opentelemetry-collector.

processors:
  # Fontes de dados: rastros
  attributes:
    actions:
      - key: environment
        value: production
        action: insert
      - key: db.statement
        action: delete
      - key: email
        action: hash

  # Fontes de dados: rastros, métricas, logs
  filter:
    error_mode: ignore
    traces:
      span:
        - 'attributes["container.name"] == "app_container_1"'
        - 'resource.attributes["host.name"] == "localhost"'
        - 'name == "app_3"'
      spanevent:
        - 'attributes["grpc"] == true'
        - 'IsMatch(name, ".*grpc.*")'
    metrics:
      metric:
        - 'name == "my.metric" and resource.attributes["my_label"] == "abc123"'
        - 'type == METRIC_DATA_TYPE_HISTOGRAM'
      datapoint:
        - 'metric.type == METRIC_DATA_TYPE_SUMMARY'
        - 'resource.attributes["service.name"] == "my_service_name"'
    logs:
      log_record:
        - 'IsMatch(body, ".*password.*")'
        - 'severity_number < SEVERITY_NUMBER_WARN'

  # Fontes de dados: rastros, métricas, logs
  memory_limiter:
    check_interval: 5s
    limit_mib: 4000
    spike_limit_mib: 500

  # Fontes de dados: rastros
  resource:
    attributes:
      - key: cloud.zone
        value: zone-1
        action: upsert
      - key: k8s.cluster.name
        from_attribute: k8s-cluster
        action: insert
      - key: redundant-attribute
        action: delete

  # Fontes de dados: rastros
  probabilistic_sampler:
    hash_seed: 22
    sampling_percentage: 15

  # Fontes de dados: rastros
  span:
    name:
      to_attributes:
        rules:
          - ^\/api\/v1\/document\/(?P<documentId>.*)\/update$
      from_attributes: [db.svc, operation]
      separator: '::'

Para configuração detalhada de processors, consulte o README de processors.

Exporters

Exporters enviam dados para um ou mais backends ou destinos. Exporters podem ser baseados em pull ou push, e podem suportar uma ou mais fontes de dados.

Cada chave na seção exporters define uma instância de exporter. A chave segue o formato type/name, onde type especifica o tipo do exporter (por exemplo, otlp, kafka, prometheus), e name (opcional) pode ser adicionado para fornecer um nome único para múltiplas instâncias do mesmo tipo.

A maioria dos exporters exige configuração para especificar pelo menos o destino, bem como configurações de segurança, como tokens de autenticação ou certificados TLS. Qualquer configuração especificada sobrescreve os valores padrão, se presentes.

Configurar um exporter não o habilita. Exporters são habilitados ao serem adicionados às pipelines apropriadas na seção service.

O Collector exige um ou mais exporters. O exemplo a seguir mostra vários exporters no mesmo arquivo de configuração:

exporters:
  # Fontes de dados: rastros, métricas, logs
  file:
    path: ./filename.json

  # Fontes de dados: rastros
  otlp_grpc/jaeger:
    endpoint: jaeger-server:4317
    tls:
      cert_file: cert.pem
      key_file: cert-key.pem

  # Fontes de dados: rastros, métricas, logs
  kafka:
    protocol_version: 2.0.0

  # Fontes de dados: rastros, métricas, logs
  # NOTA: antes da v0.86.0, use `logging` em vez de `debug`
  debug:
    verbosity: detailed

  # Fontes de dados: rastros, métricas
  opencensus:
    endpoint: otelcol2:55678

  # Fontes de dados: rastros, métricas, logs
  otlp_grpc:
    endpoint: otelcol2:4317
    tls:
      cert_file: cert.pem
      key_file: cert-key.pem

  # Fontes de dados: rastros, métricas
  otlp_http:
    endpoint: https://otlp.example.com:4318

  # Fontes de dados: métricas
  prometheus:
    endpoint: 0.0.0.0:8889
    namespace: default

  # Fontes de dados: métricas
  prometheus_remote_write:
    endpoint: http://prometheus.example.com:9411/api/prom/push
    # Ao usar o Prometheus oficial (executando via Docker)
    # endpoint: 'http://prometheus:9090/api/v1/write', adicione:
    # tls:
    #   insecure: true

  # Fontes de dados: rastros
  zipkin:
    endpoint: http://zipkin.example.com:9411/api/v2/spans

Observe que alguns exporters exigem certificados x.509 para estabelecer conexões seguras, conforme descrito em configuração de certificados.

Para mais informações sobre configuração de exporters, consulte o README.md de exporters.

Connectors

Connectors unem duas pipelines, atuando tanto como exporter quanto como receiver. Um connector consome dados como um exporter no final de uma pipeline e emite dados como um receiver no início de outra pipeline. Os dados consumidos e emitidos podem ser do mesmo tipo ou de tipos de dados diferentes. É possível usar connectors para resumir os dados consumidos, replicá-los ou roteá-los.

É possível configurar um ou mais connectors usando a seção connectors do arquivo de configuração do Collector. Por padrão, nenhum connector é configurado. Cada tipo de connector é projetado para funcionar com um ou mais pares de tipos de dados e só pode ser usado para conectar pipelines conformemente.

Configurar um connector não o habilita. Connectors são habilitados por meio das pipelines na seção service.

O exemplo a seguir mostra o connector count e como ele é configurado na seção pipelines. Observe que o connector atua como um exporter para rastros e como um receiver para métricas, conectando ambas as pipelines:

receivers:
  foo:

exporters:
  bar:

connectors:
  count:
    spanevents:
      my.prod.event.count:
        description: O número de eventos de trecho do meu ambiente de produção.
        conditions:
          - 'attributes["env"] == "prod"'
          - 'name == "prodevent"'

service:
  pipelines:
    traces:
      receivers: [foo]
      exporters: [count]
    metrics:
      receivers: [count]
      exporters: [bar]

Para configuração detalhada de connectors, consulte o README de connectors.

Extensions

Extensions são componentes opcionais que expandem as capacidades do Collector para realizar tarefas não diretamente envolvidas com o processamento de dados de telemetria. Por exemplo, é possível adicionar extensions para monitoramento de saúde do Collector, descoberta de serviços ou encaminhamento de dados, entre outras.

Extensions podem ser configuradas por meio da seção extensions do arquivo de configuração do Collector. A maioria das extensions vem com configurações padrão, então podem ser configuradas apenas especificando o nome da extension. Qualquer configuração especificada sobrescreve os valores padrão, se presentes.

Configurar uma extension não a habilita. Extensions são habilitadas na seção service.

Por padrão, nenhuma extension é configurada. O exemplo a seguir mostra várias extensions configuradas no mesmo arquivo:

extensions:
  health_check:
    endpoint: 0.0.0.0:13133
  pprof:
    endpoint: 0.0.0.0:1777
  zpages:
    endpoint: 0.0.0.0:55679

Para configuração detalhada de extensions, consulte o README de extensions.

Seção service

A seção service é usada para configurar quais componentes estão habilitados no Collector com base na configuração encontrada nas seções receivers, processors, exporters e extensions. Se um componente estiver configurado, mas não definido na seção service, ele não estará habilitado.

A seção service consiste em três subseções:

• Extensions
• Pipelines
• Telemetria

Extensions

A subseção extensions consiste em uma lista das extensions desejadas a serem habilitadas. Por exemplo:

service:
  extensions: [health_check, pprof, zpages]

Pipelines

A subseção pipelines é onde as pipelines são configuradas, que podem ser dos seguintes tipos:

• traces coleta e processa dados de rastros.
• metrics coleta e processa dados de métricas.
• logs coleta e processa dados de logs.

Uma pipeline consiste em um conjunto de receivers, processors e exporters. Antes de incluir um receiver, processor ou exporter em uma pipeline, certifique-se de definir sua configuração na seção apropriada.

É possível usar o mesmo receiver, processor ou exporter em mais de uma pipeline. Quando um processor é referenciado em múltiplas pipelines, cada pipeline obtém uma instância separada do processor.

A seguir, um exemplo de configuração de pipeline. Note que a ordem dos processors determina a ordem em que os dados são processados:

service:
  pipelines:
    metrics:
      receivers: [opencensus, prometheus]
      exporters: [opencensus, prometheus]
    traces:
      receivers: [opencensus, jaeger]
      processors: [memory_limiter]
      exporters: [opencensus, zipkin]

Assim como nos componentes, use a sintaxe type[/name] para criar pipelines adicionais para um mesmo tipo. Aqui está um exemplo estendendo a configuração anterior:

service:
  pipelines:
    # ...
    traces:
      # ...
    traces/2:
      receivers: [opencensus]
      exporters: [zipkin]

Telemetria

A seção de configuração telemetry é onde se configura a observabilidade do próprio Collector. Ela consiste em duas subseções: logs e metrics. Para aprender como configurar esses sinais, consulte Ativar telemetria interna no Collector.

Outras informações

Variáveis de ambiente

O uso e a expansão de variáveis de ambiente são suportados na configuração do Collector. Por exemplo, para usar os valores armazenados nas variáveis de ambiente DB_KEY e OPERATION, pode-se escrever o seguinte:

processors:
  attributes/example:
    actions:
      - key: ${env:DB_KEY}
        action: ${env:OPERATION}

É possível passar valores padrão para uma variável de ambiente usando a sintaxe bash: ${env:DB_KEY:-some-default-var}

processors:
  attributes/example:
    actions:
      - key: ${env:DB_KEY:-mydefault}
        action: ${env:OPERATION:-}

Use $$ para indicar um $ literal. Por exemplo, representar $DataVisualization ficaria assim:

exporters:
  prometheus:
    endpoint: prometheus:8889
    namespace: $$DataVisualization

Suporte a proxy

Exporters que usam o pacote net/http respeitam as seguintes variáveis de ambiente de proxy:

• HTTP_PROXY: Endereço do proxy HTTP
• HTTPS_PROXY: Endereço do proxy HTTPS
• NO_PROXY: Endereços que não devem usar o proxy

Se definidas no momento da inicialização do Collector, os exporters, independentemente do protocolo, enviarão o tráfego pelo proxy ou o ignorarão conforme definido por essas variáveis de ambiente.

Autenticação

A maioria dos receivers que expõem uma porta HTTP ou gRPC pode ser protegida usando o mecanismo de autenticação do Collector. Da mesma forma, a maioria dos exporters que usam clientes HTTP ou gRPC pode adicionar autenticação às requisições de saída.

O mecanismo de autenticação no Collector usa o mecanismo de extensions, permitindo que autenticadores personalizados sejam conectados às distribuições do Collector. Cada extension de autenticação tem dois usos possíveis:

• Como autenticador de cliente para exporters, adicionando dados de autenticação às requisições de saída
• Como autenticador de servidor para receivers, autenticando conexões de entrada.

Para uma lista de autenticadores conhecidos, consulte o Registro. Para desenvolver um autenticador personalizado, consulte Construindo uma extension de autenticador.

Para adicionar um autenticador de servidor a um receiver no Collector, siga estes passos:

1. Adicione a extension de autenticador e sua configuração em .extensions.
2. Adicione uma referência ao autenticador em .services.extensions, para que ele seja carregado pelo Collector.
3. Adicione uma referência ao autenticador em .receivers.<your-receiver>.<http-or-grpc-config>.auth.

O exemplo a seguir usa o autenticador OIDC no lado do receiver, tornando-o adequado para um Collector remoto que recebe dados de um OpenTelemetry Collector atuando como agente:

extensions:
  oidc:
    issuer_url: http://localhost:8080/auth/realms/opentelemetry
    audience: collector

receivers:
  otlp/auth:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        auth:
          authenticator: oidc

processors:

exporters:
  # NOTA: antes da v0.86.0, use `logging` em vez de `debug`.
  debug:

service:
  extensions:
    - oidc
  pipelines:
    traces:
      receivers:
        - otlp/auth
      processors: []
      exporters:
        - debug

No lado do agente, este é um exemplo que faz o exporter OTLP obter tokens OIDC, adicionando-os a cada chamada RPC a um Collector remoto:

extensions:
  oauth2client:
    client_id: agent
    client_secret: some-secret
    token_url: http://localhost:8080/auth/realms/opentelemetry/protocol/openid-connect/token

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:

exporters:
  otlp_grpc/auth:
    endpoint: remote-collector:4317
    auth:
      authenticator: oauth2client

service:
  extensions:
    - oauth2client
  pipelines:
    traces:
      receivers:
        - otlp
      processors: []
      exporters:
        - otlp_grpc/auth

Configurando certificados

Em um ambiente de produção, use certificados TLS para comunicação segura ou mTLS para autenticação mútua. Siga estes passos para gerar certificados autoassinados como neste exemplo. Também é possível usar os procedimentos atuais de provisionamento de certificados para obter um certificado para uso em produção.

Instale o cfssl e crie o seguinte arquivo csr.json:

{
  "hosts": ["localhost", "127.0.0.1"],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "O": "OpenTelemetry Example"
    }
  ]
}

Em seguida, execute os seguintes comandos:

cfssl genkey -initca csr.json | cfssljson -bare ca
cfssl gencert -ca ca.pem -ca-key ca-key.pem csr.json | cfssljson -bare cert

Isso cria dois certificados:

• Uma Autoridade Certificadora (CA) “OpenTelemetry Example” em ca.pem, com a chave associada em ca-key.pem
• Um certificado de cliente em cert.pem, assinado pela CA OpenTelemetry Example, com a chave associada em cert-key.pem.

Usando certificados no Collector

Depois de obter os certificados, configure o Collector para usá-los.

Configuração TLS para receivers (lado do servidor)

Configure TLS em um receiver para criptografar conexões de entrada. Use cert_file e key_file para especificar o certificado do servidor:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /path/to/cert.pem
          key_file: /path/to/cert-key.pem
      http:
        endpoint: 0.0.0.0:4318
        tls:
          cert_file: /path/to/cert.pem
          key_file: /path/to/cert-key.pem

Configuração TLS para exporters (lado do cliente)

Configure TLS em um exporter para criptografar conexões de saída. Use ca_file para verificar o certificado do servidor:

exporters:
  otlp_grpc:
    endpoint: otelcol2:4317
    tls:
      ca_file: /path/to/ca.pem

Caso também seja necessário apresentar um certificado de cliente ao servidor:

exporters:
  otlp_grpc:
    endpoint: otelcol2:4317
    tls:
      ca_file: /path/to/ca.pem
      cert_file: /path/to/cert.pem
      key_file: /path/to/cert-key.pem

Configuração mTLS (TLS mútuo)

Para mTLS, tanto o receiver quanto o exporter verificam os certificados um do outro. No receiver, adicione client_ca_file para verificar os certificados do cliente:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /path/to/server-cert.pem
          key_file: /path/to/server-key.pem
          client_ca_file: /path/to/ca.pem

No exporter, forneça tanto a CA para verificar o servidor quanto o certificado do cliente:

exporters:
  otlp_grpc:
    endpoint: remote-collector:4317
    tls:
      ca_file: /path/to/ca.pem
      cert_file: /path/to/client-cert.pem
      key_file: /path/to/client-key.pem

Configurações comuns de TLS

As seguintes configurações estão disponíveis para configuração de TLS:

Para mais detalhes sobre as opções de configuração de TLS, consulte a documentação do configtls.

Sobrescrever configurações

É possível sobrescrever configurações do Collector usando a opção --set. As configurações definidas com este método são combinadas na configuração final após todas as fontes --config serem resolvidas e combinadas.

Os exemplos a seguir mostram como sobrescrever configurações dentro de seções aninhadas:

Propriedade simples

A opção --set sempre recebe um par chave/valor, e é usada assim: --set key=value. O equivalente em YAML disso é:

key: value

Chaves aninhadas complexas

Use o duplo dois-pontos (::) no nome do par como separador de chave para referenciar valores de mapas aninhados. Por exemplo, --set outer::inner=value é traduzido para:

outer:
  inner: value

Múltiplos valores

Para definir múltiplos valores, especifique múltiplas flags –set, então --set a=b --set c=d se torna:

a: b
c: d

Valores de array

Arrays podem ser expressos envolvendo os valores em []. Por exemplo, --set "key=[a, b, c]" é traduzido para:

key:
  - a
  - b
  - c

Para representar estruturas de dados mais complexas, o uso de YAML é altamente recomendado.

Incorporando outros provedores de configuração

Um provedor de configuração pode fazer referências a outros provedores de configuração, como no exemplo a seguir:

receivers:
  otlp:
    protocols:
      grpc:

exporters: ${file:otlp-exporter.yaml}

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp_grpc]

Como verificar os componentes disponíveis em uma distribuição

Use o subcomando build-info. Abaixo está um exemplo:

otelcol components

Exemplo de saída:

buildinfo:
  command: otelcol
  description: OpenTelemetry Collector
  version: 0.143.0
receivers:
  - otlp
processors:
  - memory_limiter
exporters:
  - otlp_grpc
  - otlp_http
  - debug
extensions:
  - zpages

Como examinar a configuração final

Use print-config no modo padrão (--mode=redacted) e --feature-gates=otelcol.printInitialConfig:

otelcol print-config --config=file:examples/local/otel-config.yaml

Note que, por padrão, a configuração só será exibida quando for válida, e que informações sensíveis serão ocultadas. Para exibir uma configuração potencialmente inválida, use --validate=false.

Como visualizar campos sensíveis

Use print-config com --mode=unredacted e --feature-gates=otelcol.printInitialConfig:

otelcol print-config --mode=unredacted --config=file:examples/local/otel-config.yaml

Como exibir a configuração final em formato JSON

Use print-config com --format=json e --feature-gates=otelcol.printInitialConfig. Note que o formato JSON é considerado instável.

otelcol print-config --format=json --config=file:examples/local/otel-config.yaml