Logs OpenTelemetry dans New Relic

Cette documentation se concentre sur la manière dont New Relic traite les logs OpenTelemetry reçus via son point de terminaison OTLP dédié.

Il existe deux workflows typiques pour l'envoi des logs OpenTelemetry à New Relic :

Directement au Collector:
- Les applications peuvent envoyer les logs directement au point de terminaison OTLP de New Relic.
- Reportez-vous à la OpenTelemetry documentation du langage concerné pour obtenir des détails d'implémentation spécifiques du monitoring d'OpenTelemetry APM pour plus de détails sur le monitoring des services avec New Relic.
Via fichier ou stdout:
- Cette méthode consiste à extraire les logs d'application écrits dans des fichiers ou sur la sortie standard (stdout).
- Le OpenTelemetry Collector est généralement utilisé pour cette tâche. Les logs récupérés sont ensuite transmis au point de terminaison New Relic OTLP.
- Des informations de configuration détaillées peuvent être trouvées dans les ressources OpenTelemetry suivantes :

Quelle que soit la méthode de collecte choisie, une intégration réussie nécessite de configurer votre source log pour exporter les logs vers ce point de terminaison. Assurez-vous de vérifier les exigences de configuration du point de terminaison avant de continuer.

Modélisation des enregistrements de log OTLP

New Relic mappe les enregistrements log OTLP au type de données Log. Le tableau ci-dessous décrit comment les champs du message protoLogRecord sont mappés à New Relic Log:

Champ OTLP `logs.proto`	Champ `Log` de New Relic
`ResourceLogs.Resource.attributes`	Chaque valeur/clé est un attribut sur le champ `Log` [1]
`ScopeLogs.InstrumentationScope.name`	`otel.library.name`
`ScopeLogs.InstrumentationScope.version`	`otel.library.version`
`ScopeLogs.InstrumentationScope.attributes`	Chaque valeur/clé est un attribut sur le champ `Log` [1]
`LogRecord.time_unix_nanos`	`timestamp` [2]
`LogRecord.severity_number`	`severity.number`
`LogRecord.severity_text`	`severity.text`
`LogRecord.body`	`message`, et éventuellement l'attribut analysé [3]
`LogRecord.attributes`	Chaque valeur/clé est un attribut sur le champ `Log` [1]
`LogRecord.dropped_attribute_count`	`otel.dropped_attributes_count`
`LogRecord.flags`	`w3c.flags` (entier)
`LogRecord.trace_id`	`trace.id`
`LogRecord.span_id`	`span.id`

Notes de bas de tableau

[1] En cas de conflit dans l'attribut de ressource, l'attribut de portée, l'attribut d'enregistrement de log , les champs d'enregistrement log de niveau supérieur et l'attribut analysé de LogRecord.body [3], l'ordre de priorité (du plus élevé au plus bas) est : attribut analysé de LogRecord.body -> champs de niveau supérieur LogRecord.* > LogRecord.attributes > ScopeLogs.InstrumentationScope.attributes > ResourceLogs.Resource.attributes.

Consultez les types d'attributs OTLP pour plus de détails sur les types d'attributs pris en charge par le point de terminaison OTLP de New Relic et les limites d'attributs OTLP pour plus de détails sur la validation effectuée sur l'attribut.

[2] Si LogRecord.time_unix_nanos n'est pas présent, timestamp est défini sur l'heure à laquelle New Relic a reçu les données.

[3] L'analyse des logs est appliquée au LogRecord.body pour tenter d'extraire l'attribut de :

Texte log brut : la valeur de la chaîne sera définie comme l'attribut message.
JSON stringifié : si un log est formaté en JSON mais envoyé sous forme de chaîne de texte brut, les paires valeur/clé deviendront l'attribut du log résultant. Pour plus de détails, reportez-vous à la documentation d'analyse JSON . Ceci est particulièrement utile lors de la collecte de logs à partir de fichiers ou stdout. Dans ce cas, il est courant de n'avoir aucun attribut de ressource associé à l'enregistrement log (requis pour la corrélation du service APM) et aucune valeur pour LogRecord.trace_id / LogRecord.span_id (requis pour la corrélation de la trace). Les logs en contexte fonctionneront comme prévu si les champs obligatoires peuvent être analysés avec succès.
Structure de la carte : si les données sont formatées sous forme de carte conformément à la spécification OTLP, elles seront analysées et aplaties en attributs, de manière similaire à l'analyse JSON. Pour plus de détails, reportez-vous à la documentation d'analyse JSON .

Corrélation avec le service OpenTelemetry APM

Les log sont corrélés à une entité de service s'ils incluent l' attribut requis. En général, ils proviennent de l'attribut de ressource du log, tel que ResourceLogs.Resource.attributes, mais ils peuvent également être analysés à partir de LogRecord.body comme décrit dans la note de bas de page n°3 de la modélisation OTLP.

Pour afficher les logs d’un service, accédez à la page de Logs de ce service.

Corrélation avec trace

Les log sont corrélés avec une trace si les attributs trace.id et span.id peuvent être résolus. En général, ceux-ci proviennent des champs LogRecord.trace_id et LogRecord.span_id , mais peuvent également être analysés à partir du champ LogRecord.body comme décrit dans la note de bas de page 3 de la modélisation OTLP.

Pour afficher les logs enregistrés dans le contexte d'une trace particulière, vous avez deux options :

Accédez à l’onglet Logs dans la page de détails de trace.
Accédez à la page de Logs d’un service et cliquez sur un log pour ouvrir les détails log . S'il est associé à une trace, vous pourrez naviguer des détails du log aux détails de la trace.

se connecter en tant que New Relic événement personnalisé

OpenTelemetry définit un événement comme un LogRecord avec un EventName non vide. les événements personnalisés sont un signal central de la plateforme New Relic. Cependant, malgré l'utilisation du même nom, OpenTelemetry événement et New Relic événement personnalisé ne sont pas des concepts identiques :

Les OpenTelemetry EventNamene partagent pas le même format ou la même sémantique que les types d'événements personnalisés. Les noms d'événements OpenTelemetry sont entièrement qualifiés avec un espace de nommage et suivent une casse minuscule, par exemple com.acme.my_event. Les types d'événement personnalisé sont Pascal Case, par exemple MyEvent.
L'événement OpenTelemetry peut être considéré comme un log structuré amélioré. Comme les journaux structurés, leurs données sont codées en paires valeur-clé plutôt qu'en texte libre. De plus, le EventName agit comme un signal sans ambiguïté de la classe / du type d'événement qui s'est produit. événement personnalisé est traité comme un tout nouveau type d'événement, accessible via NRQL avec SELECT * FROM MyEvent.

En raison de ces différences, les événements OpenTelemetry sont ingérés en tant que New Relic Logs puisque la plupart du temps, les événements OpenTelemetry sont plus proches en similarité de New Relic Logs que de New Relic événement personnalisé.

Cependant, vous pouvez signaler explicitement qu'un OpenTelemetry LogRecord doit être ingéré en tant qu'événement personnalisé en ajoutant une entrée à LogRecord.attributes sous la forme : newrelic.event.type=<EventType>.

Par exemple, un LogRecord avec l'attribut newrelic.event.type=MyEvent sera ingéré en tant qu'événement personnalisé avec type=MyEvent et accessible via NRQL avec : SELECT * FROM MyEvent.