• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Guide des bonnes pratiques en matière d'exploitation forestière

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 :

  • 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'attribut logtype 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: mylog
    file: /var/log/mylog.log
    attributes:
    logtype: mylog
  • Utilisez l'intégration New Relic pour transférer le log d'autres types de données courants tels que :

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 le Log ou Log_<partion> à rechercher. Par exemple:

    FROM Log_<my_partition_name> SELECT * SINCE 1 hour ago

    Ou 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 NRQL WHERE 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'attribut logtype différent (c'est-à-dire apache_logs contre apache, iis_w3c_custom contre iis_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.

    Parsing example in the UI
  • 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 :

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 .

Droits d'auteur © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.