Présentation de la surveillance BigQuery

La surveillance et la journalisation sont essentielles pour exécuter des applications fiables dans le cloud. Les charges de travail BigQuery ne font pas exception, en particulier si vos charges de travail ont un volume élevé ou qu'elles sont critiques. Ce document offre un aperçu général des données de surveillance disponibles pour BigQuery.

Les sources de surveillance et de journalisation peuvent varier en fonction de la fréquence d'échantillonnage ou d'agrégation. Par exemple, les données de schéma d'informations peuvent être disponibles à un niveau de précision supérieur à celui des données des métriques Cloud Monitoring.

Par conséquent, les graphiques pour des métriques ayant un niveau de précision inférieur peuvent sembler différents des statistiques de schémas d'information comparables. L'agrégation a tendance à réduire ces différences. Lorsque vous concevez une solution de surveillance, évaluez le temps de réponse, la précision globale et la précision des métriques par rapport à vos besoins.

Métriques

Les métriques sont des valeurs numériques collectées à des intervalles réguliers et mises à disposition pour l'analyse. Elles vous permettent d'effectuer les opérations suivantes :

  • Créer des graphiques et des tableaux de bord
  • Déclencher des alertes pour les conditions ou les situations nécessitant une intervention humaine
  • Analyser l'historique des performances

Dans le cas de BigQuery, les métriques disponibles incluent le nombre de tâches en cours d'exécution, le nombre d'octets analysés lors d'une requête et la distribution des temps de requête. Les métriques d'une requête ne sont disponibles qu'une fois que celle-ci aboutit. Leur enregistrement peut prendre jusqu'à sept minutes. Les métriques des requêtes ayant échoué ne sont pas répertoriées. Pour obtenir la liste complète des métriques disponibles, y compris leurs taux d'échantillonnage, leur visibilité et leurs limites, consultez la section bigquery de la page Métriques Google Cloud.

Utilisez Cloud Monitoring pour afficher les métriques BigQuery, et créer des graphiques et des alertes. Chaque métrique possède un type de ressource (bigquery_dataset, bigquery_project ou global) ainsi qu'un ensemble de libellés. Utilisez ces informations pour créer des requêtes en MQL (Monitoring Query Language). Vous pouvez regrouper ou filtrer chaque métrique à l'aide des libellés.

Par exemple, pour représenter le nombre de requêtes interactives en cours de transfert, utilisez l'instruction MQL suivante, qui filtre par priority égal à interactive :

fetch global
| metric 'bigquery.googleapis.com/query/count'
| filter metric.priority = 'interactive'

L'exemple suivant permet d'obtenir le nombre de tâches de chargement en cours de transfert, regroupées par intervalles de 10 minutes :

fetch bigquery_project
| metric 'bigquery.googleapis.com/job/num_in_flight'
| filter metric.job_type = 'load'
| group_by 10m

Pour en savoir plus, consultez la page Créer des graphiques et des alertes pour BigQuery.

Journaux

Les journaux sont des enregistrements textuels générés en réponse à des événements ou actions particuliers. BigQuery crée des entrées de journal pour des actions telles que la création ou la suppression d'une table, l'achat d'emplacements ou l'exécution d'une tâche de chargement. Pour en savoir plus sur la journalisation dans Google Cloud, consultez la page Cloud Logging.

Un journal est une collection d'entrées de journal en mode "append-only". Par exemple, vous pouvez écrire vos propres entrées de journal dans un journal nommé projects/PROJECT_ID/logs/my-test-log. De nombreux services Google Cloud, y compris BigQuery, créent un type de journal appelé journaux d'audit. Ces journaux enregistrent :

  • les activités d'administration, telles que la création ou la modification de ressources ;
  • les accès aux données, telles que la lecture de données fournies par l'utilisateur à partir d'une ressource ;
  • les événements système générés par les systèmes Google, plutôt que par des actions des utilisateurs.

Les journaux d'audit sont écrits dans un format JSON structuré. Le type de données de base pour les entrées de journal Google Cloud est la structure LogEntry. Cette structure contient le nom du journal, la ressource ayant généré l'entrée de journal, l'horodatage (UTC) et d'autres informations de base.

Les détails de l'événement consigné sont contenus dans un sous-champ appelé charge utile. Pour les journaux d'audit, le champ de charge utile est nommé protoPayload. La valeur de ce champ est une structure AuditLog, indiquée par la valeur du champ protoPayload.@type, qui est définie sur type.googleapis.com/google.cloud.audit.AuditLog.

Pour les opérations sur des ensembles de données, des tables et des tâches, BigQuery écrit actuellement des journaux d'audit dans deux formats différents, bien qu'ils partagent tous deux le type de base AuditLog.

Avec l'ancien format :

  • Le champ resource.type correspond à bigquery_resource.
  • Les détails de l'opération sont écrits dans le champ protoPayload.serviceData. La valeur de ce champ est une structure AuditData.

Au format le plus récent :

  • Le champ resource.type contient bigquery_project ou bigquery_dataset. La ressource bigquery_project contient des entrées de journal sur les tâches, tandis que la ressource bigquery_dataset dispose d'entrées de journal concernant le stockage.
  • Les détails de l'opération sont écrits dans le champ protoPayload.metadata. La valeur de ce champ est une structure BigQueryAuditMetadata.

Nous vous recommandons de consulter les journaux dans un format plus récent. Pour en savoir plus, consultez le guide de migration des journaux d'audit.

Voici un exemple d'entrée de journal illustrant une opération ayant échoué :

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "status": {
      "code": 5,
      "message": "Not found: Dataset my-project:my-dataset was not found in location US"
    },
    "authenticationInfo": { ... },
    "requestMetadata":  { ... },
    "serviceName": "bigquery.googleapis.com",
    "methodName": "google.cloud.bigquery.v2.JobService.InsertJob",
    "metadata": {
  },
  "resource": {
    "type": "bigquery_project",
    "labels": { .. },
  },
  "severity": "ERROR",
  "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access",
  ...
}

Pour les opérations sur BigQuery Reservations, le champ protoPayload est une structure AuditLog, et les champs protoPayload.request et protoPayload.response contiennent davantage d'informations. Vous pouvez voir les définitions des champs dans l'API BigQuery Reservations. Pour en savoir plus, consultez la page Surveiller BigQuery Reservations.

INFORMATION_SCHEMA vue

Les vues INFORMATION_SCHEMA constituent une autre source d'insights dans BigQuery, que vous pouvez utiliser en parallèle des métriques et des journaux.

Ces vues contiennent des métadonnées sur les tâches, les ensembles de données, les tables et d'autres entités BigQuery. Par exemple, vous pouvez obtenir des métadonnées en temps réel sur les tâches BigQuery exécutées sur une période donnée, puis regrouper ou filtrer les résultats par projet, utilisateur, tables référencées et d'autres dimensions.

Vous pouvez utiliser ces informations pour effectuer une analyse plus détaillée de vos charges de travail BigQuery et répondre à des questions telles que :

  • Quelle est l'utilisation moyenne des emplacements pour toutes les requêtes effectuées au cours des sept derniers jours sur un projet donné ?
  • Quels utilisateurs ont envoyé une tâche de chargement par lot sur un projet donné ?
  • Quels codes d'erreurs de flux continu ont été le plus vus au cours des 30 dernières minutes ?

Intéressez-vous particulièrement aux métadonnées de tâches, aux métadonnées en flux continu et aux métadonnées de réservation pour obtenir des informations sur les performances. de vos charges de travail BigQuery.

Vous trouverez sur GitHub des exemples de requêtes INFORMATION_SCHEMA indiquant l'utilisation des emplacements et des réservations d'une organisation, l'exécution des tâches et les erreurs liées à une tâche. Par exemple, la requête suivante fournit la liste des requêtes en attente ou en cours d'exécution. Ces requêtes sont triées en fonction de la durée qui s'est écoulée depuis leur création dans la région us :

SELECT
    creation_time,
    project_id,
    user_email,
    job_id,
    job_type,
    priority,
    state,
    TIMESTAMP_DIFF(CURRENT_TIMESTAMP(), start_time,second) as running_time_sec
 FROM
   `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
 WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP()
    AND state != "DONE"
ORDER BY
    running_time_sec DESC

Pour en savoir plus, consultez la page Résoudre les problèmes de performances de BigQuery avec ces tableaux de bord.

Si vous avez des réservations d'emplacements, en plus d'écrire votre propre requête, vous pouvez utiliser les graphiques de ressources d'administration BigQuery pour visualiser des graphiques montrant l'utilisation des emplacements, la simultanéité des tâches et la durée d'exécution des tâches. Pour en savoir plus, consultez la Présentation des graphiques de ressources d'administration BigQuery (aperçu).

Étapes suivantes