A interface OpenTelemetry APM fornece uma experiência abrangente de monitoramento para serviços instrumentados com OpenTelemetry, oferecendo os mesmos recursos poderosos APM que você espera do agente de linguagem tradicional da New Relic.
Pré-requisitos
Antes de usar a interface do usuário do OpenTelemetry APM, certifique-se de ter:
- Configurado seu serviço com instrumentação OpenTelemetry
- Configure seu serviço para enviar dados para o New Relic
- Criou a entidade de serviçoOpenTelemetry
Se você não concluiu essas etapas, consulte o monitoramentoOpenTelemetry APM para obter instruções de configuração.
Encontre seus serviços OpenTelemetry
Para localizar seus serviços OpenTelemetry-instrumentado:
- Na interface New Relic, navegue até All entities > Services - OpenTelemetry ou APM & Services
- Selecione um serviço para abrir sua página Summary
Dica
Utilize a tag entidade no explorador entidade para filtrar serviços. Saiba mais sobre como as tags entidade são computadas nos recursos doOpenTelemetry no New Relic.
Como o OpenTelemetry funciona com o New Relic APM
Os serviços instrumentados do OpenTelemetryfornecem a mesma experiência APM com curadoria que os serviços que usam o agente de linguagem do New Relic. Veja como funciona:
Processo de mapeamento de dados
O New Relic mapeia automaticamente seus dados OpenTelemetry para nossas convenções APM por:
- Gerando métricas APM : Criamos as métricas necessárias para a experiência APM diretamente dos seus dados OpenTelemetry
- Preservando os dados originais: seus dados originais OpenTelemetry permanecem disponíveis para painéis personalizados e alertas
- Convenções de normalização: lidamos com as convenções semânticas em evolução do OpenTelemetry para que você não precise rastrear diferenças de versão
Benefícios para usuários existentes New Relic
Se você estiver migrando do New Relic Agent para OpenTelemetry, poderá continuar usando o Métrica e a Consulta familiares enquanto adota os padrões OpenTelemetry.
Importante
Por que normalizamos os dados do OpenTelemetry
As convenções semânticas do OpenTelemetry ainda estão evoluindo, muitas delas ainda não estáveis. Ao normalizar seus dados de acordo com as convenções do New Relic, nós:
- Reduza a complexidade do rastreamento de quais versões da convenção OpenTelemetry sua instrumentação usa
- Ofereça uma experiência consistente durante a transição do agente New Relic para OpenTelemetry
- Garanta que sua experiência com APM permaneça estável, independentemente das alterações do OpenTelemetry
Fontes de dados e priorização
A experiência do APM usa três tipos de dados OpenTelemetry:
- Métricas (primárias): Fornece estatísticas de serviço precisas, como taxas de transferência, tempo de resposta e taxas de erros
- Spans (suplementares): Utilizados quando métricas não estão disponíveis ou para recurso específico como trace da transação
- Logs: Integrado para resolução de problemas e correlação
Por que métricas são preferidas: métricas fornecem uma imagem completa do desempenho do seu serviço, enquanto intervalos são normalmente amostrados e podem não representar todo o tráfego.
A experiência do APM aproveita principalmente estas convenções semânticas do OpenTelemetry:
- HTTP - transação da web e chamadas externas
- RPC - Chamadas de procedimento remoto
- Mensagens - Operações de fila de mensagens
- banco de dados - operações do banco de dados
Como as transações são derivadas dos dados do OpenTelemetry
A experiência de APM da New Relic é centrada na noção de uma transação. Ao usar um agente New Relic, é responsabilidade da instrumentação do agente definir o escopo de uma transação (por exemplo, uma única solicitação da web). O agente produz dados métricos que direcionam a grande maioria da experiência New Relic APM ao registrar dados métricos de transações, medindo a duração das transações e suas operações individuais (por exemplo, chamadas externas e chamadas de banco de dados).
A instrumentação do OpenTelemetry não tem um análogo direto a uma transação do New Relic, portanto, adaptar a noção de transações aos dados do OpenTelemetry é fundamental.
Ao aproveitar as convenções semânticas do OpenTelemetry, podemos aproveitar os meios altamente estruturados e padronizados do OpenTelemetryde descrever a telemetria para conduzir a experiência APM de uma forma muito semelhante à do agente do New Relic.
As convenções semânticas definem métricas padrão para medir operações comuns, como lidar com requests HTTP ou RPC. Estas métricas são análogas às métricas de transação que o agente New Relic produz para descrever transações da web. Aproveitamos a métrica HTTP e RPC do OpenTelemetrypara sintetizar métricas que controlam a interface APM como a métricaapm.service.transaction.duration .
New Relic também fornece uma noção de transação fora da web. Transações fora da web são comumente usadas para sistemas que realizam processamento de mensagens. a instrumentação que aproveita as convenções de mensagens do OpenTelemetryresultará na síntese de métricas que representam a transação fora da web.
Importante
Operações de mensagens e dados de intervalo
As convenções de mensagens do OpenTelemetry são menos maduras que as convenções HTTP e RPC. Atualmente, geramos transações fora da web métrica para operações de mensagens a partir de dados span em vez de dados métricos. Essa abordagem segue as convenções semânticas de mensagens, mas pode ser afetada pela sua estratégia de amostragem.
Nomes de transações
Cada transação tem um nome que é derivado do atributo exigido pelas convenções semânticas do OpenTelemetry. Consulte a seção Métrica do ServiçoAPM para saber como esse nome é derivado.
Nome de transação desconhecido
Às vezes, você pode ver uma transação com unknown no nome. Isso é uma indicação de que os dados de origem usados para derivar a transação não seguem nenhuma das convenções semânticas estabelecidas do OpenTelemetry que atualmente suportamos.
Alguns exemplos:
- Métrica HTTP ausente
http.request.methodouhttp.route. Por exemplo, se a métricahttp.server.request.durationnão tiver o atributohttp.route, o nome da transação seráWebTransaction/server/GET unknown. - estrutura ou protocolos para os quais OpenTelemetry não define atualmente convenções semânticas (por exemplo, trabalhos em segundo plano e estrutura de CI).
Navegando na experiência do APM
Resumo
A página Summary fornece uma visão geral da saúde do seu serviço e é centrada na noção de transação da New Relic. Veja Como as transações são derivadas dos dados do OpenTelemetry para mais detalhes.
As métricas New Relic que controlam a página Summary são as métricas apm.service.transaction.duration e apm.service.error.count. Consulte-os para obter detalhes sobre como eles são derivados dos seus dados do OpenTelemetry.
Personalizando o Apdex destino
Na instrumentação New Relic, os destinos apdex personalizados são configurados usando a configuração do agente. Para OpenTelemetry, ao visualizar um serviço, navegue até Settings > Application para configurar seu destino Apdex.
Distributed tracing
A distributed tracing página fornece detalhados insights OpenTelemetry trace sobre os dados . Consulte distributed tracing para obter informações de uso da página. Consulte Rastreamento no para obter detalhes OpenTelemetry New Relic sobre como os dados são ingeridos no OpenTelemetry trace New Relic.
Assim como acontece com os sinais clássicos, os spans serão classificados como erros se o status do span estiver definido como ERROR (por exemplo, otel.status_code = ERROR). Se o intervalo for um erro, a descrição do status do intervalo (por exemplo, otel.status_description) será exibida em detalhes do erro.
OpenTelemetry span evento anexa informações de contexto de evento adicionais a um intervalo específico. Eles são mais comumente usados para capturar informações de exceção. Se disponível, você pode visualizar o evento de um intervalo nos trace details.
Dica
A presença de um evento de exceção de intervalo não qualifica o intervalo como um erro por si só. Somente intervalos com status de intervalo definido como ERROR são classificados como erros.
Mapa de serviço
A página do mapa de serviços fornece uma representação visual de toda a sua arquitetura. Veja os mapas de serviço para mais informações.
Transação
A página de transações fornece ferramentas para identificar problemas e analisar as transações de um serviço.
O OpenTelemetry não tem uma analogia direta com a noção de transação da New Relic. Veja Como as transações são derivadas dos dados do OpenTelemetry para mais detalhes.
As métricas New Relic que controlam a página de transações são as métricas apm.service.transaction.duration e apm.service.error.count. Consulte-os para obter detalhes sobre como eles são derivados dos seus dados do OpenTelemetry.
Rastreamento da transação
Os rastreamentos de transação para OpenTelemetry são derivados dos seus dados de intervalo. Na página de transações você pode encontrar uma lista de rastreamentos de transações. Esta lista requer que os dados de intervalo e os dados métricos de uma determinada transação sejam correlacionados. Fazemos isso adicionando um atributo transaction.name ao intervalo raiz de um trace da transação.
Detalhamento do segmento
Clicar em uma transação abre uma visão detalhada da transação, revelando um detalhamento do segmento. Ao contrário do New Relic Agent, OpenTelemetry não emite métricas para segmentos individuais. Portanto, a métrica New Relic necessária para conduzir a análise do segmento é derivada de dados de intervalo.
A desvantagem notável de calcular a divisão de segmentos a partir de dados de intervalo é que os intervalos geralmente são amostrados. Porém, mesmo com amostragem, a análise de segmentos ainda pode ajudar a identificar métodos ou operações específicas que consomem mais tempo em uma transação.
A partir dos dados do intervalo, estimamos uma taxa de amostragem calculando as taxas de transferência com base nos dados do intervalo recebidos e dividindo-as pelas taxas de transferência reais, conforme relatado pelos seus dados métricos. A taxa de amostragem estimada nos permite extrapolar a repartição do segmento de uma transação.
Esse processo não é perfeito e pode ser afetado por vários fatores, principalmente sua estratégia de amostragem. Funciona melhor quando você está amostrando estritamente uma porcentagem dos seus dados de intervalo. No entanto, por exemplo, se você amostrar apenas intervalos que representam erros, a divisão do segmento poderá ser distorcida.
Banco de dados
A página banco de dados fornece ferramentas para identificar problemas e analisar as operações do cliente do banco de dados de um serviço.
A instrumentação OpenTelemetry representa chamadas ao banco de dados usando as convenções semânticas do banco de dados.
A métrica New Relic que impulsiona a página do banco de dados é a métrica apm.service.datastore.operation.duration. Consulte-o para obter detalhes sobre como ele é derivado dos seus dados do OpenTelemetry.
Consumo de tempo por chamador
Ao clicar em uma chamada de banco de dados específica, você verá o gráfico "Consumo de tempo por chamador". Este gráfico é orientado pela métrica apm.service.transaction.overview. Essa é a mesma métrica que direciona a visualização do detalhamento do segmento da página de transação e é derivada de dados de intervalo.
Importante
As convenções semânticas do banco de dados do OpenTelemetry foram recentemente consideradas estáveis. Ainda não existem muitas instrumentações estáveis, e a instrumentação que existe muitas vezes emite apenas dados span e nenhum dado métrico.
Assim, ao utilizar instrumentação que ainda não adotou as convenções semânticas estáveis, a métrica APM gerada que aciona a página do banco de dados é derivada de dados de intervalo.
À medida que a instrumentação estável estiver disponível e você a adotar, a página do banco de dados começará a aproveitar os dados métricos OpenTelemetry. Entre em contato com a comunidade OpenTelemetry sobre a disponibilidade de instrumentação de banco de dados estável em sua linguagem.
Serviços externos
A página de serviços externos fornece ferramentas para identificar problemas e analisar chamadas externas de um serviço, incluindo a entidade chamadora (serviços upstream) e a entidade chamada (serviços downstream).
A instrumentação OpenTelemetry representa chamadas para serviços externos usando as convenções semânticas HTTP e RPC.
A métrica New Relic que impulsiona a página do banco de dados é a métrica apm.service.external.host.duration. Consulte-o para obter detalhes sobre como ele é derivado dos seus dados do OpenTelemetry.
Consumo de tempo por chamador
Ao clicar em uma chamada externa específica, você verá o gráfico "Consumo de tempo por chamador". Este gráfico é orientado pela métrica apm.service.transaction.overview. Essa é a mesma métrica que direciona a visualização do detalhamento do segmento da página de transação e é derivada de dados de intervalo.
Tempo de execução da JVM
A página de tempo de execução da JVM fornece ferramentas para identificar problemas e analisar a JVM de um serviço Java. A página é exibida somente para serviços que usam OpenTelemetry Java. Para diferenciar entre instâncias de serviço distintas, a página requer que o atributo de recurso service.instance.id seja definido (consulte Serviços para obter mais detalhes).
A página de tempo de execução JVM mostra sinais clássicos junto com métricas de tempo de execução JVM para correlacionar problemas de tempo de execução com o uso do serviço.
A consulta assume que os dados estão em conformidade com as convenções semânticas métricas JVM . Observe que essas convenções são incorporadas na biblioteca de instrumentação de tempo de execução Java do OpenTelemetry, que é incluída automaticamente com o agente Java do OpenTelemetry.
Tempo de execução
A página de tempo de execução do Go fornece ferramentas para identificar problemas e analisar o tempo de execução de um serviço Go. A página é exibida apenas para serviços que usam o OpenTelemetry Go. Para diferenciar entre instâncias de serviços distintas, a página requer que o atributo de recurso service.instance.id seja definido (consulte Serviços para obter mais detalhes).
A página do tempo de execução do Go mostra sinais clássicos junto com a métrica do tempo de execução do Go para correlacionar problemas de tempo de execução com o uso do serviço.
Os dados assumidos pela consulta são produzidos pela biblioteca de instrumentação de tempo de execuçãoOpenTelemetry Go. Observe que atualmente não há convenções semânticas para métricas de tempo de execução do Go.
Registro
A página de log fornece ferramentas para identificar problemas e analisar o log de um serviço. Consulte Usar interface de log para obter mais informações.
Errors Inbox
A página Caixa de entrada de erros fornece ferramentas para detectar e classificar erros de um serviço. Consulte Introdução à Caixa de entrada de erros para obter mais detalhes.
A página Caixa de entrada de erros é orientada por dados trace. Assim como acontece com os sinais clássicos, os intervalos são classificados como erros se o status do intervalo for definido como ERROR (por exemplo, otel.status_code = ERROR).
Os intervalos de erros são agrupados por sua impressão digital de erro, computados pela normalização de valores de identificação, como UUIDs, valores hexadecimais, endereços de e-mail, etc. Cada intervalo de erro distinto é uma instância individual dentro do grupo de erros. A mensagem do grupo de erros é determinada da seguinte forma:
- Descrição do status do período (por exemplo,
otel.status_description) rpc.grpc.status_codedas convenções semânticas de span RPChttp.status_codedas convenções semânticas de span HTTPhttp.response.status_codedas convenções semânticas de span HTTPundefinedse nenhuma das opções acima estiver presente
Exibição de extensão (legado)
No passado, os serviços instrumentados OpenTelemetry proporcionavam uma experiência de usuário totalmente diferente daquela do agente de linguagem do New Relic. Essa experiência mais antiga forneceu gráficos selecionados a partir de dados de intervalo. Dados de intervalo geralmente são amostrados, por isso podem ser enganosos, principalmente quando representam coisas como taxas de transferência.
Por enquanto, a antiga experiência do usuário ainda está disponível na página Span View (legada). Na parte superior, ele contém quatro abas: Resumo, Transações, banco de dados e Serviços externos. Todos os gráficos nessas guias são baseados em dados de intervalo.
Dica
Visão baseada em intervalo legado
Nossa experiência mais antiga OpenTelemetry APM permitiu a visualização de dados de perspectivas métricas e de amplitude. Como os dados de amplitude são normalmente amostrados, as métricas fornecem taxas de transferência e medições de tempo de resposta mais precisas. A visualização baseada em intervalo ainda está disponível, mas será descontinuada. Veja Span View (legado) para mais detalhes.
Métrica New Relic APM derivada de dados de intervalo
As métricas New Relic APM que orientam a experiência APM geralmente são derivadas de dados métricos. No entanto, há alguns cenários em que as métricas APM são derivadas de dados de intervalo. Para os cenários a seguir, observe que a estratégia de amostragem que você está usando influenciará a métrica gerada.
Detalhamento do segmento
A visão detalhada do segmento de transação é orientada a partir de dados de intervalo. Veja a análise do segmento para mais informações.
Chamadas de banco de dados
As convenções semânticas do banco de dados OpenTelemetry foram recentemente declaradas estáveis. Contudo, a maior parte da instrumentação do banco de dados ainda não adotou as convenções estáveis e ainda não emite dados métricos. Portanto, ao utilizar instrumentação mais antiga, as métricas que orientam a página do banco de dados são geradas a partir dos dados span. Recomendamos que você atualize para a instrumentação de banco de dados estável mais recente assim que ela estiver disponível para seu idioma.
Sistemas de mensagens
As convenções semânticas de mensagens do OpenTelemetry ainda estão em desenvolvimento. A maior parte da instrumentação de mensagens ainda não emite dados métricos. New Relic representa interações com sistemas de mensagens como transação fora da web. Veja Como as transações são derivadas dos dados do OpenTelemetry para obter mais informações.
OpenTelemetry Ruby
OpenTelemetry agora oferece suporte ao métrica para a maioria das linguagens, porém Ruby é uma exceção notável. Para Ruby, realizamos um esforço de melhor-fé para gerar a métrica New Relic APM a partir de dados de intervalo.
Serviço métrico APM
As métricas apm.service.* impulsionam a experiência de APM da New Relic. As seções a seguir descrevem os dados de origem OpenTelemetry usados para derivar métricas apm.service.*.
atributo de recurso métrico
Os seguintes atributos de recurso são copiados dos dados de origem para APM métrica:
container.identity.guidhost.nameinstrumentation.providerk8s.cluster.namek8s.container.namek8s.namespace.namek8s.pod.nameservice.instance.idservice.name
métrica: apm.service.transaction.duration
Nome | Unidade (UCUM) | Descrição | |
|---|---|---|---|
| Distribuição |
| Duração das transações. [2] |
Atributo | Tipo | Descrição | Exemplo |
|---|---|---|---|
|
| O nome da transação. |
|
|
| O tipo da transação. |
|
|
| Descreve uma classe de erro com a qual a transação terminou. |
|
[1]: A unidade da métrica de origem é copiada.
[2]: Se error.type for resolvido como não nulo, apm.service.error.count será incrementado com a respectiva contagem dos dados de origem.
fontes métricas
Convenção Semântica | Nome da métrica | Condições |
|
|
|
|---|---|---|---|---|---|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
métrica: apm.service.transaction.overview
Nome | Unidade (UCUM) | Descrição | |
|---|---|---|---|
| Resumo | s | Tempo de detalhamento do segmento de uma transação. |
Atributo | Tipo | Descrição | Exemplo |
|---|---|---|---|
|
| O nome da transação. |
|
|
| O tipo da transação. |
|
atributo militar | vários | atributo específico dependente da convenção do domínio de origem incluindo: | Veja |
Fontes de extensão
Convenção Semântica | Tipo de extensão | Condições |
|
| atributo militar |
|---|---|---|---|---|---|
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
métrica: apm.service.external.host.duration
Nome | Unidade | (UCUM) | Descrição | |
|---|---|---|---|---|
| Distribuição |
| Duração das chamadas externas. |
Atributo | Tipo | Descrição | Exemplo |
|---|---|---|---|
|
| Domínio do servidor, se disponível, sem consulta reversa de DNS; caso contrário, endereço IP ou nome do soquete de domínio Unix |
|
[1]: A unidade da métrica de origem é copiada.
fontes métricas
Convenção Semântica | Nome da métrica | Condições |
|
|---|---|---|---|
|
|
| |
|
|
| |
|
|
|
métrica: apm.service.datastore.operation.duration
Nome | Unidade (UCUM) | Descrição | |
|---|---|---|---|
| Distribuição |
| Duração das chamadas do armazenamento de dados. |
[1]: A unidade da métrica de origem é copiada.
Atributo | Tipo | Descrição | Exemplo |
|---|---|---|---|
|
| O produto do sistema de gerenciamento de banco de dados (SGBD) conforme identificado pela instrumentação do cliente. |
|
|
| O nome de uma coleção (tabela, contêiner) dentro do banco de dados. |
|
|
| O nome da operação ou comando que está sendo executado. |
|
|
| Resumo de baixa cardinalidade de uma consulta ao banco de dados. |
|
fontes métricas
Convenção Semântica | Nome da métrica | Condições |
|
|
|
|
|---|---|---|---|---|---|---|
|
|
|
|
|
|
Funções auxiliares
Funções auxiliares são referências a bits de lógica de alinhamento de atributos que são mais complexas do que simples referências de atributos.
Função | Descrição |
|---|---|
| Retorna o valor da string de |
| Retorna o valor da string de rpc.grpc.status_code se em conjunto: |
| Retorna a primeira palavra em |
| Retorna a primeira palavra em |
| espaço reservado para |
Sinais clássicos
Os sinais clássicos de taxas de transferência, tempo de resposta e taxas de erros aparecem em diversos locais da interface do OpenTelemetry APM. Quando usados, eles são calculados da seguinte forma:
Para métrica, a consulta assume que os dados estão em conformidade com as convenções semânticas HTTP métrica ou RPC métrica .
Para spans, as consultas são genéricas, utilizando apenas o modelo de dados de span de nível superior. Os spans são contados para taxas de transferência e tempo de resposta se forem spans de entrada raiz em um serviço, computando usando uma heurística de WHERE span.kind = server OR span.kind = consumer. Os spans serão erros se tiverem um código de status ERROR (por exemplo, otel.status_code = ERROR).
Dados restritos com filtros
Várias páginas incluem uma barra de filtros, com opções como Limitar dados para.... Isso permite que você filtre consultas na página de acordo com os critérios. Por exemplo, você pode restringir uma implantação canary específica filtrando por service.version='1.2.3-canary'. Os filtros são preservados ao navegar entre as páginas.
Métricas clássicas
Métricas clássicas são versões de baixa cardinalidade de sinais clássicos de dados, como métricas HTTP/RPC. Eles preenchem várias experiências de plataforma, incluindo o Explorer da entidade, a página de atividades da carga de trabalho e a página de detalhes do Monitoramento de alterações. Essas métricas usam nomes como newrelic.goldenmetrics.ext.service.*.
Importante
Historicamente, as métricas clássicas OpenTelemetry foram calculadas a partir de spans. Os vãos geralmente são amostrados, então eles fornecem apenas uma imagem parcial. Agora que as métricas estão amplamente disponíveis, as métricas clássicas são calculadas usando dados métricos em vez de dados span.