Les logs APM en contexte

Il existe plusieurs façons de signaler vos logs à New Relic. L’utilisation de nos agents APM est un moyen populaire, en particulier pour les petites équipes et les équipes DevOps qui apprécient l’avantage de ne pas avoir à utiliser d’autres outils .

Conseil

Vous avez beaucoup de logs ? Consultez notre tutoriel pour savoir comment les optimiser et les gérer.

Nos agents ont une fonctionnalité appelée logs in context. Pour en savoir plus sur les avantages de cette fonctionnalité, consultez Logs en contexte.

Pour les agents APM, notre fonctionnalité de logs en contexte fait plusieurs choses :

Décore le log de votre application avec des métadonnées New Relic importantes (comme span.id, trace.id, hostname, entity.guid, entity.name) qui vous permettent de voir vos données log dans diverses expériences d'interface utilisateur de New Relic.
Transfère votre log directement vers New Relic, vous n'avez donc pas besoin d'un outil tiers.
Signale certaines métriques de logs. Ceux-ci sont affichés sur le graphique Logs de la page d'interface utilisateur APM Summary .

Nos versions actuelles de l'agent APM ont ces fonctionnalités activées par défaut.

Vous avez le contrôle sur tous les aspects de cette fonctionnalité via la configuration de l'agent APM. Pour connaître les raisons pour lesquelles vous pourriez vouloir désactiver un ou plusieurs d'entre eux, voir Limitations. Par exemple, si vous souhaitez qu'un agent APM ajoute des métadonnées New Relic, vous pouvez utiliser la fonctionnalité de décoration log , tout en désactivant le transfert de loget en utilisant à la place un autre agent de logging (par exemple, notre agent infrastructure ou un agent de logging tiers).

Les détails d'implémentation et les instructions de configuration varient selon l'agent (voir les détails de l'agent).

Pour en savoir plus sur la puissance des logs en contexte, consultez cet exemple de cas d'utilisation. L'exemple décrit comment une équipe d'ingénieurs a utilisé les logs en contexte pour résoudre les problèmes de temps de réponse lents et de taux d'erreur croissants de leur application.

Pour voir comment les logs en contexte peuvent vous aider à trouver la cause première d'un problème dans vos applications et hôtes, regardez cette courte vidéo (environ 15 minutes). 3:40 minutes):

Démarrer

Pour configurer logs en contexte :

Si vous n'en avez pas déjà un, créez un compte New Relic. C'est gratuit, pour toujours.
Installez un agent APM, en vous assurant que vous disposez de la dernière version de l'agent APM.
Les versions les plus récentes de nos agents APM ont les logs en contexte (ajout de métadonnées et de transfert) activés par défaut. Vous devrez peut-être parfois apporter certaines mises à jour au fichier de configuration de l'agent pour que le log fonctionne correctement. Pour plus de détails à ce sujet, voir Activer les logs pour votre agent.

C'est ça ! Démarrez le dépannage de vos applications avec les logs en contexte APM en accédant à l'interface utilisateur APM et en recherchant les données log associées.

Screenshot of APM Summary page with logs in context options

Accédez à votre log, à votre trace et à vos erreurs, le tout à partir de la page APM Summary dans New Relic.

API d'agent APM

Si votre framework de logging n'est pas disponible avec nos solutions de logs en contexte existantes, vous pouvez configurer votre bibliothèque de logging en utilisant l'appel d'API pour annoter votre log.

Configuration de log de l'agent APM

Nos derniers agents ont les logs en contexte (décoration log et transfert de log ) activés par défaut. Voici des informations sur les agents APM qui prennent en charge les logs en contexte et le transfert de log :

Procédures de logs en contexte Go pour l'agent v3.17.0 ou supérieur
Procédures pour les logs en contexte Java pour agent v7.6.0 ou supérieur
Procédures de logs en contexte .NET pour l'agent v9.8.0 ou supérieur
Procédures de logs en contexte Node.js pour l'agent v8.11.0 ou supérieur
Procédures de logs en contexte PHP pour agent v10.1.0 ou supérieur
Procédures de logs en contexte Python pour l'agent v7.12.0.176
Procédures des logs en contexte Ruby pour l'agent v8.6.0 ou supérieur

Si vous ne pouvez pas ou ne souhaitez pas utiliser le transfert de log APM, vous pouvez transférer votre log en utilisant une autre solution.

Limites

Les logs en contexte APM sont activés par défaut. Cela peut avoir un impact négatif sur votre sécurité, votre conformité, votre facturation ou les performances de votre système.

Voici quelques limitations supplémentaires connues :

À l'exception de l'agent Node.js , transfert de logs n'envoie pas le log complet. Renseignez-vous sur les détails du transfert de log .
Le log de démarrage n'est pas disponible tant que l'agent n'est pas chargé.
Si vous utilisez Kubernetes, sachez que nous décorons le log via instrumentation, et non à partir de l'API Kubernetes . Ceci est distinct et séparé du log d'écriture dans le système de fichiers. Le log ne touche jamais l'hôte ou n'existe pas à un endroit où l'API peut être appelée.
Lorsqu'une exception est levée depuis votre application, vous ne verrez actuellement aucune trace d'appels dans les logs en contexte associés pour les agents Java ou .NET. Pour contourner ce problème, vous pouvez modifier vos règles de filtrage des dépôts.
Fluentd peut ajouter le processID de l'entité qui a généré le log, mais le log APM ne peut pas le voir. De plus, dans Kubernetes, l’API est appelée pour ajouter des métadonnées, mais ces données ne peuvent pas être vues depuis l’application. Si vous avez besoin de l'entité mémorisée, nous vous recommandons d'utiliser les logs en contexte automatiques, mais de ne pas expédier le log depuis l'application. Continuez plutôt à utiliser Fluentd, Fluent Bit ou une autre solution pour transférer le fichier de log.

Si vous devez ajuster les paramètres par défaut, consultez Désactiver le logging automatique.

Assurer la confidentialité des données

Prudence

Vous contrôlez les données log envoyées à New Relic, alors assurez-vous de suivre les consignes de sécurité de votre organisation pour masquer, obscurcir ou empêcher l'envoi d'informations personnelles identifiables (PII), d'informations de santé protégées (PHI) ou de toute autre donnée sensible.

Notre log d'ingestion pipeline de masque automatiquement les cartes de crédit, les numéros de sécurité sociale, les cartes d'identité nationales, etc. Pour plus d'informations, consultez notre documentation de sécurité pour la gestion des logs.

Vous pouvez également créer des règles personnalisées pour masquer ou pirater des données sensibles dans votre log avec notre fonctionnalité obfuscation . Cela est essentiel lorsqu'il est peu pratique ou impossible de restreindre l'accès aux données sensibles, ou lorsque certaines données ne doivent jamais être stockées par New Relic. Lisez notre documentation sur l’obfuscation pour en savoir plus.

Détails sur le transfert de log

Pour tous les agents (sauf Node.js), l'option transfert de logne transmet pas l'intégralité log. Pour plus de détails sur ce qui est envoyé avec le transfert de log , voir le réducteur ci-dessous.

Par exemple, disons que votre log a un attribut comme celui-ci :

{
  "v": "x",
  "level": "x",
  "name": "x",
  "hostname": "x",
  "pid": 01,
  "timestamp": "x",
  "message": "x",
  "bunches": "of custom stuff"
}

Lorsqu'un agent APM (à l'exception de Node.js) décore le log avec nos métadonnées et le transmet, il peut n'avoir que quelques attributs dans New Relic, comme ceci :

{
  "timestamp": "x",
  "message": "x",
  "span.id": "x",
  "trace.id": "x",
  "hostname": "x",
  "entity.guid": "x",
  "entity.name": "x"
}

Si vous avez besoin d'informations plus détaillées sur le log , les options incluent :

Configurez l'agent APM pour inclure des données log spécifiques.
Conservez la décorationlog en place, mais désactivez le transfert de logde l'agent APM et utilisez plutôt votre propre solution de transfert de log .

Pour plus d'informations sur ces options, consultez les logs spécifiques à l'agent dans la documentation contextuelle.

Métriques de Log

Lorsque vous configurez un agent , vous obtenez automatiquement un graphique des mesures de logging sur la page APM Summary :

Screenshot showing the logging metrics chart

Ce graphique montre le nombre de logarithmes. Si vous n'avez pas désactivé le transfert de log , vous pouvez cliquer sur les liens des graphiques qui vous mèneront aux logs eux-mêmes. Même si vous désactivez le transfert de log , ce graphique montre toujours le log potentiel que vous pourriez inspecter si vous aviez activé le transfert de log .

Les métriques de logging sont signalées via l'attribut apm.service.logging.lines , comme indiqué dans la requête suivante :

SELECT count(apm.service.logging.lines) FROM Metric WHERE (entity.guid = 'AN_ENTITY_GUID') LIMIT MAX SINCE 60 seconds AGO TIMESERIES

Si vous ne souhaitez pas voir le graphique des métriques de logging, vous pouvez le désactiver, mais pas au niveau du compte. Pour désactiver les métriques de logging, consultez les documents de configuration APM dédiés à votre agent (par exemple, cette option de configuration logging_metrics pour PHP).

Important

Si vous désactivez les métriques de logging, cela ne désactive pas la fonctionnalité de transfert de log APM. Pour arrêter la transmission du log APM, consultez Gérer ou désactiver les logs en context d'APM.

Empêcher la duplication des logs

L'utilisation de la fonctionnalité de logs en contexte augmentera votre ingestion de données. Selon le modèle de tarification de votre compte, cela peut avoir un impact sur vos limites d'ingestion et votre facturation.

Prudence

Si vous souhaitez utiliser l'agent APM pour envoyer le log directement depuis vos applications, vous devez désactiver ou modifier les solutions de transfert de logqui collectent actuellement le log de ces applications. Dans le cas contraire, vous enverrez un log en double, ce qui entraînera une double facturation.

Consultez notre guide de mise à niveau pour en savoir plus sur la manière dont vous pouvez éviter d'envoyer des logs en double.

Pour plus d'informations, suivez les procédures pour désactiver votre redirecteur de logspécifique.

Gérez vos limites d'ingestion

Example: Votre équipe d'ingénierie résout un problème avec votre application, vous augmentez donc temporairement le volume de logs collectés par l'agent APM pour fournir un logging plus granulaire. Cependant, si vous laissez des limites plus élevées fonctionner pendant plusieurs jours, cela pourrait entraîner l'envoi de données inutiles qui augmenteront votre facture.

Pour éviter toute surprise, nous vous recommandons d'utiliser une requête NRQL pour créer une condition d'alerte afin de suivre vos limites d'ingestion. Par exemple:

Pour créer une alerte lorsque votre utilisation dépasse un seuil mensuel fixe de gigaoctets de données, ajoutez cette requête NRQL à votre condition d'alerte :

FROM NrMTDConsumption SELECT latest(GigabytesIngested) WHERE productLine = 'DataPlatform'

Exemple : Le pouvoir des logs en contexte

Voici un cas d'utilisation détaillé de l'utilisation des logs dans contexte pour arriver à la cause première d'un problème.

Example scenario: L'ingénieur de garde reçoit une notification d'alerte New Relic concernant un mauvais temps de réponse et une augmentation du taux d'erreur pour son application. Ils doivent découvrir la cause profonde de l'augmentation des erreurs et de la latence, afin de pouvoir décider s'il faut faire pivoter un hôte problématique hors de l'équilibrage de charge ou annuler la sortie la plus récente.

Pour démarrer le dépannage, ils se rendent dans l'interface utilisateur de New Relic.

Lorsque l'ingénieur consulte la page APM Summary de l'application, il voit beaucoup plus de logs d'erreurs conduisant à une augmentation du temps de réponse. Ils veulent voir si le log peut révéler la cause profonde du problème.

How can they quickly decide what's related to the problem?

Ils n'ont pas mis en place de collecte log . Mais l'agent Java pour leur application a été récemment mis à jour pour inclure les logs APM dans le contexte, de sorte que l'application reçoit désormais automatiquement les métadonnées des logs et des liens. Les métriques qui apparaissent dans l'interface utilisateur facettent le comptage par sévérité des logs. (Ceci est défini par les Java log capacités de décoration intégrées de l'agent .)

What entities are related?

Sur la même page d'interface utilisateur, ils cliquent sur le graphique Logs afin de pouvoir consulter la vue Log summary . Cette vue montre quand les logs instrumentés ont été collectés et quand ces logs avaient un niveau de gravité Error ou pire. Il leur montre également une liste de log patterns et le pourcentage de tous les logs correspondant à chaque modèle.

Dans l'interface utilisateur Log patterns , des messages d'erreur rares ont commencé à se produire fréquemment et ils apparaissent désormais dans la liste. Cela aide l'ingénieur à se concentrer sur le log problématique au lieu de toutes les mises à jour de statut bruyantes.

What patterns should they focus on?

L'ingénieur remarque des modèles log intéressants et souhaite afficher uniquement les logs qui correspondent à ce modèle. Ils cliquent dessus pour ajouter la valeur du modèle comme filtre au log affiché. Cela restreint la portée.

L'ingénieur souhaite voir toutes les valeurs contenues dans l'enregistrement log , il clique donc sur la vue Log details. Cela les aide à valider que le log lui-même est significatif. Cela leur permet également d'explorer plus en détail Kubernetes l'environnement dans lequel l'application s'exécute, ou directement les traces distribuées ou les erreurs liées à log l'enregistrement .

L'ingénieur décide de regarder l'erreur APM où il peut voir une trace complète d'appels. Ils peuvent également voir le log depuis leur interface utilisateur Errors inbox .

L'équipe de dépannage a effectué des tests pour isoler la cause, mais tous les logs n'ont pas été collectés pour les transactions de test. La collecte log par défaut dans le fichier de configuration de leur agent Java (environ 10 000 logs par minute dans application_logging:forwarding:max_samples_stored:) a été utile pour valider que les services ont un problème. Mais ils doivent désormais augmenter l'échantillonnage à un nombre plus élevé pour un dépannage plus détaillé.

L'équipe de dépannage détermine que le problème provient d'un changement récemment introduit, elle annule donc ce code. Pour économiser des ressources et réduire les dépenses, ils refusent la collecte log pour application_logging:forwarding:max_samples_stored: dans leur fichier de configuration, mais ils maintiennent l'échantillonnage log en cours d'exécution au cas où le problème se répéterait.

L'équipe de dépannage met également à jour ses runbooks pour pointer vers la page Log patterns filtrée sur cette application, et elle ajoute le runbook à sa condition d'alerte. La prochaine fois qu’ils recevront une alerte similaire à cette situation, ils pourront utiliser ces leçons apprises pour un dépannage plus rapide.

Cette traduction automatique est fournie pour votre commodité.

Les logs APM en contexte

Conseil