Registro OpenTelemetry no New Relic

Esta documentação se concentra em como New Relic processa o log OpenTelemetry recebido por meio de seu endpoint OTLP dedicado.

Existem dois fluxos de trabalho típicos para enviar log OpenTelemetry para New Relic:

• Direto para o coletor:

  • O aplicativo pode enviar log diretamente para o New Relic OTLP endpoint.
  • Consulte a documentação relevante da linguagem OpenTelemetry para obter detalhes de implementação específicos e o monitoramento OpenTelemetry APM para obter detalhes sobre serviços de monitoramento com New Relic.

• Via arquivo ou stdout:

  • Este método envolve a extração do log do aplicativo gravado em arquivos ou saída padrão (stdout).

  • O coletor OpenTelemetry é normalmente usado para essa tarefa. O log raspado é então encaminhado para o New Relic OTLP endpoint.

  • Informações detalhadas de configuração podem ser encontradas nos seguintes recursos do OpenTelemetry:

    • Coletor OpenTelemetry
    • Receptor de filelog com Kubernetes
    • Um exemplo prático demonstrando esse fluxo de trabalho para aplicativo Java usando Log4j2

Independentemente do método de coleta escolhido, uma integração bem-sucedida requer a configuração de sua origem log para exportar o log para este endpoint. Certifique-se de revisar os requisitos de configuração do endpoint antes de continuar.

Mapeamento de registro log OTLP

O New Relic mapeia registros de log OTLP para o tipo de dados Log. A tabela abaixo descreve como os campos da mensagem protoLogRecord são mapeados para New Relic Log:

Notas de rodapé da tabela

[1] Em caso de conflito no atributo de recursos, atributo de escopo, atributo de registro de log , campos de registro de log de nível superior e atributo analisado de LogRecord.body [3], a ordem do precedente (do maior para o menor) é: atributo analisado de LogRecord.body -> campos LogRecord.* de nível superior > LogRecord.attributes > ScopeLogs.InstrumentationScope.attributes > ResourceLogs.Resource.attributes.

Consulte os tipos de atributos OTLP para obter detalhes sobre os tipos de atributos suportados New Relic OTLP endpoint e os limites de atributos OTLP para obter detalhes sobre a validação realizada no atributo.

[2] Se LogRecord.time_unix_nanos não estiver presente, timestamp será definido como o horário em que a New Relic recebeu os dados.

[3] A análise de log é aplicada ao LogRecord.body para tentar extrair atributo de:

• Texto de log simples: O valor da string será definido como o atributo message .
• JSON stringificado: se um log for formatado como JSON, mas enviado como uma string de texto simples, os pares valor principal se tornarão atributos do log resultante. Para mais detalhes, consulte a documentação de análise JSON . Isso é particularmente útil ao coletar logs de arquivos ou stdout. Nesse caso, é comum não ter nenhum atributo de recurso associado ao registro de log (necessário para correlação de serviçoAPM ) e nenhum valor para LogRecord.trace_id / LogRecord.span_id (necessário para correlaçãotrace ). Os logs no contexto funcionarão conforme o esperado se os campos necessários puderem ser analisados com sucesso.
• Estrutura do mapa: se os dados forem formatados como um mapa de acordo com a especificação OTLP, eles serão analisados e nivelados em atributos, semelhante à análise JSON. Para mais detalhes, consulte a documentação de análise JSON .

Correlação com o serviço OpenTelemetry APM

log estão correlacionados com uma entidade de serviço se incluírem o atributo exigido. Normalmente, eles vêm do atributo de recurso do log, como ResourceLogs.Resource.attributes, mas também podem ser analisados a partir de LogRecord.body conforme descrito na nota de rodapé nº 3 do mapeamento OTLP.

Para visualizar o log de um serviço, navegue até a página de log desse serviço.

Correlação com traces

Log são correlacionados com um trace se trace.id e span.id atributo puderem ser resolvidos. Normalmente, eles vêm dos campos LogRecord.trace_id e LogRecord.span_id , mas também podem ser analisados a partir do LogRecord.body conforme descrito na nota de rodapé 3 do mapeamento OTLP.

Para visualizar o log registrado no contexto de um determinado trace, você tem duas opções:

• Navegue até a guia Logs na página de detalhes de trace .
• Navegue até a página de log de um serviço e clique em um log para abrir os detalhes log. Se estiver associado a um trace, você poderá navegar dos Log details até osTrace details.

Logs como evento New Relic personalizado

OpenTelemetry define um evento como um LogRecord com um EventName não vazio. eventos personalizados são um sinal central na plataforma New Relic. Entretanto, apesar de usarem o mesmo nome, OpenTelemetry evento e New Relic evento personalizado não são conceitos idênticos:

• OpenTelemetry EventNames não compartilham o mesmo formato ou semântica que os tipos de eventos personalizados. Os nomes dos eventos OpenTelemetry são totalmente qualificados com um namespace e seguem letras minúsculas, por exemplo com.acme.my_event. tipos de eventos personalizados são pascal case, por exemplo MyEvent.
• O evento OpenTelemetry pode ser considerado um log estruturado aprimorado. Assim como os logs estruturados, seus dados são codificados em pares valor principal em vez de texto de formato livre. Além disso, o EventName atua como um sinal inequívoco da classe/tipo de evento que ocorreu. eventos personalizados são tratados como um tipo de evento totalmente novo, acessível via NRQL com SELECT * FROM MyEvent.

Devido a essas diferenças, os eventos OpenTelemetry são ingeridos como New Relic Logs, já que na maioria das vezes, os eventos OpenTelemetry são mais semelhantes ao New Relic Logs do que ao evento personalizado New Relic.

No entanto, você pode sinalizar explicitamente que um OpenTelemetry LogRecord deve ser ingerido como um evento personalizado adicionando uma entrada em LogRecord.attributes seguindo o formato: newrelic.event.type=<EventType>.

Por exemplo, um LogRecord com atributo newrelic.event.type=MyEvent será ingerido como um evento personalizado com type=MyEvent e acessível via NRQL com: SELECT * FROM MyEvent.