Comece a usar a observabilidade do coletor

Cobrança

O uso do Collector Observability é faturável durante o preview de acordo com o seu Pedido, conforme aplicável ao modelo de preços associado à sua Conta e conforme definido abaixo.

Os custos associados a este recurso são determinados pelos seguintes fatores, conforme aplicável ao modelo de preços associado à sua Conta:

Core Compute: A página de Resumo, medida em Core CCU, é faturável durante o preview.

Ingestão de dados: Dados adicionais da telemetria interna, medidos em GB ingeridos, são faturáveis durante o preview.

Se este recurso se tornar disponível de forma geral, seu uso será faturável de acordo com o seu Pedido.

Configuração passo a passo

Baixe o arquivo de configuração

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

bash

$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; se estiver no JP, defina como https://otlp.jp.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:

bash

$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:2.5.0 --config=/etc/nrdot-collector/config.yaml \
>  --config='/etc/nrdot-collector/config-internal.yaml'

Importante

A ordem dos argumentos --config importa se você tiver uma configuração pré-existente sob o nó service::telemetry. O coletor usa uma estratégia de 'o último vence' em nível de nó ao mesclar configurações e certas partes da configuração (por exemplo, listas, nós folha) não podem ser mesclados, então são sobrescritos pelo último argumento --config.

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.
Após adicionar a tag, consulte Visualizar seu coletor na interface para explorar os dados do seu coletor.

Opcional: personalize 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 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 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.

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 mencionado na página de Resumo, 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.

Esta tradução de máquina é fornecida para sua comodidade.