Surveillance

Edge pour Private Cloud version 4.16.05

Ce document décrit les techniques de surveillance des composants compatibles avec un environnement sur site. le déploiement d'Apigee Edge.

Activer l'authentification 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 utiliser 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 possède une action change_jmx_auth que vous utilisez pour activer/désactiver l'authentification et définir les identifiants JMX.

Pour activer l'authentification JMX, exécutez la commande suivante :

>  /<inst_root>/apigee/apigee-service/bin/apigee-service comp change_jmx_auth optionsOrConfigFile

où :

  • comp correspond à edge-management-server, Edge-message-processor, Edge-router, 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 (modifiable)
  • Le fichier de configuration comprend les éléments suivants:
    • JMX_USERNAME=nom d'utilisateur
    • JMX_ENABLED=y/n
    • JMX_PASSWORD=password (si elle n'est pas définie ou si elle n'est pas transmise avec -p, un message vous invite à le faire).

Par exemple, pour utiliser des options sur la ligne de commande :

> /<inst_root>/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:

> /<inst_root>/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 le même nom d'utilisateur et mot de passe.

Pour désactiver ultérieurement l'authentification JMX, utilisez la commande suivante :

> /<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -e n

Serveur de gestion

En utilisant JConsole pour surveiller la vérification de l'état du système et traiter les informations

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 fournies par Management Server (ou tout autre 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ées via JMX.

service:jmx:rmi:///jndi/rmi://<ip address>:<port>/platform

<adresse IP> est l'adresse IP du serveur de gestion (ou serveur concerné). Le port par défaut est 1099 pour le serveur de gestion.

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

MBeans JMX

Attributs JMX

Mémoire

HeapMemoryUsage

NonHeapMemoryUsage

Utilisation

Remarque:Les valeurs d'attribut seront affichées avec quatre valeurs: commit, "init", "max" et "used".

Utilisation de l'API Edge Application vérifications

Vous pouvez effectuer la vérification de l'API sur le serveur de gestion (ou tout autre serveur) en appelant la commande suivante : CURL:

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

&lt;host&gt; est l'adresse IP de l'administrateur Google Cloud.

Cet appel renvoie la valeur "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 est incapable de répondre au port 8080 requêtes.

Dépannage

  1. Connectez-vous au serveur et exécutez la commande suivante:
    /&lt;inst_root&gt;/apigee/apigee-service/bin/apigee-service état du serveur de gestion en périphérie
  2. Si le service n'est pas en cours d'exécution, démarrez-le:
    /&lt;inst_root&gt;/apigee/apigee-service/bin/apigee-service démarrage du serveur de gestion en périphérie

Utilisation de l'application Edge : vérification des utilisateurs, de l'organisation et du déploiement

Le serveur de gestion joue un rôle essentiel dans le regroupement de tous les autres colis dans chaque environnement sur site. l'installation. Vous pouvez vérifier l'état des utilisateurs, de l'organisation et du déploiement sur le serveur de gestion. en exécutant les 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, suivantes:

  1. Recherchez d'éventuelles erreurs dans les journaux du serveur de gestion (à l'emplacement <inst_root>/apigee/var/log/edge-management-server).
  2. Effectuer un appel au serveur de gestion pour vérifier s'il fonctionne correctement.
  3. Supprimez le serveur de l'ELB, puis redémarrez le serveur de gestion.
    /&lt;inst_root&gt;/apigee/apigee-service/bin/apigee-service redémarrage du serveur de gestion en périphérie

Routeur

Vous pouvez effectuer une vérification de l'API sur le routeur (ou n'importe quel serveur) en appelant la commande CURL suivante : commande:

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

Où "host" est l'adresse IP du routeur.

Cet appel renvoie la valeur "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 au port 8081. requêtes.

Dépannage

  1. Connectez-vous au serveur et exécutez les commandes suivantes:
    /&lt;inst_root&gt;/apigee/apigee-service/bin/apigee-service état du routeur périphérique
  2. 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
  3. Si le service est en cours d'exécution, vérifiez qu'il fonctionne. Vous surveillez l'état du cluster en vérifiant le memberCount par rapport à accessibilityCount et en alertant toutes les instances avec "memberCount != accessibleCount"
    curl -v -u &lt;userEmail&gt;:&lt;password&gt; http://localhost:port/v1/cluster

    Port d'emplacement : 8081 pour le routeur et 8082 pour le processeur de messages. Le résultat de la commande CURL ci-dessus est affiché ci-dessous :
    {
    "memberCount" : 12,
    "pod" : "rea1gw001",
    "reachableCount" : 12,
    "region" : "us-east-1",
    "types" : [ "management-server" ]
    * Connection #0 to host ms05apigee left intact
    * Closing connection #0
    }
  4. Si ce n'est pas le cas, exécutez la commande suivante pour examiner l'échec ou trouver le membre à l'origine du problème.
    curl http://localhost:port/v1/cluster/members

    où port : 8081 pour le routeur et 8082 pour le processeur de messages. Le résultat de la commande ci-dessus La commande CURL se présente comme suit:
    {
    &quot;lastChange&quot; : 0,
    "latence" : 0,
    "état" : "CONNECTÉ",
    "uuid" : "9c4c8bde-0015-4dc5-82d2-59fb326c4074"
    }, {
    "adresse" : "/192.168.5.209:4526",
    &quot;clusterType&quot; : "routeur,processeur de messages",
    &quot;lastChange&quot; : 1350658037228,
    "latence" : 3,
    "pod" : "rea1gw001",
    "région" : "us-east-1",
    "serverType" : "message-processeur",
    "état" : "CONNECTÉ",
    "uuid" : "f1c663a1-2bb8-469f-b5fd-69a5c5aa91c5"
    }, {
    "adresse" : "/192.168.5.29:4526",
    &quot;clusterType&quot; : "routeur,processeur de messages",
    &quot;lastChange&quot; : 1350623005057,
    "latence" : 1,
    "pod" : "rea1gw001",
    "région" : "us-east-1",
    "serverType" : "message-processeur",
    "état" : " DÉCONNEXION",
    "uuid" : "4cfe932b-f644-4581-b1ae-df338af9c7ce"
    }, {
    "adresse" : "/192.168.4.182:4526",
    &quot;clusterType&quot; : "routeur,processeur de messages",
    &quot;lastChange&quot; : 1350657730535,
    "latence" : 1,
    "pod" : "rea1gw001",
    "région" : "us-east-1",
    "serverType" : "message-processeur",
    "état" : "CONNECTÉ",
    "uuid" : "cba063d5-b8a4-409f-9e0b-f5d403e02091"
    }
  5. Notez que l'adresse IP 192.168.5.29 est déconnectée. Redémarrez le serveur
    /<inst_root>/apigee/apigee-service/bin/apigee-service edge-router restart

    Remarque : Si un routeur est dans un état déconnecté, supprimez-le de l'ELB, puis redémarrez-le.
  6. Après le redémarrage, vérifiez qu'il fonctionne.
    curl -v http://localhost:port/v1/cluster

    port est 8081 pour le routeur et 8082 pour le processeur de messages.

Processeur de messages

En utilisant JConsole pour surveiller la vérification de l'état du système et traiter les informations

Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.

Remarque: Veillez à utiliser le port 1101.

Utilisation de l'API Edge Application vérifications

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

Utiliser JConsole pour surveiller la vérification de l'état du système et traiter les informations

Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.

Remarque : Assurez-vous d'utiliser le port -1102.

Utiliser les vérifications de l'API Edge Application

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 compatible avec Qpid Server:

curl http://<qpid_IP>:8083/v1/servers/self

Serveur Postgres

En utilisant JConsole pour surveiller la vérification de l'état du système et traiter les informations

Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.

Remarque : Assurez-vous d'utiliser le port -1103.

Utiliser les vérifications de l'API Edge Application

Suivez la même procédure que celle décrite ci-dessus pour le serveur de gestion.

Remarque : Assurez-vous d'utiliser le port 8084. La commande CURL suivante est Également compatible avec Postgres Server:

curl http://<postgres_IP>:8084/v1/servers/self

Utilisation de Edge Vérifications de l'organisation et de l'environnement des applications

Vous pouvez vérifier le nom de l'organisation et de l'environnement intégré sur le serveur Postgres en émettant 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 axstatus de l'application Edge cocher

Vous pouvez vérifier le statut des serveurs d'analyse en émettant le CURL suivant .

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

Le système doit afficher le statut SUCCÈS pour tous les serveurs d'analyse. Le résultat de la commande CURL ci-dessus est indiqué 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 sur http://bucardo.org/wiki/Check_postgres.

Remarque : Le script check_postgres.pl doit être installé dans chaque nœud PostgreSQL.

Avant d'exécuter le script:

  1. Assurez-vous d'avoir installé perl-Time-HiRes.x86_64, un module Perl qui implémente des alarmes, des temps de pause, des gettimeofday et des minuteurs d'intervalle haute résolution. Par exemple : pouvez l'installer à l'aide de la commande suivante:
    installation yum 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 vous installez le script, effectuez les vérifications suivantes:

  1. 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 Go' --critique='900 Go'
  2. Connexion entrante à la base de données : vérifie le nombre de connexions entrantes vers 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
  3. 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 -action connection
  4. 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%' --critique='90%'
  5. Organisations/environnements intégrés : vérifie le nombre d'organisations intégré 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(*) comme résultat à partir de pg_tables, où schemaname='analytics' et nom de table comme '%fact'" --warning='80' --Critical='90' --valtype=integer

Remarque: Veuillez consulter la page http://bucardo.org/check_postgres/check_postgres.pl.html au cas où vous auriez besoin d'aide pour utiliser les commandes ci-dessus.

Vérifications de 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 :

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 de postgres processus

Vous pouvez effectuer la 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.

Il renvoie l'état "ACTIVE" lorsque le processus postgres est actif. Si le processus postgres n'est pas opérationnel, l'état "INACTIVE" est renvoyé.

Ressources Postgres

Apache Cassandra

Utiliser JConsole : surveillance de la tâche statistiques

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

<adresse IP> est l'adresse IP du serveur Cassandra Google Cloud.

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

Pour activer l'authentification JMX afin d'ajouter un mot de passe:

  1. Modifiez /<inst_root>/apigee/customer/application/cassandra.properties. Si le fichier n'existe pas, créez-le.
  2. Ajoutez ce qui suit au fichier :
    conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
  3. Enregistrez le fichier.
  4. Copiez les fichiers suivants de votre répertoire $JAVA_HOME vers /&lt;inst_root&gt;/apigee/data/apigee-cassandra/:
    cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmxremote.password

    cp ${JAVA_HOME}/lib/management/jmxremote.access $APIGEE_ROOT/data/apigee-cassandra/jmxremote.access
  5. Modifiez jmxremote.password et Ajoutez un nom d'utilisateur et un mot de passe au fichier:
    cassandra mot de passe

    password correspond au mot de passe JMX.
  6. Modifiez jmxremote.access et ajoutez le rôle suivant:
    cassandra lecture/écriture
  7. Assurez-vous que les fichiers appartiennent à "apigee" et que le mode de fichier est de 400:
    &gt; chown apigee:apigee /&lt;inst_root&gt;/apigee/data/apigee-cassandra/jmxremote.*
    &gt; chmod 400 /<inst_root>/apigee/data/apigee-cassandra/jmxremote.*
  8. Exécutez configure sur Cassandra:
    &gt; /<racine_inst>/apigee/apigee-service/bin/apigee-service apigee-cassandra configurer
  9. Redémarrez Cassandra :
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Pour désactiver l'authentification ultérieurement:

  1. Modifiez /&lt;inst_root&gt;/apigee/customer/application/cassandra.properties.
  2. Supprimez la ligne suivante du fichier:
    conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
  3. Exécutez configure sur Cassandra :
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  4. Redémarrez Cassandra:
    &gt; /<racine_inst>/apigee/apigee-service/bin/apigee-service apigee-cassandra redémarrer

Statistiques Cassandra JMX

MBeans JMX

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 du cluster

L'utilitaire nodetool, qui est une interface de ligne de commande pour Cassandra, permet de gérer nœuds de cluster. L'utilitaire est disponible sous &lt;inst_root&gt;/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 du cluster Cassandra :

  1. Informations générales sur l'anneau (également possible pour un seul nœud Cassandra): recherchez le "Haut" et "Normale" 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 State Load Owns Token
    192.168.124.201 dc1 ra1 Up Normal 1.67 Mo 33,33 % 0
    192.168.124.202 dc1 ra1 Up Normal 1.68 Mo 33,33 % 56713727820156410577229101238628035242
    192.168.124.203 dc1 ra1 Up Normal 1.67 Mo 33,33 % 113427455640312821154458202477256070484
  2. Informations générales sur les nœuds (appel par nœud)
    nodetool -h infos localhost

    Le résultat de la commande ci-dessus se présente comme suit:
    Jeton : 0
    Infos populaires : true
    Chargement : 1,67 Mo
    N° de génération : 1361968765
    Temps d'activité (secondes) : 78 108
    Mémoire de tas (Mo) : 46,80 / 772 00
    Centre de données : dc1
    Rack : ra1
    Exceptions : 0
  3. État du serveur Thrift (API du client de diffusion)
    host]# outil de nœud -h localhost statusthrift

    Le résultat de la commande ci-dessus indique l'état "running" (exécution en cours).
  4. État des opérations de streaming de données: observez le trafic pour "Cassandra". nodes
    nodetool -h localhost netstats 192.168.124.203

    Le résultat de la commande ci-dessus se présente comme suit:
    Mode: NORMAL
    Aucun contenu diffusé en streaming vers /192.168.124.203
    Rien en streaming depuis /192.168.124.203
    Nom du pool actif en attente de finalisation
    Commandes N/A 0 1688
    Réponses N/A 0 292277

Surveillance Cassandra (UI)

Reportez-vous à l'URL du centre d'opérations Datastax: http://www.datastax.com/products/opscenter.

Ressource Cassandra

Reportez-vous à l'URL suivante: http://www.datastax.com/docs/1.0/operations/monitoring.

Apache ZooKeeper

Vérifier l'état de ZooKeeper

  1. Vérifiez que le processus ZooKeeper est en cours d'exécution. ZooKeeper écrit un fichier PID dans &lt;inst_root&gt;/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 /<inst_root>/apigee/apigee-zookeeper/bin/zkCli.sh) et lisez une valeur dans la base de données.
  4. Vérifiez l'état:
    &gt; /<inst_root>/apigee/apigee-service/bin/apigee-service statut apigee-zookeeper

Utiliser des mots à quatre lettres ZooKeeper

ZooKeeper peut être surveillé via un petit ensemble de commandes (mots de quatre lettres) envoyées au port 2181 à l'aide de netcat (nc) ou de 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: liste tous les détails pour le serveur.
  • stat : affiche des informations brèves sur le serveur et les clients connectés.

Les commandes suivantes peuvent être envoyées au port ZooKeeper:

  1. Exécutez la commande à quatre lettres "ruok" pour vérifier si le serveur fonctionne sans erreur. Une réponse réussie renvoie "imok".
    echo ruok | nc <hôte> 2181

    Renvoie:
    imok
  2. Exécutez la commande de quatre lettres, "stat", pour afficher les statistiques sur les performances du serveur et les clients connectés.
    statistique d'écho | nc <hôte> 2181

    Renvoie:
    Version de Zookeeper: 3.4.5-1392090, Créé le 30/09/2012 à 17h52 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)
    Latence min/moy./max. : 0/0/128
    Reçu: 26144
    Envoyé: 26160
    Connexions: 4
    Exceptionnel: 0
    Zxid: 0x2000002c2
    Mode: followers
    Nombre de nœuds: 283

    Remarque: Il est parfois important de vérifier si un ZooKeeper est en mode Mode: leader, un abonné ou un observateur.
  3. Si netcat (nc) n'est pas disponible, vous pouvez utiliser Python comme alternative. Créer un fichier nommé zookeeper.py, contient les éléments suivants:
    heure d'importation, 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 stat 192.168.124.201

OpenLDAP

Test de niveau LDAP

Vous pouvez surveiller OpenLDAP pour voir si les requêtes spécifiques sont correctement diffusées. Dans d'autres termes, recherchez une recherche spécifique qui renvoie le bon résultat.

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

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

    Une fois le mot de passe saisi, une réponse s'affiche sous la forme:
    dn: uid=admin,ou=users,ou=global,dc=apigee,dc=com
    objetClasse: organizationPerson
    objetClasse: personne
    objetClasse: inetOrgPerson
    objetClasse: top
    uid: admin
    cn: admin
    sn: admin
    Mot de passe utilisateur : e1NTSEF9bS9xbS9RbVNXSFFtUWVsU1F0c3BGL3BQMkhObFp2eDFKUytmZVE9PQ=
    =
    E-mail: opdk@apigee.com
  2. Vérifiez si le serveur de gestion est toujours connecté au problème LDAP:
    curl -u &lt;userEMail&gt;:&lt;password&gt; http://localhost:8080/v1/users/&lt;ADMIN&gt;

    Renvoie:
    {
    &quot;emailId&quot; : <ADMIN>,
    "prénom" : "admin",
    "nom" : "admin"
    }

Vous pouvez également surveiller les caches OpenLDAP, ce qui permet de réduire le nombre d’accès au disque et donc à améliorer les performances du système. Surveillez, puis ajustez la taille du cache dans OpenLDAP peut avoir une incidence considérable sur les performances du serveur d’annuaire. Vous pouvez consulter le journal (&lt;inst_root&gt;/apigee/var/log) pour obtenir concernant le cache.