Éléments à surveiller

Edge pour Private Cloud version 4.17.05

Généralement, dans une configuration de production, il est nécessaire d'activer les mécanismes de surveillance dans un déploiement d'Apigee Edge pour le cloud privé. Ces techniques de surveillance avertissent les administrateurs réseau (ou opérateurs) en cas d'erreur ou d'échec. Chaque erreur générée est signalée en tant qu'alerte dans Apigee Edge. Pour en savoir plus sur les alertes, consultez la page Bonnes pratiques de surveillance.

Pour plus de facilité, les composants d'Apigee sont principalement classés en deux catégories:

  • Services de serveur Java spécifiques à Apigee : serveurs de gestion, processeur de messages, serveur Qpid et serveur Postgres.
  • Services tiers : incluent Nginx Router, Apache Cassandra, Apache ZooKeeper, OpenLDAP, la base de données PostgreSQL et Qpid.

Dans un déploiement sur site d'Apigee Edge, le tableau suivant fournit un aperçu rapide des paramètres que vous pouvez surveiller:

Composant

Vérifications du système

Statistiques au niveau du processus

Vérifications au niveau de l'API

Vérification du flux de messages

Spécifique au composant

Services Java spécifiques à Apigee

Serveur de gestion

?

?

?

Processeur de messages

?

?

?

?

Serveur Qpid

?

?

?

Serveur Postgres

?

?

?

Services tiers

Apache Cassandra

?

?

Apache ZooKeeper

?

?

OpenLDAP

?

?

Base de données PostgreSQL

?

?

QPID

?

?

Routeur Nginx

?

?

?

En général, une fois Apigee Edge installé, vous pouvez effectuer les tâches de surveillance suivantes pour suivre les performances d'une installation d'Apigee Edge pour le cloud privé.

Vérifications de l'état du système

Il est très important de mesurer les paramètres d'état du système tels que l'utilisation du processeur, de la mémoire et la connectivité des ports à un niveau supérieur. Vous pouvez surveiller les paramètres suivants pour connaître les principes de base de l'état du système.

  • CPU Utilization (Utilisation du processeur) : spécifie les statistiques de base (utilisateur/système/attente d'E/S/inactivité) sur l'utilisation du processeur. Par exemple, la quantité totale de CPU utilisée par le système.
  • Free/Used Memory (Mémoire disponible/utilisée) : spécifie l'utilisation de la mémoire système en octets. Par exemple, la mémoire physique utilisée par le système.
  • Utilisation de l'espace disque : spécifie les informations du système de fichiers en fonction de l'utilisation actuelle du disque. Par exemple, l'espace disque dur utilisé par le système.
  • Load average (moyenne de la charge) : spécifie le nombre de processus en attente d'exécution.
  • Statistiques du réseau : paquets réseau et/ou octets transmis et reçus, ainsi que les erreurs de transmission concernant un composant spécifié.

Processus/Vérifications des applications

Au niveau des processus, vous pouvez afficher des informations importantes sur tous les processus en cours d'exécution. Il s'agit, par exemple, des statistiques d'utilisation de la mémoire et du processeur utilisées par un processus ou une application. Pour les processus tels que qpidd, postgres AppData, java, etc., vous pouvez surveiller les éléments suivants:

  • Identification du processus: identifiez un processus Apigee particulier. Par exemple, vous pouvez surveiller l'existence d'un processus Java du serveur Apigee.
  • Statistiques des threads: affichez les modèles de thread sous-jacents utilisés par un processus. Par exemple, vous pouvez surveiller le pic du nombre de threads et le nombre de threads pour tous les processus.
  • Utilisation de la mémoire: affichez l'utilisation de la mémoire pour tous les processus Apigee. Par exemple, vous pouvez surveiller des paramètres tels que l'utilisation de la mémoire du tas de mémoire et l'utilisation de mémoire autre que les tas de mémoire utilisée par un processus.

Vérifications au niveau de l'API

Au niveau de l'API, vous pouvez vérifier si le serveur est opérationnel pour les appels d'API fréquemment utilisés par proxy d'Apigee. Par exemple, vous pouvez effectuer une vérification de l'API sur le serveur de gestion, le routeur et le processeur de messages en appelant la commande cURL suivante:

curl http://<host>:<port>/v1/servers/self/up

Où <host> est l'adresse IP du composant Apigee Edge. Le numéro de <port> est spécifique à chaque composant Edge. Exemple :

Serveur de gestion: 8080

  • Routeur: 8081
  • Processeur de messages: 8082
  • etc.

Consultez les sections individuelles ci-dessous pour en savoir plus sur l'exécution de cette commande pour chaque composant.

Cet appel renvoie les valeurs "true" et "false". Pour de meilleurs résultats, vous pouvez également émettre des appels d'API directement sur le backend (avec lequel le logiciel Apigee interagit) afin de déterminer rapidement si une erreur existe dans l'environnement logiciel Apigee ou sur le backend.

Remarque: Pour surveiller vos proxys d'API, vous pouvez également utiliser l'état d'API d'Apigee. API Health effectue des appels planifiés à vos proxys d'API et vous informe lorsqu'ils échouent et comment. Lorsque les appels réussissent, l'état de l'API vous indique les temps de réponse et peut même vous avertir lorsque la latence des réponses est élevée. API Health peut effectuer des appels depuis différents emplacements à travers le monde pour comparer le comportement de l'API entre les régions.

Vérification du flux de messages

Vous pouvez collecter des données auprès des routeurs et des processeurs de messages sur le modèle/les statistiques de flux de messages. Vous pouvez ainsi surveiller les éléments suivants:

  • Nombre de clients actifs
  • Nombre de réponses (x10, x20, 30x, 40x et 50x)
  • Échecs de connexion

Cela vous permet de fournir des tableaux de bord pour le flux de messages de l'API. Pour en savoir plus, consultez les articles suivants:

Vérification de l'état du routeur du processeur de messages

Le routeur met en œuvre un mécanisme de vérification de l'état pour déterminer lesquels des processeurs de messages fonctionnent comme prévu. Si un processeur de messages est détecté comme étant en panne ou lent, le routeur peut automatiquement le mettre hors service. Le cas échéant, le routeur écrit un message "Mark Down" dans le fichier journal du routeur à l'emplacement /opt/apigee/var/log/edge-router/logs/system.log.

Vous pouvez surveiller le fichier journal du routeur pour y détecter ces messages. Par exemple, si le routeur désactive la rotation d'un processeur de messages, il écrit un message dans le journal sous la forme suivante:

2014-05-06 15:51:52,159 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now DISCONNECTED. handle = <MP_IP> at 1399409512159

2014-04-17 12:54:48,512 org: env: nioEventLoopGroup-2-2 INFO HEARTBEAT - HBTracker.gotResponse() : No HeartBeat detected from /<MP_IP>:<PORT> Mark Down

où /<MP_IP>:<PORT> est l'adresse IP et le numéro de port du processeur de messages.

Si, par la suite, le routeur effectue une vérification de l'état et détermine que le processeur de messages fonctionne correctement, il rétablit automatiquement sa rotation. Le routeur écrit également un message "Mark Up" dans le journal sous la forme suivante:

2014-05-06 16:07:29,054 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now CONNECTED. handle = <IP> at 1399410449054

2014-04-17 12:55:06,064 org: env: nioEventLoopGroup-4-1 INFO HEARTBEAT - HBTracker.updateHB() : HeartBeat detected from /<IP>:<PORT> Mark Up