Um dos principais pontos fortes do OpenTelemetry é seu rico conjunto de ferramentas que fornece controle incomparável sobre seu pipeline de dados de telemetria. Esse controle complementa o modelo de preços baseados no consumo da New Relic.
Esta página fala sobre uma variedade de conceitos que contribuem para o volume de dados ao usar OpenTelemetry com New Relic e ferramentas/padrões disponíveis para gerenciar seu pipeline de dados de telemetria. Ele está organizado em seções que falam sobre os principais conceitos que contribuem para o volume de dados para recursos, traces, métrica e log, seguidos por um catálogo de ferramentas disponíveis para ajudar a gerenciar o volume.
Conceitos-chave: Recursos
OTLP define uma estrutura de mensagem hierárquica semelhante em todos os sinais, o que evita a repetição no nível do protocolo, compartilhando informações entre registros.
- Cada solicitação de exportação contém muitos
Resource{SignalRecord}s - Cada
Resource{SignalRecord}contém muitosScope{SignalRecord}s - Cada
Scope{SignalRecord}contém muitos{SignalRecord}s {SignalRecord}éSpan,MetriceLogRecord
Essa estrutura hierárquica é nivelada quando enviada ao endpoint New Relic, e cada atributo de recurso é desnormalizado em registros Span, Metric e Log individuais. Para obter mais informações sobre como os dados do OpenTelemetry são tratados no New Relic, consulte as páginas a seguir:
A maioria das implementações da linguagem OpenTelemetry fornecem pacotes com detectores de recursos, que contribuem com atribuição de recursos com base nas informações detectadas no ambiente. Estes atributos podem ser extremamente úteis, mas podem incluir mais informações do que o necessário.
Para obter mais detalhes, consulte o seguinte:
- Detectores de recursos SDK
- Processador de recursos do coletor
- Processador de transformação de coletor.
Conceitos-chave: traces
Amostragem
Amostragem é o processo de controlar quais spans são exportados para um backend de observabilidade. Os dados de trace podem fornecer insights altamente valiosas, mas se não forem verificados, podem rapidamente encher os discos rígidos (e as contas!).
Por padrão, os SDKs do OpenTelemetry usam o amostrador ParentBased(root=AlwaysOn). O amostrador ParentBased delega para diferentes amostradores configuráveis com base na existência de um span pai, se esse pai é local para o processo atual ou remoto e se esse pai é amostrado. O amostrador ParentBased(root=AlwaysOn) padrão fará a amostragem de um intervalo se uma das seguintes afirmações for verdadeira:
- Não há span pai (ou seja, este span é a raiz)
- O pai é amostrado, independentemente de o pai ser local ou remoto
Em outras palavras, ele amostrará o intervalo, a menos que o pai não esteja amostrado.
Este é um bom padrão para a comunidade OpenTelemetry , pois permite ao usuário instalar instrumentação e ver dados trace sem primeiro precisar estar ciente do conceito de amostragem. No entanto, você deve ter cuidado com a implantação de produção do OpenTelemetry. De acordo com esta política, todos os spans são amostrados, a menos que haja algum componente upstream ou gateway tomando decisões de amostragem inteligentes para os sistemas downstream se conformarem.
Para alternativas, consulte o seguinte:
- Amostrador ParentBased(root=TraceIdRatioBased)
- Processador de filtro coletor
- Processador de amostragem traseira do coletor
Dados de extensão
Os spans OpenTelemetry são compostos por uma variedade de campos de nível superior (nome, tipo, etc.), atributo, span evento e span links. A quantidade de dados anexados aos spans corresponde diretamente ao volume de dados no New Relic.
Instrumentação biblioteca toma decisões sobre quais informações anexar aos spans, muitas vezes seguindo as convenções semânticas. Quando ocorrem exceções, as informações geralmente são anexadas ao intervalo na forma de um evento de intervalo de exceção. Este evento inclui um atributo que representa a mensagem de exceção, o tipo e stack trace, que, dependendo do idioma e do aplicativo, pode consistir em milhares de bytes. Se exceções ocorrerem com frequência, o trace stack poderá produzir um grande volume de dados no New Relic.
Para estratégias de gerenciamento de dados de span, consulte o seguinte:
Marcador
Um escopo de instrumentação é uma unidade lógica de código de aplicativo com telemetria associada a ele. Cada biblioteca de instrumentação possui um (ou mais) escopos exclusivos, e tracer(es) correspondente(s).
Rastreadores que não produzem dados trace de alto valor podem ser desativados seletivamente sem interromper o trace.
Para obter mais detalhes, consulte SDK desativar rastreador, medidor, agente.
Conceitos-chave: métrica
Intervalo de coleta
Métrica agrega medições individuais e exporta o estado agregado fora do processo. Para protocolos baseados em push, como OTLP, a exportação ocorre em um intervalo configurável, cujo padrão é 60s. Este intervalo corresponde diretamente ao volume de dados no New Relic. Reduza o intervalo para 30s e o volume de dados deverá aproximadamente dobrar. Aumente o intervalo para 120s e o volume de dados deverá ser reduzido aproximadamente pela metade.
O intervalo padrão 60s é um padrão razoável, pois equilibra a compensação entre o volume de dados e o atraso de observabilidade. Aumente o intervalo muito alto e atrasos nos sinais críticos que chegam ao dashboard e alertas New Relic podem agravar os problemas.
Para mais detalhes, consulte Leitor de métricas de exportação periódica do SDK exportIntervalMillis.
Cardinalidade
As medidas que a métrica agrega estão associadas a um conjunto de atributo. O número de conjuntos distintos de atributo é chamado de cardinalidade. A cardinalidade é importante porque determina quanta memória do aplicativo é necessária para manter o estado agregado das medições, quantos dados são exportados em cada intervalo de coleta e o volume de dados no New Relic.
Se a cardinalidade for muito alta, considere omitir os atributos que contribuem para ela. Se você controlar a instrumentação, isso pode significar gravar menos atributos a cada medição. No entanto, a instrumentação muitas vezes não é diretamente configurável.
Para detalhes sobre como retirar atributo da métrica, veja o seguinte:
Temporalidade de agregação
Na métrica OpenTelemetry , o conceito de temporalidade de agregação define se o estado das medidas agregadas é redefinido ou não após cada coleta. Quando a temporalidade da agregação é cumulativa, o estado agregado não é zerado e a métrica representa os valores cumulativos desde o início do aplicativo. Quando a temporalidade da agregação é delta, o estado agregado é redefinido após cada coleta e a métrica representa a diferença desde a coleta anterior.
Embora o endpoint OTLP do New Relic endpoint a temporalidade de agregação cumulativa, a arquitetura métrica New Relic é um sistema delta métrico. Usar a configuração cumulativa padrão geralmente incorrerá em mais uso de memória dos SDKs e resultará em uma alta ingestão de dados. A conversão de agregação cumulativa para agregação delta é uma atividade com estado, pois é necessário manter o ponto anterior de cada série temporal para calcular a diferença. Por esse motivo, é melhor configurar a temporalidade de agregação no SDK, o que economiza memória do aplicativo e evita complexidade extra no downstream.
Para obter mais detalhes, consulte o seguinte:
Metros e instrumento
Um escopo de instrumentação é uma unidade lógica de código de aplicativo com telemetria associada a ela. Cada biblioteca de instrumentação possui um (ou mais) escopos exclusivos e medidor(es) correspondente(s), e cada medidor possui um ou mais instrumentos.
Medidores ou instrumentos que não fornecem dados métricos valiosos podem ser desativados seletivamente.
Para obter mais detalhes, consulte o seguinte:
Conceitos-chave: logs
Dados do LogRecord
OpenTelemetry log Os registros são compostos por uma variedade de campos de nível superior (timestamp, gravidade, corpo, etc.) e atributo. A quantidade de dados anexados aos registros de log corresponde diretamente ao volume de dados no New Relic.
Biblioteca de instrumentação (chamada de log anexadores no espaço , uma OpenTelemetry log vez que a de OpenTelemetry log ponte API se destina a conectar o log da log API ao OpenTelemetry) toma decisões sobre quais informações anexar aos log logs, geralmente seguindo as convenções semânticas.
Para estratégias sobre como gerenciar dados de log, consulte o seguinte:
- Limites do SDK LogRecord
- SDK configura anexadores de log
- Processador de filtro coletor
- Processador de transformação de coletor
Agente
Um escopo de instrumentação é uma unidade lógica de código de aplicativo com telemetria associada a ele. Para OpenTelemetry registro em log , cada agente distinto (ligado por um log anexador usando a de OpenTelemetry log ponte API) possui um escopo de instrumentação exclusivo.
agente que não produz dados log de alto valor pode ser desabilitado seletivamente.
Para obter mais detalhes, consulte o seguinte:
Catálogo de ferramentas de gerenciamento de pipeline
A tabela a seguir lista uma variedade de ferramentas úteis para gerenciar seu pipeline de dados OpenTelemetry. Observe que OpenTelemetry é um ecossistema altamente extensível. Se essas ferramentas não forem suficientes, outras ferramentas poderão estar disponíveis ou você poderá escrever uma lógica de extensão personalizada para os SDKs ou coletor de linguagem para atingir seus objetivos.
Nome | Coletor ou SDK? | Descrição |
|---|---|---|
SDK | Os SDKs da linguagem OpenTelemetry empacotam detectores para fornecer atributo de recursos com base no ambiente. Alguns conjuntos deles geralmente são habilitados por padrão com opções de instrumentação de código zero, como o agente OpenTelemetry Java. Consulte para obter detalhes sobre como ativar/desativar detectores de recursos. | |
SDK | O amostrador bash Defina o amostrador | |
SDK | O OpenTelemetry trace SDK permite que os limites de span sejam configurados para especificar o comprimento máximo e a quantidade de atributo, o número máximo de eventos de span e o número máximo de links de span. Os limites de período podem ser configurados programaticamente no SDK bash Defina os limites de extensão para alinhar com os endpoint limites de atributo do OTLP do New Relic. | |
SDK | O OpenTelemetry log SDK permite que limites de extensão sejam configurados para especificar o comprimento máximo e a quantidade de atributo. Os limites do LogRecord podem ser configurados programaticamente no SDK bash Defina os log limites de registro para alinhar com os endpoint limites de atributo do OTLP do New Relic. | |
SDK desabilita , , | SDK | O OpenTelemetry SDK define
,
e
para configurar e desabilitar rastreador, medidores e agente respectivamente. Este conceito está atualmente em desenvolvimento e não está disponível em todas as implementações de linguagem. Consulte individuais e entre em contato com os mantenedores do idioma para verificar o status. |
Leitor métrico de exportação periódica SDK | SDK | O OpenTelemetry métrica SDK permite configurar o intervalo de coleta do leitor métrico exportador periódico. O intervalo pode ser configurado programaticamente, mas é comum usar env vars: bash Defina o intervalo de coleta como 60s (60k ms). Este é o padrão, mas pode ser ajustado para se adequar. |
SDK | O OpenTelemetry métrica SDK permite que
seja configurado com visualizações para especificar várias opções, incluindo o conjunto de chaves de atributos a serem retidas, o tipo de agregação e a eliminação da métrica. Geralmente, as visualizações são configuradas programaticamente. Consulte para verificar alternativas em seu idioma. Por exemplo, OpenTelemetry Java tem suporte experimental para configuração de visualizações em um . | |
SDK | O OpenTelemetry métrica SDK permite configurar a temporalidade de agregação para o exportador OTLP. Essa temporalidade pode ser configurada programaticamente, mas é comum usar env vars: bash Defina a temporalidade de agregação do exportador de métrica OTLP como delta, alinhando-se com a preferência do endpoint OTLP da New Relic. | |
SDK | A de OpenTelemetry log ponte API foi projetada para uso por log anexadores , que conectam o log da log API de ao OpenTelemetry. Esses anexadores log podem ser instalados automaticamente com opções de instrumentação de código zero, como o agente OpenTelemetry Java, ou podem exigir etapas de instalação manuais. Eles geralmente têm opções de configuração para especificar quais logs e quais dados serão transferidos para OpenTelemetry. Além disso, muitas vezes é possível configurar a que está log API sendo interligada para especificar qual log (com base na gravidade ou no nome do agente) deve ser passado para o log anexador. Consulte para obter detalhes. | |
Coletor | O processador de filtro coletor pode ser usado para filtrar registros de extensão, métrica e log do seu pipeline de observabilidade. Para vãos, ele pode funcionar como um simples amostrador de cauda, agindo em vãos completos, mas sem acesso ao trace completo (Nota: isso pode resultar em traços quebrados). Para métrica, pode ser utilizado para descartar métricas ou séries que não tenham valor alto. Para log, pode ser usado para descartar registros log que não sejam de alto valor (por exemplo log com severidade de granulação fina ou de agente barulhento). | |
Coletor | O coletor tailsampling permite que você decida se deseja amostrar com base no trace concluído. Por exemplo, você pode enfatizar a retenção de rastreios que contenham erros ou que afetem áreas de alto interesse do sistema. A desvantagem é que o processador tailsampling adiciona complexidade ao pipeline de observabilidade, pois exige que todos os spans de um trace sejam roteados para a mesma instância do coletor, e que o coletor mantenha os spans na memória enquanto aguarda a conclusão do trace. Isso requer um planejamento cuidadoso quando seu pipeline de observabilidade atinge uma escala que não pode ser tratada por uma única instância de coletor. | |
Coletor | O processador de recursos coletor permite escrever regras simples para manipular atributo de recursos de spans, métricas e log. Por exemplo, você pode excluir atributos que não sejam de alto valor. | |
Coletor | O processador de transformada métrica permite manipular dados métricos. Por exemplo, você pode excluir séries que não tenham valor alto ou mesclar séries temporais para reduzir a cardinalidade (às vezes chamada de reagregação espacial). | |
Coletor | O processador de transformação do coletor permite transformar dados de observabilidade usando condições para selecionar dados e instruções para modificá-los. Por exemplo, você pode remover atributos de recursos, truncar atributos, alterar campos de nível superior para spans, métricas e logs de log e muito mais. | |
Coletor | O processador coletor cumulativo para delta permite transformar a temporalidade da agregação de métrica de cumulativa para delta. Isto é útil para alinhar sua métrica com a temporalidade de agregação preferida do OTLP endpoint da New Relic. Observe que a tradução da agregação cumulativa para a agregação delta é um processo stateful, exigindo que o coletor armazene o último ponto de cada série temporal na memória para calcular e emitir a diferença. Isso requer um planejamento cuidadoso dos recursos de memória do coletor e a estruturação do pipeline de observabilidade para garantir que todos os pontos da mesma série cheguem à mesma instância do coletor. |