Surveillance

Edge pour Private Cloud v4.18.05

Ce document décrit les techniques de surveillance des composants pris en charge par un déploiement sur site d'Apigee Edge.

Présentation

Edge propose plusieurs méthodes pour obtenir des informations sur les services et vérifier leur état. Le tableau suivant répertorie les types de vérifications que vous pouvez effectuer sur chaque service éligible:

Ports de surveillance de l'API JMX et de gestion

Chaque composant est compatible avec les appels de surveillance JMX et de l'API de gestion sur différents ports. Le tableau suivant répertorie les ports JMX et de l'API de gestion pour chaque type de serveur:

Utiliser JMX

Les processus de surveillance du serveur de gestion, du processeur de messages, de Qpid et de Postgres utilisent tous JMX. Toutefois, JMX n'est activé par défaut que pour Cassandra et est désactivé par défaut pour tous les autres composants Edge. Vous devez donc activer JMX individuellement pour chaque composant avant de pouvoir les surveiller.

L'authentification JMX n'est pas activée par défaut. Vous pouvez activer l'authentification JMX pour tous les composants, à l'exception de Cassandra.

Activer JMX

JMX n'est activé par défaut que pour Cassandra et désactivé par défaut pour tous les autres composants Edge. Cette section explique comment activer JMX pour les autres composants Edge.

Pour activer JMX:

1. Modifiez le fichier de configuration du composant. Ce fichier se trouve à l'emplacement opt/apigee/edge-component_name/bin/start. Dans les environnements de production, ces fichiers de configuration se trouvent sur différentes machines.

   Choisissez l'un des emplacements de fichier suivants sur chaque serveur:

   • Serveur de gestion: /opt/apigee/edge-management-server/bin/start
   • Processeur de messages: /opt/apigee/edge-message-processor/bin/start
   • Postgres: /opt/apigee/edge-postgres-server/bin/start
   • Qpid: /opt/apigee/edge-qpid-server/bin/start
   • Routeur : /opt/apigee/edge-router/bin/start

   Par exemple, le fichier de configuration du serveur de gestion se trouve à l'emplacement /opt/apigee/edge-management-server/bin/start sur son serveur.

2. Ajoutez les options com.sun.management.jmxremote suivantes à la ligne exec qui démarre le composant :

   -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=port_number \
     -Dcom.sun.management.jmxremote.local.only=false \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false

   Où port_number est le port JMX du service. Pour obtenir le numéro de port JMX de votre service, consultez la section Ports de surveillance JMX et API de gestion.

   Par exemple, pour activer JMX sur le serveur de gestion, ajoutez ce qui suit au fichier de configuration du 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 \
     -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 \
     $* $debug_options com.apigee.kernel.MicroKernel

   Cet exemple spécifie le port 1099 pour le serveur de gestion. Comme indiqué précédemment, chaque service possède son propre numéro de port.

   La ligne modifiée dans le fichier de configuration se présente comme suit:

   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 -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 $* $debug_options com.apigee.kernel.MicroKernel

3. Enregistrez le fichier de configuration.
4. Redémarrez le composant à l'aide de la commande restart.

   Par exemple, pour redémarrer le serveur de gestion, exécutez la commande suivante:

   /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart

L'authentification pour JMX n'est pas activée par défaut. Vous pouvez activer l'authentification JMX pour tous les composants, à l'exception de Cassandra, comme décrit dans Activer l'authentification JMX.

Activer l'authentification JMX

L'authentification JMX n'est pas activée par défaut. Vous pouvez activer l'authentification JMX pour tous les composants, à l'exception de Cassandra.

Pour activer l'authentification JMX, exécutez l'action change_jmx_auth suivante sur tous les nœuds:

/opt/apigee/apigee-service/bin/apigee-service component change_jmx_auth [options|-f config_file]

Où :

• component est l'un des éléments suivants :
  • edge-management-server
  • edge-message-processor
  • edge-postgres-server
  • edge-qpid-server
  • edge-router
• options spécifie les éléments suivants :
  • -u username
  • -p password
  • -e [y|n] (activer ou désactiver)
• config_file spécifie l'emplacement d'un fichier de configuration dans lequel vous définissez les éléments suivants :
  • JMX_USERNAME=username
  • JMX_ENABLED=y|n
  • JMX_PASSWORD=password (si elle n'est pas définie ou si elle n'est pas transmise avec -p, vous êtes invité)

Vous pouvez utiliser les options de ligne de commande ou le fichier de configuration pour définir le nom d'utilisateur, le mot de passe et l'état d'activation/de désactivation. Vous ne spécifiez pas à la fois un ensemble d'options et un fichier de configuration.

L'exemple suivant active l'authentification JMX pour le serveur de gestion à l'aide des options de ligne de commande:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -u foo -p bar -e y

L'exemple suivant utilise un fichier de configuration plutôt que des options de ligne de commande:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -f /tmp/my-config-file

Si vous exécutez Edge sur plusieurs nœuds, exécutez la commande sur tous les nœuds, en spécifiant le même nom d'utilisateur et le même mot de passe.

Pour désactiver l'authentification JMX sur la ligne de commande, utilisez l'option "-e n", comme illustré dans l'exemple suivant:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -e n

Surveiller avec JConsole

Utilisez JConsole (un outil compatible avec JMX) pour gérer et surveiller la vérification de l'état et les statistiques de traitement. Avec JConsole, vous pouvez utiliser les statistiques JMX exposées par vos serveurs et les afficher dans une interface graphique. Pour en savoir plus, consultez la section Utiliser JConsole.

JConsole utilise l'URL de service suivante pour surveiller les attributs JMX (MBeans) proposés via JMX:

service:jmx:rmi:///jndi/rmi://IP_address:port_number/jmxrmi

Où :

• IP_address est l'adresse IP du serveur que vous souhaitez surveiller.
• port_number correspond au numéro de port JMX du serveur que vous souhaitez surveiller.

Par exemple, pour surveiller le serveur de gestion, exécutez une commande comme celle-ci (en supposant que l'adresse IP du serveur est 216.3.128.12):

service:jmx:rmi:///jndi/rmi://216.3.128.12:1099/jmxrmi

Notez que cet exemple spécifie le port 1099, qui est le port JMX du serveur de gestion. Pour les autres ports, consultez la section Ports de surveillance JMX et API de gestion.

Le tableau suivant présente les statistiques JMX génériques:

Surveiller avec l'API de gestion

Edge inclut plusieurs API que vous pouvez utiliser pour effectuer des vérifications de service sur vos serveurs, ainsi que pour vérifier vos utilisateurs, vos organisations et vos déploiements. Cette section décrit ces API.

Effectuer des vérifications de service

L'API de gestion fournit plusieurs points de terminaison pour surveiller et diagnostiquer les problèmes liés à vos services. Ces points de terminaison incluent les éléments suivants:

<ServerField>
  <Up>true</Up>
</ServerField>

curl: Failed connect to localhost:port_number; Connection refused

Pour utiliser ces points de terminaison, appelez un utilitaire tel que curl avec des commandes qui utilisent la syntaxe suivante:

curl http://host:port_number/v1/servers/self/up
  -H "Accept: [application/json|application/xml]"
curl http://host:port_number/v1/servers/self -u username:password
  -H "Accept: [application/json|application/xml]"

Où :

• host correspond à l'adresse IP du serveur que vous souhaitez vérifier. Si vous êtes connecté au serveur, vous pouvez utiliser "localhost". Sinon, spécifiez l'adresse IP du serveur, ainsi que le nom d'utilisateur et le mot de passe.
• port_number est le port de l'API Management du serveur que vous souhaitez vérifier. Il s'agit d'un port différent pour chaque type de composant. Par exemple, le port de l'API Management du serveur de gestion est 8080. Pour obtenir la liste des numéros de port de l'API Management à utiliser, consultez la section Ports de surveillance JMX et de l'API Management.

Pour modifier le format de la réponse, vous pouvez spécifier l'en-tête Accept comme "application/json" ou "application/xml".

L'exemple suivant obtient l'état du routeur sur localhost (port 8081):

curl http://localhost:8081/v1/servers/self/up -H "Accept: application/xml"

L'exemple suivant permet d'obtenir des informations sur le processeur de messages sur l'adresse 216.3.128.12 (port 8082):

curl http://216.3.128.12:8082/v1/servers/self -u sysAdminEmail:password
  -H "Accept: application/xml"

Surveiller l'état des utilisateurs, de l'organisation et du déploiement

Vous pouvez utiliser l'API Management pour surveiller l'état de l'utilisateur, de l'organisation et du déploiement de vos proxys sur les serveurs de gestion et les processeurs de messages en exécutant les commandes suivantes:

curl http://host:port_number/v1/users -u sysAdminEmail:password
curl http://host:port_number/v1/organizations -u sysAdminEmail:password
curl http://host:port_number/v1/organizations/orgname/deployments -u sysAdminEmail:password

où port_number est 8080 pour le serveur de gestion ou 8082 pour le processeur de messages.

Cet appel nécessite votre authentification avec votre nom d'utilisateur et votre mot de passe d'administrateur système.

Le serveur doit renvoyer un état "déployé" pour tous les appels. Si ces étapes échouent, procédez comme suit:

1. Recherchez d'éventuelles erreurs dans les journaux du serveur. Les journaux se trouvent à l'emplacement suivant :
   • Serveur de gestion: opt/apigee/var/log/edge-management-server
   • Processeur de messages: opt/apigee/var/log/edge-message-processor
2. Appelez le serveur pour vérifier qu'il fonctionne correctement.
3. Supprimez le serveur de l'ELB, puis redémarrez-le :

   /opt/apigee/apigee-service/bin/apigee-service service_name restart

   Où service_name correspond à :

   • edge-management-server
   • edge-message-processor

Vérifier l'état avec la commande apigee-service

Vous pouvez résoudre les problèmes de vos services Edge à l'aide de la commande apigee-service lorsque vous êtes connecté au serveur exécutant le service.

Pour vérifier l'état d'un service avec apigee-service:

1. Connectez-vous au serveur et exécutez la commande suivante :

   /opt/apigee/apigee-service/bin/apigee-service service_name status

   où service_name est l'un des éléments suivants :

   • Serveur de gestion: edge-management-server
   • Processeur de messages: edge-message-processor
   • Postgres: edge-postgres-server
   • Qpid: edge-qpid-server
   • Routeur : edge-router

   Exemple :

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor status

2. Si le service n'est pas en cours d'exécution, démarrez-le :

   /opt/apigee/apigee-service/bin/apigee-service service_name start

3. Après avoir redémarré le service, vérifiez qu'il fonctionne, soit à l'aide de la commande apigee-service status que vous avez utilisée précédemment, soit à l'aide de l'API Management décrite dans la section Surveiller avec l'API Management.

   Exemple :

   curl -v http://localhost:port_number/v1/servers/self/up

   où port_number est le port de l'API de gestion du service.

   Cet exemple suppose que vous êtes connecté au serveur et que vous pouvez utiliser "localhost" comme nom d'hôte. Pour vérifier l'état à distance avec l'API de gestion, vous devez spécifier l'adresse IP du serveur et inclure le nom d'utilisateur et le mot de passe de l'administrateur système dans votre appel d'API.

Surveillance de Postgres

Postgres est compatible avec plusieurs utilitaires que vous pouvez utiliser pour vérifier son état. Ces utilitaires sont décrits dans les sections suivantes.

Vérifier les organisations et les environnements sur Postgres

Vous pouvez vérifier les noms d'organisation et d'environnement intégrés au serveur Postgres en exécutant la commande curl suivante:

curl -v http://postgres_IP:8084/v1/servers/self/organizations

Le système doit afficher le nom de l'organisation et de l'environnement.

Vérifier l'état des données analytiques

Vous pouvez vérifier l'état des serveurs d'analyse Postgres et Qpid en exécutant la commande curl suivante:

curl -u userEmail:password http://host:port_number/v1/organizations/orgname/environments/envname/provisioning/axstatus

Le système doit afficher un état de réussite pour tous les serveurs d'analyse, comme illustré dans l'exemple suivant:

{
  "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

Cette section décrit les techniques que vous pouvez utiliser spécifiquement pour surveiller la 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. Pour en savoir plus, consultez la page http://bucardo.org/wiki/Check_postgres.

Avant d'exécuter le script:

1. Vous devez installer le script check_postgres.pl sur chaque nœud Postgres.
2. Assurez-vous d'avoir installé perl-Time-HiRes.x86_64, un module Perl qui implémente des alarmes, des délais, des gettimeofday et des minuteurs d'intervalle haute résolution. Par exemple, vous pouvez l'installer à l'aide de la commande suivante:
   

   yum install perl-Time-HiRes.x86_64

3. CentOS 7: avant d'utiliser check_postgres.pl sur CentOS v7, installez le RPM perl-Data-Dumper.x86_64.

Sortie de check_postgres.pl

La sortie par défaut des appels d'API à l'aide de check_postgres.pl est compatible avec Nagios. Après avoir installé le script, effectuez les vérifications suivantes:

1. 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'

2. Vérifiez le nombre de connexions entrantes vers la base de données et comparez-le au nombre maximal de connexions autorisées :

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends

3. Vérifiez 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 -action connection

4. Vérifiez l'espace disque :

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'

5. Vérifiez le nombre d'organisations et d'environnements intégrés à 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_tables where schemaname='analytics' and tablename like '%fact'" --warning='80' --critical='90' --valtype=integer

Exécuter des 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

Exécutez ensuite la commande ci-dessous :

\d analytics."org.env.fact"

Vérifier l'état de santé du processus postgres

Vous pouvez effectuer des vérifications de l'API sur la machine Postgres en appelant la commande curl suivante:

curl -v http://postgres_IP:8084/v1/servers/self/health

Cette commande renvoie l'état ACTIVE lorsque le processus postgres est actif. Si le processus Postgres n'est pas opérationnel, il renvoie l'état INACTIVE.

Ressources Postgres

Pour en savoir plus sur la surveillance du service Postgres, consultez les ressources suivantes:

• 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ù IP_address correspond à l'adresse IP du serveur Cassandra.

JMX est activé par défaut pour Cassandra, et l'accès JMX distant à Cassandra ne nécessite pas de mot de passe.

Statistiques JMX Cassandra

Utiliser nodetool pour gérer les nœuds de cluster

L'utilitaire nodetool est une interface de ligne de commande pour Cassandra qui gère les nœuds du cluster. L'utilitaire se trouve à l'emplacement /opt/apigee/apigee-cassandra/bin.

Les appels suivants peuvent être effectués sur tous les nœuds du cluster Cassandra:

1. Informations générales sur l'anneau (également possible pour un seul nœud Cassandra): recherchez les icônes "Haut" et "Normal" pour tous les nœuds.

   nodetool -h localhost ring

   Le résultat de la commande ci-dessus se présente comme suit :

   Datacenter: dc-1
   ==========
   Address            Rack     Status State   Load    Owns    Token
   192.168.124.201    ra1      Up     Normal  1.67 MB 33,33%  0
   192.168.124.202    ra1      Up     Normal  1.68 MB 33,33%  5671...5242
   192.168.124.203    ra1      Up     Normal  1.67 MB 33,33%  1134...0484

2. 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:

   ID                     : e2e42793-4242-4e82-bcf0-oicu812
   Gossip active          : true
   Thrift active          : true
   Native Transport active: true
   Load                   : 273.71 KB
   Generation No          : 1234567890
   Uptime (seconds)       : 687194
   Heap Memory (MB)       : 314.62 / 3680.00
   Off Heap Memory (MB)   : 0.14
   Data Center            : dc-1
   Rack                   : ra-1
   Exceptions             : 0
   Key Cache              : entries 150, size 13.52 KB, capacity 100 MB, 1520781 hits, 1520923 requests, 1.000 recent hit rate, 14400 save period in seconds
   Row Cache              : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds
   Counter Cache          : entries 0, size 0 bytes, capacity 50 MB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
   Token                  : 0

3. État du serveur Thrift (serveur de l'API cliente)

   nodetool -h localhost statusthrift

   Le résultat de la commande ci-dessus se présente comme suit:
   

   running

4. État des opérations de streaming de données: observez le trafic des nœuds Cassandra :

   nodetool -h localhost netstats

   Le résultat de la commande ci-dessus se présente comme suit:
   

   Mode: NORMAL
   Not sending any streams.
   Read Repair Statistics:
   Attempted: 151612
   Mismatch (Blocking): 0
   Mismatch (Background): 0
   Pool Name                    Active   Pending      Completed   Dropped
   Commands                        n/a         0              0         0
   Responses                       n/a         0              0       n/a

Pour en savoir plus sur nodetool, consultez la section À propos de l'utilitaire nodetool.

Surveillance Cassandra (UI)

Consultez l'URL de 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érifier l'état de ZooKeeper

1. Assurez-vous 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.
2. Testez les ports ZooKeeper pour vous assurer que vous pouvez établir une connexion TCP aux ports 2181 et 3888 sur chaque serveur ZooKeeper.
3. Assurez-vous que vous pouvez 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 à partir de la base de données.
4. Vérifiez l'état :

   /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

Utiliser les mots de quatre lettres ZooKeeper

ZooKeeper peut être surveillé via un petit ensemble de commandes (mots de quatre lettres) envoyés au port 2181 à l'aide de netcat (nc) ou telnet.

Pour en savoir plus sur les commandes ZooKeeper, consultez la documentation de référence sur les commandes Apache ZooKeeper.

Exemple :

• srvr: liste les informations complètes sur le serveur.
• stat: liste des informations succinctes sur le serveur et les clients connectés.

Vous pouvez envoyer les commandes suivantes au port ZooKeeper:

1. Exécutez la commande à quatre lettres "ruok" pour vérifier si le serveur fonctionne sans erreur. Une réponse positive renvoie "imok".

   echo ruok | nc host 2181

   Renvoie :

   imok

2. Exécutez la commande à quatre lettres stat pour obtenir la liste des performances du serveur et des statistiques des clients connectés :

   echo stat | nc host 2181

   Renvoie :

   Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT
   Clients:
   /0:0:0:0:0:0:0:1:33467[0](queued=0,recved=1,sent=0)
   /192.168.124.201:42388[1](queued=0,recved=8433,sent=8433)
   /192.168.124.202:42185[1](queued=0,recved=1339,sent=1347)
   /192.168.124.204:39296[1](queued=0,recved=7688,sent=7692)
   Latency min/avg/max: 0/0/128
   Received: 26144
   Sent: 26160
   Connections: 4
   Outstanding: 0
   Zxid: 0x2000002c2
   Mode: follower
   Node count: 283

3. 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))
   c.send(sys.argv[2])
   time.sleep(0.1)
   print c.recv(512)

   Exécutez maintenant les lignes Python suivantes:

   python zookeeper.py 192.168.124.201 ruok
   python zookeeper.py 192.168.124.201 stat

Test au niveau LDAP

Vous pouvez surveiller OpenLDAP pour voir si les demandes spécifiques sont traitées correctement. En d'autres termes, recherchez une recherche spécifique qui renvoie le résultat approprié.

1. 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 -b "uid=admin,ou=users,ou=global,dc=apigee,dc=com" -x -W -D "cn=manager,dc=apigee,dc=com" -H ldap://localhost:10389 -LLL

   Vous êtes alors invité à saisir le mot de passe administrateur LDAP:

   Enter LDAP Password:

   Une fois le mot de passe saisi, une réponse au format suivant s'affiche:

   dn:
   uid=admin,ou=users,ou=global,dc=apigee,dc=com
   objectClass: organizationalPerson
   objectClass: person
   objectClass: inetOrgPerson
   objectClass: top
   uid: admin
   cn: admin
   sn: admin
   userPassword:: e1NTSEF9bS9xbS9RbVNXSFFtUWVsU1F0c3BGL3BQMkhObFp2eDFKUytmZVE9PQ=
    =
   mail: opdk@google.com

2. Vérifiez si le serveur de gestion est toujours connecté à LDAP à l'aide de la commande suivante :

   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. Surveiller, puis ajuster la taille du cache dans le serveur OpenLDAP peut 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.