Afficher les journaux dans les destinations de récepteurs

Ce document explique comment rechercher les entrées de journal que vous avez acheminées de Cloud Logging vers des destinations compatibles:

Destination Fréquence de routage
Buckets Cloud Storage Lots horaires
Tables BigQuery Presque en temps réel
Sujets Pub/Sub Presque en temps réel
Buckets Cloud Logging Presque en temps réel
Splunk Quasi-temps réel

Pour une présentation conceptuelle des récepteurs, consultez la page Présentation du routage et du stockage: récepteurs.

Pour savoir comment acheminer vos journaux, consultez la page Configurer des récepteurs.

Cloud Storage

Pour afficher vos journaux acheminés dans Cloud Storage, procédez comme suit:

  1. Accédez au navigateur Cloud Storage dans Cloud Console :

    Accéder au navigateur Cloud Storage

  2. Sélectionnez le bucket Cloud Storage que vous utilisez comme destination de routage.

Pour en savoir plus sur l'organisation des journaux dans le bucket Cloud Storage, consultez la section Organisation Cloud Storage de ce document.

Fréquence de routage

Les entrées de journal sont enregistrées toutes les heures et sous forme de lots dans des buckets Cloud Storage. L'affichage des premières entrées peut prendre 2 à 3 heures.

Organisation des journaux

Lorsque vous routez des journaux vers un bucket Cloud Storage, Logging écrit un ensemble de fichiers dans le bucket.

Les fichiers sont organisés en hiérarchies de répertoires classées par type de journal et par date. Type de journal, appelé[LOG_ID] dans la sectionLogEntry qui peut être un nom simple, tel quesyslog ou un nom de type composéappengine.googleapis.com/request_log (Installation de Python groupée). Si ces journaux sont stockés dans un bucket nommé my-gcs-bucket, les répertoires sont alors nommés comme dans l'exemple suivant:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

Un bucket Cloud Storage peut contenir des journaux provenant de plusieurs types de ressources. La taille d'un fichier est d'environ 3,5 Gio.

Logging ne garantit pas la déduplication des entrées de journal pour les récepteurs contenant des requêtes identiques ou qui se chevauchent. Les entrées de journal de ces récepteurs peuvent être écrites plusieurs fois dans un bucket Cloud Storage.

Les répertoires feuilles (DD/) contiennent plusieurs fichiers, chacun contenant les entrées du journal acheminé pendant une période spécifiée dans le nom du fichier. Les fichiers sont partitionnés et leur nom se termine par un numéro de partition, Sn ou An (n = 0, 1, 2, etc.). Par exemple, voici deux fichiers qui pourraient être stockés dans le répertoire my-gcs-bucket/syslog/2015/01/13/ :

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

Ces deux fichiers contiennent les entrées de journal syslog pour toutes les instances comprises entre 8h00:00 UTC et 08:59:59 UTC. Les horodatages d'entrée de journal sont exprimés en temps universel coordonné (UTC).

Les entrées de journal qui arrivent avec une receiveTimestamp dans la fenêtre alignée de 60 minutes de leur timestamp sont écrites dans les fichiers de la partition principale. Par exemple, une entrée de journal ayant une valeur timestamp de 08:00:00 et une valeur receiveTimestamp de 08:10:00 est stockée dans le fichier segment principal.

Ces fichiers incluent une partition principale numérotée dans le suffixe : _Sn.json.

Les entrées de journal qui arrivent avec une timestamp dans une fenêtre alignée de 60 minutes différente de leur receiveTimestamp sont écrites dans les fichiers de segments d'addendum. Par exemple, une entrée de journal ayant une valeur timestamp de 08:00:00 et une valeur receiveTimestamp de 09:10:00 est stockée dans un fichier de partition de l'avenant.

Ces fichiers incluent une partition d'ajout numérotée avec le suffixe: _An.json:Unix_timestamp.

Par exemple, une entrée de journal dont le champ timestamp est compris entre 08:00:00 et 08:59:59, mais une valeur receiveTimestamp dans une fenêtre alignée de 60 minutes différente est écrit dans un fichier. par le suffixe _An.json:Unix_timestamp, où l'horodatage Unix identifie l'heure à laquelle le fichier a été acheminé vers Cloud Storage. Si une entrée de journal a un timestamp défini sur 08:50:00 et un receiveTimestamp 09:10:00, et qu'elle est acheminée le 25 mars 2021 à 09:15:00. le fichier d'ajout sera écrit comme suit:

08:00:00_08:59:59_A0.json:1616681700

Pour obtenir toutes les entrées de journal, vous devez consulter l'ensemble des partitions pour chaque période (dans le cas présent, les partitions de fichiers 0 et 1). Le nombre de partitions de fichiers écrites peut varier pour chaque période en fonction du volume d'entrées de journal.

Dans les fichiers partitionnés individuels, les entrées de journal sont stockées sous la forme d'une liste d'objets LogEntry. Pour obtenir un exemple d'entrée syslog, consultez la section Type LogEntry de ce document.

Notez que l'ordre de tri des entrées de journal dans les fichiers n'est ni uniforme, ni garanti.

Filtres

Pour obtenir des exemples de filtres de routage des journaux vers Cloud Storage, consultez la page Exemples de requêtes.

BigQuery

Pour afficher vos journaux routés dans BigQuery, procédez comme suit:

  1. Accédez à la page BigQuery dans Cloud Console:

    Accéder à BigQuery

  2. Sélectionnez l'ensemble de données servant de destination à votre récepteur.

  3. Sélectionnez une table de l'ensemble de données. Les entrées de journal sont visibles dans l'onglet Détails. Vous pouvez également interroger la table pour qu'elle renvoie vos données.

Pour en savoir plus sur l'organisation des tables et sur l'exportation des journaux et le schéma BigQuery, consultez la section Organisation des tables pour en savoir plus sur la manière dont les journaux acheminés sont consignés. sont renseignés.

Fréquence de routage

Lorsqu'une table est créée lorsque Logging achemine les entrées de journal vers BigQuery, plusieurs minutes peuvent s'écouler avant que les premières entrées ne s'affichent dans la nouvelle table. Les entrées de journal suivantes apparaissent généralement dans la minute qui suit.

Organisation des tables

Lorsque vous routez des journaux vers un ensemble de données BigQuery, Logging crée des tables datées pour contenir les entrées de journal acheminées. Le nom de ces tables est basé sur le nom des entrées de journal et sur leur horodatage1. Le tableau suivant vous explique la façon dont les noms des journaux et les horodatages sont mappés au nom des tables :

Nom du journal Horodatage d'entrée de journal1 Nom de la table BigQuery
syslog 2017-05-23T18:19:22.135Z syslog_20170523
apache-access 2017-01-01T00:00:00.000Z apache_access_20170101
compute.googleapis.com/activity_log 2017-12-31T23:59:59.999Z compute_googleapis_com_activity_log_20171231

1 Les horodatages d'entrée de journal utilisent l'heure UTC (temps universel coordonné).

Schémas et champs

Les schémas de table BigQuery pour les journaux acheminés sont basés sur la structure du type LogEntry et sur le contenu des charges utiles des journaux. Vous pouvez afficher le schéma d'une table en sélectionnant une table comportant des entrées de journal acheminées dans l'UI Web de BigQuery.

Le schéma de table BigQuery utilisé pour représenter les charges utiles d'entrées de journal complexes peut prêter à confusion et, dans le cas des journaux d'audit acheminés, des règles de dénomination spéciales sont utilisées. Pour en savoir plus, consultez la page Schéma BigQuery des journaux exportés.

Requêtes

Pour obtenir des exemples de requêtes d'acheminement de journaux vers BigQuery, consultez la page Exemples de requêtes.

Pour en savoir plus sur la syntaxe des requêtes BigQuery, consultez la documentation de référence sur les requêtes. Les fonctions de caractères génériques de table sont particulièrement utiles et offrent la possibilité d'exécuter des requêtes sur plusieurs tables. L'opérateur FLATTEN est également très pratique, car il permet d'afficher des données à partir de champs répétés.

Exemple de requête concernant les journaux Compute Engine

La requête BigQuery suivante récupère les entrées de journal de plusieurs jours et de différents types de journaux :

  • La requête recherche les trois derniers jours des journaux syslog et apache-access. Elle a été exécutée le 23 février 2015 et couvre toutes les entrées de journal reçues les 21 et 22 février, ainsi que les entrées reçues le 23 février jusqu'à la création de la requête.

  • La requête récupère les résultats d'une seule instance de Compute Engine : 1554300700000000000.

SELECT
  timestamp AS Time,
  logName as Log,
  textPayload AS Message
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.syslog_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP())),
  (TABLE_DATE_RANGE(my_bq_dataset.apache_access_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP()))
WHERE
  resource.type == 'gce_instance'
  AND resource.labels.instance_id == '1554300700000000000'
ORDER BY time;

Voici quelques exemples de lignes de sortie :

Row | Time                    | Log                                         | Message
--- | ----------------------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------
 5  | 2015-02-21 03:40:14 UTC | projects/project-id/logs/syslog             | Feb 21 03:40:14 my-gce-instance collectd[24281]: uc_update: Value too old: name = 15543007601548826368/df-tmpfs/df_complex-used; value time = 1424490014.269; last cache update = 1424490014.269;
 6  | 2015-02-21 04:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 04:17:01 my-gce-instance /USR/SBIN/CRON[8082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 7  | 2015-02-21 04:49:58 UTC | projects/project-id/logs/apache-access      | 128.61.240.66 - - [21/Feb/2015:04:49:58 +0000] "GET / HTTP/1.0" 200 536 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)"
 8  | 2015-02-21 05:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 05:17:01 my-gce-instance /USR/SBIN/CRON[9104]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 9  | 2015-02-21 05:30:50 UTC | projects/project-id/log/syslogapache-access | 92.254.50.61 - - [21/Feb/2015:05:30:50 +0000] "GET /tmUnblock.cgi HTTP/1.1" 400 541 "-" "-"

Exemple de requête concernant les journaux App Engine

La requête BigQuery suivante récupère les requêtes App Engine du mois dernier qui n'ont pas abouti :

SELECT
  timestamp AS Time,
  protoPayload.host AS Host,
  protoPayload.status AS Status,
  protoPayload.resource AS Path
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.appengine_googleapis_com_request_log_,
    DATE_ADD(CURRENT_TIMESTAMP(), -1, 'MONTH'), CURRENT_TIMESTAMP()))
WHERE
  protoPayload.status != 200
ORDER BY time

Voici une partie des résultats :

Row | Time                    | Host                                  | Status | Path
--- | ----------------------- | ------------------------------------- | ------ | ------
 6  | 2015-02-12 19:35:02 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo?thud=3
 7  | 2015-02-12 19:35:21 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo
 8  | 2015-02-16 20:17:19 UTC | my-gcp-project-id.appspot.com         |    404 | /favicon.ico
 9  | 2015-02-16 20:17:34 UTC | my-gcp-project-id.appspot.com         |    404 | /foo?thud=%22what???%22

Pub/Sub

Nous vous recommandons d'utiliser Pub/Sub pour intégrer des journaux Cloud Logging à des logiciels tiers.

Les journaux acheminés vers Pub/Sub sont généralement disponibles en quelques secondes, et 99% des journaux sont disponibles en moins de 60 secondes.

Pour afficher vos journaux acheminés via Pub/Sub, procédez comme suit:

  1. Accédez à la page Pub/Sub dans Cloud Console :

    Accéder à Pub/Sub

  2. Recherchez ou créez un abonnement associé au sujet utilisé dans le récepteur de journaux, puis extrayez une entrée de journal. Vous devrez peut-être attendre la publication d'une nouvelle entrée.

Pour en savoir plus sur l'organisation des journaux dans Pub/Sub, consultez la section Organisation des journaux de ce document.

Fréquence de routage

Lorsque vous routez les journaux vers un sujet Pub/Sub, Logging publie chaque entrée de journal en tant que message Pub/Sub dès qu'il la reçoit.

Organisation des journaux

Le champ data de chaque message correspond à un objet LogEntry encodé en base64. Un abonné Pub/Sub peut par exemple extraire l'objet suivant d'un sujet qui reçoit des entrées de journal. L'objet affiché contient une liste qui ne comprend qu'un seul message. Notez toutefois que Pub/Sub peut renvoyer plusieurs messages lorsque plusieurs entrées de journal sont disponibles. La valeur data (environ 600 caractères) et la valeur ackId (environ 200 caractères) ont été raccourcies pour rendre l'exemple plus lisible :

{
 "receivedMessages": [
  {
   "ackId": "dR1JHlAbEGEIBERNK0EPKVgUWQYyODM...QlVWBwY9HFELH3cOAjYYFlcGICIjIg",
   "message": {
    "data": "eyJtZXRhZGF0YSI6eyJzZXZ0eSI6Il...Dk0OTU2G9nIjoiaGVsbG93b3JsZC5sb2cifQ==",
    "attributes": {
     "compute.googleapis.com/resource_type": "instance",
     "compute.googleapis.com/resource_id": "123456"
    },
    "messageId": "43913662360"
   }
  }
 ]
}

Si vous décodez le champ data et le mettez en forme, vous obtenez l'objet LogEntry suivant :

{
  "log": "helloworld.log",
  "insertId": "2015-04-15|11:41:00.577447-07|10.52.166.198|-1694494956",
  "textPayload": "Wed Apr 15 20:40:51 CEST 2015 Hello, world!",
  "timestamp": "2015-04-15T18:40:56Z",
  "labels": {
    "compute.googleapis.com\/resource_type": "instance",
    "compute.googleapis.com\/resource_id": "123456"
  },
  "severity": "WARNING"
  }
}

Intégration de Pub/Sub avec des services tiers

Logging permet l'intégration de la journalisation avec des tiers tels que Splunk. Pour obtenir la liste actuelle des intégrations, consultez la page Partenaires pour connaître les intégrations de la suite Google Cloud Operations.

Vous acheminez vos journaux via un sujet Pub/Sub, et le tiers les reçoit en s'abonnant au même sujet.

Pour effectuer l'intégration, attendez-vous à effectuer une démarche semblable à la suivante :

  1. Demandez au service tiers de vous fournir un nom de compte de service Google Cloud créé à partir de son projet Google Cloud, par exemple, 12345-xyz@developer.gserviceaccount.com. Ce nom vous permet ensuite d'autoriser le service tiers à recevoir vos journaux.

  2. Dans le projet contenant les journaux,

  3. Activez l'API Pub/Sub.

    Activer l'API

  4. Créer un sujet Pub/Sub Vous pouvez effectuer cette opération lors de la configuration d'un récepteur de journaux ou en procédant comme suit :

    1. Accédez à la liste des sujets Pub/Sub.
    2. Sélectionnez Créer un sujet et saisissez un nom de sujet. Exemple : projects/my-project-id/topics/my-pubsub-topic. Vous allez acheminer vos journaux vers ce sujet.

      Chaque message envoyé au sujet inclut l'horodatage de l'entrée de journal acheminée dans le message Pub/Sub attributes. Exemple:

      "attributes": {
        "logging.googleapis.com/timestamp": "2018-10-01T00:00:00Z"
      }
      
    3. Cliquez sur Create (Créer).

    4. Autorisez Logging à acheminer les journaux vers le sujet. Pour obtenir des instructions, consultez la page Définir des autorisations pour Pub/Sub.

  5. Autorisez le service tiers à s'abonner à votre sujet :

    1. Restez dans la liste des sujets Pub/Sub de votre projet dans Cloud Console.
    2. Sélectionnez votre nouveau sujet.
    3. Sélectionnez Autorisations.
    4. Saisissez le nom du compte de service du service tiers.
    5. Dans le menu Sélectionner un rôle, sélectionnez Abonné Pub/Sub.
    6. Cliquez sur Ajouter.
  6. Fournissez au service tiers le nom de votre sujet Pub/Sub, par exemple projects/my-project-number/topics/my-pubsub-topic. Ils doivent s'abonner au sujet avant de commencer le routage.

  7. Commencez à acheminer les journaux une fois que votre tiers est abonné au sujet:

    1. Dans votre projet contenant les journaux que vous souhaitez acheminer, cliquez sur Créer une exportation au-dessus du champ de requête. Le panneau Modifier l'exportation s'affiche.
    2. Indiquez un nom de récepteur.
    3. Dans le menu Sink Service (Service du récepteur), sélectionnez Cloud Pub/Sub.
    4. Dans le menu Sink Destination (Destination du récepteur), sélectionnez le sujet Pub/Sub auquel le service tiers est abonné.
    5. Sélectionnez Créer un récepteur.
    6. Une boîte de dialogue contenant le message Récepteur créé s'affiche. Ce message indique que le récepteur a bien été créé avec les autorisations d'écriture de journaux correspondants futurs dans la destination que vous avez sélectionnée.

Le service tiers devrait commencer à recevoir immédiatement les entrées de journal.

Pour plus d'informations sur les scénarios de routage de journaux courants à l'aide de Pub/Sub, consultez la section Modèles de routage pour le routage vers Cloud Logging: scénarios d'exportation de journaux.

Cloud Logging

Les buckets de journaux sont des conteneurs de stockage Cloud Logging dans vos projets Google Cloud qui contiennent vos données de journaux. Vous pouvez créer des récepteurs de journaux pour acheminer tous vos journaux ou une partie seulement de ces derniers vers n'importe quel bucket dans Cloud Logging. Cette flexibilité vous permet de choisir le projet Cloud dans lequel vos journaux sont stockés et ceux dans lesquels ils sont stockés.

Pour obtenir des instructions sur la création, puis sur la liste des buckets de journaux associés à votre projet Cloud, consultez la page Gérer les buckets.

Organisation des entrées de journal

Les entrées de journal de journalisation sont des objets de type LogEntry.

Les entrées de journal portant le même type de journal, appelées [LOG_ID] dans la référence LogEntry, ont généralement le même format. Le tableau suivant présente des exemples d'entrées de journal:

syslog

Le syslog de Compute Engine est un type de journal personnalisé produit par l'agent de journalisation google-fluentd, qui s'exécute sur des instances de machine virtuelle:

{
  logName: "projects/my-gcp-project-id/logs/syslog",
  timestamp: "2015-01-13T19:17:01Z",
  resource: {
    type: "gce_instance",
    labels: {
      instance_id: "12345",
      zone: "us-central1-a",
      project_id: "my-gcp-project-id"
    }
  },
  insertId: "abcde12345",
  textPayload: "Jan 13 19:17:01 my-gce-instance /USR/SBIN/CRON[29980]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)"
}

request_log

Le journal request_log d'App Engine contient des entrées de journal comportant des champs protoPayload qui incluent des objets de type RequestLog :

{
  logName: "projects/my-gcp-project-id/logs/appengine.googleapis.com%2Frequest_log",
  timestamp: "2015-01-13T19:00:39.796169Z",
  resource: {
    type: "gae_app",
    labels: {
      module_id: "default",
      zone: "us6",
      project_id: "my-gcp-project-id",
      version_id: "20150925t173233"
    }
  }
  httpRequest: {
    status: 200
  }
  insertId: "abcde12345",
  operation: {
    id: "abc123",
    producer: "appengine.googleapis.com/request_id",
    first: true,
    last: true
  }
  protoPayload: {
    @type: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
    versionId: "20150925t173233",
    status: 200,
    startTime: "2017-01-13T19:00:39.796169Z",
    # ...
    appId: "s~my-gcp-project-id",
    appEngineRelease: "1.9.17",
  }
}

activity

Le journal activity est un journal d'audit pour les activités d'administration. Sa charge utile est une représentation JSON de type AuditLog :

{
 logName: "projects/my-gcp-project-id/logs/cloudaudit.googleapis.com%2Factivity"
 timestamp: "2017-04-22T13:41:32.245Z"
 severity: "NOTICE"
 resource: {
  type: "gce_instance"
  labels: {
   instance_id: "2403273232180765234"
   zone: "us-central1-b"
   project_id: "my-gcp-project-id"
  }
 }
 insertId: "54DC1882F4B49.A4996C2.6A02F4C1"
 operation: {
  id: "operation-1492868454262-54dc185e9a4f0-249fe233-f73d472a"
  producer: "compute.googleapis.com"
  last: true
 }
 protoPayload: {
  @type: "type.googleapis.com/google.cloud.audit.AuditLog"
  authenticationInfo: {
   principalEmail: "649517127304@cloudservices.gserviceaccount.com"
  }
  requestMetadata: {…}
  serviceName: "compute.googleapis.com"
  methodName: "v1.compute.instances.delete"
  resourceName: "projects/my-gcp-project-id/zones/us-central1-b/instances/abc123"
 }
}

Entrées de journal tardives

Les entrées de journal acheminées sont enregistrées dans des buckets Cloud Storage par lots horaires. Il peut s'écouler deux à trois heures avant que les premières entrées ne s'affichent. Les partitions de fichiers journaux acheminés avec le suffixe An ("Ajouter") contiennent les entrées de journal reçues en retard.

Si la destination subit une panne, Cloud Logging met les données en mémoire tampon jusqu'à la fin de la panne.

Si la destination du récepteur ne contient aucun journal, vérifiez les métriques système de l'exportation. Les métriques du système d'exportation indiquent le nombre d'entrées de journal acheminées et supprimées en raison d'erreurs. Si les métriques du système d'exportation indiquent qu'aucune entrée de journal n'a été acheminée vers la destination, vérifiez votre filtre pour vérifier que les entrées correspondant à votre filtre sont récemment arrivées dans Logging:

Accéder au Routeur de journaux

Entrées de journal App Engine

App Engine combine plusieurs sous-entrées de type google.appengine.logging.v1.LogLine (également appelées AppLog ou AppLogLine) sous une entrée de journal principale de type google.appengine.logging.v1.RequestLog pour la requête qui entraîne l'activité de journal. Les lignes de journal possèdent chacune un "ID de requête" qui identifie l'entrée principale. L'explorateur de journaux affiche les lignes de journal avec l’entrée de journal de requêtes. Logging tente de placer toutes les lignes de journal dans le lot avec la requête d'origine, même si leurs horodatages les placent dans le lot suivant. Si cela n'est pas possible, il se peut que l'entrée de journal de requête ne contienne pas certaines lignes et qu'il reste des lignes de journal "orphelines" sans requête dans le lot suivant. Si cette possibilité est importante pour vous, vous devez être prêt à reconnecter les éléments de la requête lors du traitement de vos journaux.

Dépannage

Si les journaux semblent ne pas figurer dans la destination du récepteur, vous pouvez afficher les métriques logging.googleapis.com/exports/ pour vérifier le nombre d'entrées de journal envoyées par le récepteur:

  • exports/byte_count: nombre d'octets dans les entrées de journal acheminées
  • exports/log_entry_count: nombre d'entrées de journal acheminées.
  • exports/error_count: nombre d'entrées de journal dont le routage a échoué.

Les métriques comportent des libellés qui enregistrent les décomptes par nom et récepteur de nom de récepteur. Elles vous permettent de savoir si votre récepteur achemine correctement les données des journaux ou s'ils échouent. Pour en savoir plus sur l'affichage des métriques, consultez la page Afficher les métriques basées sur les journaux.

Si vous pensez que le récepteur ne route pas correctement les journaux, consultez la section Résoudre les problèmes de routage et de récepteurs.

Tarifs

Cloud Logging ne facture pas l'acheminement des journaux, mais des frais de destination peuvent s'appliquer. Pour plus d'informations, consultez les tarifs appropriés du service:

Notez également que si vous envoyez et excluez vos journaux de flux de cloud privé virtuel (VPC) depuis Cloud Logging, des frais de génération de journaux de flux VPC s'appliquent en plus des frais de destination.