Introdução

Recentemente, anunciamos o lançamento da APM + OpenTelemetry Convergence da New Relic, o que significa que nossa plataforma agora oferece uma experiência de observabilidade de classe mundial para seus dados do OpenTelemetry (OTel).

Como o OTel em si é um framework de coleta de dados e não um backend de observabilidade, a instrumentação é apenas o primeiro passo no processo de adoção. O projeto se concentra em como gerar telemetria, e não no que fazer com ela. Para obter insights acionáveis dos fluxos de dados brutos produzidos pelo OTel, você precisa de uma plataforma sofisticada, dimensionável e inteligente para ingerir, armazenar, correlacionar e visualizar esses dados. 

É aí que entra a New Relic. Nesta publicação do blog, usaremos o fork da New Relic do aplicativo demonstrativo da comunidade do OpenTelemetry, o Astroshop, para mostrar como a New Relic ajuda você a obter valor a partir dos seus dados do OTel. 

Implantando o Astroshop

O Astroshop é um sistema distribuído baseado em microsserviços criado pela comunidade do OTel em vários idiomas para demonstrar a implementação do OTel em um ambiente quase real. A New Relic mantém um fork deste aplicativo demonstrativo; para preencher a lacuna entre instrumentação e insights, pré-configuramos nosso fork para agilizar o processo de configuração e permitir que você envie dados para sua conta da New Relic quase imediatamente.

O Astroshop também vem equipado com sinalizadores de recursos que você pode ativar e desativar para simular uma variedade de problemas de software do mundo real. No exemplo que estamos usando nesta publicação do blog, o sinalizador de recurso productcatalogfailure foi habilitado, o que significa que um erro será gerado para solicitações GetProduct com uma ID de produto específica. 

Implantar o aplicativo demonstrativo é simples. Confirme se seu ambiente atende aos pré-requisitosclone o fork, e então implante o Astroshop localmente usando o Kubernetes ou Docker. Em seguida, valide sua implantação e, por fim, vamos explorar seus dados.

Iluminando a interface da New Relic

Assim que os vários microsserviços do Astroshop começarem a relatar dados (aguarde alguns minutos após a implantação para que as entidades sejam sintetizadas), você poderá ver todos eles na sua visualização de Entidades. Na sua conta New Relic, navegue até APM & Services, clique em Services - OpenTelemetry e, em seguida, clique em “View all" (Exibir tudo).

Observação: você notará que nem todos os serviços estão relatando dados de tempo de resposta, taxas de transferência e taxa de erros. Isso ocorre por dois motivos:

  • A convergência APM + OTel depende de dados de métricas, que nem todos os serviços estão relatando ainda.
  • O projeto OTel tem vários níveis de implementação nas APIs e SDKs de linguagem, o que impactou a instrumentação de métricas em alguns dos serviços. 

A APM + OTel UI Convergence foi projetada para levar a melhor experiência de APM da New Relic às fontes de dados do OTel. O mecanismo central dessa convergência é um processo de normalização inteligente de dados: quando dados padrão do OTel são enviados ao endpoint OTLP da New Relic, a plataforma produz automaticamente uma cópia normalizada desses dados, adaptando-os às nossas convenções semânticas de APM robustas e maduras. Este processo é totalmente não destrutivo; os dados de origem do OTel são preservados e disponibilizados para consulta, o que garante total fidelidade dos dados. 

Esse preenchimento automático da interface não é mágica; é o resultado direto da adesão às convenções semânticas definidas pelo OTel e reconhecidas pela plataforma New Relic. A New Relic usa atributos específicos anexados aos dados de telemetria para sintetizar entidades, o processo de identificação, classificação e criação de entidades como serviços, hosts e bancos de dados dentro da interface.

A tabela a seguir detalha vários atributos críticos e os recursos específicos da New Relic que eles habilitam:

Atributo OTelNível de exigênciaRecurso New Relic habilitadoPor que é importante
service.nameObrigatórioSíntese de entidadesEste é o identificador primário. Sem ele, seu serviço não aparecerá como uma entidade distinta na interface da New Relic.
service.instance.idRecomendadoAnálise de "Instâncias"Permite filtrar e comparar o desempenho entre diferentes instâncias (por exemplo, pods) do mesmo serviço.
telemetry.sdk.languageRecomendadoVisualizações de interface específicas da linguagemDesbloqueia visualizações especializadas, como a página "JVMs" para serviços Java, fornecendo métricas específicas de runtime.
host.id / host.nameRecomendadoCorrelação serviço-hostVincula o serviço do seu aplicativo à entidade host subjacente (máquina virtual ou física) no mapa de serviço e nas visualizações de infraestrutura.
k8s.cluster.nomeRecomendadoCorrelação do KubernetesVincula seu serviço ao cluster do Kubernetes específico em que ele está sendo executado, ativando a aba "Kubernetes" na página de resumo do serviço.
trace.id / span.idImplicitamente obrigatórioLogs em contexto / Correlação de traceEsses são os "fios clássicos" que vinculam automaticamente as mensagens do log ao trace e span específicos onde foram geradas.

Explorando a interface APM + OTel Convergence

Agora que você tem uma compreensão básica do que está acontecendo nos bastidores, vamos analisar mais de perto os dados do seu Astroshop. Para este exemplo, selecionaremos o serviço product-catalog. Clicar em uma entidade levará você para a visualização Resumo dessa entidade. 

Role um pouco para baixo e você verá o gráfico de Erros e a lista de Transações. A transação chamada grpc/oteldemo.ProductCatalogService.GetProduct tem uma taxa de erro de mais de 4%.

Clicar no botão “View details" (Ver detalhes) para a transação GetProduct abre a nova visualização Transação 360, que avança a análise de trace único padrão para fornecer uma visão dinâmica de todo o ecossistema de transações. O uso desse recurso fornece informações rápidas sobre o desempenho do aplicativo e da infraestrutura, incluindo alertas críticos ativos e novas versões de implantação (dentro do período selecionado). O contexto é o que permite que você correlacione problemas diretamente com a implantação, host ou serviço exato. 

Esta visualização inclui o novo mapa de fluxo dinâmico, que permite ver como os dados de trace fluem pelos serviços. Ela usa os dados de trace para correlacionar mudanças de desempenho entre entidades upstream e downstream, em relação à janela de tempo correspondente anterior. 

Ao percorrer a exibição, você verá informações sobre os serviços de APM e transações que participaram do trace.

Como a transação GetProduct está sendo indicada como a causa do problema, vamos nos aprofundar mais clicando em grpc/oteldemo.ProductCatalogService.GetProduct, o que abrirá outra visualização Transação 360 com algumas guias perto do topo.

Selecionar a aba “See errors" (Ver erros) exibe mais informações, incluindo quantas vezes esse erro ocorreu. Na seção Implantando o Astroshop, mencionamos que o sinalizador de recurso productCatalogFailure foi habilitado no exemplo desta publicação do blog. A mensagem para esse grupo de erros é "Erro: Sinalizador de recurso de falha do catálogo de produtos habilitado", que é exatamente o que esperávamos ver. 

Observação: se você está se perguntando por que o gráfico de taxa de erros não parece mostrar nenhum dado, apesar da clara existência de erros, é porque esse gráfico está consultando especificamente códigos de status HTTP de 500 ou menos. (Clicar em “...” de qualquer gráfico abre um menu que oferece diversas opções; selecionar “View query" [Exibir consulta] mostrará a consulta exata que está sendo usada para gerar dados para aquele gráfico.)

Quando saímos dessa visualização detalhada e retornamos à visualização inicial da Transação 360 acessada na página de Resumo, podemos clicar na seta suspensa para expandir “Supporting infrastructure entities" (Entidades de infraestrutura de suporte) e ver se há algum impacto.

New Relic Now Experimente hoje mesmo as novas integrações de agentes.
Assistir agora.