Bienvenue dans le guide des bonnes pratiques de logging de New Relic. Vous trouverez ici des recommandations détaillées sur la façon d'optimiser notre fonctionnalité de log et de gérer la consommation de données.
Conseil
Vous avez beaucoup de logs ? Consultez notre tutoriel pour savoir comment les optimiser et les gérer.
Log de transfert
Voici quelques conseils sur le transfert de logpour compléter notre documentation sur le transfert de log:
Lors du transfert du log, nous vous recommandons d'utiliser notre agent New Relic Infrastructure et/ou nos agents APM. Si vous ne pouvez pas utiliser les agents New Relic, utilisez d’autres agents pris en charge (comme FluentBit, Fluentd et Logstash).
Voici quelques exemples de configuration Github pour les agents de logging pris en charge :
Important
Si vos logs sont stockés dans un répertoire sur un hôte/conteneur sous-jacent et sont instrumentés par notre agent infrastructure pour collecter les logs, vous pouvez voir des logs en double collectés à la fois par l'agent infrastructure et l'agent . Pour éviter d'envoyer des logs en double, consultez nos recommandations dans ce guide.
Ajoutez un attribut
logtype
à toutes les données que vous transférez. L'attribut required permet d'utiliser nos règles d'analyse intégrées et peut également être utilisé pour créer des règles d'analyse personnalisées en fonction du type de données. L'attributlogtype
est considéré comme un attribut bien connu et est utilisé dans notre dashboard quickstart pour les informations récapitulatives log .Utilisez nos règles d’analyse intégrées pour les types de logs connus. Nous analyserons automatiquement les logs de nombreux types log différents et bien connus lorsque vous définissez l'attribut
logtype
approprié.Voici un exemple de la manière d'ajouter l'attribut
logtype
à un log transmis par notre agent infrastructure :logs:- name: mylogfile: /var/log/mylog.logattributes:logtype: mylogUtilisez l'intégration New Relic pour transférer le log d'autres types de données courants tels que :
- environnements conteneurisés : Kubernetes (K8S)
- Intégration du fournisseur de cloud : AWS, Azure ou GCP
- L'une de nos autres intégrations sur hôte prises en charge avec logging
Partitions de données
Si vous consommez ou prévoyez de consommer une quantité importante de données log chaque jour, vous devez absolument travailler sur un plan de gouvernance d'ingestion pour les logs, y compris un plan de partitionnement des données de manière à fournir des regroupements fonctionnels et thématiques. Vous pouvez obtenir des améliorations de performances significatives grâce à une utilisation appropriée des partitions de données. Si vous envoyez tous vos logs vers un « bucket » géant (la partition log par défaut) dans un seul compte, vous risquez de rencontrer des requêtes lentes ou des requêtes échouées puisque vous devrez analyser tous les logs de votre compte pour renvoyer les résultats de chaque requête. Pour plus de détails, consultez Limites de taux de requête NRQL.
Une façon d’améliorer les performances des requêtes consiste à limiter la plage horaire recherchée. La recherche de logs sur de longues périodes de temps renverra plus de résultats et nécessitera plus de temps. Évitez les recherches sur de longues fenêtres temporelles lorsque cela est possible et utilisez le sélecteur de plage temporelle pour restreindre les recherches à des fenêtres temporelles plus petites et plus spécifiques.
Une autre façon d’améliorer les performances de recherche est d’utiliser des partitions de données. Voici quelques bonnes pratiques pour les partitions de données :
Assurez-vous d’utiliser des partitions au début de votre processus d’intégration des logs. Créez une stratégie d'utilisation des partitions afin que votre utilisateur sache où rechercher et trouver un log spécifique. De cette façon, vos alertes, votre dashboard et vos vues enregistrées n'ont pas besoin d'être modifiés si vous implémentez des partitions plus tard dans votre parcours de log.
Créez des partitions de données qui correspondent aux catégories de votre environnement ou de votre organisation qui sont statiques ou qui changent rarement (par exemple, par unité commerciale, équipe, environnement, service, etc.).
Créez des partitions pour optimiser le nombre d'événements qui doivent être analysés pour votre requête la plus courante. Si vous avez un volume d'ingestion élevé, vous aurez plus d'événements dans des fenêtres de temps plus courtes, ce qui entraînera des recherches sur des périodes plus longues qui prendront plus de temps et risqueront d'expirer. Il n'y a pas de règle absolue, mais en général, un événement de log « tel que scanné » obtient plus de 500 millions (en particulier plus d'un milliard). Pour les requêtes courantes, vous souhaiterez peut-être envisager d'ajuster votre partitionnement.
Même si votre volume d'ingestion est faible, vous pouvez également utiliser des partitions de données pour une séparation logique des données ou simplement pour améliorer les performances des requêtes sur des types de données distincts.
Pour rechercher des partitions de données dans l'interface utilisateur Logs , vous devez sélectionner la ou les partitions appropriées, ouvrir le sélecteur de partition et cocher les partitions que vous souhaitez rechercher. Si vous utilisez NRQL, utilisez la clause
FROM
pour spécifier leLog
ouLog_<partion>
à rechercher. Par exemple:FROM Log_<my_partition_name> SELECT * SINCE 1 hour agoOu pour rechercher un log sur plusieurs partitions :
FROM Log, Log_<my_partition_name> SELECT * SINCE 1 hour ago
Analyser le log
Analyser votre log lors de l'ingestion est le meilleur moyen de rendre vos données log plus utilisables par vous et les autres utilisateurs de votre organisation. Lorsque vous analysez un attribut, vous pouvez facilement l'utiliser pour effectuer une recherche dans l'interface utilisateur Logs et dans NRQL sans avoir à analyser les données au moment de la requête. Cela vous permet également de les utiliser facilement dans et le dashboard.
Pour analyser le log, nous vous recommandons de :
Analysez votre log lors de l'ingestion pour créer
attributes
(ou des champs), que vous pouvez utiliser lors de la recherche ou de la création et d'alertes. L'attribut peut être des chaînes de données ou des valeurs numériques.Utilisez l’attribut
logtype
que vous avez ajouté à votre log lors de l’ingestion, ainsi que d’autres clauses NRQLWHERE
pour faire correspondre les données que vous souhaitez analyser. Écrivez des règles de correspondance spécifiques pour filtrer le log aussi précisément que possible. Par exemple:WHERE logtype='mylog' AND message LIKE '%error%'Utilisez nos règles d’analyse intégrées et l’attribut
logtype
associé chaque fois que possible. Si les règles intégrées ne fonctionnent pas pour vos données, utilisez un nom d'attributlogtype
différent (c'est-à-direapache_logs
contreapache
,iis_w3c_custom
contreiis_w3c
), puis créez une nouvelle règle d'analyse dans l'interface utilisateur à l'aide d'une version modifiée des règles intégrées afin qu'elle fonctionne pour votre format de données log .Utilisez notre interface utilisateur Parsing pour tester et valider vos règles Grok. En utilisant l'option
Paste log
, vous pouvez coller l'un de vos messages de log pour tester votre expression Grok avant de créer et d'enregistrer une règle d'analyse permanente.Utilisez la configuration externe FluentBit pour analyser le log multiligne et pour d'autres pré-analyses plus approfondies avant l'ingestion dans New Relic. Pour plus de détails et la configuration de l'analyse multiligne avec notre agent d'infrastructure, consultez cet article de blog.
Créez des modèles Grok optimisés pour correspondre au log filtré afin d'extraire l'attribut. Évitez d'utiliser de manière excessive des modèles Grok coûteux comme GREEDYDATA. Si vous avez besoin d’aide pour identifier des règles d’analyse sous-optimales, contactez votre représentant de compte New Relic.
GROK bonnes pratiques
- Utilisez les types Grok pour spécifier le type de valeur d'attribut à extraire. Si elles sont omises, les valeurs sont extraites sous forme de chaînes. Ceci est particulièrement important pour les valeurs numériques si vous souhaitez pouvoir utiliser les fonctions NRQL (c'est-à-dire
monthOf()
,max()
,avg()
,>
,<
, etc.) sur ces attributs. - Utilisez l'interface utilisateur Parsing pour tester vos modèles Grok. Vous pouvez coller un exemple de log dans l'interface utilisateur Parsing pour valider vos modèles Grok ou Regex et s'ils extraient l'attribut comme prévu.
- Ajoutez des ancres à la logique d'analyse (par exemple,
^
) pour indiquer le début d'une ligne ou$
à la fin d'une ligne. - Utilisez
()?
autour d'un modèle pour identifier les champs facultatifs - Évitez d'utiliser à outrance des modèles Grok coûteux comme
'%{GREEDYDATA}
. Essayez de toujours utiliser un modèle Grok et un type Grok valides lors de l'extraction d'un attribut.
Règles de filtrage des abandons
Supprimer le log lors de l'ingestion
- Créez des règles de filtrage pour supprimer les logs qui ne sont pas utiles ou qui ne sont pas nécessaires pour satisfaire les cas d'utilisation du dashboard, des alertes ou du dépannage.
Supprimer l'attribut de votre log lors de l'ingestion
- Créez des règles de suppression pour supprimer les attributs inutilisés de votre log.
- Supprimez l’attribut
message
après l’analyse. Si vous analysez l'attribut de message pour créer un nouvel attribut à partir des données, supprimez le champ de message. - Exemple : si vous transférez des données depuis infrastructure AWS, vous pouvez créer des règles de suppression pour supprimer tout attribut AWS susceptible de créer un gonflement indésirable des données.
Dimensionnement des logs New Relic
Notre façon de facturer le stockage peut différer de celle de certains de nos concurrents. La manière dont nous mesurons les données log est similaire à la manière dont nous mesurons et facturons d'autres types de données, qui sont définies dans Calcul d'utilisation.
Si nos cloud d'intégration (AWS, Azure, GCP) sont installés, nous ajouterons des métadonnées cloud à chaque enregistrement log , ce qui augmentera la facture d'ingestion globale. Ces données peuvent cependant être supprimées pour réduire l'ingestion.
Les principaux facteurs de surcharge des données log sont les suivants, par ordre d'impact :
- Intégration dans le cloud
- Formatage JSON
- modèles de log (vous pouvez désactiver/activer les modèles dans l'interface utilisateur Logs .)
Logs de recherche
Pour les recherches log courantes, créez et utilisez Saved views dans l'interface utilisateur. Créez une recherche pour vos données et cliquez sur + Add Column pour ajouter un attribut supplémentaire à la table de l'interface utilisateur. Vous pouvez ensuite déplacer les colonnes afin qu'elles apparaissent dans l'ordre souhaité, puis les enregistrer en tant que vue enregistrée avec des autorisations privées ou publiques. Configurez les vues enregistrées pour qu'elles soient publiques afin que vous et d'autres utilisateurs puissiez facilement exécuter des recherches courantes avec toutes les données d'attribut pertinentes affichées. Il s'agit d'une bonne pratique pour les applications tierces comme Apache, nginx, etc. afin que l'utilisateur puisse facilement voir ces logs sans effectuer de recherche.
Utilisez le générateur de requêtes pour exécuter des recherches à l'aide de NRQL. Le générateur de requêtes vous permet d'utiliser toutes les fonctions avancées disponibles dans NRQL.
Créez ou utilisez le dashboardquickstart disponible pour répondre aux questions courantes sur votre log et pour examiner les données de votre log au fil du temps dans des graphiques de séries chronologiques. Créez un dashboard avec plusieurs panneaux pour découper et analyser vos données log de différentes manières.
Utilisez nos fonctions NRQL avancées telles que capture() ou aparse() pour analyser les données au moment de la recherche.
Installez le dashboard Logs analysis et/ou APM logs monitoring quickstart pour obtenir rapidement des informations plus détaillées sur vos données log . Pour ajouter ces dashboards, accédez à one.newrelic.com > Integrations & Agents > Logging > Dashboards.
Quelle est la prochaine étape ?
Voir Démarrer avec .