Exemples

Cette page présente le langage MQL (Monitoring Query Language) à l'aide d'une série d'exemples. Elle n'a pas vocation à couvrir tous les aspects du langage. Le langage MQL est décrit en détail dans la documentation de référence sur le langage MQL.

Vous pouvez écrire une requête spécifique sous de nombreuses formes. Le langage est très flexible, et vous pouvez utiliser de nombreux raccourcis une fois que vous connaissez la syntaxe. Pour en savoir plus, consultez la section Requêtes strictes et concises.

Avant de commencer

Ces exemples utilisent l'onglet "Éditeur de requêtes" de l'explorateur de métriques. Pour les exécuter, collez la requête dans l'éditeur et cliquez sur Exécuter la requête. Pour obtenir une présentation de cet éditeur, consultez la page Utiliser l'éditeur de requêtes.

Une certaine connaissance des concepts de Cloud Monitoring, y compris des types de métriques, des types de ressources surveillées et des séries temporelles, est utile. Pour obtenir une présentation de ces concepts, consultez la page Métriques, séries temporelles et ressources.

Modèle de données

Les requêtes MQL récupèrent et manipulent les données de la base de données de séries temporelles Cloud Monitoring. Cette section présente certains concepts et termes associés à cette base de données. Pour en savoir plus, consultez la section Modèle de données dans la documentation de référence.

Chaque série temporelle provient d'un seul type de ressource surveillée, et chaque série temporelle collecte des données d'un type de métrique. Les types de ressources surveillées et de métriques ont une structure standard, définie par un descripteur de ressource surveillée et un descripteur de métrique. Par exemple, le type de ressource peut être gce_instance, soit une VM Compute Engine, et le type de métrique peut être compute.googleapis.com/instance/cpu/utilization, soit l'utilisation du processeur de la VM Compute Engine.

Ces descripteurs spécifient également un ensemble de libellés permettant de collecter des informations sur d'autres attributs du type de ressource ou de métrique. Par exemple, les ressources ont généralement un libellé zone, qui permet d'enregistrer leur emplacement géographique.

Une série temporelle unique est créée pour chaque combinaison de valeurs pour les libellés de la paire d'un descripteur de métrique et d'un descripteur de ressource surveillée.

Les libellés disponibles pour le type de ressource sont indiqués dans la liste des ressources surveillées, par exemple gce_instance. Pour le type de métrique, les libellés sont indiqués dans la liste des métriques, par exemple les métriques de Compute Engine.

Pour en savoir plus sur les types de métriques et de ressources, ainsi que sur les libellés, consultez la page Composants du modèle de métrique.

La base de données Cloud Monitoring stocke toutes les séries temporelles d'un type de ressource et d'un type de métrique spécifiques dans une table. Le type de métrique et le type de ressource servent d'identifiant pour la table. La requête MQL ci-dessous extrait la table des séries temporelles enregistrant l'utilisation du processeur pour les instances Compute Engine :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization

Les séries temporelles individuelles de la table sont identifiées par les valeurs écrites pour les libellés associés aux types de métriques et de ressources.

Les requêtes MQL récupèrent les données de séries temporelles de ces tables et les transforment en tables de sortie. Ces tables de sortie peuvent être transmises à d'autres opérations. Par exemple, vous pouvez isoler les séries temporelles écrites par les ressources d'une zone ou d'un ensemble de zones spécifique en transmettant la table récupérée en tant qu'entrée à une opération filter :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| filter zone =~ 'us-central.*'

La requête précédente génère une table qui ne contient que les séries temporelles des ressources d'une zone commençant par us-central :

Les requêtes MQL sont structurées en transmettant la sortie d'une opération en tant qu'entrée à l'opération suivante. Cette approche basée sur les tables vous permet d'associer des opérations pour manipuler ces données par le biais du filtrage, de la sélection et d'autres opérations de base de données courantes telles que les jointures internes et externes. Vous pouvez également exécuter diverses fonctions sur les données des séries temporelles, car elles sont transmises d'une opération à une autre.

Les opérations et les fonctions disponibles dans le langage MQL sont entièrement décrites dans la documentation de référence sur le langage MQL.

Structure d'une requête

Une requête est composée d'une ou de plusieurs opérations. Les opérations sont liées ou canalisées, de sorte que la sortie d'une opération soit l'entrée de la suivante. Par conséquent, le résultat d'une requête dépend de l'ordre des opérations. Voici quelques exemples de ce que vous pouvez faire :

  • Lancer une requête avec une opération fetch ou une autre opération de sélection
  • Créer une requête avec plusieurs opérations canalisées
  • Sélectionner le sous-ensemble d'informations souhaité avec les opérations filter
  • Agréger les informations associées avec les opérations group_by
  • Examiner les anomalies avec les opérations top et bottom
  • Combiner plusieurs requêtes avec les opérations { ; } et join
  • Utiliser l'opération et les fonctions value pour calculer des ratios et d'autres valeurs

Toutes les requêtes n'utilisent pas toutes ces options.

Ces exemples ne présentent qu'une partie des opérations et des fonctions disponibles. Pour en savoir plus sur la structure des requêtes MQL, consultez la section Structure des requêtes dans la documentation de référence.

Ces exemples ne spécifient pas deux choses que vous pouvez vous attendre à voir : les périodes et l'alignement. Les sections suivantes expliquent pourquoi.

Périodes

Lorsque vous utilisez l'éditeur de requêtes, la période des requêtes est définie implicitement par le paramétrage du graphique. Par défaut, la période du graphique est d'une heure. Pour plus d'informations sur les périodes dans l'éditeur de requêtes, consultez la section Périodes, graphiques et éditeur de requêtes.

Alignement

De nombreuses opérations utilisées dans ces exemples, telles que les opérations join et group_by, dépendent de tous les points de série temporelle d'une table qui se produisent à intervalles réguliers. L'action d'aligner tous les points à des horodatages réguliers est appelée alignement. Elle est généralement implicite, et aucun des exemples présentés ici ne la montre.

Le langage MQL aligne automatiquement les tables pour les opérations join et group_by si nécessaire, mais il vous permet également d'effectuer l'alignement de manière explicite.

  • Pour obtenir des informations générales sur le concept d'alignement, consultez la section Alignement : agrégation au sein d'une série.

  • Pour plus d'informations sur l'alignement dans le langage MQL, consultez la section Alignement dans la documentation de référence. L'alignement peut être explicitement contrôlé à l'aide des opérations align et every.

Extraction et filtrage

Les requêtes MQL commencent par la récupération et la sélection ou le filtrage des données. Cette section illustre certaines opérations de base de récupération, de regroupement et de filtrage avec le langage MQL.

Récupérer des données de séries temporelles

Une requête commence toujours par une opération fetch, qui récupère les séries temporelles depuis le datastore Cloud Monitoring.

La requête la plus simple consiste en une seule opération fetch et un argument qui identifie les séries temporelles à extraire, comme suit :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization

L'argument comprend un type de ressource surveillée (gce_instance), une paire de signes deux-points (::) et un type de métrique (compute.googleapis.com/instance/cpu/utilization).

Cette requête récupère toutes les séries temporelles écrites par les instances Compute Engine pour le type de métrique compute.googleapis.com/instance/cpu/utilization, qui enregistre l'utilisation du processeur de ces instances.

Si vous exécutez la requête à partir de l'éditeur de requêtes dans l'explorateur de métriques, vous obtenez un graphique représentant chacune des séries temporelles demandées :

Le graphique montre les données d'utilisation du processeur pour les instances Compute Engine.

Chacune des séries temporelles demandées est affichée sous forme de ligne dans le graphique. Chaque série temporelle inclut une liste de valeurs horodatées issues de la métrique d'utilisation du processeur pour une instance de VM de ce projet.

Dans l'espace de stockage backend utilisé par Cloud Monitoring, les séries temporelles sont stockées dans des tables. L'opération fetch organise les séries temporelles des types de métrique et de ressource surveillée spécifiés dans une table, qui est ensuite renvoyée par l'opération fetch. Les données renvoyées sont affichées dans le graphique.

L'opération fetch est décrite, ainsi que ses arguments, sur la page de référence sur fetch. Pour en savoir plus sur les données générées par les opérations, consultez les pages de référence sur les séries temporelles et les tables.

Filtrer

Les requêtes sont généralement composées de plusieurs opérations combinées. La combinaison la plus simple consiste à canaliser la sortie d'une opération vers l'entrée de la suivante en utilisant l'opérateur de barre verticale, |. L'exemple suivant illustre l'utilisation d'une barre verticale pour fournir en entrée la table dans une opération de filtrage :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| filter instance_name =~ 'gke.*'

Cette requête canalise la table, renvoyée par l'opération fetch présentée dans l'exemple précédent, vers une opération filter, qui prend comme expression une valeur booléenne, dans ce cas, "instance_name commence par gke".

L'opération filter prend la table d'entrée, supprime les séries temporelles pour laquelle le filtre est faux et génère la table obtenue. La capture d'écran suivante montre le graphique obtenu :

Le graphique affiche les résultats filtrés pour

Si aucun nom d'instance ne commence par gke, modifiez le filtre avant d'essayer cette requête. Par exemple, si vous avez des instances de VM comportant apache au début de leur nom, utilisez le filtre suivant :

 | filter instance_name =~ 'apache.*'

L'expression filter est évaluée une fois pour chaque série temporelle d'entrée. Si l'expression renvoie true, cette série temporelle est incluse dans la sortie. Dans cet exemple, l'expression de filtre procède à une mise en correspondance d'expression régulière, =~, sur le libellé instance_name de chaque série temporelle. Si la valeur du libellé correspond à l'expression régulière 'gke.*', la série temporelle est incluse dans la sortie. Dans le cas contraire, elle est supprimée de la sortie.

Pour plus d'informations sur le filtrage, consultez la page de référence sur filter. Le prédicat filter peut être n'importe quelle expression arbitraire qui renvoie une valeur booléenne. Pour en savoir plus, consultez la section Expressions.

Regroupement et agrégation

Le regroupement vous permet de regrouper des séries temporelles selon des dimensions spécifiques. L'agrégation combine toutes les séries temporelles d'un groupe en une seule série temporelle de sortie.

La requête suivante filtre la sortie de l'opération fetch initiale pour ne conserver que les séries temporelles des ressources d'une zone commençant par us-central. Elle regroupe ensuite les séries temporelles par zone et les combine à l'aide de l'agrégation mean.

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| filter zone =~ 'us-central.*'
| group_by [zone], mean(val())

La table résultant de l'opération group_by comporte une série temporelle par zone. La capture d'écran suivante montre le graphique obtenu :

Graphique présentant une extraction filtrée regroupée par zone.

L'opération group_by prend deux arguments, séparés par une virgule (,). Ces arguments déterminent le comportement de regroupement précis. Dans cet exemple, group_by [zone], mean(val()), les arguments fonctionnent comme suit :

  • Le premier argument, [zone], contrôle le regroupement des séries temporelles. Il s'agit d'une expression de mappage, qui spécifie ici les libellés à utiliser pour le regroupement. L'étape de regroupement collecte toutes les séries temporelles d'entrée ayant les mêmes valeurs zone de sortie dans un groupe, dans ce cas, les séries temporelles collectées à partir des VM Compute Engine d'une zone.

    La série temporelle de sortie n'a qu'un libellé zone, dont la valeur est copiée à partir des séries temporelles d'entrée du groupe. Les autres libellés des séries temporelles d'entrée sont supprimés de la série temporelle de sortie.

    L'expression de mappage peut faire bien plus que de répertorier des libellés. Pour en savoir plus, consultez la page de référence sur map.

  • Le second argument, mean(val()), contrôle la façon dont les séries temporelles de chaque groupe sont combinées ou agrégées en une seule série temporelle de sortie. Chaque point de la série temporelle de sortie d'un groupe est le résultat de l'agrégation des points ayant le même horodatage de toutes les séries temporelles d'entrée du groupe.

    La valeur résultant de l'agrégation est déterminée par la fonction d'agrégation appliquée, mean dans cet exemple. La fonction est appliquée aux valeurs des points à agréger, qui sont renvoyées par la fonction val(). Dans cet exemple, vous obtenez la moyenne de l'utilisation du processeur des machines virtuelles de la zone à chaque point de sortie.

    L'expression mean(val()) est un exemple d'expression d'agrégation.

L'opération group_by combine toujours regroupement et agrégation. Si vous spécifiez un regroupement, mais omettez l'argument d'agrégation, group_by utilise une agrégation par défaut, aggregate(val()), qui sélectionne une fonction appropriée pour le type de données. Consultez la section sur aggregate pour obtenir la liste des fonctions d'agrégation par défaut.

Sélectionner des séries temporelles

Les exemples de cette section montrent comment sélectionner des séries temporelles spécifiques dans une table d'entrée.

Sélectionner les premières ou dernières séries temporelles

Pour afficher les données de séries temporelles des trois instances Compute Engine présentant le niveau le plus élevé d'utilisation du processeur dans votre projet, saisissez la requête suivante :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| top 3

La capture d'écran suivante montre le résultat pour un projet :

Le graphique montre les trois séries temporelles présentant le niveau le plus élevé d'utilisation.

Vous pouvez récupérer les séries temporelles présentant le niveau le plus faible d'utilisation du processeur en remplaçant top par bottom.

L'opération top génère une table avec un nombre spécifié de séries temporelles sélectionnées dans sa table d'entrée. Les séries temporelles incluses dans la sortie a la plus grande valeur pour un aspect des séries temporelles. Ici, l'argument 3 indique de sélectionner trois séries temporelles.

Étant donné que cette requête ne spécifie aucune méthode de tri des séries temporelles, elle renvoie celles ayant la plus grande valeur pour le point le plus récent. Vous pouvez éventuellement ajouter un argument supplémentaire à l'opération top : une expression qui indique comment déterminer la série temporelle ayant la valeur la plus élevée. La requête précédente équivaut à ceci :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| top 3, val()

L'expression val() sélectionne la valeur du point le plus récent dans chaque série temporelle à laquelle elle est appliquée. La requête renvoie ainsi les séries temporelles ayant la valeur la plus élevée pour le point le plus récent.

Vous pouvez fournir une expression qui effectue une agrégation sur tout ou partie des points d'une série temporelle pour indiquer la valeur de tri. La valeur suivante prend la moyenne de tous les points des 10 dernières minutes :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| top 3, mean(val()).within(10m)

Si la fonction within n'est pas utilisée, la fonction mean est appliquée aux valeurs de tous les points affichés dans les séries temporelles.

L'opération bottom fonctionne d'une manière semblable. La requête suivante recherche la valeur du plus grand point de chaque série temporelle avec max(val()), puis sélectionne les trois séries temporelles pour lesquelles cette valeur est la plus faible :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| bottom 3, max(val())

Il peut s'agir des flux présentant les pics les plus faibles. La capture d'écran suivante montre le graphique obtenu :

Le graphique montre les trois séries temporelles présentant le niveau le plus élevé d'utilisation.

Sélectionner les premières ou dernières séries temporelles dans des groupes

Les opérations de table top et bottom sélectionnent des séries temporelles dans l'ensemble de la table d'entrée. Les opérations top_by et bottom_by regroupent les séries temporelles d'une table, puis choisissent un certain nombre de séries temporelles dans chaque groupe.

La requête suivante sélectionne dans chaque zone la série temporelle ayant la plus haute valeur maximale, et :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| top_by [zone], 1, max(val())

Le graphique montre la valeur maximale la plus haute par zone.

L'expression [zone] indique qu'un groupe est constitué de toutes les séries temporelles ayant la même valeur pour la colonne zone. La valeur 1 dans top_by indique le nombre de séries temporelles à sélectionner dans le groupe de chaque zone. L'expression max(val()) recherche la plus grande valeur de la période du graphique dans chaque série temporelle.

Vous pouvez utiliser n'importe quelle fonction d'agrégation à la place de max. Dans l'exemple suivant, l'agrégateur mean et within sont utilisés pour spécifier la plage de tri de 20 minutes. Les deux premières séries temporelles de chaque zone sont sélectionnées :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| top_by [zone], 2, mean(val()).within(20m)

Le graphique montre les deux pics moyens les plus élevés dans une plage de 20 minutes.

Notez qu'il n'y a qu'une seule instance dans la zone us-central-c. Par conséquent, une seule série temporelle est renvoyée, il n'y a pas de "top 2" dans le groupe.

Combiner des sélections avec union

Vous pouvez combiner des opérations de sélection telles que top et bottom pour créer des graphiques qui affichent les deux. Par exemple, la requête suivante renvoie la série temporelle unique présentant la valeur maximale et la série temporelle unique présentant la valeur minimale :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| {
    top 1, max(val())
  ;
    bottom 1, min(val())
  }
| union

Le graphique obtenu affiche deux lignes, l'une contenant la valeur la plus élevée et l'autre contenant la plus basse :

Le graphique montre les séries temporelles présentant les valeurs les plus élevées et les plus faibles.

Vous pouvez utiliser des accolades ({ }) pour spécifier des séquences d'opérations, chacune produisant une table de séries temporelles en sortie. Les opérations individuelles sont séparées par un signe deux-points (;).

Dans cet exemple, l'opération fetch renvoie une seule table, qui est canalisée vers chacune des deux opérations de la séquence, une opération top et une opération bottom. Chacune de ces opérations génère une table de sortie basée sur la même table d'entrée. L'opération union combine ensuite les deux tables en une seule, qui s'affiche sur le graphique.

Pour en savoir plus sur la séquence d'opérations multiples utilisant { }, consultez la section Structure d'une requête dans la documentation de référence.

Calculer des ratios

Supposons que vous ayez créé un service Web distribué qui s'exécute sur des instances de VM Compute Engine et utilise Cloud Load Balancing.

Vous souhaitez afficher un graphique indiquant le ratio entre les requêtes qui renvoient des réponses HTTP 500 (erreurs internes) et le nombre total de requêtes, c'est-à-dire le ratio requêtes/échecs. Cette section illustre plusieurs façons de calculer ce ratio.

Cloud Load Balancing utilise le type de ressource surveillée http_lb_rule. Le type de ressource surveillée http_lb_rule possède un libellé matched_url_path_rule qui enregistre le préfixe des URL définies dans la règle. La valeur par défaut est UNMATCHED.

Le type de métrique loadbalancing.googleapis.com/https/request_count comporte un libellé response_code_class. Ce libellé capture la classe des codes de réponse.

Utiliser outer_join et div

La requête suivante détermine les réponses 500 pour chaque valeur du libellé matched_url_path_rule dans chaque ressource surveillée http_lb_rule de votre projet. Elle joint ensuite cette table de comptage des échecs à la table d'origine, qui contient tous les décomptes de réponses et divise les valeurs pour afficher le ratio entre les réponses d'échec et le nombre total de réponses :

fetch https_lb_rule::loadbalancing.googleapis.com/https/request_count
| {
    filter response_code_class = 500
  ;
    ident
  }
| group_by [matched_url_path_rule]
| outer_join 0
| div

Le graphique suivant montre le résultat pour un projet :

Le graphique montre le ratio entre les réponses d'échec et le nombre total de réponses obtenu par jointure.

L'opération fetch génère une table de séries temporelles contenant les décomptes de requêtes pour toutes les requêtes à équilibrage de charge. Cette table est traitée de deux manières par les deux séquences d'opérations entre accolades.

  • filter response_code_class = 500 ne renvoie que les séries temporelles associées au libellé response_code_class avec la valeur 500. La série temporelle obtenue comptabilise les requêtes avec des codes de réponse HTTP 5xx (erreur).

    Cette table est le numérateur du ratio.

  • L'opération ident ou d'identité génère son entrée, ce qui renvoie la table extraite à l'origine. Il s'agit de la table qui contient les séries temporelles avec des décomptes pour chaque code de réponse.

    Cette table est le dénominateur du ratio.

Les tables de numérateur et de dénominateur, générées respectivement par les opérations filter et ident, sont traitées séparément par l'opération group_by. L'opération group_by regroupe les séries temporelles de chaque table en fonction de la valeur du libellé matched_url_path_rule et additionne les décomptes pour chaque valeur du libellé. Cette opération group_by n'indique pas explicitement la fonction d'agrégateur. Une valeur par défaut, sum, est utilisée.

  • Pour la table filtrée, le résultat group_by correspond au nombre de requêtes renvoyant une réponse 500 pour chaque valeur matched_url_path_rule.

  • Pour la table d'identité, les résultats group_by correspondent au nombre total de requêtes pour chaque valeur matched_url_path_rule.

Ces tables sont canalisées vers l'opération outer_join, qui associe les séries temporelles aux valeurs de libellé correspondantes, une dans chacune des deux tables d'entrée. Les séries temporelles associées sont compressées en faisant correspondre l'horodatage de chaque point d'une série temporelle à celui d'un point de l'autre série temporelle. Pour chaque paire de points mis en correspondance, outer_join génère un seul point de sortie avec deux valeurs, provenant de chacune des tables d'entrée. La série temporelle compressée est générée par la jointure avec les mêmes libellés que les deux séries temporelles d'entrée.

Comme il s'agit d'une jointure externe, si un point de la seconde table n'a pas de point correspondant dans la première, une valeur de remplacement doit être fournie. Dans cet exemple, un point avec la valeur 0 (argument de l'opération outer_join) est utilisé.

Enfin, l'opération div prend chaque point avec deux valeurs et divise les valeurs pour générer un seul point de sortie : il s'agit du ratio entre les réponses 500 et toutes les réponses pour chaque mappage d'URL.

La chaîne div ici est en fait le nom de la fonction div, qui divise deux valeurs numériques. Cependant, elle est utilisée ici comme opération. Lorsqu'elles sont utilisées en tant qu'opérations, les fonctions telles que div attendent deux valeurs dans chaque point d'entrée (ce que garantit join) et génèrent une seule valeur pour le point de sortie correspondant.

La partie | div de la requête est un raccourci pour | value val(0) / val(1). L'opération value permet à des expressions arbitraires sur les colonnes de valeur d'une table d'entrée de générer les colonnes de valeur de la table de sortie. Pour plus d'informations, consultez les pages de référence sur l'opération value et les expressions.

Utiliser ratio

La fonction div peut être remplacée par n'importe quelle fonction sur deux valeurs. Toutefois, comme les ratios sont fréquemment utilisés, la langage MQL fournit une opération de table ratio qui les calcule directement.

La requête ci-dessous équivaut à la version précédente, utilisant outer_join et div :

fetch https_lb_rule::loadbalancing.googleapis.com/https/request_count
| {
    filter response_code_class = 500
  ;
    ident
  }
| group_by [matched_url_path_rule]
| ratio

Dans cette version, l'opération ratio remplace les opérations outer_join 0 | div de la version précédente et génère le même résultat.

Utiliser group_by et /

Il existe une autre façon de calculer le ratio entre les réponses d'erreur et le nombre total de réponses. Dans ce cas, comme le numérateur et le dénominateur du ratio sont dérivés de la même série temporelle, vous pouvez également calculer le ratio en effectuant uniquement un regroupement. La requête suivante illustre cette approche :

fetch https_lb_rule::loadbalancing.googleapis.com/https/request_count
| group_by [matched_url_path_rule],
    sum(if(response_code_class = 500, val(), 0)) / sum(val())

Cette requête utilise une expression d'agrégation basée sur le ratio de deux sommes :

  • La première somme (sum) utilise la fonction if pour comptabiliser les libellés ayant la valeur 500 et 0 pour les autres. La fonction sum calcule le nombre de requêtes ayant renvoyé 500.

  • La seconde somme (sum) additionne les décomptes de toutes les requêtes, val().

Les deux sommes sont ensuite divisées, ce qui donne le ratio entre le nombre de réponses 500 et le nombre total de réponses. Cette requête génère le même résultat que les requêtes figurant dans les sections Utiliser outer_join et div et Utiliser ratio.

Utiliser filter_ratio_by

Comme les ratios sont souvent calculés en divisant deux sommes dérivées de la même table, le langage MQL fournit l'opération filter_ratio_by à cet effet. La requête suivante effectue la même opération que la version précédente, qui divise explicitement les sommes :

fetch https_lb_rule::loadbalancing.googleapis.com/https/request_count
| filter_ratio_by [matched_url_path_rule], response_code_class = 500

Le premier opérande de l'opération filter_ratio_by, ici [matched_url_path_rule], indique comment regrouper les réponses. La seconde opération, ici response_code_class = 500, agit comme une expression de filtrage pour le numérateur.

  • La table de dénominateur est le résultat du regroupement de la table extraite par matched_url_path_rule et agrégée à l'aide de sum.
  • La table de numérateur est la table extraite, filtrée pour les séries temporelles ayant le code de réponse HTTP 5xx, puis regroupée par matched_url_path_rule et agrégée à l'aide de sum.

Décalage temporel

Parfois, vous souhaitez comparer ce qui se passe actuellement et ce qui est survenu dans le passé. La langage MQL fournit l'opération de table time_shift, qui permet de déplacer les données du passé vers la période actuelle, afin de les comparer aux valeurs actuelles.

Ratios au fil du temps

La requête suivante utilise time_shift, join et div pour calculer le ratio de l'utilisation moyenne dans chaque entre la période actuelle et une semaine auparavant.

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| group_by [zone], mean(val())
| {
    ident
  ;
    time_shift 1w
  }
| join | div

Le graphique suivant montre un résultat possible de cette requête :

Le graphique montre le ratio des données actuelles et décalées dans le temps.

Les deux premières opérations extraient les séries temporelles souhaitées, puis les regroupent, par zone, en calculant les valeurs moyennes pour chacune d'entre elles. La table obtenue est ensuite transmise à deux opérations. La première opération, ident, transmet la table sans la modifier.

La seconde opération, time_shift, ajoute la période (1 semaine) aux horodatages des valeurs dans la table, ce qui décale les données d'une semaine en avant. Cette modification aligne les horodatages des anciennes données dans la seconde table avec les horodatages des données actuelles dans la première table.

La table non modifiée et la table décalée dans le temps sont ensuite combinées à l'aide d'une opération join interne. L'opération join génère une table de séries temporelles où chaque point a deux valeurs : l'utilisation actuelle et l'utilisation une semaine auparavant. La requête utilise ensuite l'opération div pour calculer le ratio entre la valeur actuelle et la valeur de la semaine passée.

Données passées et présentes

En combinant time_shift avec union, vous pouvez créer un graphique qui affiche simultanément les données passées et présentes. Par exemple, la requête suivante renvoie l'utilisation moyenne globale pour la période actuelle et pour la semaine précédente. À l'aide de union, vous pouvez afficher ces deux résultats sur le même graphique.

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| group_by []
| {
     add [when: "now"]
  ;
     add [when: "then"] | time_shift 1w
  }
| union

Le graphique suivant montre un résultat possible de cette requête :

Le graphique indique l'utilisation moyenne actuelle et passée.

Cette requête extrait les séries temporelles souhaitées, puis utilise group_by [] pour les combiner en une seule série temporelle sans libellé, ne laissant que les points de données d'utilisation du processeur. Ce résultat est transmis à deux opérations. La première ajoute une colonne pour un nouveau libellé appelé when avec la valeur now. La seconde ajoute un libellé appelé when avec la valeur then et transmet le résultat à l'opération time_shift pour décaler les valeurs d'une semaine. Cette requête utilise le modificateur de mappage add. Pour en savoir plus, consultez la section Mappages.

Les deux tables, chacune contenant des données pour une seule série temporelle, sont transmises à union, qui génère une table contenant les séries temporelles des deux tables d'entrée.

Étape suivante

Pour obtenir une présentation des structures du langage MQL, consultez la page À propos du langage MQL.

Pour obtenir une description complète du langage MQL, consultez la documentation de référence sur le langage MQL.

Pour en savoir plus sur l'interaction avec les graphiques, y compris ceux générés par l'éditeur de requêtes, consultez la page Travailler avec des graphiques.