Monitoramento do OpenTelemetry Collector

Monitore a integridade e o desempenho do seu coletor OpenTelemetry com uma experiência de UI de APM dedicada. Quando seu coletor falha ou apresenta mau funcionamento, isso pode causar um apagão de dados de observabilidade, perda permanente de dados ou insights distorcidos. É por isso que criamos o Collector Observability — uma experiência de APM feita sob medida para o trabalho de streaming que os coletores realizam. Você pode aproveitar a telemetria interna do coletor para ver rapidamente como cada componente do seu coletor está operando, para que você possa identificar problemas antes que eles impactem seu pipeline de observabilidade.

Configurar o monitoramento do coletor

Habilite a telemetria interna para o seu coletor

Por padrão, o coletor não emite sua telemetria interna, então você precisará habilitá-la primeiro.

Baixe o arquivo de configuração

$
curl 'https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/heads/main/examples/internal-telemetry-config.yaml' \
>
  --silent --output internal-telemetry-config.yaml

Definir variáveis de ambiente

• INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY: Chave de licença de ingestão para a conta para a qual a telemetria interna deve ser enviada. Essa chave pode ser diferente da chave que o coletor usa para enviar dados regulares para a New Relic, ou seja, NEW_RELIC_LICENSE_KEY no exemplo abaixo.
• INTERNAL_TELEMETRY_SERVICE_NAME: O padrão é otel-collector, determina o nome da entidade no New Relic
• INTERNAL_TELEMETRY_OTLP_ENDPOINT: O padrão é EUA https://otlp.nr-data.net; se estiver na UE, defina como https://otlp.eu01.nr-data.net

Execute o coletor com a configuração mesclada

Além da configuração normal para componentes e pipelines (no exemplo a seguir --config=/etc/nrdot-collector/config.yaml), adicione um segundo argumento --config que mesclará ambas as configurações:

$
docker run \
>
  -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \
>
  -e NEW_RELIC_LICENSE_KEY='...' \
>
  -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \
>
  -v './internal-telemetry-config.yaml:/etc/nrdot-collector/config-internal.yaml' \
>
  newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \
>
  --config='/etc/nrdot-collector/config-internal.yaml'

Alternativa (não recomendada para produção)

Não recomendamos isso por motivos de confiabilidade, mas, para fins de teste, você também pode referenciar a configuração diretamente e o coletor a carregará na inicialização:

$
docker run \
>
  -e INTERNAL_TELEMETRY_NEW_RELIC_LICENSE_KEY='...' \
>
  -e NEW_RELIC_LICENSE_KEY='...' \
>
  -e INTERNAL_TELEMETRY_SERVICE_NAME='demo-collector' \
>
  newrelic/nrdot-collector:1.10.0 --config=/etc/nrdot-collector/config.yaml \
>
  --config='https://raw.githubusercontent.com/newrelic/nrdot-collector-releases/refs/tags/1.10.0/examples/internal-telemetry-config.yaml'

Adicionar tag de entidade

A tag newrelic.service.type: otel_collector atua como uma adesão à experiência no nível da interface do usuário. Escolha uma das seguintes opções:

• Opção 1: Use a configuração de exemplo fornecida acima, que contém a configuração da Opção 2.
• Opção 2: Adicione o argumento --config=yaml:service::telemetry::resource::newrelic.service.type: otel_collector ao coletor. Isso adiciona o atributo como um atributo de recurso e a New Relic faz a etiquetagem para você na ingestão. Se você remover esta opção, levará um dia para a tag expirar.
• Opção 3: Adicionar tag via interface do APM (topo da página, ao lado do nome da entidade). Você também pode remover isso pela UI para alternar de volta.

Personalizando a configuração

A configuração padrão expõe variáveis de ambiente adicionais da forma INTERNAL_TELEMETRY_... para ajustar opções comuns, como níveis de detalhe e amostragem. Consulte a própria configuração para obter mais detalhes.

Recomendamos usar a configuração padrão para monitorar o seu coletor. No entanto, você pode modificar a configuração de exemplo para atender às suas necessidades, como reduzir o nível de detalhes, a amostragem ou as taxas de coleta de dados. Consulte a documentação oficial para mais detalhes. Lembre-se de que alterações na configuração podem fazer com que certas partes da interface do usuário não exibam dados. Consulte também Limitações. As opções de configuração de telemetria interna do coletor mudam à medida que a comunidade OTel evolui. Você tem controle total sobre sua configuração, incluindo a opção de usar os padrões fornecidos.

Considerações sobre sobrecarga

Como toda telemetria, a telemetria interna do coletor aumenta a sua ingestão de dados. A sobrecarga depende da sua carga de trabalho e configuração. Aqui estão os principais fatores a considerar:

Métricas Cria uma sobrecarga constante para o coletor e todos os componentes ativos, independentemente da vazão. As métricas são emitidas em um intervalo constante (60 segundos por padrão). Qualquer componente pode emitir métricas personalizadas, conforme indicado pelo respectivo metadata.yaml, o que pode aumentar a sobrecarga.

Se você precisar reduzir a quantidade de métricas que seu coletor emite, recomendamos definir o nível de métrica para normal, por exemplo, via a variável de ambiente INTERNAL_TELEMETRY_METRICS_LEVEL na configuração de exemplo, pois apenas um subconjunto das métricas do detailed é usado pela UI e são tipicamente métricas destinadas ao ajuste fino de desempenho ou a problemas de rede, então você pode reativá-las conforme necessário.

Logs Tem impacto mínimo durante a operação normal. Pode ocorrer uma sobrecarga maior quando os logs de erro aumentam rapidamente, mas isso é reduzido porque os logs são amostrados por padrão. O algoritmo de amostragem permite um número constante de logs por intervalo definido e, em seguida, faz a amostragem a uma taxa estática. Consulte service::telemetry::logs::sampling.

Traces Desativados por padrão devido a:

• Maturidade limitada dos rastreamentos. Nem todos os componentes estão instrumentados, consulte esta issue do GitHub.
• Sobrecarga imprevisível que varia com a carga de trabalho e a configuração de lotes de agentes e coletores upstream.
• Nenhum algoritmo de amostragem adaptativa disponível. Isso torna impossível fornecer uma recomendação de amostragem universal que não arrisque custos inesperados para certos casos de uso.

Quando os rastreamentos se tornarem mais maduros, eles fornecerão insights valiosos sobre quanto tempo o coletor gasta processando dados no nível do componente. Para experimentar com traces durante o desenvolvimento, defina INTERNAL_TELEMETRY_TRACE_LEVEL=info e comece com uma taxa de amostragem baixa, como INTERNAL_TELEMETRY_TRACE_SAMPLE_RATIO=0.001 (0,1%), enquanto monitora seu volume de ingestão e ajusta conforme necessário.

Visualize seu coletor na UI

Explore a telemetria interna na interface do APM

Para visualizar a telemetria interna do seu coletor, navegue até APM & Services > Services - OpenTelemetry > your_collector_name para explorar a entidade do coletor.

Dependendo dos componentes que o seu coletor utiliza, alguns gráficos podem não ser preenchidos. Por exemplo, se você não processar logs no seu coletor, os gráficos relacionados a esse sinal ficarão vazios.

Página de resumo

A página de Resumo fornece uma visão geral da saúde e do desempenho do seu coletor:

• Métricas gerais de integridade do coletor
• Gráficos para o comportamento de receptores, processadores, exportadores e processamento em lote (requer batchprocessor)
• Gráfico dedicado para o memorylimiter devido ao seu modo de falha único

• Relacionamentos e métricas de infraestrutura (se configurado, consulte exemplos de configuração)

Página de processos

Acompanhe o consumo de recursos em nível de sistema com a página Processos:

• Utilização e tendências da CPU
• Uso e padrões de memória
• Indicadores de desempenho em nível de processo

Exemplos de configuração

Esta seção contém exemplos de como o guia passo a passo acima se aplica a diferentes casos de uso envolvendo o coletor.

Coletor simples com telemetria interna habilitada

Exemplo mínimo de um coletor em execução com docker compose.

Popular relacionamentos de infraestrutura (opcional, experimental)

Como mostrado acima, o APM pode mostrar métricas de infraestrutura para a infraestrutura onde o coletor está sendo executado, mas apenas se sua infraestrutura estiver instrumentada e um relacionamento puder ser formado. A relação é impulsionada por atributos adicionais na telemetria interna do coletor. Você pode ler mais sobre este tópico em nossa documentação do OTel. As etapas para configurar isso dependem muito da sua infraestrutura exata. Para a escolha comum do Kubernetes, criamos um exemplo que demonstra como obter relacionamentos de contêiner para serviço com base em nossa solução OTel para Kubernetes.

Limitações

• A telemetria do Coletor ainda não está estável:

  • A versão suportada da telemetria interna é definida implicitamente pela versão do coletor principal que usamos para construir o NRDOT; consulte a versão do otlpreceiver no manifesto do nrdot-collector.
  • Se a telemetria emitida mudar durante a Visualização Pública, nos reservamos o direito de suportar apenas a versão mais recente.

• Requisitos de formato de exportação: A interface do coletor espera telemetria no formato exportado pelo otlpexporter. Não suporta métricas exportadas via Prometheus.

• Métricas de componentes personalizados: A telemetria interna que não está listada na documentação de telemetria interna ainda não é suportada. Componentes personalizados ou componentes contrib emitem métricas padrão, mas também podem definir suas próprias métricas. Ainda estamos trabalhando em uma maneira de ajudar você a obter insights a partir deles sem criar dashboards personalizados.

• Métricas douradas para contêineres OTel: Ainda não totalmente suportadas, o que significa que algumas colunas no painel de infraestrutura podem não ser preenchidas para contêineres.