Index

Docs > Log Management > Configuration des logs > Index

Les index de logs offrent un contrôle précis sur le coût de votre gestion de logs. Ils vous permettent de répartir vos données en plusieurs groupes de valeurs, afin d’appliquer différents critères de rétention, de quotas, de surveillance de l’utilisation ou de facturation. Les index se trouvent sur la page Configuration, dans la section Indexes. Cliquez deux fois sur les index ou sur le bouton edit pour découvrir le nombre de logs indexés au cours des trois derniers jours, ainsi que la période de rétention de ces logs :

Vous pouvez utiliser des logs indexés pour la recherche à facettes, les patterns, les analyses, la création de dashboards et la surveillance.

Utilisation de plusieurs index

Par défaut, chaque compte possède un seul index représentant un ensemble monolithique composé de tous vos logs. Datadog propose également plusieurs index selon vos besoins, disposant des fonctionnalités suivantes :

Plusieurs périodes de rétention
Plusieurs quotas journaliers, pour un meilleur contrôle de votre budget

Le Log Explorer prend en charge l’envoi de requêtes sur plusieurs index.

Contactez l'assistance Datadog pour activer l'utilisation de plusieurs index pour votre compte.

Ajouter des index

Si l’utilisation de plusieurs index est activée, utilisez le bouton « New Index » pour créer un index.

Remarque : les noms d’index doivent commencer par une lettre et ne peuvent contenir que des lettres minuscules, des nombres ou le caractère ‘-’.

Filtres d’index

Grâce aux filtres d’index, vous pouvez choisir de façon dynamique à quels index sont transmis les logs de votre choix. Par exemple, si vous créez un premier index filtré sur l’attribut status:notice, un deuxième index filtré sur l’attribut status:error et un dernier index sans filtre (équivalent à *), tous vos logs status:notice sont envoyés au premier index, tous vos logs status:error vont dans le deuxième index et tous les autres logs sont rassemblés dans le dernier index.

Remarque : les logs sont envoyés dans le premier index filtré auquel ils correspondent. Faites glisser et déposez les index dans la liste pour modifier leur ordre, selon vos besoins.

Filtres d’exclusion

Par défaut, les index de logs ne possèdent pas de filtre d’exclusion. Ainsi, tous les logs correspondant à leur filtre sont indexés.

Toutefois, puisque vos logs ne sont pas tous utiles, les filtres d’exclusion contrôlent leur transmission dans l’index afin d’identifier les logs à supprimer. Les logs exclus sont supprimés des index, mais continuent à être analysés par la fonctionnalité de live tailing et peuvent être utilisés pour générer des métriques et être archivés.

Les filtres d’exclusion sont définis par une requête, une règle d’échantillonnage et un bouton d’activation :

La query (requête) par défaut est *. Celle-ci entraîne l’exclusion de tous les logs transmis dans l’index. Réduisez le filtre d’exclusion en définissant uniquement un sous-ensemble de logs avec une requête de log.
La sampling rule (règle d’échantillonnage) par défaut Exclude 100% of logs exclut tous les logs correspondant à la requête. Définissez un taux d’échantillonnage entre 0 et 100 %, et choisissez de l’appliquer à chaque log ou à des groupes de logs caractérisés par les valeurs uniques d’un attribut.
Par défaut, le filtre est activé. Les logs sont donc supprimés de l’index selon les paramètres du filtre. Cliquez sur le bouton pour désactiver le filtre afin de l’ignorer pour les nouveaux logs transmis.

Remarque : les filtres d’index pour les logs sont uniquement traités avec le premier filtre d’exclusion actif correspondant. Si un log correspond à un filtre d’exclusion (même si le log n’est pas transmis en raison d’un échantillonnage), il ignore tous les filtres d’exclusion suivants.

Faites glisser et déposez les filtres d’exclusion dans la liste pour modifier leur ordre, selon vos besoins.

Scénarios

Désactivation et activation d’un filtre

Imaginons que vous souhaitez uniquement utiliser vos logs DEBUG lorsque votre plate-forme souffre d’une défaillance, ou que vous cherchez à surveiller le déploiement d’une version critique de votre application. Configurez un filtre d’exclusion à 100 % sur status:DEBUG, et activez-le ou désactivez-le à partir de l’interface Datadog ou via l’API dès que vous en avez besoin.

Suivi des tendances

Imaginons que vous n’avez pas besoin de conserver tous les logs liés aux requêtes serveur d’accès Web. Vous pouvez choisir d’indexer tous les logs 3xx, 4xx et 5xx, mais d’exclure 95 % des logs 2xx avec source:nginx AND http.status_code:[200 TO 299] pour surveiller les tendances. Astuce : transformez vos logs d’accès Web en KPI utiles en générant une métrique à partir de vos logs. Celle-ci vous permettra par exemple de compter le nombre de requêtes et de les taguer par code de statut, navigateur et pays.

Échantillonnage cohérent avec des entités de plus haut niveau

Des millions d’utilisateurs se connectent à votre site Web chaque jour. Bien que vous n’ayez pas besoin de connaître parfaitement tous vos utilisateurs, il peut être utile de comprendre les caractéristiques de certains d’entre eux. Définissez un filtre d’exclusion qui s’applique à tous les logs de production (env:production) et excluez les logs pour 90 % de @user.email :

Vous pouvez utiliser l’APM avec les logs grâce à l’injection d’ID de trace dans les logs. Vous n’avez pas besoin de garder tous vos logs sur les utilisateurs. Cependant, veillez à ce que les logs que vous conservez représentent tous les aspects d’une trace. Une telle pratique simplifiera grandement votre correction des problèmes. Configurez un filtre d’exclusion appliqué aux logs à partir de votre service instrumenté (service:mon_app_python) et excluez les logs pour 50 % des Trace ID. Assurez-vous d’utiliser le remappeur d’ID de trace en amont dans vos pipelines.

Pour garantir un échantillonnage homogène parmi plusieurs index :

Créez une règle d’exclusion dans chaque index.
Utilisez le même taux d’échantillonnage et le même attribut pour définir l’entité de niveau supérieur de toutes les règles d’exclusion.
Vérifiez bien les règles d’exclusion, les filtres et l’ordre respectif (seule la première règle d’exclusion correspondante est appliquée aux logs).

Dans les exemples suivants :

En général, tous les logs avec un request_id spécifique sont soit conservés soit exclus (probabilité de 50 %).
Les logs dotés d’un tag threat:true ou compliance:true sont tous conservés, quel que soit leur request_id.
Les logs DEBUG sont indexés selon la règle d’échantillonnage request_id, sauf si le filtre d’exclusion des logs de debugging est activé. Dans ce cas, les logs sont échantillonnés.
50 % des logs d’accès Web 2XX dotés d’un request_id sont conservés. Tous les autres logs d’accès Web 2XX sont échantillonnés selon la règle du filtre d’exclusion à 90 %.

Mettre à jour la rétention des logs

Le paramètre de rétention des index spécifie la durée pendant laquelle les logs sont stockés et interrogeables dans Datadog. Vous pouvez choisir la durée de rétention de votre choix dans la configuration de votre compte. Pour ajouter des rétentions qui ne font actuellement pas partie de votre contrat, contactez l’assistance Datadog.

Définir un quota journalier

Il est possible de définir un quota journalier pour limiter le nombre de logs stockés dans un index au cours d’une journée. Ce quota est appliqué à l’ensemble des logs qui auraient dû être stockés (c’est-à-dire une fois les filtres d’exclusion appliqués). Une fois ce quota atteint, les logs ne sont plus indexés. Ils restent toutefois disponibles pour le live tailing et continuent à être envoyés vers vos archives et utilisés pour générer des métriques.

Ce quota peut être modifié ou supprimé à tout moment en modifiant l’index :