Utiliser des métriques basées sur les journaux

Cette page présente les principes de base de l'émission de journaux pour créer des SLI de disponibilité et de latence. Elle fournit également des exemples d'implémentation pour définir des SLO à l'aide de métriques basées sur les journaux.

L'utilisation d'éléments de données dans les entrées de journal pour créer des indicateurs de niveau de service est un moyen d'exploiter des charges utiles de journaux existantes. Dans le cas contraire, il peut être possible d'ajouter la journalisation à un service existant, ce qui peut s'avérer plus simple que la création d'instrumentation de métriques.

Journaux et métriques

Les journaux collectent des enregistrements appelés entrées de journal décrivant des événements spécifiques exécutés dans les systèmes informatiques. Les journaux sont écrits par le code, par les services de plate-forme sur lesquels le code s'exécute (par exemple, Dataflow), et par l'infrastructure dont dépend la plate-forme (par exemple, les instances Compute Engine).

Étant donné que les journaux des systèmes modernes proviennent (et ils le sont encore parfois) de fichiers texte écrits sur le disque, une entrée de journal est analogue à une ligne d'un fichier journal et peut être considérée comme l'unité quantitative de la journalisation.

Une entrée de journal se compose au minimum de deux éléments :

Horodatage indiquant le moment auquel l'événement s'est produit ou son ingestion dans le système de journalisation
Charge utile du texte, sous forme de données textuelles non structurées ou de données structurées, le plus souvent au format JSON.

Les journaux peuvent également stocker des métadonnées associées, en particulier lorsqu'ils sont ingérés dans Cloud Logging. Ces métadonnées peuvent inclure la ressource qui écrit le journal, le nom du journal et un niveau de gravité pour chaque entrée.

Journaux

Les journaux sont utilisés à deux fins principales:

Les journaux d'événements décrivent des événements spécifiques qui ont lieu dans le système. Vous pouvez utiliser des journaux d'événements pour générer des messages qui garantissent aux utilisateurs que tout fonctionne correctement ("tâche réussie"), ou pour fournir des informations en cas d'échec ("exception reçue du serveur").
Les journaux Transaction décrivent les détails de chaque transaction traitée par un système ou un composant. Par exemple, un équilibreur de charge enregistre chaque requête reçue, que la requête se termine ou non, et enregistre des informations supplémentaires telles que l'URL demandée, le code de réponse HTTP et éventuellement des informations telles que le backend. qui a servi à traiter la requête.

Métriques

Contrairement aux journaux, les métriques ne décrivent généralement pas des événements spécifiques. Plus généralement, les métriques sont utilisées pour représenter l'état d'un système au fil du temps. Une métrique est composée d'une série de points de données mesurant une information sur votre système. Chaque point de données inclut un horodatage et une valeur numérique.

Les métriques peuvent également être associées à des métadonnées. La série de points de données, appelée série temporelle, peut inclure des informations telles que le nom de la métrique, une description et souvent des libellés spécifiant la ressource qui écrit les données. Pour en savoir plus sur le modèle de métrique Monitoring, consultez la page Métriques, séries temporelles et ressources.

Métriques basées sur les journaux

Les métriques basées sur les journaux sont des métriques créées à partir des entrées de journal en extrayant des informations des entrées de journal et en les transformant en données de séries temporelles. Cloud Logging fournit des mécanismes pour créer deux types de métriques à partir d'entrées de journal:

Les métriques de compteur, qui comptabilisent le nombre d'entrées de journal correspondant à un filtre particulier. Vous pouvez utiliser une métrique de compteur pour déterminer, par exemple, le nombre de requêtes ou d'erreurs enregistrées dans le journal.
Les métriques de distribution, qui utilisent des expressions régulières pour analyser la charge utile dans chaque entrée de journal afin d'extraire les valeurs numériques en tant que distribution.

Pour plus d'informations sur les métriques basées sur les journaux dans Cloud Logging, consultez la page Utiliser des métriques basées sur les journaux.

Utiliser des métriques basées sur les journaux en tant que SLI

Les métriques basées sur les journaux vous permettent d'extraire les données des journaux sous une forme que vous pouvez utiliser pour créer des SLI dans Monitoring:

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes à l'aide de métriques de compteur basées sur les journaux.
Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une métrique de distribution basée sur les journaux.

Exemples d'entrées de journal

L'application Stack Doctor est un exemple d'un service mis en œuvre pour émettre des messages de journal contenant des informations sur toutes les requêtes, erreurs et latence adressées au service. Le code du service est disponible dans le dépôt GitHub stack-doctor.

Le service génère des entrées du journal Cloud Logging dans le journal projects/stack-doctor/logs/bunyan_log. L'entrée de journal pour chaque type d'événement inclut une valeur message différente. Les entrées de journal pour différents types d'événements se présentent comme suit:

À chaque requête:

{
  "insertId": "..........iTRVT5MOK2VOsVe31bzrTD",
  "jsonPayload": {
    "pid": 81846,
    "time": "Mon Aug 31 2020 20:30:49 GMT-0700 (Pacific Daylight Time)",
    "hostname": "<hostname>",
    "level": 30,
    "message": "request made",
    "v": 0,
    "name": "sli-log"
  },
    "resource": {
    "type": "global",
    "labels": {
      "project_id": "stack-doctor"
    }
  },
  "timestamp": "2020-09-01T03:30:49.263999938Z",
  "severity": "INFO",
  "logName": "projects/stack-doctor/logs/bunyan_log",
  "receiveTimestamp": "2020-09-01T03:30:50.003471183Z"
}

En cas de requêtes réussies:

{
  "insertId": "..........qTRVT5MOK2VOsVe31bzrTD",
  "jsonPayload": {
    "name": "sli-log",
    "v": 0,
    "pid": 81846,
    "level": 30,
    "hostname": "<hostname>",
    "time": "Mon Aug 31 2020 20:30:49 GMT-0700 (Pacific Daylight Time)",
    "message": "success!"
  },
  "resource": {
    "type": "global",
    "labels": {
      "project_id": "stack-doctor"
    }
  },
  "timestamp": "2020-09-01T03:30:49.874000072Z",
  "severity": "INFO",
  "logName": "projects/stack-doctor/logs/bunyan_log",
  "receiveTimestamp": "2020-09-01T03:30:50.201547371Z"
}

Lors des requêtes terminées:

{
  "insertId": "..........mTRVT5MOK2VOsVe31bzrTD",
  "jsonPayload": {
    "time": "Mon Aug 31 2020 20:30:49 GMT-0700 (Pacific Daylight Time)",
    "level": 30,
    "name": "sli-log",
    "message": "slept for 606 ms",
    "hostname": "<hostname>",
    "pid": 81846,
    "v": 0
  },
  "resource": {
    "type": "global",
    "labels": {
      "project_id": "stack-doctor"
    }
  },
  "timestamp": "2020-09-01T03:30:49.874000072Z",
  "severity": "INFO",
  "logName": "projects/stack-doctor/logs/bunyan_log",
  "receiveTimestamp": "2020-09-01T03:30:50.201547371Z"
}

Pour les erreurs :

{
  "insertId": "..........DTRVT5MOK2VOsVe31bzrTD",
  "jsonPayload": {
    "hostname": "<hostname>",
    "level": 50,
    "pid": 81846,
    "message": "failure!",
    "name": "sli-log",
    "time": "Mon Aug 31 2020 20:30:44 GMT-0700 (Pacific Daylight Time)",
    "v": 0
  },
  "resource": {
    "type": "global",
    "labels": {
      "project_id": "stack-doctor"
    }
  },
  "timestamp": "2020-09-01T03:30:44.414999961Z",
  "severity": "ERROR",
  "logName": "projects/stack-doctor/logs/bunyan_log",
  "receiveTimestamp": "2020-09-01T03:30:46.182157077Z"
}

À partir de ces entrées, vous pouvez créer des métriques basées sur les journaux, qui comptent toutes les requêtes, comptent les erreurs et suivent la latence des requêtes. Vous pouvez ensuite utiliser les métriques basées sur les journaux pour créer des SLI de disponibilité et de latence.

Créer des métriques basées sur les journaux pour les SLI.

Avant de pouvoir créer des SLI sur des métriques basées sur les journaux, vous devez créer les métriques basées sur les journaux.

Pour les SLI de disponibilité sur le nombre de requêtes et d'erreurs, utilisez des métriques de compteur basées sur les journaux.
Pour les SLI de latence, utilisez des métriques de distribution basées sur les journaux.

Une fois que vous avez créé les métriques basées sur les journaux, vous pouvez les trouver dans Monitoring en les recherchant dans l'explorateur de métriques. Dans Monitoring, les métriques basées sur les journaux portent le préfixe logging.googleapis.com/user.

Métriques pour les SLI de disponibilité

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes dans l'API Cloud Monitoring à l'aide de la structure TimeSeriesRatio pour définir un ratio de "bonnes" ou "mauvaises" requêtes par rapport au total de requêtes. Ce ratio est utilisé dans le champ goodTotalRatio d'une structure RequestBasedSli.

Vous devez créer des métriques de compteur basées sur les journaux, qui peuvent être utilisées pour créer ce ratio. Vous devez créer au moins deux des éléments suivants:

une métrique qui comptabilise le nombre total d'événements ; Utilisez cette métrique dans le totalServiceFilter du ratio.

Pour l'exemple "stack-doctor", vous pouvez créer une métrique basée sur les journaux, qui comptabilise les entrées de journal dans lesquelles la chaîne de message "requête effectuée" apparaît.
Métrique qui compte les événements "bad", utilisez cette métrique dans le badServiceFilter du ratio.

Pour l'exemple "stack-doctor", vous pouvez créer une métrique basée sur les journaux, qui comptabilise les entrées de journal dans lesquelles la chaîne de message "failure!" (échec !) s'affiche.
Métrique qui comptabilise les événements "satisfaisants", utilisez cette métrique dans le goodServiceFilter du ratio.

Pour l'exemple "stack-doctor", vous pouvez créer une métrique basée sur les journaux, qui comptabilise les entrées de journal dans lesquelles la chaîne de message "success!" s'affiche.

Le SLI décrit pour cet exemple repose sur une métrique pour le nombre total de requêtes nommées log_based_total_requests, et sur une métrique pour les erreurs nommées log_based_errors.

Vous pouvez créer des métriques basées sur les journaux à l'aide de Google Cloud Console, de l'API Cloud Logging ou de Google Cloud CLI. Pour créer des métriques de compteur basées sur les journaux à l'aide de la console Google Cloud, vous pouvez suivre la procédure suivante :

Dans la console Google Cloud, accédez à la page Métriques basées sur les journaux.
Accéder à la page Métriques basées sur les journaux

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

La page des métriques basées sur les journaux affiche un tableau de métriques définies par l'utilisateur et un tableau de métriques définies par le système.
Cliquez sur Créer une métrique, au-dessus du tableau des métriques définies par l'utilisateur.
Dans le volet Type de métrique, sélectionnez Compteur.
Dans le volet Détails, attribuez un nom à la nouvelle métrique. Pour l'exemple "stack-doctor", saisissez log_based_total_requests ou log_based_errors.

Vous pouvez ignorer les autres champs de cet exemple.
Dans le panneau Filtrer la sélection, créez une requête qui ne récupère que les entrées de journal que vous souhaitez comptabiliser dans votre métrique.

Pour l'exemple "stack-doctor", la requête pour log_based_total_requests peut inclure les éléments suivants:
```
resource.type="global"
logName="projects/stack-doctor/logs/bunyan_log"
jsonPayload.message="request made"
```
La requête pour logs_based_errors modifie la chaîne de message:
```
resource.type="global"
logName="projects/stack-doctor/logs/bunyan_log"
jsonPayload.message="failure!"
```
Cliquez sur Aperçu des journaux pour vérifier votre filtre et ajustez-le si nécessaire.
Ignorez le volet Labels (Libellés) pour cet exemple.
Cliquez sur Créer une métrique pour terminer la procédure.

Pour plus d'informations sur la création de métriques de compteur basées sur les journaux, consultez la page Créer une métrique de compteur.

Métriques pour les SLI de latence

Vous pouvez exprimer un SLI de latence basé sur les requêtes dans l'API Cloud Monitoring à l'aide d'une structure DistributionCut, utilisée dans le champ distributionCut d'une structure RequestBasedSli. Vous devez créer une métrique de distribution basée sur les journaux pour créer un SLI de latence. Cet exemple crée une métrique de distribution basée sur les journaux, nommée log_based_latency..

Vous pouvez créer des métriques basées sur les journaux à l'aide de Google Cloud Console, de l'API Cloud Logging ou de Google Cloud CLI. Pour créer des métriques de distribution basées sur les journaux à l'aide de la console Google Cloud, vous pouvez suivre la procédure suivante :

Dans la console Google Cloud, accédez à la page Métriques basées sur les journaux.
Accéder à la page Métriques basées sur les journaux

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

La page des métriques basées sur les journaux affiche un tableau de métriques définies par l'utilisateur et un tableau de métriques définies par le système.
Cliquez sur Créer une métrique, au-dessus du tableau des métriques définies par l'utilisateur.
Dans le volet Type de métrique, sélectionnez Distribution.
Dans le volet Détails, attribuez un nom à la nouvelle métrique. Pour l'exemple "stack-doctor", saisissez log_based_latency.

Vous pouvez ignorer les autres champs de cet exemple.
Dans le panneau Filtrer la sélection, créez une requête qui ne récupère que les entrées de journal que vous souhaitez comptabiliser dans votre métrique.

Pour l'exemple "stack-doctor", la requête pour log_based_latency peut inclure les éléments suivants:
```
resource.type="global"
logName="projects/stack-doctor/logs/bunyan_log"
jsonPayload.message="slept for"
```
Spécifiez les champs suivants pour la requête de filtre:
- Nom du champ : json.message
- Expression régulière : \s(\d*)\s
  
  La chaîne de messages des requêtes terminées se présente sous la forme "slept" (a dormi) pendant n ms". L'expression régulière extrait la valeur de latence n de la chaîne.
Ignorez le volet Labels (Libellés) pour cet exemple.
Cliquez sur Créer une métrique pour terminer la procédure.

Pour plus d'informations sur la création de métriques de distribution basées sur les journaux, consultez la page Créer des métriques de distribution.

SLI de disponibilité

Dans Cloud Monitoring, vous exprimez un SLI de disponibilité basé sur les requêtes à l'aide d'une structure TimeSeriesRatio. L'exemple suivant montre un SLO qui utilise les métriques log_based_total_requests et log_based_errors dans le ratio. Ce SLO s'attend à ce que le taux de "bonnes" requêtes par rapport aux requêtes totales est d'au moins 98% sur une période glissante de 24 heures:

{
 "serviceLevelIndicator": {
   "requestBased": {
     "goodTotalRatio": {
       "totalServiceFilter":
         "metric.type=\"logging.googleapis.com/user/log_based_total_requests\"
          resource.type=\"global\"",
       "badServiceFilter":
         "metric.type=\"logging.googleapis.com/user/log_based_errors\"
          resource.type=\"global\""
     }
   }
 },
 "goal": 0.98,
 "rollingPeriod": "86400s",
 "displayName": "Log-Based Availability"
}

SLI de latence

Dans Cloud Monitoring, vous exprimez un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut. L'exemple suivant montre un SLO qui utilise la métrique log_based_latency et s'attend à ce que 98% des requêtes aboutissent à moins de 500 ms sur une période glissante de 24 heures:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"logging.googleapis.com/user/log_based_latency\"
          resource.type=\"global\"",
        "range": {
          "min": 0,
          "max": 500
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "86400s",
  "displayName": "98% requests under 500 ms"
}