Consignes concernant la surveillance des clusters

Présentation

Ce guide fournit des instructions sur les éléments à surveiller et sur la surveillance d'un déploiement Apigee Hybrid. Il est destiné aux administrateurs de clusters hybrides et aux administrateurs d'organisation.

Si vous débutez avec Google Cloud Monitoring, veuillez consulter la documentation de Google Cloud Monitoring pour savoir comment Créer des graphiques avec l'explorateur de métriques et connaître le Fonctionnement des alertes.

Les clusters Apigee hybrid fournissent des métriques SLI (indicateur de niveau de service) pour vous aider à comprendre les performances des services d'application et du système à un moment donné. Vous pouvez afficher la liste complète des métriques disponibles.

Google Cloud Monitoring utilise le Type de ressource pour identifier chaque métrique SLI. Il existe trois types de ressources courants utilisés pour toutes les métriques Apigee hybrid.

  • k8s_container pour les métriques au niveau du système
  • Proxy pour les métriques du proxy d'API Apigee
  • Target pour les métriques cibles de l'API Apigee

Les types de ressources possèdent des étiquettes courantes qui s'appliquent à toutes les métriques associées. Par exemple, toutes les métriques dotées du type de ressource k8s_container disposent des libellés cluster_name, pod_name et container_name à utiliser en plus des libellés de métriques. Une combinaison d'étiquettes de type de ressource et d'étiquettes de métrique doit être utilisée pour surveiller efficacement l'état et les performances des clusters.

Seuil d'alerte : dans un monde parfait, les seuils d'alerte seraient évidents et la documentation fournie regrouperait les valeurs censées déclencher des alertes. Dans les faits, il est moins évident pour Apigee de définir quelles sont les performances acceptables et quelle est l'utilisation dangereuse des ressources des services et des infrastructures. Les valeurs de seuil d'alerte varient considérablement en fonction des modèles de trafic et des accords de SLO/contrat de niveau de service.

L'optimisation et la détermination du seuil d'alerte se font de manière continue, car elles peuvent changer avec l'utilisation du service et de l'infrastructure. Utilisez les seuils "Avertissement" et "Critique" pour les notifications et les alertes.

  • Opérationnel: la valeur est inférieure au seuil d'avertissement.
  • Problème: la valeur est supérieure au seuil d'avertissement, mais inférieure au seuil critique.
  • Critique: Valeur >Seuil critique.

Pour déterminer le seuil "normal", les clients doivent utiliser les outils fournis pour déterminer le seuil optimal, qu'il s'agisse des tableaux de bord Cloud Monitoring qu'ils peuvent créer à l'aide du langage MQL fourni ci-dessous ou des données analytiques d'Apigee, puis identifier les seuils d'alerte en conséquence.

La surveillance des clusters hybrides peut être classée en quatre groupes généraux, par exemple : Trafic, Base de données, Plan de contrôle Apigee et surveillance d'infrastructure. Les sections suivantes décrivent ces groupes en détail :

Trafic

Les métriques SLI du proxy et de la cible Apigee fournissent le nombre de requêtes/réponses et les latences du proxy d'API et des cibles. La métrique SLI de latence de la règle Apigee fournit des latences de réponse des règles. Ces métriques SLI fournissent une couverture pour surveiller le trafic de l'API Apigee.

Taux de demandes

Nombre de demandes de proxy

Cas d'utilisation : utilisez proxy/request_count pour surveiller le nombre de requêtes de proxy. Le graphique proxy/request_count affiche le taux de requêtes des proxys. Ce graphique permet d'identifier le proxy qui reçoit un taux de demandes plus élevé, des modèles de taux de demandes et tout pic anormal d'appels de requête pour un proxy particulier. Tout pic anormal et inattendu du trafic de l'API peut poser un problème de sécurité en lien avec un bot ou une attaque sur des proxys d'API. De même, une baisse importante du trafic cloud global indique des problèmes avec les clients ou la connectivité des composants Apigee en amont.

Types de ressources Proxy
Métrique proxy/request_count
Grouper par method, et tous les libellés de types de ressources Proxy
Agrégateur pondérée
Considérations relatives aux alertes Événements tels que les alertes indiquant un pic/une diminution du nombre de requêtes (request_count) anormal(e)
Alert threshold Aucune
Requête MQL du tableau de bord Cloud Monitoring :

fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method],
  [value_request_count_aggregate: aggregate(value.request_count)]

Nombre de requêtes cibles

Cas d'utilisation : utilisez target/request_count pour surveiller le nombre de requêtes de l'environnement d'exécution Apigee cible. Le graphique target/request_count affiche le taux de demandes reçues par la cible Apigee. Ce graphique peut être utile pour identifier la cible dont le taux de demandes est plus élevé, le taux de requêtes et tout pic anormal dans les requêtes pour une cible particulière.

Types de ressources Cible
Métrique target/request_count
Grouper par method, et tous les libellés de types de ressources Target
Agrégateur pondérée
Considérations relatives aux alertes Événements tels que les alertes indiquant un pic/une diminution du nombre de requêtes (request_count) anormal(e)
Alert threshold Aucune
Requête MQL du tableau de bord Cloud Monitoring :

fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, metric.endpoint],
  [value_request_count_aggregate: aggregate(value.request_count)]

Taux d'erreurs

Nombre de réponses d'erreur du proxy

Cas d'utilisation : utilisez proxy/response_count pour surveiller le taux de réponse d'erreur du proxy. Le graphique proxy/response_count affiche le taux de requêtes du proxy d'API. Ce graphique permet de comprendre quel proxy obtient un taux d'erreur de requête plus élevé ou tout pic d'erreur anormal dans les appels de requête d'un proxy particulier.

Types de ressources Proxy
Métrique proxy/response_count
Filtrer par response_code != 200
Grouper par method, response_code, fault_code, fault_source, apigee_fault et tous les libellés de types de ressources Proxy
Agrégateur pondérée
Considérations relatives aux alertes Taux d'erreur des réponses de proxy : nombre total d'erreurs de réponse / nombre total de réponses.
  • Nombre total d'erreurs de réponse = somme des target/response_count avec filtre response_code != 200
  • Nombre total de réponses = somme des target/response_count
Alert threshold Dépend du SLO de l'installation. Les installations en production et hors production peuvent présenter des seuils différents. Par exemple, pour la production, déclenchez une notification d'événement si le taux d'erreur 500 de la réponse du proxy est de 5% pendant 5 minutes.
Requête MQL du tableau de bord Cloud Monitoring :

fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/response_count'
| filter (metric.response_code != 200)
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.fault_code,
   metric.fault_source, metric.apigee_fault],
  [value_response_count_aggregate: aggregate(value.response_count)]
Exemple de langage MQL d'alerte des opérations Google Cloud:

fetch apigee.googleapis.com/Proxy::apigee.googleapis.com/proxy/response_count
| {
   filter (metric.response_code == 500)
   ;
   ident
}
| group_by drop[metric.response_code ], sliding(5m), .sum
| ratio
| scale '%'
| every (30s)
| condition val() > 5'%'

Nombre de réponses d'erreur de cible

Cas d'utilisation : utilisez target/response_count pour surveiller le taux de réponse d'erreur de cible de l'API. Le graphique target/response_count affiche le taux de requêtes de la cible de l'API. Ce graphique peut être utile pour identifier la cible qui reçoit un taux de demandes plus élevé ou un pic d'erreur anormal dans les appels de requête.

Types de ressources Cible
Métrique target/response_count
Filtrer par response_code != 200
Grouper par method, et tous les libellés de types de ressources Target
Agrégateur pondérée
Considérations relatives aux alertes Taux d'erreur des réponses de proxy, par exemple: Nombre total d'erreurs de réponse / Nombre total de réponses.
  • Nombre total d'erreurs de réponse = somme des target/response_count avec filtre response_code != 200
  • Nombre total de réponses = somme des target/response_count
Alert threshold Dépend du SLO de l'installation. Par exemple, pour la production, déclenchez une notification d'événement si le taux d'erreur de réponse cible est de 5 % pendant 3 minutes.
Requête MQL du tableau de bord Cloud Monitoring :

fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/response_count'
| filter (metric.response_code != 200)
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.type, metric.endpoint,
   metric.response_code],
  [value_response_count_aggregate: aggregate(value.response_count)]

Latences

Latences de proxy

Cas d'utilisation: utilisez proxy/latencies pour surveiller les latences de toutes les réponses de proxy d'API à une requête. Le graphique proxy/latencies peut être utile pour identifier la latence du proxy d'API Apigee par rapport à la latence globale de vos requêtes de proxy d'API.

Types de ressources Proxy
Métrique proxy/latencies
Grouper par method, et tous les libellés de types de ressources Proxy
Agrégateur p99 (99e centile)
Considérations relatives aux alertes Valeur élevée du centile de latence p99.
Alert threshold Dépend du SLO de l'installation. Par exemple, pour la production, déclenchez une notification d'événement si la valeur de centile de latence p99 du proxy est de 5 secondes pendant 5 minutes.
Requête MQL du tableau de bord Cloud Monitoring :

fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/latencies'
| align delta(1m)
| every 1m
| group_by [metric.method],
    [value_latencies_percentile: percentile(value.latencies, 99)]

Latences cibles

Cas d'utilisation: utilisez la valeur target/latencies pour surveiller les latences de toutes les réponses cibles de proxy d'API à une requête. Le graphique target/latencies identifie la durée totale que met la cible du proxy d'API Apigee pour répondre à une requête. Ce temps n'inclut pas les frais du proxy d'API Apigee.

Types de ressources Cible
Métrique target/latencies
Grouper par method, centile et tous les libellés de type de ressource Target
Agrégateur p99 (99e centile)
Considérations relatives aux alertes Valeur élevée du centile de latence p99.
Alert threshold Dépend du SLO de l'installation. Par exemple, pour la production, déclenchez une notification d'événement si la valeur de centile de latence p99 cible est de 5 secondes pendant 5 minutes.
Requête MQL du tableau de bord Cloud Monitoring :

    fetch apigee.googleapis.com/Target
    | metric 'apigee.googleapis.com/target/latencies'
    | align delta(1m)
    | every 1m
    | group_by [metric.method],
        [value_latencies_percentile: percentile(value.latencies, 99)]

Base de données

Cassandra

Le service de base de données Apigee Cassandra dispose de plusieurs métriques SLI Cassandra. Ces métriques SLI peuvent fournir une surveillance complète du service Apigee Cassandra. Au minimum, il est nécessaire de surveiller l'utilisation des ressources Cassandra (processeur, mémoire et volume de disque) et la latence des requêtes de lecture et d'écriture du client pour vérifier l'état du service Cassandra.

Taux de demandes de lecture Cassandra

Cas d'utilisation : la métrique SLI Cassandra/clientrequest_rate (avec champ d'application positionné sur Lecture) fournit des informations sur le taux moyen de requêtes en lecture sur les services Cassandra à un moment donné. Cette métrique permet de comprendre les tendances au niveau des activités de requête en lecture des clients.

Types de ressources k8s_container
Métrique cassandra/clientrequest_rate
Filtrer par scope = Read et unit = OneMinuteRate
Grouper par scope, unit et toutes les étiquettes de type de ressource k8s_container
Agrégateur pondérée
Considérations relatives aux alertes Pour tout problème potentiel ou modification importante des modèles de requête des clients, par exemple, un pic ou une baisse soudaine et inattendue du taux de requêtes en lecture.
Alert threshold Aucun
Requête MQL du tableau de bord Cloud Monitoring :

fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Taux de demandes d'écriture Cassandra

Cas d'utilisation: la métrique SLI cassandra/clientrequest_rate (avec champ d'application positionné sur Ecriture) fournit des informations sur le taux moyen de requêtes d'écriture sur les services Cassandra à un moment donné. Cette métrique permet de comprendre les tendances au niveau des activités d'écriture des clients.

Types de ressources k8s_container
Métrique cassandra/clientrequest_rate
Filtrer par scope = Read et unit = OneMinuteRate
Grouper par scope, unit et toutes les étiquettes de type de ressource k8s_container
Agrégateur pondérée
Considérations relatives aux alertes Pour tout problème potentiel ou modification importante des modèles de requête des clients, par exemple, un pic ou une baisse soudaine et inattendue des requêtes d'écriture qui justifient un examen approfondi.
Alert threshold Aucune
Requête MQL du tableau de bord Cloud Monitoring :

fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Latence des demandes de lecture Cassandra

Cas d'utilisation: la métrique SLI cassandra/clientrequest_latence (avec champ d'application=lecture) fournit la latence des requêtes de lecture des services Cassandra (99e centile, 95e centile ou 75e centile). Ces métriques facilitent l'affichage des performances Cassandra et peuvent indiquer les modifications des modèles d'utilisation ou un problème qui se manifeste au fil du temps.

Types de ressources k8s_container
Métrique cassandra/clientrequest_latency
Filtrer par scope = Read et unit = 99thPercentile
Grouper par scope, unit et toutes les étiquettes de type de ressource k8s_container
Agrégateur pondérée
Considérations relatives aux alertes Si le SLI de latence des requêtes de lecture affiche systématiquement le 99e centile de latence comme étant à la hausse.
Alert threshold Dépend de votre SLO pour les services Cassandra. Par exemple, en production, déclenchez une notification d'événement si la valeur de clientrequest_latency du 99e centile est de 5 secondes pendant 3 minutes.
Requête MQL du tableau de bord Cloud Monitoring :

fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Latence des demandes d'écriture Cassandra

Cas d'utilisation: la métrique SLI cassandra/clientrequest_latency (avec champ d'application=écriture) fournit la latence des requêtes d'écriture des services Cassandra (99e centile, 95e centile ou 75e centile). Ces métriques facilitent l'affichage des performances Cassandra et peuvent indiquer les modifications des modèles d'utilisation ou un problème qui se manifeste au fil du temps.

Types de ressources k8s_container
Métrique cassandra/clientrequest_latency
Filtrer par scope = Write et unit = 99thPercentile
Grouper par scope, unit et toutes les étiquettes de type de ressource k8s_container
Agrégateur pondérée
Considérations relatives aux alertes Si le SLI de latence des requêtes d'écriture affiche systématiquement la latence du 99e centile comme étant toujours en hausse.
Alert threshold Dépend de votre SLO pour les services Cassandra. Par exemple, en production, déclenchez une notification d'événement si la valeur clientrequest_latency du 99e centile est de 5 secondes pendant 3 minutes.
Requête MQL du tableau de bord Cloud Monitoring :

fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Plan de contrôle Apigee

Les métriques SLI du service du synchronisateur Apigee fournissent le nombre de requêtes et de réponses et les latences entre le plan de contrôle Apigee et le plan d'exécution Apigee Hybrid. Les instances du synchronisateur exécutées dans le plan d'exécution doivent interroger régulièrement le plan de contrôle, télécharger les contrats et les mettre à la disposition des instances d'exécution locales.

Taux de demandes

Nombre de requêtes en amont

Cas d'utilisation: les métriques upstream/request_count indiquent le nombre de requêtes effectuées par le service du synchronisateur sur le plan de contrôle Apigee.

Types de ressources k8s_container
Métrique upstream/request_count
Filtrer par container_name = apigee-synchronizer et type = CONTRACT
Grouper par method, type, container_name et toutes les étiquettes de type de ressource k8s_container
Agrégateur pondérée
Considérations relatives aux alertes Utilisez cette option pour les anomalies de trafic, telles qu'une augmentation ou une baisse anormale du nombre de requêtes request_count.
Alert threshold Aucune
Requête MQL du tableau de bord Cloud Monitoring :

fetch k8s_container
| metric 'apigee.googleapis.com/upstream/request_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, resource.container_name],
  [value_request_count_aggregate: aggregate(value.request_count)]

Taux d'erreur

Nombre de réponses en amont

Cas d'utilisation: la métrique SLI upstream/response_count fournit le nombre de réponses reçues par le service du synchronisateur à partir du plan de contrôle Apigee. Ce graphique peut être utile pour identifier les problèmes de connectivité ou de configuration entre le plan de contrôle et le plan d'exécution Apigee hybrid.

Types de ressources k8s_container
Métrique upstream/request_count
Filtrer par method, response_type, container_name et toutes les étiquettes de type de ressource k8s_container
Grouper par
Agrégateur pondérée
Considérations relatives aux alertes Si des erreurs se produisent dans les métriques en amont/réponse_count avec des codes de réponse autres que 200 renvoyés par le plan de contrôle Apigee, un examen supplémentaire est requis pour ces erreurs.
Alert threshold Dépend de votre SLO pour les services Cassandra. Par exemple, en production, déclenchez une notification d'événement si le synchronisateur rencontre plus d'une erreur response_code toutes les trois minutes.
Requête MQL du tableau de bord Cloud Monitoring :

fetch k8s_container
| metric 'apigee.googleapis.com/upstream/response_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.response_code != '200' && metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.type, resource.container_name],
  [value_response_count_aggregate: aggregate(value.response_count)]

Infrastructure

GKE et d'autres plates-formes Kubernetes fournissent des métriques SLI au niveau du système. Les étiquettes des métriques SLI peuvent être filtrées et regroupées pour surveiller un conteneur spécifique et son utilisation des ressources. Pour surveiller l'état et la disponibilité de l'infrastructure du cluster d'exécution Apigee, un administrateur de cluster peut surveiller l'utilisation courante des conteneurs et des pods, comme le nombre de processeurs, la quantité de mémoire, de disques et de redémarrages du conteneur. Pour en savoir plus sur les métriques et les étiquettes disponibles, consultez la documentation GKE.

Le tableau suivant regroupe certains des services et des conteneurs que vous pouvez surveiller pour chaque service.

Nom du service Nom du conteneur
Cassandra apigee-cassandra
Processeur de messages (MP) apigee-runtime
Synchronisateur apigee-synchronizer
Télémétrie apigee-prometheus-app
apigee-prometheus-proxy
apigee-prometheus-agg
apigee-stackdriver-exporter

Conteneurs/Pods

Nombre de redémarrages

Cas d'utilisation : la métrique SLI kubernetes.io/container/restart_count affiche le nombre de redémarrages d'un conteneur. Ce graphique peut être utile pour déterminer si un conteneur plante ou redémarre fréquemment. Le conteneur de services spécifique peut être filtré en fonction des libellés de métriques pour une surveillance de conteneur d'un service spécifique.

Voici comment utiliser la métrique kubernetes.io/container/restart_count pour le conteneur Cassandra. Vous pouvez utiliser cette métrique pour n'importe quel conteneur du tableau ci-dessus.

Types de ressources k8s_container
Métrique kubernetes.io/container/restart_count
Filtrer par namespace_name = apigee et container_name =~ .*cassandra.*
Grouper par cluster_name, namespace_name, pod_name, container_name et tous les libellées de types de ressources k8s_container
Agrégateur pondérée
Considérations relatives aux alertes Si un conteneur redémarre fréquemment, une analyse plus approfondie est nécessaire pour en identifier la cause. Un conteneur peut redémarrer pour plusieurs raisons, par exemple OOMKilled, un disque de données saturé ou des problèmes de configuration, pour n'en nommer que quelques-uns.
Alert threshold Dépend du SLO de l'installation. Par exemple, pour la production, déclenchez une notification d'événement si un conteneur redémarre plus de cinq fois en 30 minutes.
Requête MQL du tableau de bord Cloud Monitoring :

fetch k8s_container
| metric 'kubernetes.io/container/restart_count'
| filter
  (resource.container_name =~ '.*cassandra.*'
   && resource.namespace_name == 'apigee')
| align rate(1m)
| every 1m
| group_by
  [resource.cluster_name, resource.namespace_name, resource.pod_name,
   resource.container_name],
  [value_restart_count_aggregate: aggregate(value.restart_count)]