Cet article explique comment afficher les métriques hybrides Apigee dans un tableau de bord Stackdriver.
À propos de Stackdriver
Pour en savoir plus sur les métriques, les tableaux de bord et Stackdriver, consultez les pages suivantes :
Activer les métriques hybrides
Avant de pouvoir envoyer des métriques hybrides à Stackdriver, vous devez d'abord activer la collecte des métriques. Pour en savoir plus sur cette procédure, consultez la section Configurer la collecte de métriques.
À propos des noms et des libellés de métriques hybrides
Lorsque cette option est activée, le système hybride renseigne automatiquement les métriques Stackdriver. 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 Stackdriver est donc le suivant :
apigee.googleapis.com/proxy/request_count
Stackdriver vous permet de filtrer et de regrouper les données de métriques en fonction des libellés. Certains libellés sont prédéfinis, d'autres sont explicitement ajoutés par le système hybride. La section Métriques disponibles ci-dessous répertorie toutes les métriques hybrides disponibles, ainsi que tout libellé ajouté spécifiquement pour une métrique que vous pouvez utiliser pour filtrer et regrouper.
Afficher les métriques
L'exemple suivant montre comment afficher les métriques dans Stackdriver :- Ouvrez l'explorateur de métriques Monitoring dans un navigateur. Si vous êtes déjà dans la console Stackdriver, sélectionnez Explorateur de métriques.
Dans Find resource type and metric (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 répertoriée dans la section Métriques disponibles, ou recherchez une métrique. Par exemple, recherchez
proxy/latencies:
- Sélectionnez la métrique souhaitée.
- Appliquez les filtres. Les choix de filtre pour chaque métrique sont répertoriés dans la section Métriques disponibles.
Par exemple, pour la métrique
proxy_latencies, les choix de filtre sont les suivants : org=org_name. - Stackdriver affiche le graphique pour la métrique sélectionnée.
- 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. Stackdriver fournit des tableaux de bord prédéfinis pour les ressources et services que vous utilisez, et 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 donne un contrôle total sur les graphiques affichés et sur leur configuration. Pour en savoir plus sur la création de graphiques, consultez la page Créer des graphiques.
L'exemple suivant montre comment créer un tableau de bord dans Stackdriver, puis ajouter des graphiques pour afficher les données de métrique :
- Ouvrez l'explorateur de métriques Monitoring dans un navigateur, puis sélectionnez Tableaux de bord.
- Sélectionnez + Créer un tableau de bord.
- Donnez un nom au tableau de bord. Par exemple : Trafic de requête de proxy hybride
- Cliquez sur Confirmer.
Pour chaque graphique que vous souhaitez ajouter à votre tableau de bord, procédez comme suit :
- Dans le tableau de bord, sélectionnez Ajouter un graphique.
- Sélectionnez la métrique souhaitée, comme décrit ci-dessus dans Afficher les métriques.
- Renseignez la boîte de dialogue pour définir votre graphique.
- Cliquez sur Enregistrer. Stackdriver affiche les données de la métrique sélectionnée.
Métriques disponibles
Les tableaux suivants répertorient les métriques pour l'analyse du trafic de proxy.
Métriques sur le trafic de proxy, de cible et de serveur
Le service Prometheus collecte et traite les métriques (comme décrit dans la section Collection de métriques) pour le trafic du proxy, de la cible et du serveur.
Le tableau suivant décrit les métriques et les libellés utilisés par Prometheus. Ces libellés sont utilisés dans les entrées de journal des métriques.
| Nom de la métrique | Libellé | Utilisation |
|---|---|---|
/proxy/request_count |
method |
Nombre total de requêtes de proxy d'API reçues. |
/proxy/response_count |
method
response_code |
Nombre total de réponses de proxy d'API reçues. |
/proxy/latencies |
method |
Nombre total de millisecondes nécessaire pour répondre à un appel. Ce temps inclut les frais du proxy d'API Apigee et l'heure du serveur cible. |
/target/request_count |
method
|
Nombre total de requêtes envoyées à la cible du proxy. |
/target/response_count |
method
|
Nombre total de réponses reçues de la cible du proxy. |
/target/latencies |
method
|
Nombre total de millisecondes nécessaire pour répondre à un appel. Ce temps n'inclut pas les frais du proxy d'API Apigee. |
/policy/latencies |
policy_name |
Nombre total de millisecondes nécessaire pour exécuter cette règle nommée. |
/server/fault_count |
source |
Nombre total d'erreurs pour l'application de serveur. Par exemple, il peut s'agir d'une application |
/server/nio |
state |
Nombre de sockets ouverts. |
/server/num_threads |
Nombre de threads non-daemon actifs sur le serveur. | |
/server/request_count |
method
|
Nombre total de requêtes reçues par l'application de serveur. Par exemple, il peut s'agir d'une application |
/server/response_count |
method
|
Nombre total de réponses envoyées par l'application de serveur. Par exemple, il peut s'agir d'une application |
/server/latencies |
method
|
La latence correspond à la latence en millisecondes introduite par l'application de serveur. Par exemple, il peut s'agir d'une application |
/upstream/request_count |
method
|
Nombre de requêtes envoyées par l'application serveur à son application en amont. Par exemple, pour |
/upstream/response_count |
method
|
Nombre de réponses reçues par l'application serveur de son application en amont. Par exemple, pour |
/upstream/latencies |
method
|
Latence engendrée par l'application serveur en amont, en millisecondes. Par exemple, pour |
Métriques UDCA
Le service Prometheus collecte et traite les métriques (comme décrit dans la section Collection de métriques) pour le service UDCA comme il le fait pour d'autres services hybrides.
Le tableau suivant décrit les métriques et les libellés utilisés par Prometheus dans les données de métrique UDCA. Ces libellés sont utilisés dans les entrées de journal des métriques.
| Nom de la métrique | Libellé | Utilisation |
|---|---|---|
/udca/server/local_file_oldest_ts |
dataset
|
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 continue d'augmenter, cela signifie que les anciens fichiers sont encore sur le disque. |
/udca/server/local_file_latest_ts |
dataset
|
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 |
dataset
|
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 cohérente 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 |
dataset |
Intervalle de temps (en secondes) entre la création du fichier de données et l'importation du fichier de données. 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. L'histogramme de la latence totale entre la création du fichier et l'importation. |
/udca/server/upload_latencies |
dataset |
Durée totale (en secondes) d'importation d'un fichier de données par l'UDCA. 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, y compris tous les appels en amont. |
/udca/upstream/http_error_count |
service
|
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 échoue et pour en identifier la raison. Ces erreurs peuvent se produire pour divers services (
|
/udca/upstream/http_latencies |
service
|
Latence en amont des services, 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 |
dataset |
Taille, en octets, du fichier importé dans les services Apigee. 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 |
dataset |
Nombre de fichiers importés par l'UDCA dans les services Apigee. Remarques :
|
/udca/disk/used_bytes |
dataset
|
Espace occupé par les fichiers de données sur le disque du pod de collecte de données, en octets. Augmentation de cette valeur au fil du temps :
|
/udca/server/pruned_file_count |
dataset
|
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 |
dataset |
Nombre de fichiers, par ensemble de données, que l'UDCA tente d'importer. Après trois tentatives pour chaque fichier, l'UDCA déplace le fichier dans le sous-répertoire |
Métriques Cassandra
Le service Prometheus collecte et traite les métriques (comme décrit dans la section Collection de métriques) pour Cassandra comme il le fait pour d'autres services hybrides.
Le tableau suivant décrit les métriques et les libellés utilisés par Prometheus dans les données de métriques Cassandra. Ces libellés sont utilisés dans les entrées de journal des métriques.
| Nom de la métrique (hors domaine) | Libellé | 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 |
pool |
Utilisation maximale de la mémoire de la machine virtuelle Java pour le pool. |
/cassandra/jvm_memory_pool_bytes_init |
pol |
Utilisation initiale de la mémoire de la machine virtuelle Java pour le pool. |
/cassandra/jvm_memory_bytes_max |
area |
Utilisation maximale de la mémoire du tas de mémoire JVM. |
/cassandra/process_cpu_seconds_total |
Temps CPU utilisateur et système en secondes. | |
/cassandra/jvm_memory_bytes_used |
area |
Utilisation de la mémoire du tas de mémoire JVM. |
/cassandra/compaction_pendingtasks |
unit |
Compactages exceptionnels pour les sstables Cassandra. Pour en savoir plus, consultez la section Compactage. |
/cassandra/jvm_memory_bytes_init |
area |
Utilisation de la mémoire initiale du tas de mémoire JVM. |
/cassandra/jvm_memory_pool_bytes_used |
pool |
Utilisation de la mémoire du pool JVM. |
/cassandra/jvm_memory_pool_bytes_committed |
pool |
Utilisation de la mémoire sur engagement du pool JVM. |
/cassandra/clientrequest_latency |
scope
|
Latence de la requête de lecture dans la plage du 75e centile en microsecondes. |
/cassandra/jvm_memory_bytes_committed |
area |
Utilisation de la mémoire sur engagement du tas de mémoire JVM. |