Afficher les métriques

Dans cette rubrique, nous expliquons comment afficher les métriques Apigee hybrid dans un tableau de bord Cloud Operations.

À propos de Cloud Operations

Pour en savoir plus sur les métriques, les tableaux de bord et Cloud Operations, consultez les ressources suivantes :

Activer les métriques hybrides

Avant de pouvoir envoyer des métriques hybrides à Cloud Operations, vous devez d'abord activer la collecte des métriques. Pour en savoir plus sur cette procédure, consultez Configurer la collecte de métriques.

À propos des noms et des étiquettes de métriques hybrides

Lorsque cette option est activée, le système hybride remplit automatiquement les métriques Cloud Operations. Le préfixe de nom de domaine des métriques créé par le système hybride est le suivant :

apigee.googleapis.com/

Par exemple, la métrique /proxy/request_count contient le nombre total de requêtes reçues par un proxy d'API. Le nom de la métrique dans Cloud Operations est donc le suivant :

apigee.googleapis.com/proxy/request_count

Cloud Operations vous permet de filtrer et de regrouper les données de métriques en fonction d'étiquettes. Certaines étiquettes sont prédéfinies, d'autres sont explicitement ajoutées par le système hybride. La section Métriques disponibles ci-dessous liste toutes les métriques hybrides disponibles, ainsi que toute étiquette ajoutée spécifiquement pour une métrique que vous pouvez utiliser pour filtrer et regrouper les données.

Afficher les métriques

L'exemple suivant montre comment afficher les métriques dans Cloud Operations :
  1. Ouvrez l'explorateur de métriques Monitoring dans un navigateur. Si vous êtes déjà dans la console Cloud Operations, sélectionnez Explorateur de métriques.

  2. Dans Rechercher un type de ressource et une métrique, localisez et sélectionnez la métrique que vous souhaitez examiner. Choisissez une métrique spécifique figurant dans la liste Métriques disponibles, ou recherchez une métrique.

  3. Sélectionnez la métrique souhaitée.
  4. Appliquez des filtres. Les choix de filtre pour chaque métrique sont listés dans Métriques disponibles.
  5. Cloud Operations affiche le graphique pour la métrique sélectionnée.
  6. Cliquez sur Enregistrer.

Créer un tableau de bord

Les tableaux de bord vous permettent d'afficher et d'analyser les données de métrique qui sont importantes pour vous. Cloud Operations propose des tableaux de bord prédéfinis pour les ressources et services que vous utilisez. Vous pouvez également créer des tableaux de bord personnalisés.

Vous utilisez un graphique pour afficher une métrique Apigee dans votre tableau de bord personnalisé. Les tableaux de bord personnalisés vous donnent un contrôle total sur les graphiques affichés et sur leur configuration. Pour en savoir plus sur la création de graphiques, consultez Créer des graphiques.

L'exemple suivant montre comment créer un tableau de bord dans Cloud Operations et ajouter des graphiques pour afficher les données de métriques :

  1. Ouvrez l'explorateur de métriques Monitoring dans un navigateur, puis sélectionnez Tableaux de bord.
  2. Sélectionnez + Créer un tableau de bord.
  3. Donnez un nom au tableau de bord. Par exemple : Trafic de requête de proxy hybride
  4. Cliquez sur Confirmer.

  5. Pour chaque graphique que vous souhaitez ajouter à votre tableau de bord, procédez comme suit :

    1. Dans le tableau de bord, sélectionnez Ajouter un graphique.
    2. Sélectionnez la métrique souhaitée, comme décrit ci-dessus dans Afficher les métriques.
    3. Renseignez la boîte de dialogue pour définir votre graphique.
    4. Cliquez sur Enregistrer. Cloud Operations affiche les données de la métrique sélectionnée.

Métriques disponibles

Les tableaux suivants listent les métriques pour l'analyse du trafic de proxy. Pour en savoir plus sur chaque métrique Apigee, consultez Métriques Google Cloud.

Métriques sur le trafic du proxy, de la cible et du serveur

OpenTelementry collecte et traite les métriques (comme décrit dans Collecte de métriques) pour le trafic du proxy, de la cible et du serveur.

Le tableau suivant décrit les métriques utilisées par le collecteur OpenTelemetry.

Nom de la métrique Utilisation
/proxy/request_count Nombre de requêtes adressées au proxy Apigee depuis l'enregistrement du dernier échantillon.
/proxy/response_count Nombre de réponses envoyées par le proxy d'API Apigee.
/proxy/latencies Répartition des latences, qui sont calculées entre le moment où la requête a été reçue par le proxy Apigee et le moment où la réponse a été envoyée depuis le proxy Apigee vers le client.
/proxyv2/request_count Nombre total de requêtes de proxy d'API reçues.
/proxyv2/response_count Nombre total de réponses de proxy d'API reçues.
/proxyv2/latencies_percentile Centile de toutes les réponses de stratégie d'API à une requête.
/target/request_count Nombre de requêtes envoyées à la cible Apigee depuis l'enregistrement du dernier échantillon.
/target/response_count Nombre de réponses reçues de la cible Apigee depuis l'enregistrement du dernier échantillon.
/target/latencies Répartition des latences, qui sont calculées entre le moment où la requête a été envoyée à la cible Apigee et le moment où la réponse a été reçue par le proxy Apigee. Ce temps n'inclut pas les frais généraux du proxy d'API Apigee.
/targetv2/request_count Nombre total de requêtes envoyées à la cible du proxy.
/targetv2/response_count Nombre total de réponses reçues de la cible du proxy.
/server/fault_count

Nombre total d'erreurs pour l'application de serveur.

Par exemple, il peut s'agir d'une application apigee-runtime, apigee-synchronizer ou apigee-udca. Utilisez l'étiquette pod_name pour filtrer les résultats par application.

/server/nio Il s'agit d'une métrique de jauge qu'il est possible de filtrer par l'étiquette state pour récupérer des informations détaillées sur différentes étiquettes. Les valeurs représentent différentes opérations système et d'E/S. Les étiquettes telles que accepted, accepted_total, close_failed, close_success, conn_pending, connected, connected_total, max_conn et timeouts sont liées aux opérations de socket et de connexion. Les autres étiquettes concernent d'autres opérations système.
/server/num_threads Nombre de threads non-daemon actifs sur le serveur.
/server/request_count

Nombre total de requêtes reçues par l'application de serveur.

Par exemple, il peut s'agir d'une application apigee-runtime, apigee-synchronizer ou apigee-udca. Utilisez l'étiquette pod_name pour filtrer les résultats par application.
/server/response_count

Nombre total de réponses envoyées par l'application de serveur.

Par exemple, il peut s'agir d'une application apigee-runtime, apigee-synchronizer ou apigee-udca. Utilisez l'étiquette pod_name pour filtrer les résultats par application.
/server/latencies

La latence correspond à la latence en millisecondes introduite par l'application de serveur.

Par exemple, il peut s'agir d'une application apigee-runtime, apigee-synchronizer ou apigee-udca. Utilisez l'étiquette pod_name pour filtrer les résultats par application.
/upstream/request_count

Nombre de requêtes envoyées par l'application de serveur à son application en amont.

Par exemple, pour apigee-synchronizer, le plan de contrôle est en amont. Ainsi, upstream/request_count pour apigee-synchronizer est une métrique qui indique les requêtes que apigee-synchronizer a envoyées au plan de contrôle.
/upstream/response_count

Nombre de réponses reçues par l'application de serveur de son application en amont.

Par exemple, pour apigee-synchronizer, le plan de contrôle est en amont. Ainsi, upstream/response_count pour apigee-synchronizer est une métrique qui indique les requêtes que apigee-synchronizer reçoit du plan de contrôle.
/upstream/latencies

Latence engendrée par l'application de serveur en amont, en millisecondes.

Par exemple, pour apigee-synchronizer, le plan de contrôle est en amont. Ainsi, upstream/latencies pour apigee-synchronizer est une métrique qui indique la latence observée à partir du plan de contrôle.

Métriques UDCA

OpenTelemetry collecte et traite les métriques (comme décrit dans Collecte de métriques) pour le service UDCA comme il le fait pour d'autres services hybrides.

Le tableau suivant décrit les métriques que le collecteur OpenTelemetry utilise dans les données de métriques UDCA.

Nom de la métrique Utilisation
/udca/server/local_file_oldest_ts

Code temporel (en millisecondes), depuis le début de l'epoch Unix, pour le fichier le plus ancien dans l'ensemble de données.

Cette valeur est calculée toutes les 60 secondes et ne reflète pas l'état en temps réel. Si l'UDCA est à jour et qu'aucun fichier n'est en attente d'importation lors du calcul de cette métrique, la valeur est 0.

Si cette valeur augmente continuellement, cela signifie que les anciens fichiers sont encore sur le disque.
/udca/server/local_file_latest_ts

Code temporel (en millisecondes), depuis le début de l'epoch Unix, pour le dernier fichier sur le disque par état.

Cette valeur est calculée toutes les 60 secondes et ne reflète pas l'état en temps réel. Si l'UDCA est à jour et qu'aucun fichier n'est en attente d'importation lors du calcul de cette métrique, la valeur est 0.
/udca/server/local_file_count

Décompte du nombre de fichiers sur disque dans le pod de collecte de données.

Dans l'idéal, la valeur sera proche de 0. Une valeur élevée constante indique que les fichiers ne sont pas importés ou que l'UDCA ne peut pas les importer assez rapidement.

Cette valeur est calculée toutes les 60 secondes et ne reflète pas l'état de l'UDCA en temps réel.
/udca/server/total_latencies

Intervalle de temps entre la création du fichier de données et l'achèvement de son importation, en secondes.

Les buckets seront de 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s et 64 s.

Histogramme de la latence totale entre la création du fichier et l'importation.
/udca/server/upload_latencies

Durée totale d'importation d'un fichier de données par l'UDCA, en secondes.

Les buckets seront de 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s et 64 s.

Les métriques affichent un histogramme pour la latence totale d'importation, ce qui inclut tous les appels en amont.
/udca/upstream/http_error_count

Nombre total d'erreurs HTTP rencontrées par l'UDCA. Cette métrique est utile pour déterminer quelle partie des dépendances externes de l'UDCA présente une défaillance et pour en identifier la raison.

Ces erreurs peuvent se produire pour divers services (getDataLocation, Cloud storage, Token generator) et pour divers ensembles de données (tels que api et trace) avec différents codes de réponse.
/udca/upstream/http_latencies

Latence des services en amont, en secondes.

Les buckets seront de 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s et 64 s.

Histogramme pour la latence des services en amont.
/udca/upstream/uploaded_file_sizes

Taille du fichier importé dans les services Apigee, en octets.

Les buckets seront de 1 Ko, 10 Ko, 100 Ko, 1 Mo, 10 Mo, 100 Mo et 1 Go.

Histogramme de la taille du fichier par ensemble de données, organisation et environnement.
/udca/upstream/uploaded_file_count Nombre de fichiers importés par l'UDCA dans les services Apigee.

Remarques :

  • La valeur correspondant à l'ensemble de données event doit continuer à augmenter.
  • La valeur correspondant à l'ensemble de données api doit continuer à augmenter si le trafic est constant pour l'organisation/environnement.
  • La valeur correspondant à l'ensemble de données trace doit augmenter lorsque vous utilisez les outils Apigee Trace pour déboguer ou inspecter vos requêtes.
/udca/disk/used_bytes

Espace occupé par les fichiers de données sur le disque du pod de collecte de données, en octets.

Augmentation de cette valeur dans le temps :

  • ready_to_upload implique que l'agent est en retard.
  • failed implique que les fichiers s'accumulent sur le disque et qu'ils ne sont pas importés. Cette valeur est calculée toutes les 60 secondes.
/udca/server/pruned_file_count Nombre de fichiers qui ont été supprimés, car leur durée de vie (valeur TTL) était dépassée. L'ensemble de données peut inclure des API, des traces et d'autres composants. L'état peut être UPLOADED, FAILED ou DISCARDED.
/udca/server/retry_cache_size

Nombre de fichiers, par ensemble de données, que l'UDCA retente d'importer.

Après trois tentatives pour chaque fichier, l'UDCA déplace le fichier dans le sous-répertoire /failed et le supprime de ce cache. L'augmentation de cette valeur dans le temps implique que le cache n'est pas effacé, ce qui se produit lorsque des fichiers sont déplacés dans le sous-répertoire /failed après trois tentatives.

Métriques Cassandra

OpenTelementry collecte et traite les métriques (comme décrit dans Collecte de métriques) pour Cassandra comme il le fait pour d'autres services hybrides.

Le tableau suivant décrit les métriques que le collecteur OpenTelemetry utilise dans les données de métriques Cassandra.

Nom de la métrique (hors domaine) Utilisation
/cassandra/process_max_fds Nombre maximal de descripteurs de fichiers ouverts.
/cassandra/process_open_fds Descripteurs de fichiers ouverts.
/cassandra/jvm_memory_pool_bytes_max Utilisation maximale de la mémoire de la machine virtuelle Java pour le pool.
/cassandra/jvm_memory_pool_bytes_init Utilisation initiale de la mémoire de la machine virtuelle Java pour le pool.
/cassandra/jvm_memory_bytes_max Utilisation maximale de la mémoire du tas de mémoire de la machine virtuelle Java.
/cassandra/process_cpu_seconds_total Temps CPU utilisateur et système en secondes.
/cassandra/jvm_memory_bytes_used Utilisation de la mémoire du tas de mémoire de la machine virtuelle Java.
/cassandra/compaction_pendingtasks Compactages exceptionnels pour les sstables Cassandra. Pour en savoir plus, consultez Compactage.
/cassandra/jvm_memory_bytes_init Utilisation initiale de la mémoire du tas de mémoire de la machine virtuelle Java.
/cassandra/jvm_memory_pool_bytes_used Utilisation de la mémoire du pool JVM.
/cassandra/jvm_memory_pool_bytes_committed Utilisation sur engagement de la mémoire du pool JVM.
/cassandra/clientrequest_latency Latence de la requête de lecture dans la plage du 75e centile, en microsecondes.
/cassandra/jvm_memory_bytes_committed Utilisation sur engagement de la mémoire du tas de mémoire de la machine virtuelle Java.

Utiliser les métriques Cassandra

Apigee recommande de considérer les métriques suivantes comme essentielles à la surveillance de votre base de données Cassandra :

  • Taux de requêtes Cassandra : utilisez cette métrique pour surveiller le taux de requêtes de lecture et d'écriture Cassandra.
    Métrique : apigee.googleapis.com/cassandra/clientrequest_latency
    Étiquettes de ressource : project_id, location, cluster_name, namespace_name, pod_name, container_name
    Étiquettes de métriques : scope, unit

    Utilisez ces étiquettes pour filtrer la ressource spécifique ou pour le regroupement.

    Pour surveiller le taux de requêtes de lecture Cassandra, appliquez le filtrage suivant.

    Filtres : metric.scope == 'Read'
    metric.unit == 'OneMinuteRate'

    Pour surveiller le taux de requêtes d'écriture Cassandra, appliquez le filtrage suivant.

    Filtres : metric.scope == 'Write'
    metric.unit == 'OneMinuteRate'
  • Latence des requêtes Cassandra : utilisez cette métrique pour surveiller la latence des requêtes de lecture et d'écriture Cassandra. Il s'agit de la même métrique que pour le taux de requêtes, apigee.googleapis.com/cassandra/clientrequest_latency avec l'application de filtres différents.

    Pour surveiller la latence des requêtes de lecture Cassandra, appliquez le filtrage suivant.

    Filtres : metric.scope == 'Read'
    metric.unit == '99thPercentile' ou '95thPercentile' ou '75thPercentile'

    Pour surveiller la latence des requêtes d'écriture Cassandra, appliquez le filtrage suivant.

    Filtres : metric.scope == 'Write'
    metric.unit == '99thPercentile' ou '95thPercentile' ou '75thPercentile'
  • Utilisation des requêtes par le processeur du pod Cassandra
    Métrique : kubernetes.io/container/cpu/request_utilization (GKE on Google Cloud)

    Pour en savoir plus, consultez Métriques Kubernetes.

    kubernetes.io/anthos/container/cpu/request_utilization (Google Distributed Cloud)
    Étiquettes de ressource : project_id, location, cluster_name, namespace_name, pod_name, container_name

    Utilisez ces étiquettes pour filtrer la ressource spécifique ou pour le regroupement.

  • Utilisation du volume de données Cassandra
    Métrique : kubernetes.io/pod/volume/utilization (GKE on Google Cloud)

    Pour en savoir plus, consultez Métriques Kubernetes.

    kubernetes.io/anthos/pod/volume/utilization (Google Distributed Cloud)
    Étiquettes de ressource : project_id, location, cluster_name, namespace_name, pod_name
    Étiquettes de métriques : volume_name

    Utilisez ces étiquettes pour filtrer la ressource spécifique ou pour le regroupement.

Recommandations pour le scaling du cluster Cassandra

Dans le cas de figure suivant, vous devriez envisager de procéder à un scaling de votre cluster Cassandra. En général, si les requêtes de lecture ou d'écriture présentent systématiquement une latence au 99e centile ou que la latence augmente en continu, et que cela se manifeste par des pics dans l'utilisation des ressources de processeur demandées et dans les taux de requêtes de lecture ou d'écriture, votre cluster Cassandra peut être considéré comme étant sous pression. Vous pouvez en pareil cas envisager d'augmenter la capacité du cluster. Pour en savoir plus, consultez Scaling de Cassandra.

MétriqueSeuilDurée du déclencheur
kubernetes.io/pod/volume/utilization85 %5 min
kubernetes.io/container/cpu/request_utilization85 %3 min
Read request Latency 99thPercentile5 s3 min
Write request Latency 99thPercentile5 s3 min