Edge pour Private Cloud version 4.17.01
Ce document décrit les techniques de surveillance des composants compatibles avec un déploiement sur site d'Apigee Edge.
Activer JMX
JMX est activé par défaut pour Cassandra et désactivé par défaut pour tous les autres composants Edge. Vous devez donc activer JMX individuellement pour chaque composant.
Chaque composant est compatible avec JMX sur un port différent. Le tableau suivant répertorie le port JMX et le fichier que vous modifiez pour activer JMX sur ce port:
Composant | Port JMX | Fichier |
---|---|---|
Serveur de gestion | 1099 | /opt/apigee/edge-management-server/bin/start |
Processeur de messages | 1101 | /opt/apigee/edge-mesage-processor/bin/start |
QPID | 1102 | /opt/apigee/edge-qpid-server/bin/start |
Postgres | 1103 | /opt/apigee/edge-postgres-server/bin/start |
Par exemple, pour activer JMX sur le serveur de gestion, ouvrez /opt/apigee/edge-management-server/bin/start dans un éditeur. La ligne suivante doit s'afficher pour démarrer le serveur de gestion:
exec $JAVA -classpath "$classpath" -Xms$min_mem -Xmx$max_mem $xx_opts -Djava.security.auth.login.config=$conf_path/jaas.config -Dinstallation.dir=$install_dir $sys_props -Dconf.dir=$conf_path -Ddata.dir=$data_dir $* $debug_options com.apigee.kernel.MicroKernel
Modifiez cette ligne pour ajouter ce qui suit:
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
Notez que cette ligne spécifie le numéro de port JMX 1099 pour le serveur de gestion. Définissez le numéro de port de chaque composant, tel que défini dans le tableau ci-dessus. Exemple :
exec $JAVA -classpath "$classpath" -Xms$min_mem -Xmx$max_mem $xx_opts -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.security.auth.login.config=$conf_path/jaas.config -Dinstallation.dir=$install_dir $sys_props -Dconf.dir=$conf_path -Ddata.dir=$data_dir $* $debug_options com.apigee.kernel.MicroKernel
Enregistrez le fichier, puis redémarrez le composant. Par exemple, pour redémarrer le serveur de gestion:
> /opt/apigee/apigee-service/bin/ apigee-service edge-management-server restart
Activer l'authentification JMX et définir le mot de passe JMX
Le processus de surveillance du serveur de gestion, du processeur de messages, de Qpid et de Postgres utilise tous JMX. JMX est activé par défaut et l'accès à distance JMX ne nécessite pas de mot de passe.
Pour activer l'authentification JMX, chaque composant dispose d'une action change_jmx_auth qui vous permet d'activer ou de désactiver l'authentification et de définir les identifiants JMX.
Pour activer l'authentification JMX, utilisez la commande suivante:
> /opt/apigee/apigee-service/bin/apigee-service comp change_jmx_auth optionsOrConfigFile
où :
- comp est edge-management-server, Edge-message-processor, Edge-qpid-server ou Edge-postgres-server.
- Les options sont les suivantes :
- -u: nom d'utilisateur
- -p: mot de passe
- -e: y (activer) ou n (dsiable)
- Le fichier de configuration inclut les éléments suivants :
- JMX_USERNAME=nom d'utilisateur
- JMX_ACTIVÉ=o/n
- JMX_PASSWORD=password (s'il n'est pas défini ou n'est pas transmis avec -p, vous êtes invité à le faire)
Par exemple, pour utiliser les options sur la ligne de commande:
> /opt/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -u foo -p bar -e y
Si vous disposez d'un fichier de configuration:
> /opt/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -f configFile
Si vous exécutez Edge sur plusieurs nœuds, exécutez cette commande sur tous les nœuds, en spécifiant les mêmes nom d'utilisateur et mot de passe.
Pour désactiver ultérieurement l'authentification JMX, utilisez la commande suivante:
> /opt/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -e n
Serveur de gestion
Surveiller la vérification de l'état du système et les informations de traitement à l'aide de JConsole
Utilisez JConsole (un outil conforme à JMX) pour gérer et surveiller les vérifications d'état et les statistiques de processus. À l'aide de JConsole, vous pouvez utiliser les statistiques JMX exposées par Management Server (ou tout serveur) et les afficher dans une interface graphique. Pour en savoir plus sur l'utilisation de JConsole, consultez la page http://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html.
Utilisez JConsole et l'URL de service suivante pour surveiller les attributs JMX (MBeans) proposés via JMX.
service:jmx:rmi:///jndi/rmi://<ip address>:<port>/jmxrmi
où <ip address> est l'adresse IP du serveur de gestion (ou du serveur correspondant). Par défaut, le port est 1099 pour le serveur de gestion.
Le tableau suivant présente les statistiques JMX génériques:
JMX MBeans |
Attributs JMX |
---|---|
Mémoire |
HeapMemoryUsage |
NonHeapMemoryUsage |
|
Utilisation |
|
Remarque:Les valeurs d'attribut s'affichent dans quatre valeurs : "commit", "init", "max" et "used". |
Utiliser les vérifications de l'API Edge Application
Vous pouvez effectuer une vérification de l'API sur le serveur de gestion (ou tout autre serveur) en appelant la commande CURL suivante:
curl http://<host>:8080/v1/servers/self/up
Où <host> est l'adresse IP du serveur de gestion.
Cet appel renvoie les valeurs "true" et "false". Si la valeur est "true", cela signifie que le nœud est opérationnel et que le service Java est en cours d'exécution.
Si vous ne recevez pas de réponse HTTP 200 (OK), Edge ne peut pas répondre aux requêtes sur le port 8080.
Dépannage
- Connectez-vous au serveur et exécutez la commande suivante:
/opt/apigee/apigee-service/bin/apigee-service Edge-management-server status - Si le service n'est pas en cours d'exécution, démarrez-le:
/opt/apigee/apigee-service/bin/apigee-service Edge-management-server start
Utilisation d'une application de périphérie : vérifications des utilisateurs, de l'organisation et du déploiement
Management Server joue un rôle essentiel pour rassembler tous les autres colis dans chaque installation sur site. Vous pouvez vérifier l'état de l'utilisateur, de l'organisation et du déploiement sur le serveur de gestion à l'aide des commandes suivantes:
curl -u userEmail:password http://localhost:8080/v1/users curl -u userEmail:password http://localhost:8080/v1/organizations curl -u userEmail:password http://localhost:8080/v1/organizations/orgname/deployments
Le système doit afficher l'état "déployé" pour tous les appels. En cas d'échec, procédez comme suit:
- Recherchez d'éventuelles erreurs dans les journaux du serveur de gestion (à l'adresse opt/apigee/var/log/edge-management-server).
- Appelez le serveur de gestion pour vérifier s'il fonctionne correctement.
- Supprimez le serveur de l'ELB, puis redémarrez le serveur de gestion.
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
Routeur
Vous pouvez effectuer une vérification de l'API sur le routeur (ou n'importe quel serveur) en appelant la commande CURL suivante:
curl http://<host>:8081/v1/servers/self/up
Où, hôte est l'adresse IP du routeur.
Cet appel renvoie les valeurs "true" et "false". Si la valeur est "true", cela signifie que le nœud est opérationnel et que le service de routeur est en cours d'exécution.
Si vous ne recevez pas de réponse HTTP 200 (OK), Edge ne pourra pas répondre aux requêtes sur le port 8081.
Dépannage
- Connectez-vous au serveur et exécutez les commandes suivantes:
/<inst_root>/apigee/apigee-service/bin/apigee-service Edge-router status - Si le service n'est pas en cours d'exécution, démarrez-le
/<inst_root>/apigee/apigee-service/bin/apigee-service Edge-router start - Après le redémarrage, vérifiez qu'il fonctionne.
curl -v http://localhost:port/v1/servers/self/up
Où port correspond à 8081 pour le routeur et 8082 pour le processeur de messages.
Processeur de messages
Surveiller la vérification de l'état du système et les informations de traitement à l'aide de JConsole
Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.
Remarque: Veillez à utiliser le port 1101.
Utiliser les vérifications de l'API Edge Application
Suivez la même procédure que celle décrite ci-dessus pour le routeur.
Remarque: Veillez à utiliser le port 8082.
Utiliser les vérifications de flux de messages JMX
Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.
Remarque: Veillez à utiliser le port 1101.
Serveur Qpid
Surveiller la vérification de l'état du système et les informations de traitement à l'aide de JConsole
Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.
Remarque: Veillez à utiliser le port 1102.
Utiliser les vérifications de l'API d'application Edge
Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.
Remarque: Veillez à utiliser le port 8083. La commande CURL suivante est également prise en charge pour le serveur Qpid:
curl http://<qpid_IP>:8083/v1/servers/self
Serveur Postgres
Surveiller la vérification de l'état du système et les informations de traitement à l'aide de JConsole
Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.
Remarque: Veillez à utiliser le port 1103.
Utiliser les vérifications de l'API d'application Edge
Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.
Remarque: Veillez à utiliser le port 8084. La commande CURL suivante est également compatible avec le serveur Postgres:
curl http://<postgres_IP>:8084/v1/servers/self
Utiliser les vérifications de l'organisation et de l'environnement des applications périphériques
Vous pouvez vérifier le nom de l'organisation et de l'environnement intégrés au serveur Postgres en exécutant les commandes CURL suivantes:
curl http:// <postgres_IP>:8084/v1/servers/self/organizations
Remarque: Veillez à utiliser le port 8084.
Le système doit afficher le nom de l'organisation et de l'environnement.
Utiliser la vérification de l'état axstatus de l'application Edge
Vous pouvez vérifier l'état des serveurs d'analyse à l'aide de la commande CURL suivante.
curl -u userEmail:password http://<host>:<port>/v1/organizations/<orgname>/environments/<envname>/provisioning/axstatus
Le système doit afficher l'état SUCCESS pour tous les serveurs d'analyse. Le résultat de la commande CURL ci-dessus est présenté ci-dessous:
{ "environments" : [ { "components" : [ { "message" : "success at Thu Feb 28 10:27:38 CET 2013", "name" : "pg", "status" : "SUCCESS", "uuid" : "[c678d16c-7990-4a5a-ae19-a99f925fcb93]" }, { "message" : "success at Thu Feb 28 10:29:03 CET 2013", "name" : "qs", "status" : "SUCCESS", "uuid" : "[ee9f0db7-a9d3-4d21-96c5-1a15b0bf0adf]" } ], "message" : "", "name" : "prod" } ], "organization" : "acme", "status" : "SUCCESS" }
Base de données PostgreSQL
Utiliser le script check_postgres.pl
Pour surveiller la base de données PostgreSQL, vous pouvez utiliser un script de surveillance standard, check_postgres.pl, disponible à l'adresse http://bucardo.org/wiki/Check_postgres.
Remarque: Le script check_postgres.pl doit être installé dans chaque nœud Postgres.
Avant d'exécuter le script:
- Assurez-vous d'avoir installé perl-Time-HiRes.x86_64, un module Perl qui implémente une alarme haute résolution, une veille, une alarme gettimeofday et un minuteur d'intervalle. Par exemple, vous pouvez l'installer à l'aide de la commande suivante:
yum install perl-Time-HiRes.x86_64
Le résultat par défaut des appels d'API utilisant le script check_postgres.pl est compatible avec Nagios. Après avoir installé le script, effectuez les vérifications suivantes:
- Taille de la base de données – Vérifiez la taille de la base de données:
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -include=apigee -action database_size --warning='800 GB' --critical='900 GB' - Connexion entrante à la base de données : vérifie le nombre de connexions entrantes à la base de données et le compare au nombre maximal de connexions autorisées :
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends - Disponibilité et performances de la base de données – vérifie si la base de données est en cours d'exécution et disponible:
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -actionconnection - Espace disque : vérifie l'espace disque :
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%' - Organisations/environnements intégrés : vérifie le nombre d'organisations et d'environnements intégrés dans un nœud Postgres :
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action=custom_query --query="select count(*) as result' from pg'warning'tables où
Remarque: Veuillez consulter http://bucardo.org/check_postgres/check_postgres.pl.html si vous avez besoin d'aide pour utiliser les commandes ci-dessus.
Vérifications de la base de données
Vous pouvez vérifier que les tables appropriées sont créées dans la base de données PostgreSQL. Connectez-vous à la base de données PostgreSQL à l'aide de la commande suivante:
psql -h /opt/apigee/var/run/apigee-postgresql/ -U apigee -d apigee
puis exécutez la commande suivante:
\d analytics."<org>.<env>.fact"
Vérifier l'état de fonctionnement du processus postgres
Vous pouvez effectuer une vérification de l'API sur la machine postgres en appelant la commande CURL suivante:
http://<postgres_IP>:8084/v1/servers/self/health/
Remarque: Veillez à utiliser le port 8084.
Elle renvoie l'état "ACTIF" lorsque le processus postgres est actif. Si le processus postgres n'est pas opérationnel, il renvoie l'état "INACTIVE".
Ressources Postgres
- http://www.postgresql.org/docs/9.0/static/monitoring.html
- http://www.postgresql.org/docs/9.0/static/diskusage.html
- http://bucardo.org/check_postgres/check_postgres.pl.html
Apache Cassandra
Utiliser JConsole : surveiller les statistiques des tâches
Utilisez JConsole et l'URL de service suivante pour surveiller les attributs JMX (MBeans) proposés via JMX.
service:jmx:rmi:///jndi/rmi://<ip address>:7199/jmxrmi
où <adresse IP> est l'adresse IP du serveur Cassandra.
JMX est activé par défaut pour Cassandra, et l'accès JMX distant à Cassandra ne nécessite aucun mot de passe.
Pour activer l'authentification JMX afin d'ajouter un mot de passe:
- Modifiez /opt/apigee/customer/application/cassandra.properties. Si le fichier n'existe pas, créez-le.
- Ajoutez le code suivant au fichier:
conf_cassandra-env_com.sun.management.jmxremote.authenticate=true - Enregistrez le fichier.
- Copiez les fichiers suivants de votre répertoire $JAVA_HOME vers
/opt/apigee/data/apigee-cassandra/:
cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmx.password
cp ${JAVA_remote.password}/lib.mx/remoteGHOME - Modifiez jmxremote.password et ajoutez le nom d'utilisateur et le mot de passe au fichier:
cassandra password
où password correspond au mot de passe JMX. - Modifiez jmxremote.access et ajoutez le rôle suivant:
cassandra readwrite - Assurez-vous que les fichiers appartiennent à "apigee" et que le mode de fichier est 400:
> chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.*
> chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.* - Exécutez configure sur Cassandra:
> /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure - Redémarrez Cassandra:
> /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
Pour désactiver l'authentification ultérieurement:
- Modifiez /opt/apigee/customer/application/cassandra.properties.
- Supprimez la ligne suivante du fichier:
conf_cassandra-env_com.sun.management.jmxremote.authenticate=true - Exécutez "Configure" sur Cassandra:
> /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure - Redémarrez Cassandra:
> /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
Statistiques Cassandra JMX
JMX MBeans |
Attributs JMX |
---|---|
ColumnFamilies/apprepo/environments ColumnFamilies/apprepo/organizations ColumnFamilies/apprepo/apiproxy_revisions ColumnFamilies/apprepo/apiproxies ColumnFamilies/audit/audits ColumnFamilies/audit/audits_ref |
PendingTasks |
MemtableColumnsCount |
|
MemtableDataSize |
|
ReadCount |
|
RecentReadLatencyMicros |
|
TotalReadLatencyMicros |
|
WriteCount |
|
RecentWriteLatencyMicros |
|
TotalWriteLatencyMicros |
|
TotalDiskSpaceUsed |
|
LiveDiskSpaceUsed |
|
LiveSSTableCount |
|
BloomFilterFalsePositives |
|
RecentBloomFilterFalseRatio |
|
BloomFilterFalseRatio |
Utiliser l'utilitaire Nodetool pour gérer les nœuds de cluster
L'utilitaire nodetool, qui est une interface de ligne de commande pour Cassandra, permet de gérer les nœuds des clusters. Vous trouverez l'utilitaire à l'adresse opt/apigee/apigee-cassandra/bin.
Pour en savoir plus sur l'utilitaire Nodetool, consultez la page http://www.datastax.com/docs/1.0/references/nodetool.
Les appels suivants peuvent être effectués sur tous les nœuds de cluster Cassandra:
- Informations générales sur l'anneau (également possibles pour un seul nœud Cassandra): recherchez les valeurs "Haut" et "Normal" pour tous les nœuds.
[host]# nodetool -h localhost ring
La sortie de la commande ci-dessus se présente comme suit:
Address DC Rack Status Load Owns Token
192.168.124.201 dc1 ra1 Up Normal 1,67 Mo 33,33% 0dc1.24 Mo - Informations générales sur les nœuds (appel par nœud)
nodetool -h localhost info
Le résultat de la commande ci-dessus se présente comme suit :
Jeton : 0
Gossip actif : true
Chargement : 1,67 Mo
Numéro de génération : 1361968765 :
Exceptions : 8 h 00 (secondes) : 78108 - État du serveur de récupération (API cliente de diffusion)
host]# nodetool -h localhost statusthrift
Le résultat de la commande ci-dessus affiche l'état "running" (exécution en cours). - État des opérations de streaming de données: Observer le trafic pour les nœuds cassandra
nodetool -h localhost netstats 192.168.124.203
Le résultat de la commande ci-dessus se présente comme suit:
Mode: NORMAL
Aucun flux vers /192.168.124.
Active 9.203 en streaming
6.203
Surveillance de Cassandra (UI)
Accédez à l'URL datastax opscenter: http://www.datastax.com/products/opscenter.
Ressource Cassandra
Consultez l'URL suivante: http://www.datastax.com/docs/1.0/operations/monitoring.
Apache ZooKeeper
Vérification de l'état de ZooKeeper
- Vérifiez que le processus ZooKeeper est en cours d'exécution. ZooKeeper écrit un fichier PID dans opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid.
- Testez les ports ZooKeeper pour vous assurer que vous pouvez établir une connexion TCP aux ports 2181 et 3888 sur chaque serveur ZooKeeper.
- Assurez-vous de pouvoir lire les valeurs de la base de données ZooKeeper. Connectez-vous à l'aide d'une bibliothèque cliente ZooKeeper (ou /opt/apigee/apigee-zookeeper/bin/zkCli.sh) et lisez une valeur dans la base de données.
- Vérifiez l'état:
> /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status
Utilisation du format de quatre lettres de ZooKeeper
ZooKeeper peut être surveillé via un petit ensemble de commandes (mots de quatre lettres) qui sont envoyées au port 2181 à l'aide de netcat (nc) ou telnet.
Pour en savoir plus sur les commandes ZooKeeper, consultez la page http://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_zkCommands.
Exemple :
- srvr: répertorie tous les détails du serveur.
- stat: fournit de brefs détails sur le serveur et les clients connectés.
Les commandes suivantes peuvent être envoyées au port ZooKeeper:
- Exécutez la commande à quatre lettres "ruok" pour vérifier si le serveur s'exécute sans erreur. Si l'opération réussit, "imok" est renvoyé.
echo ruok | nc <host> 2181
Renvoie:
imok - Exécutez la commande à quatre lettres "stat" pour obtenir la liste des performances du serveur et des statistiques sur les clients connectés.
echo stat | nc <host1> 2181
Renvoie :
Zookeeper version : 3.4.5-1392090, construit à 17:52 GMT
Clients :
/0:0:0:0:0:queue. - Si netcat (nc) n'est pas disponible, vous pouvez utiliser Python à la place. Créez un fichier nommé zookeeper.py contenant les éléments suivants :
import time, socket,
sys c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
c.connect((sys.argv[1], 2181))
python.
OpenLDAP
Test de niveau LDAP
Vous pouvez surveiller l’OpenLDAP pour voir si les requêtes spécifiques sont correctement traitées. En d'autres termes, recherchez une recherche spécifique qui renvoie le bon résultat.
- Utilisez ldapsearch (yum install openldap-clients) pour interroger l'entrée de l'administrateur système. Cette entrée permet d'authentifier tous les appels d'API.
ldapsearch: - Vérifiez si le serveur de gestion est toujours connecté au problème LDAP:
curl -u <userEMail>:<password> http://localhost:8080/v1/users/<ADMIN>
Renvoie:
{
"emailId" : <ADMIN>,
"firstName" : "admin",
"lastName" : "admin"
}
Vous pouvez également surveiller les caches OpenLDAP, qui permettent de réduire le nombre d'accès au disque et donc d'améliorer les performances du système. La surveillance, puis le réglage de la taille du cache sur le serveur OpenLDAP peuvent avoir un impact important sur les performances du serveur d'annuaire. Vous pouvez afficher les fichiers journaux (opt/apigee/var/log) pour obtenir des informations sur le cache.