Consignes concernant la surveillance des clusters

Version 1.13 (latest)

   Versions compatibles :

• v1.13 (la plus récente)
• v1.12
• v1.11                         
• Liste des versions compatibles

   Versions non compatibles :

• v1.10
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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 :

Remarque : La surveillance du trafic des API est identique pour les clusters Apigee X et Apigee hybrid. Les utilisateurs d'Apigee X ont accès aux métriques SLI concernant le trafic des API telles que le proxy, la cible et la règle dans le projet Google Cloud de l'organisation, et peuvent utiliser ces métriques SLI pour la surveillance et les alertes.

Conseil : En règle générale, les tableaux de bord "Taux de demandes" sont utiles seuls pour visualiser le modèle de trafic. Ajouter un seuil d'alerte uniquement pour les métriques SLI concernant le taux de demandes peut s'avérer difficile, sauf si le modèle/le volume de trafic est prédéterminé. Toutefois, un graphique de taux de requêtes peut fournir des informations utiles sur les pics ou baisses anormaux de trafic lors du débogage de tout problème lié au trafic (lecture, écriture, code de réponse, etc.).

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'erreur

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 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	request_count ou une baisse anormale des alertes.
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)]