Um guia de implementação para OpenTelemetry e New Relic

Este guia inclui dicas e práticas recomendadas para implementar OpenTelemetry com New Relic e é útil para:

Clientes existentes da New Relic que atualmente usam nossas soluções APM ou outras soluções de monitoramento de terceiros, mas desejam migrar para OpenTelemetry
Qualquer organização que queira passar a usar OpenTelemetry e New Relic

Este guia orientará você em dez etapas importantes que ajudarão você a aproveitar ao máximo seus dados do OpenTelemetry com o New Relic.

1. instrumento aplicativo com OpenTelemetry

O primeiro passo em qualquer jornada do OpenTelemetry é instrumentalizar seu aplicativo. Este guia fornece uma visão geral desta etapa e destaca algumas considerações importantes. Para obter instruções mais detalhadas, consulte Como começar a usar o OpenTelemetry.

Para algumas linguagens, como Java, .NET, Python e Node.js, OpenTelemetry fornece uma abordagem de instrumentação automática. Este é um excelente ponto de partida para muitos aplicativos que podem ser desenvolvidos posteriormente. Instruções para instrumentação automática podem ser encontradas aqui:

A instrumentação manual pode ser usada para linguagens que não suportam instrumentação automática, como Go. Também pode ser usado para aumentar a telemetria coletada por meio de instrumentação automática.

A autoinstrumentação coleta traços e, em alguns casos, métricas. Ambos os sinais são importantes para observar o seu aplicativo.

Independentemente da abordagem de instrumentação escolhida, é importante entender que diversas partes da interface do New Relic dependem da presença de atributos específicos para funcionar corretamente.

O atributo service.name é necessário para associar seu recurso a uma entidade na interface. E service.instance.id é necessário para que determinados painéis sejam acesos.

Os sinais clássicos dos gráficos para entidade OpenTelemetry no New Relic incluem um botão de alternância que permite escolher se deseja que spans ou métricas conduzam os gráficos. A New Relic deriva sinais clássicos de spans com base na seguinte métrica:

http.server.duration
rpc.server.duration
http.status_code

Use o SDK para adicionar essas métricas à instrumentação da sua aplicação se elas ainda não estiverem presentes na instrumentação automática.

Todos esses atributos são definidos pelas convenções semânticas de recursos do OpenTelemetry e normalmente são definidos pela criação de um recurso usando o OpenTelemetry SDK.

OpenTelemetry também pode ser usado para capturar log. Para nos permitir correlacionar o rastreamento do OpenTelemetry com nosso recurso de login no contexto, certifique-se de que os atributos service.name, trace.id e span.id estejam incluídos nas entradas log . Para obter mais informações sobre relatórios de log do OpenTelemetry, consulte nossos documentos de log do OpenTelemetry.

2. implantar o OpenTelemetry Collector

Em seguida, é hora de implantar o coletor OpenTelemetry, que é recomendado para usar o OpenTelemetry na produção, pois descarrega tarefas como lotes, novas tentativas e criptografia.

Aqui estão algumas dicas sobre como configurar o coletor OpenTelemetry:

Use the right endpoint
. Deve ser configurado para exportar dados OTLP para nosso endpoint. Isso é explicado em nossa documentação sobre envio de dados de um coletor OpenTelemetry.
Avoided dropped data
.Para evitar a eliminação de dados, recomendamos truncar qualquer atributo com comprimento superior a 4095 caracteres. Para obter um exemplo de aplicação dessas práticas, consulte esta configuração do coletor.
Infrastructure
. Para coletar métricas de infraestrutura, inclua o receptor métrico do host na configuração do coletor. Ao usar o receptor host como parte da configuração do coletor, detectamos automaticamente a métrica do host como parte de uma entidade host e sintetizamos suas métricas clássicas (em resumo, você obtém a mesma experiência que teria com nosso agente de infraestrutura).
Scaling
. Grandes implantações de OpenTelemetry precisarão escolher uma estratégia para dimensionar o coletor, tanto para benefícios de desempenho quanto de resiliência. Para obter detalhes sobre como dimensionar o coletor, consulte a documentação do OpenTelemetry.
Kubernetes
.Se seus serviços do instrumento OpenTelemetry estiverem em execução em um ambiente Kubernetes, siga as etapas em Vincular o aplicativo OpenTelemetry-instrumento ao Kubernetes. Isso garante que seus dados do Kubernetes serão correlacionados com os dados do OpenTelemetry.

Muitos clientes optam por executar o coletor usando métodos de implantação de agente e gateway:

Agent
: com esse método, o coletor é executado no mesmo host que o aplicativo (por exemplo, binário, sidecar ou daemonset).
Gateway
: com este método, uma ou mais instâncias de coletor são executadas como um serviço independente por cluster, data center ou região.

O agente coletor em cada host executa tarefas básicas de processamento antes de exportar dados para um cluster de coletores de gateway. Os gateway coletores por sua vez são configurados para exportar dados para o New Relic. Para mais detalhes, consulte Referência arquitetura para OpenTelemetry com New Relic.

3. Implementar estratégia de amostragem de rastreamento

Por padrão, o OpenTelemetry irá capturar 100% dos rastreamentos do aplicativo e enviá-los para o New Relic. Portanto, antes de implantar o OpenTelemetry em produção, uma estratégia de amostragem para rastreamento deve ser implementada. Isso ajuda a reduzir a sobrecarga do aplicativo relacionada à telemetria, bem como a reduzir a quantidade de saída de dados da sua rede e o volume de ingestão de dados no New Relic.

Para conhecer as práticas recomendadas relacionadas à amostragem do OpenTelemetry, consulte nossos documentos de amostragem. A configuração da amostragem deve ser ajustada como parte do processo de teste de carga (descrito abaixo), com o objetivo de garantir dados trace suficientes para solucionar problemas e, ao mesmo tempo, evitar excesso de saída e ingestão de dados.

Ao usar amostras baseadas na cauda, tome cuidado para evitar extensões órfãs e fragmentadas. Para saber como dimensionar o coletor ao usar o processador de amostragem final para evitar intervalos órfãos, consulte a documentação do OpenTelemetry sobre dimensionamento de coletores.

4. Execute testes de carga e ajuste a configuração

Antes de colocar o OpenTelemetry em produção com um aplicativo, é melhor realizar um teste de carga em um ambiente de testes. Isso oferece a você a oportunidade de:

Meça a sobrecarga da instrumentação OpenTelemetry no aplicativo, analisando a utilização incremental de CPU e memória, bem como a latência do serviço.
Meça o volume de saída de dados do coletor e o volume de ingestão no New Relic, pois ambos aumentarão a ingestão e terão possíveis impactos no faturamento.
Isso também oferece uma oportunidade de testar a carga do coletor OpenTelemetry e garantir que ele possa lidar suficientemente com a carga semelhante à de produção. Para dicas sobre como dimensionar o coletor, consulte a documentação do OpenTelemetry.

5. Defina objetivos de nível de serviço

Depois que os dados do OpenTelemetry fluem para o New Relic, é importante definir objetivos de nível de serviço, para que você possa determinar quando os SLOs não estão sendo atendidos e tomar as medidas adequadas.

nível de serviço são usados para medir o desempenho de um serviço do ponto de vista do usuário final (ou aplicativo cliente). Com o New Relic, você pode definir e consumir indicadores de nível de serviço (SLIs) e objetivos de nível de serviço (SLOs) para seu aplicativo. Recomendamos configurar o nível de serviço para serviços de instrumento OpenTelemetry.

Depois de criar seu conjunto de SLOs, o New Relic começará a gerar dados SLI. A visão operacional mostra como seu nível de serviço está melhorando ou piorando em diferentes janelas de tempo. Você pode usar essa visualização para acompanhar a obtenção do SLI ao longo do tempo (%) e ver a conformidade de cada nível de serviço.

Você também pode monitor o orçamento de erros de cada SLO, que indica qual porcentagem de solicitações ainda pode ter uma resposta ruim durante o período do SLO, sem comprometer o objetivo.

6. Configure alertas e gerenciamento de incidentes

Também é importante configurar políticas de alertas, para que você possa detectar e corrigir problemas antes que eles afetem o usuário final da aplicação.

Em um nível superior, são configurados por meio de políticas de alertas, que incluem uma ou mais condições do alerta. incidente de condição do alerta são agrupados como problemas. Por fim, os problemas podem acionar fluxos de trabalho que incluem lógica para transformar problemas em notificação. Para obter um diagrama que ajude você a entender esses conceitos, consulte Conceitos de alertas.

Por exemplo, você pode definir uma condição do alerta para abrir um incidente se o tempo de resposta de um serviço do instrumento OpenTelemetry exceder 500 ms. Você pode então definir um fluxo de trabalho que envie uma notificação por e-mail para uma lista de distribuição quando ocorrer o incidente de condição de alerta ou notificar uma equipe de plantão usando o Slack.

Você também pode configurar alertas em nível de serviço, para notificá-lo quando ocorrer um incidente significativo de impacto nos negócios.

Para saber como criar uma política de alertas com condições, consulte Crie seu primeiro alerta. Para saber como transformar problemas em notificação, veja fluxo de trabalho. Ao criar um fluxo de trabalho, você pode especificar um ou mais destinos para enviar notificações a sistemas de terceiros, como Slack, ServiceNow e Jira.

A integração do alerta da New Relic com sistemas e processos de gerenciamento de incidentes é fundamental para obter valor dos dados do OpenTelemetry porque traz mais visibilidade aos problemas do aplicativo e fornece insights que facilitam a rápida correção dos problemas.

Para mais dicas sobre alertas:

7. Crie carga de trabalho para agrupar entidade relacionada

A carga de trabalho do New Relic permite agrupar entidades relacionadas, fornecendo dados agregados de saúde e atividades de serviços de front-end a backend em toda a sua stack. As cargas de trabalho ajudam você a entender o status de sistemas complexos, detectar problemas, entender a causa e o impacto de um incidente e resolver esses problemas rapidamente.

Recomendamos a criação de carga de trabalho para agrupar os serviços OpenTelemetry juntamente com a entidade relacionada. Isso pode incluir monitoramento de entidade por nosso monitoramento de infraestrutura, , monitoramento de Kubernetes, e outras entidades. A carga de trabalho ajuda você a agrupar entidades em partes mais gerenciáveis, normalmente alinhadas com as equipes responsáveis por essas entidades. Isto é especialmente valioso para ambientes grandes, que podem ter milhares de entidades monitoradas.

A criação de carga de trabalho desbloqueia outros recursos valiosos no New Relic, como Errors Inbox. Com Errors Inbox, suas equipes podem detectar, fazer a triagem e tomar medidas proativas em relação a todos os erros antes que eles afetem seus clientes. Os erros são agrupados de forma inteligente para reduzir o ruído e garantir que erros críticos sejam detectados de forma rápida e eficiente. Isso permite que sua equipe resolva erros de toda a sua stack, incluindo erros de APM, dados do browser (RUM), dispositivos móveis, dados do AWS Lambda sin servidor e OpenTelemetry, exibidos em uma tela.

Como o OpenTelemetry é implementado para os serviços do seu aplicativo, recomendamos usar Errors Inbox para revisar e corrigir proativamente os erros mais comuns antes que eles afetem o usuário final. Para saber quais atributos do OpenTelemetry são usados pela Errors Inbox para identificar grupos de erros, consulte Como são criadas impressões digitais exclusivas.

8. Crie um painel para visualizações personalizadas

A New Relic fornece diversas visualizações prontas para uso dos dados do OpenTelemetry para ajudar você a começar. À medida que suas equipes começarem a usar os dados para resolução de problemas e identificar problemas de forma proativa, você poderá descobrir a necessidade de visualizações personalizadas. Você pode criar um painel personalizado para essa finalidade.

Para saber os benefícios de criar dashboards personalizados e como começar a usá-los, consulte dashboard.

9. Adicione contexto com instrumentação personalizada

Seja começando com instrumentação automática ou manual, muitas vezes fará sentido adicionar instrumentação adicional ao longo do tempo, à medida que surgem necessidades de dados adicionais durante a triagem de problemas. Por exemplo:

Atributo pode ser adicionado a spans para fornecer contexto adicional sobre a solicitação, o que pode ser útil durante a resolução de problemas para entender o impacto comercial do problema (por exemplo, adicionar o ID do locatário a um span, para ajudar na resolução de problemas a multi -requerimento de inquilino).
Spans aninhados adicionais podem ser capturados, fornecendo mais detalhes para a resolução de problemas de um aspecto particular da aplicação de forma mais profunda.
A métrica personalizada pode ser capturada, tanto de uma perspectiva técnica (por exemplo, rastrear o número de ocorrências no cache e misses) ou de uma perspectiva comercial (por exemplo, rastrear o número médio de itens no carrinho durante o checkout).

Os documentos do OpenTelemetry fornecem orientações e exemplos destes e muito mais por idioma. Por exemplo, ao usar Java você pode usar os seguintes documentos:

Também temos alguns exemplos que mostram uma instrumentação manual do OpenTelemetry utilizando diversas linguagens.

10. Use, meça e refine

Para melhorar a maturidade da sua observabilidade, é importante adotar uma mentalidade de melhoria contínua. Como o OpenTelemetry e outros dados capturados no New Relic são usados para solucionar problemas, você deve observar o seguinte e tomar as medidas apropriadas:

A condição de alerta existente detectou proativamente o problema antes que o usuário final fosse impactado? Caso contrário, você deve ajustar a condição do alerta ou adicionar novas.
Estão aparecendo continuamente alertas críticos que não exigem nenhuma ação? Nesse caso, a condição do alerta deve ser ajustada para que apenas sejam levantadas as condições que exigem ação.
Foram fornecidos detalhes suficientes no rastreamento para solucionar o problema? Caso contrário, você deve revisar a instrumentação e considerar capturar mais atributos de span e spans aninhados.
Foram necessárias consultas personalizadas de NRQL para solucionar problemas? Nesse caso, você deve considerar incorporar alguns dos gráficos resultantes ao painel.

À medida que a instrumentação é refinada ao longo do tempo, a capacidade de detectar problemas proativamente será melhorada e o tempo para resolvê-los será reduzido. Isto leva a uma redução tanto no MTTD (tempo médio de detecção) como no MTTR (tempo médio de resolução).

Temos um guia de gerenciamento de qualidade de alerta que orienta você no processo de melhoria e otimização da qualidade de seus alertas, levando, em última análise, a um aumento no tempo de operação e disponibilidade, redução do MTTR e diminuição do volume de alertas.

Também temos um guia de gerenciamento a nível de serviço que orienta você sobre como melhorar e otimizar a qualidade do seu gerenciamento a nível de serviço. A implementação bem sucedida destas recomendações pode proporcionar os seguintes benefícios:

Redução no número de incidentes que perturbam os negócios
MTTR reduzido
Esforço reduzido por incidente

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