Surveillance

Ce document décrit les techniques de surveillance des composants compatibles avec 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 :

API de gestion
Service Utilisation de la mémoire [JMX*] Vérification du service État de l'utilisateur/de l'organisation/ du déploiement axstatus Vérification de la base de données État de apigee-service apigee-monit**
Serveur de gestion
Processeur de messages
Postgres
Qpid
Routeur
En savoir plus En savoir plus En savoir plus En savoir plus En savoir plus En savoir plus En savoir plus

* Avant de pouvoir utiliser JMX, vous devez l'activer, comme décrit dans Activer JMX.

** Le service apigee-monit vérifie si un composant est opérationnel et tente de le redémarrer si ce n'est pas le cas. Pour en savoir plus, consultez Autocorrection avec apigee-monit.

Ports de surveillance JMX et de l'API Management

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

Composant Port JMX Port de l'API Management
Serveur de gestion 1099 8080
Routeur 1100 8081
Processeur de messages 1101 8082
Qpid 1102 8083
Postgres 1103 8084

Utiliser JMX pour la surveillance

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. Pour Cassandra, suivez les instructions de la section Activer l'authentification JMX pour Cassandra.

Activer JMX

JMX est activé par défaut uniquement 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 des machines différentes.

    Choisissez l'un des emplacements de fichiers 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 sur son serveur se trouve dans /opt/apigee/edge-management-server/bin/start.

  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 Ports de surveillance de l'API JMX et Management.

    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, comme décrit dans la section Activer l'authentification JMX. Pour activer l'authentification JMX pour Cassandra, consultez Activer l'authentification JMX pour Cassandra.

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. Pour Cassandra, suivez les instructions de la section Activer l'authentification JMX pour 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_name 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 non défini ou non transmis avec -p, vous êtes invité à le faire)

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 les vérifications d'é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 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 est le numéro de port JMX du serveur que vous souhaitez surveiller.

Par exemple, pour surveiller le serveur de gestion, exécutez une commande semblable à la suivante (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 Ports de surveillance de l'API Management et JMX.

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

MBeans JMX Attributs JMX

Mémoire

HeapMemoryUsage

NonHeapMemoryUsage

Utilisation

Surveiller avec l'API Management

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 Management fournit plusieurs points de terminaison pour surveiller et diagnostiquer les problèmes liés à vos services. Voici des exemples de points de terminaison :

Point de terminaison Description
/servers/self/up

Vérifie si un service est en cours d'exécution. Cet appel d'API ne nécessite pas d'authentification.

Si le service est en cours d'exécution, ce point de terminaison renvoie la réponse suivante :

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

Si le service n'est pas en cours d'exécution, vous obtiendrez une réponse semblable à celle-ci (selon le service et la façon dont vous l'avez vérifié) :

curl: Failed connect to localhost:port_number; Connection refused
/servers/self

Renvoie des informations sur le service, y compris :

  • Propriétés de configuration
  • Heure de début et temps d'activité
  • Informations sur le build, le RPM et l'UUID
  • Nom d'hôte et adresse IP internes et externes
  • Région et pod
  • Propriété <isUp>, qui indique si le service est en cours d'exécution

Cet appel d'API nécessite que vous vous authentifiiez avec vos identifiants d'administrateur Apigee.

Pour utiliser ces points de terminaison, appelez un utilitaire tel que curl avec des commandes utilisant 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 est 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 pour le 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 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 récupère l'état du routeur sur l'hôte local (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 à 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 des utilisateurs, 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 correspond à 8080 pour le serveur de gestion ou à 8082 pour le processeur de messages.

Cet appel nécessite que vous vous authentifiiez avec votre nom d'utilisateur et votre mot de passe d'administration système.

Le serveur doit renvoyer l'état "deployed" pour tous les appels. Si ces commandes é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. Envoyez une requête au 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érifiez l'état à l'aide de la commande apigee-service.

Vous pouvez résoudre les problèmes liés à 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 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 Management pour le 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 Management, 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 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 d'Analytics

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 Postgres.

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 mises en veille, des fonctions gettimeofday et des chronomètres 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 utilisant 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 à 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 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_tables where schemaname='analytics' and tablename like '%fact'" --warning='80' --critical='90' --valtype=integer

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

Vous pouvez effectuer des vérifications d'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 :

Apache Cassandra

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

Activer l'authentification JMX pour Cassandra

Vous pouvez activer l'authentification JMX pour Cassandra. Après cela, vous devrez transmettre un nom d'utilisateur et un mot de passe à tous les appels à l'utilitaire nodetool.

Pour activer l'authentification JMX pour Cassandra :

  1. Créez et modifiez le fichier cassandra.properties :
    1. Modifiez le fichier /opt/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
conf_cassandra-env_com.sun.management.jmxremote.password.file=${APIGEE_ROOT}/data/apigee-cassandra/jmxremote.password
conf_cassandra-env_com.sun.management.jmxremote.access.file=${APIGEE_ROOT}/data/apigee-cassandra/jmxremote.access
    3. Enregistrez le fichier cassandra.properties.
    4. Remplacez le propriétaire du fichier par apigee:apigee, comme illustré dans l'exemple suivant : 
      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties

    Pour en savoir plus sur l'utilisation des fichiers de propriétés pour définir des jetons, consultez Comment configurer Edge.

  2. Créer et modifier jmx_auth.sh :
    1. Créez un fichier à l'emplacement suivant s'il n'existe pas : 
      /opt/apigee/customer/application/jmx_auth.sh
    2. Ajoutez les propriétés suivantes au fichier : 
      export CASS_JMX_USERNAME=JMX_USERNAME
export CASS_JMX_PASSWORD=JMX_PASSWORD
    3. Enregistrez le fichier jmx_auth.sh.
    4. Exécutez le fichier : 
      source /opt/apigee/customer/application/jmx_auth.sh
  3. Copiez et modifiez le fichier jmxremote.password :
    1. Copiez le fichier suivant 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/jmxremote.password
    2. Modifiez le fichier jmxremote.password et ajoutez votre nom d'utilisateur et votre mot de passe JMX à l'aide de la syntaxe suivante : 
      JMX_USERNAME JMX_PASSWORD

      Où JMX_USERNAME et JMX_PASSWORD sont le nom d'utilisateur et le mot de passe JMX que vous avez définis précédemment.

    3. Assurez-vous que le fichier appartient à "apigee" et que le mode de fichier est 400 : 
      chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.password
chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.password
  4. Copiez et modifiez le fichier jmxremote.access :
    1. Copiez le fichier suivant de votre répertoire $JAVA_HOME vers /opt/apigee/data/apigee-cassandra/ : 
      cp ${JAVA_HOME}/lib/management/jmxremote.access $APIGEE_ROOT/data/apigee-cassandra/jmxremote.access
    2. Modifiez le fichier jmxremote.access et ajoutez le rôle suivant : 
      JMX_USERNAME readwrite
    3. Assurez-vous que le fichier appartient à "apigee" et que le mode de fichier est 400 : 
      chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.access
chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.access
  5. Exécutez configure sur Cassandra : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  6. Redémarrez Cassandra : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  7. Répétez cette procédure sur tous les autres nœuds Cassandra.

Activer le chiffrement des mots de passe JMX

Pour activer le chiffrement des mots de passe JMX, procédez comme suit :

  1. Ouvrez le fichier source/conf/casssandra-env.sh.
  2. Annulez la mise en commentaire des lignes suivantes dans le fichier :
    • JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config={T}conf_cassandra-env_java.security.auth.login.config{/T}"
    • JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.login.config=ApigeeSecureFileLoginModule"
  3. Dans la ligne de commande, générez un ou plusieurs hachages SHA1 des mots de passe souhaités en saisissant echo -n 'Secret' | openssl dgst -sha1.
  4. Définissez le ou les mots de passe pour le nom d'utilisateur dans jmxremote.password.
  5. Après la mise à jour, remettez le fichier cassandra-env.sh en lecture seule.

Activer JMX avec SSL pour Cassandra

L'activation de JMX avec SSL offre une sécurité et un chiffrement supplémentaires pour la communication basée sur JMX avec Cassandra. Pour activer JMX avec SSL, vous devez fournir une clé et un certificat à Cassandra pour accepter les connexions JMX basées sur SSL. Vous devez également configurer nodetool (et tous les autres outils qui communiquent avec Cassandra via JMX) pour SSL.

JMX avec SSL activé est compatible avec les mots de passe JMX en texte brut et chiffrés.

Pour activer JMX avec SSL pour Cassandra, procédez comme suit :

  1. Activez JMX. Activez le chiffrement du mot de passe si nécessaire.
  2. Activez l'authentification JMX pour Cassandra. comme décrit ci-dessus. Assurez-vous que nodetool fonctionne avec le nom d'utilisateur et le mot de passe configurés. 
    /opt/apigee/apigee-cassandra/bin/nodetool -u <JMX_USER> -pw <JMX_PASS> ring

  3. Préparez le keystore et le truststore.

    • Le keystore doit contenir une clé et un certificat, et est utilisé pour configurer le serveur Cassandra. Si le keystore contient plusieurs paires de clés, Cassandra utilise la première paire de clés pour activer SSL.

      Notez que les mots de passe du keystore et de la clé doivent être identiques (par défaut, lorsque vous générez la clé à l'aide de keytool).

    • Le truststore ne doit contenir que le certificat et est utilisé par les clients (commandes basées sur apigee-service ou nodetool) pour se connecter via JMX.

    Après avoir vérifié les exigences ci-dessus :

    1. Placez le fichier keystore dans /opt/apigee/data/apigee-cassandra.
    2. Assurez-vous que le fichier du keystore n'est lisible que par l'utilisateur Apigee en saisissant la commande suivante : 
      chown apigee:apigee /opt/apigee/data/apigee-cassandra/keystore.node1
chmod 400 /opt/apigee/data/apigee-cassandra/keystore.node1
  4. Configurez Cassandra pour JMX avec SSL en procédant comme suit :
    1. Arrêtez le nœud Cassandra en saisissant la commande suivante : 
      apigee-service apigee-cassandra stop
    2. Activez SSL dans Cassandra en ouvrant le fichier /opt/apigee/customer/application/cassandra.properties et en ajoutant la ligne suivante : 
      conf_cassandra-env_com.sun.management.jmxremote.ssl=true

      Le fichier doit appartenir à apigee:apigee.

    3. Activez la configuration liée à SSL dans Cassandra comme suit. Ouvrez le fichier /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh et annulez la mise en commentaire des lignes suivantes, en modifiant le chemin d'accès /opt/apigee/data/apigee-cassandra/keystore.node1 et le mot de passe du keystore si nécessaire. 
      JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node1"
JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keystore-password"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true"
       : assurez-vous que le fichier appartient à apigee:apigee.
    4. Démarrez le nœud Cassandra en saisissant la commande suivante : 
      apigee-service apigee-cassandra start
  5. Configurez les commandes Cassandra apigee-service. Vous devez définir certaines variables d'environnement lors de l'exécution des commandes apigee-service, y compris celles ci-dessous : 
    apigee-service apigee-cassandra stop
apigee-service apigee-cassandra wait_for_ready
apigee-service apigee-cassandra ring
apigee-service apigee-cassandra backup

    Plusieurs options permettent de configurer apigee-service pour l'authentification JMX et SSL. Choisissez une option en fonction de la facilité d'utilisation et de vos pratiques de sécurité.

    Option 1 (arguments SSL stockés dans un fichier)

    Définissez les variables d'environnement suivantes :

    export CASS_JMX_USERNAME=ADMIN
# Provide encrypted password here if you have setup JMX password encryption
export CASS_JMX_PASSWORD=PASSWORD
export CASS_JMX_SSL=Y

    Créez un fichier dans le répertoire d'accueil de l'utilisateur Apigee (/opt/apigee). 

    $HOME/.cassandra/nodetool-ssl.properties

    Modifiez le fichier et ajoutez les lignes suivantes :

    -Djavax.net.ssl.trustStore=<path-to-truststore.node1>
-Djavax.net.ssl.trustStorePassword=<truststore-password>
-Dcom.sun.management.jmxremote.registry.ssl=true

    Assurez-vous que le fichier du truststore est lisible par l'utilisateur Apigee.

    Exécutez la commande apigee-service suivante : Si elle s'exécute sans erreur, vos configurations sont correctes.

    apigee-service apigee-cassandra ring

    Option 2 (arguments SSL stockés dans des variables d'environnement)

    Définissez les variables d'environnement suivantes :

    export CASS_JMX_USERNAME=ADMIN
# Provide encrypted password here if you have setup JMX password encryption
export CASS_JMX_PASSWORD=PASSWORD
export CASS_JMX_SSL=Y
# Ensure the truststore file is accessible by Apigee user.
export CASS_JMX_TRUSTSTORE=<path-to-trustore.node1>
export CASS_JMX_TRUSTSTORE_PASSWORD=<truststore-password>

    Exécutez la commande apigee-service suivante : Si elle s'exécute sans erreur, vos configurations sont correctes. 

    apigee-service apigee-cassandra ring

    Option 3 (arguments SSL transmis directement à apigee-service)

    Exécutez une commande apigee-service comme celle ci-dessous. Vous n'avez pas besoin de configurer de variables d'environnement.

    CASS_JMX_USERNAME=ADMIN CASS_JMX_PASSWORD=PASSWORD CASS_JMX_SSL=Y CASS_JMX_TRUSTSTORE=<path-to-trustore.node1> CASS_JMX_TRUSTSTORE_PASSWORD=<trustore-password> /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra ring

  6. Configurez nodetool. Nodetool nécessite que des paramètres JMX lui soient transmis. Vous pouvez configurer nodetool pour qu'il s'exécute avec JMX compatible SSL de deux manières, comme décrit dans les options de configuration ci-dessous :

    Les options diffèrent selon la manière dont les configurations liées à SSL sont transmises à nodetool. Dans les deux cas, l'utilisateur exécutant nodetool doit disposer des autorisations de LECTURE sur le fichier truststore. Choisissez l'option appropriée en fonction de la facilité d'utilisation et de vos pratiques de sécurité.

    Pour en savoir plus sur les paramètres nodetool, consultez la documentation DataStax.

    Option de configuration 1

    Créez un fichier dans le répertoire d'accueil de l'utilisateur exécutant nodetool.

    $HOME/.cassandra/nodetool-ssl.properties

    Ajoutez les lignes suivantes au fichier :

    -Djavax.net.ssl.trustStore=<path-to-truststore.node1>
-Djavax.net.ssl.trustStorePassword=<truststore-password>
-Dcom.sun.management.jmxremote.registry.ssl=true

    Le chemin d'accès au truststore spécifié ci-dessus doit être accessible par tout utilisateur exécutant nodetool.

    Exécutez nodetool avec l'option --ssl.

    /opt/apigee/apigee-cassandra/bin/nodetool --ssl -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring

    Option de configuration 2

    Exécutez nodetool en tant que commande unique avec les paramètres supplémentaires listés ci-dessous.

    /opt/apigee/apigee-cassandra/bin/nodetool -Djavax.net.ssl.trustStore=<path-to-truststore.node1> -Djavax.net.ssl.trustStorePassword=<truststore-password> -Dcom.sun.management.jmxremote.registry.ssl=true -Dssl.enable=true -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring

Rétablir les configurations SSL

Si vous devez annuler les configurations SSL décrites dans la procédure ci-dessus, procédez comme suit :

  1. Arrêtez apigee-cassandra en saisissant 
    apigee-service apigee-cassandra stop
  2. Supprimez la ligne conf_cassandra-env_com.sun.management.jmxremote.ssl=true du fichier /opt/apigee/customer/application/cassandra.properties.
  3. Mettez en commentaire les lignes suivantes dans /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh : 
    # JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node0"
# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keypass"
# JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true”
  4. Démarrez apigee-cassandra en saisissant
    5. apigee-service apigee-cassandra start
  5. Supprimez la variable d'environnement CASS_JMX_SSL si elle a été définie.

    unset CASS_JMX_SSL
  6. Vérifiez que les commandes basées sur apigee-service, telles que ring, stop, backup, etc., fonctionnent.
  7. Cessez d'utiliser le commutateur --ssl avec nodetool.

Désactiver l'authentification JMX pour Cassandra

Pour désactiver l'authentification JMX pour Cassandra :

  1. Modifier /opt/apigee/customer/application/cassandra.properties.
  2. Supprimez la ligne suivante du fichier : 
    conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
  3. Exécutez la commande "configure" sur Cassandra : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  4. Redémarrez Cassandra : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  5. Répétez cette procédure sur tous les autres nœuds 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 est l'adresse IP du serveur Cassandra.

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 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 de cluster. L'utilitaire est disponible à l'adresse /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 valeurs "Up" et "Normal" pour tous les nœuds. 
    nodetool [-u username -pw password] -h localhost ring

    Vous ne devez transmettre votre nom d'utilisateur et votre mot de passe que si vous avez activé l'authentification JMX pour Cassandra.

    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 [-u username -pw password]  -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 (fournissant l'API cliente) 
    nodetool [-u username -pw password] -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 pour les nœuds Cassandra : 
    nodetool [-u username -pw password] -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 À propos de l'utilitaire nodetool.

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 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 de la base de données.
  4. Vérifiez l'état : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

Utiliser les commandes de quatre lettres de 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 documentation de référence sur les commandes Apache ZooKeeper.

Exemple :

  • srvr : liste toutes les informations sur le serveur.
  • stat : liste des informations succinctes 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 s'exécute sans erreur. Une réponse réussie renvoie "imok". 
    echo ruok | nc host 2181

    Renvoie :

    imok
  2. Exécutez la commande à quatre lettres stat pour lister les statistiques sur les performances du serveur et les 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 comme alternative. 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 requêtes spécifiques sont correctement traitées. En d'autres termes, vérifiez qu'une recherche spécifique 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 est utilisée pour 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 ensuite invité à saisir le mot de passe administrateur LDAP :

    Enter LDAP Password:

    Après avoir saisi le mot de passe, vous obtenez une réponse au format suivant :

    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 d'améliorer ainsi les performances du système. La surveillance, puis l'ajustement de la taille du cache sur le serveur OpenLDAP peuvent avoir un impact important sur les performances du serveur d'annuaire. Vous pouvez consulter les fichiers journaux (opt/apigee/var/log) pour obtenir des informations sur le cache.