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 ponto final OTLP do New Relic endpoint 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 alta ingestão de dados. A conversão de agregação cumulativa para delta é uma atividade com estado, pois você precisa 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 posteriormente.
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 do OpenTelemetry. Observe que o OpenTelemetry é um ecossistema altamente extensível. Se essas ferramentas não forem suficientes, outras ferramentas podem estar disponíveis ou você pode escrever uma lógica de extensão personalizada para os SDKs de linguagem ou coletor 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 a documentação do idioma 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 intervalo para alinhar com os New Relic endpoint limites de atributo do OTLP. | |
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 do registro para alinhá-los New Relic com endpoint os limites de atributo do OTLP. | |
SDK desabilita rastreador, medidores, agente | SDK | O OpenTelemetry SDK define |
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 | |
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 métrico OTLP como delta, alinhando-se com a New Relic endpoint preferência do OTLP . | |
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 a documentação de cada idioma para obter detalhes. | |
Coletor | O processador de filtro de coletor pode ser usado para filtrar registros de intervalo, métricos e log do seu pipeline de observabilidade. Para extensões, ele pode funcionar como um amostrador de cauda simples, atuando em extensões concluídas, mas sem acesso ao trace completo (Observação: isso pode resultar em traço quebrado). Para métrica, ele pode ser usado para descartar métricas ou séries que não sejam de alto valor. Para log, ele pode ser usado para descartar registros log que não sejam de alto valor (por exemplo log com severidade de grão fino ou de agente barulhento). | |
Coletor | O coletor tailsampling permite que você decida se deseja amostrar com base no traço concluído. Por exemplo, você pode enfatizar a retenção de rastros que contenham erros ou que afetem áreas de alto interesse do sistema. A desvantagem é que o processador de amostragem de cauda adiciona complexidade ao seu pipeline de observabilidade, pois exige que todos os intervalos de um trace sejam roteados para a mesma instância de coletor e que o coletor mantenha os intervalos 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 manipulada por uma única instância de coleta. | |
Coletor | O processador de recursos de coletor permite que você escreva regras simples para manipular atributos de recursos de spans, métrica 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 alto valor ou mesclar séries temporais para reduzir a cardinalidade (às vezes chamado de reagregação espacial). | |
Coletor | O processador de transformação de 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 intervalos, logs métricos e de log e muito mais. | |
Coletor | O processador coletor cumulativetodelta permite transformar a temporalidade da agregação métrica de cumulativa para delta. Isso é útil para alinhar sua métrica com a temporalidade de agregação preferida do New Relic OTLP endpoint do . Observe que a tradução da agregação cumulativa para a agregação delta é um processo com estado, exigindo que o coletor armazene o último ponto de cada série temporal na memória para poder computar e emitir a diferença. Isso requer um planejamento cuidadoso dos recursos de coleta de memória e a estruturação do pipeline de observabilidade para garantir que todos os pontos da mesma série cheguem à mesma instância de coleta. |