Cómo supervisar

Edge para la nube privada v4.18.05

En este documento, se describen las técnicas de supervisión de los componentes compatibles con una implementación de Apigee Edge en las instalaciones.

Descripción general

Edge admite varias formas de obtener detalles sobre los servicios y de verificar sus estados. En la siguiente tabla, se enumeran los tipos de verificaciones que puedes realizar en cada servicio apto:

Servicio JMX:*
Uso de memoria		 API de Administración:
Verificación de servicios		 API de Mgmt:
Estado de la implementación, la organización o el usuario		 API de Administración:
axstatus		 Verificación de la base de datos Estado de apigee-service
Servidor de administración
Message Processor
Postgres
Qpid
Router
Más información Más información Más información Más información Más información Más información
* Antes de poder usar JMX, debes habilitarlo, como se describe en Habilita JMX.

Puertos de supervisión de la API de JMX y Management

Cada componente admite llamadas de supervisión de JMX y de la API de Management en diferentes puertos. En la siguiente tabla, se enumeran los puertos de JMX y de la API de Management para cada tipo de servidor:

Componente Puerto JMX Puerto de la API de Management
Servidor de administración 1099 8080
Router 1100 8081
Message Processor 1101 8082
Qpid 1102 8083
Postgres 1103 8084

Usa JMX

Los procesos de supervisión del servidor de administración, el procesador de mensajes, Qpid y Postgres usan JMX. Sin embargo, JMX está habilitado de forma predeterminada solo para Cassandra y, de forma predeterminada, inhabilitado para todos los demás componentes de Edge. Por lo tanto, debes habilitar JMX de forma individual para cada componente antes de poder supervisarlo.

La autenticación JMX no está habilitada de forma predeterminada. Puedes habilitar la autenticación de JMX para todos los componentes, excepto Cassandra.

Habilitar JMX

JMX está habilitado de forma predeterminada solo para Cassandra y, de forma predeterminada, inhabilitado para todos los demás componentes de Edge. En esta sección, se describe cómo habilitar JMX para los otros componentes de Edge.

Para habilitar JMX, haz lo siguiente:

  1. Edita el archivo de configuración del componente. Este archivo se encuentra en opt/apigee/edge-component_name/bin/start. En los entornos de producción, estos archivos de configuración estarán en máquinas diferentes.

    Elige entre las siguientes ubicaciones de archivos en cada servidor:

    • Servidor de administración: /opt/apigee/edge-management-server/bin/start
    • Procesador de mensajes: /opt/apigee/edge-message-processor/bin/start
    • Postgres: /opt/apigee/edge-postgres-server/bin/start
    • Qpid: /opt/apigee/edge-qpid-server/bin/start
    • Router: /opt/apigee/edge-router/bin/start

    Por ejemplo, el archivo de configuración del servidor de administración en su servidor se encuentra en /opt/apigee/edge-management-server/bin/start.

  2. Agrega las siguientes opciones de com.sun.management.jmxremote a la línea exec que inicia el componente: 
    -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

    En el ejemplo anterior, port_number es el puerto JMX del servicio. Para obtener el número de puerto JMX de tu servicio, consulta Puertos de supervisión de JMX y la API de Management.

    Por ejemplo, para habilitar JMX en el servidor de administración, agrega lo siguiente al archivo de configuración del servidor de administración:

    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

    En este ejemplo, se especifica el puerto 1099 para el servidor de administración. Como se indicó anteriormente, cada servicio tiene su propio número de puerto.

    La línea editada en el archivo de configuración se ve de la siguiente manera:

    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. Guarda el archivo de configuración.
  4. Reinicia el componente con el comando restart.

    Por ejemplo, para reiniciar el servidor de administración, ejecuta el siguiente comando:

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

La autenticación para JMX no está habilitada de forma predeterminada. Puedes habilitar la autenticación de JMX para todos los componentes, excepto Cassandra, como se describe en Habilita la autenticación de JMX.

Habilitar la autenticación JMX

La autenticación JMX no está habilitada de forma predeterminada. Puedes habilitar la autenticación de JMX para todos los componentes, excepto Cassandra.

Para habilitar la autenticación de JMX, ejecuta la siguiente acción change_jmx_auth en todos los nodos:

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

Aquí:

  • component es una de las siguientes opciones:
    • edge-management-server
    • edge-message-processor
    • edge-postgres-server
    • edge-qpid-server
    • edge-router
  • options especifica lo siguiente:
    • -u username
    • -p password
    • -e [y|n] (habilitar o inhabilitar)
  • config_file especifica la ubicación de un archivo de configuración en el que se define lo siguiente:
    • JMX_USERNAME=username
    • JMX_ENABLED=y|n
    • JMX_PASSWORD=password (si no se establece o no se pasa con -p, se te solicita)

Puedes usar las opciones de la línea de comandos o el archivo de configuración para definir el nombre de usuario, la contraseña y el estado de habilitación o inhabilitación. No especificas un conjunto de opciones ni un archivo de configuración.

En el siguiente ejemplo, se habilita la autenticación JMX para el servidor de administración mediante las opciones de línea de comandos:

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

En el siguiente ejemplo, se usa un archivo de configuración en lugar de opciones de línea de comandos:

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

Si ejecutas Edge en varios nodos, ejecuta el comando en todos ellos y especifica el mismo nombre de usuario y contraseña.

Para inhabilitar la autenticación de JMX en la línea de comandos, usa la opción "-e n", como se muestra en el siguiente ejemplo:

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

Supervisa con JConsole

Usa JConsole (una herramienta compatible con JMX) para administrar y supervisar la verificación de estado y procesar estadísticas. Con JConsole, puedes consumir las estadísticas de JMX que exponen tus servidores y mostrarlas en una interfaz gráfica. Para obtener más información, consulta Cómo usar JConsole.

JConsole usa la siguiente URL de servicio para supervisar los atributos JMX (MBeans) que se ofrecen a través de JMX:

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

Aquí:

  • IP_address es la dirección IP del servidor que deseas supervisar.
  • port_number es el número de puerto de JMX del servidor que deseas supervisar.

Por ejemplo, para supervisar el servidor de administración, ejecuta un comando como el siguiente (suponiendo que la dirección IP del servidor sea 216.3.128.12):

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

Ten en cuenta que este ejemplo especifica el puerto 1099, que es el puerto JMX del servidor de administración. Para otros puertos, consulta Puertos de supervisión de la API de Management y JMX.

En la siguiente tabla, se muestran las estadísticas genéricas de JMX:

MBeans de JMX Atributos de JMX

Memoria

HeapMemoryUsage

NonHeapMemoryUsage

Uso

Cómo supervisar con la API de Management

Edge incluye varias APIs que puedes usar para realizar verificaciones de servicio en tus servidores, así como verificar tus usuarios, organizaciones y implementaciones. En esta sección, se describen estas APIs.

Realiza verificaciones del servicio

La API de Management proporciona varios extremos para supervisar y diagnosticar problemas de tus servicios. Estos extremos incluyen lo siguiente:

Extremo Descripción
/servers/self/up

Comprueba si un servicio se está ejecutando. Esta llamada a la API no requiere que te autentiques.

Si el servicio se está ejecutando, este extremo muestra la siguiente respuesta:

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

Si el servicio no se está ejecutando, recibirás una respuesta similar a la siguiente (según el servicio y cómo lo hayas verificado):

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

Muestra información sobre el servicio, incluida la siguiente:

  • Propiedades de configuración
  • Hora de inicio y hora de actividad
  • Información de compilación, RPM y UUID
  • Nombre de host y dirección IP internos y externos
  • Región y pod
  • Propiedad <isUp>, que indica si el servicio se está ejecutando

Esta llamada a la API requiere que te autentiques con tus credenciales de administrador de Apigee.

Para usar estos extremos, invoca una utilidad como curl con comandos que usen la siguiente sintaxis:

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

Aquí:

  • host es la dirección IP del servidor que deseas verificar. Si accediste al servidor, puedes usar “localhost”. De lo contrario, especifica la dirección IP del servidor, así como el nombre de usuario y la contraseña.
  • port_number es el puerto de la API de Management del servidor que deseas verificar. Este es un puerto diferente para cada tipo de componente. Por ejemplo, el puerto de la API de Management del servidor de administración es 8080. Si deseas obtener una lista de los números de puerto de la API de Management que se deben usar, consulta Puertos de supervisión de la API de Management y JMX.

Para cambiar el formato de la respuesta, puedes especificar el encabezado Accept como "application/json" o "application/xml".

En el siguiente ejemplo, se obtiene el estado del router en localhost (puerto 8081):

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

En el siguiente ejemplo, se obtiene información sobre Message Processor en 216.3.128.12 (puerto 8082):

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

Supervisa el estado de los usuarios, la organización y la implementación

Puedes usar la API de Management para supervisar el estado de los usuarios, la organización y la implementación de tus proxies en los servidores de Management y los procesadores de mensajes. Para ello, emite los siguientes comandos:

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

En el que port_number es 8080 para el servidor de administración o 8082 para el procesador de mensajes.

Esta llamada requiere que te autentiques con el nombre de usuario y la contraseña de administración del sistema.

El servidor debería mostrar el estado “implementado” para todas las llamadas. Si estas soluciones no funcionan, haz lo siguiente:

  1. Revisa los registros del servidor en busca de errores. Los registros se encuentran en la siguiente ubicación:
    • Servidor de administración: opt/apigee/var/log/edge-management-server
    • Procesador de mensajes: opt/apigee/var/log/edge-message-processor
  2. Realiza una llamada al servidor para verificar si funciona correctamente.
  3. Quita el servidor del ELB y, luego, reinícialo: 
    /opt/apigee/apigee-service/bin/apigee-service service_name restart

    En el ejemplo anterior, service_name es:

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

Verifica el estado con el comando apigee-service

Puedes solucionar problemas de tus servicios de Edge con el comando apigee-service cuando accedes al servidor que ejecuta el servicio.

Para verificar el estado de un servicio con apigee-service, haz lo siguiente:

  1. Accede al servidor y ejecuta el siguiente comando: 
    /opt/apigee/apigee-service/bin/apigee-service service_name status

    En el ejemplo anterior, service_name es una de las siguientes opciones:

    • Servidor de administración: edge-management-server
    • Message Processor: edge-message-processor
    • Postgres: edge-postgres-server
    • Qpid: edge-qpid-server
    • Router: edge-router

    Por ejemplo:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor status
  2. Si no se está ejecutando el servicio, inícialo: 
    /opt/apigee/apigee-service/bin/apigee-service service_name start
  3. Después de reiniciar el servicio, verifica que funcione, ya sea con el comando apigee-service status que usaste antes o con la API de Management que se describe en Supervisa con la API de Management.

    Por ejemplo:

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

    En el que port_number es el puerto de la API de Management para el servicio.

    En este ejemplo, se supone que accediste al servidor y puedes usar "localhost" como nombre de host. Para verificar el estado de forma remota con la API de Management, debes especificar la dirección IP del servidor y, además, incluir el nombre de usuario y la contraseña del administrador del sistema en tu llamada a la API.

Supervisión de Postgres

Postgres admite varias utilidades que puedes usar para verificar su estado. Estas utilidades se describen en las siguientes secciones.

Verifica las organizaciones y los entornos en Postgres

Para verificar los nombres de organización y entorno que se incorporaron en el servidor Postgres, emite el siguiente comando curl:

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

El sistema debería mostrar el nombre de la organización y del entorno.

Verifica el estado de las estadísticas

Para verificar el estado de los servidores de estadísticas de Postgres y Qpid, emite el siguiente comando curl:

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

El sistema debería mostrar un estado de éxito para todos los servidores de estadísticas, como se muestra en el siguiente ejemplo:

{
  "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 datos de PostgreSQL

En esta sección, se describen técnicas que puedes usar en particular para supervisar la base de datos de Postgres.

Usa la secuencia de comandos check_postgres.pl

Para supervisar la base de datos de PostgreSQL, puedes usar una secuencia de comandos de supervisión estándar, check_postgres.pl. Para obtener más información, consulta http://bucardo.org/wiki/Check_postgres.

Antes de ejecutar la secuencia de comandos, haz lo siguiente:

  1. Debes instalar la secuencia de comandos check_postgres.pl en cada nodo de Postgres.
  2. Asegúrate de haber instalado perl-Time-HiRes.x86_64, un módulo de Perl que implementa alarmas de alta resolución, suspensión, gettimeofday y temporizadores por intervalos. Por ejemplo, puedes instalarlo con el siguiente comando:
    yum install perl-Time-HiRes.x86_64
  3. CentOS 7: Antes de usar check_postgres.pl en CentOS v7, instala el RPM de perl-Data-Dumper.x86_64.

Resultado de check_postgres.pl

El resultado predeterminado de las llamadas a la API que usan check_postgres.pl es compatible con Nagios. Después de instalar la secuencia de comandos, realiza las siguientes verificaciones:

  1. Verifica el tamaño de la base de datos: 
    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. Verifica la cantidad de conexiones entrantes a la base de datos y compárala con la cantidad máxima de conexiones permitidas: 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends
  3. Comprueba si la base de datos se está ejecutando y si está disponible: 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection
  4. Verifica el espacio en el disco: 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'
  5. Verifica la cantidad de organizaciones y entornos integrados en un nodo de 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

Ejecuta verificaciones de bases de datos

Puedes verificar que se hayan creado las tablas correctas en la base de datos de PostgreSQL. Accede a la base de datos de PostgreSQL con el siguiente comando:

psql -h /opt/apigee/var/run/apigee-postgresql/ -U apigee -d apigee

Luego, ejecute lo siguiente:

\d analytics."org.env.fact"

Verifica el estado del proceso de Postgres

Para realizar verificaciones de API en la máquina de Postgres, invoca el siguiente comando curl:

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

Este comando muestra el estado ACTIVE cuando el proceso de Postgres está activo. Si el proceso de Postgres no está en funcionamiento, muestra el estado INACTIVE.

Recursos de Postgres

Para obtener información adicional sobre la supervisión del servicio de Postgres, consulta lo siguiente:

Apache Cassandra

Usa JConsole: Supervisa las estadísticas de tareas

Usa JConsole y la siguiente URL de servicio para supervisar los atributos de JMX (MBeans) que se ofrecen a través de JMX:

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

Donde IP_address es la IP del servidor de Cassandra.

JMX está habilitado de forma predeterminada para Cassandra, y el acceso remoto de JMX a Cassandra no requiere una contraseña.

Estadísticas de JMX de Cassandra

MBeans de JMX Atributos de 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

Usa nodetool para administrar los nodos del clúster

La utilidad nodetool es una interfaz de línea de comandos para Cassandra que administra los nodos del clúster. Puedes encontrar la utilidad en /opt/apigee/apigee-cassandra/bin.

Se pueden realizar las siguientes llamadas en todos los nodos del clúster de Cassandra:

  1. Información general del anillo (también es posible para un solo nodo de Cassandra): Busca "Up" y "Normal" para todos los nodos. 
    nodetool -h localhost ring

    El resultado del comando anterior se ve de la siguiente manera: 

    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. Información general sobre los nodos (llamada por nodo) 
    nodetool -h localhost info

    El resultado del comando anterior se ve de la siguiente manera:

    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. Estado del servidor Thrift (API de cliente de publicación) 
    nodetool -h localhost statusthrift

    El resultado del comando anterior se ve de la siguiente manera:

    running

  4. Estado de las operaciones de transmisión de datos: Observa el tráfico de los nodos de Cassandra: 
    nodetool -h localhost netstats

    El resultado del comando anterior se ve de la siguiente manera:

    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

Para obtener más información sobre nodetool, consulta Acerca de la utilidad nodetool.

Supervisión de Cassandra (IU)

Consulta la URL del centro de operaciones de DataStax: http://www.datastax.com/products/opscenter.

Recurso de Cassandra

Consulta la siguiente URL: http://www.datastax.com/docs/1.0/operations/monitoring.

Apache ZooKeeper

Verifica el estado de ZooKeeper

  1. Asegúrate de que el proceso de ZooKeeper se esté ejecutando. ZooKeeper escribe un archivo PID en opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid.
  2. Prueba los puertos de ZooKeeper para asegurarte de que puedas establecer una conexión TCP a los puertos 2181 y 3888 en todos los servidores de ZooKeeper.
  3. Asegúrate de que puedes leer valores de la base de datos de ZooKeeper. Conéctate con una biblioteca cliente de ZooKeeper (o /opt/apigee/apigee-zookeeper/bin/zkCli.sh) y lee un valor de la base de datos.
  4. Verifica el estado: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

Usa palabras de cuatro letras de ZooKeeper

ZooKeeper se puede supervisar a través de un pequeño conjunto de comandos (palabras de cuatro letras) que se envían al puerto 2181 con netcat (nc) o telnet.

Para obtener más información sobre los comandos de ZooKeeper, consulta la Referencia del comando de Apache ZooKeeper.

Por ejemplo:

  • srvr: Muestra los detalles completos del servidor.
  • stat: Muestra detalles breves del servidor y los clientes conectados.

Se pueden emitir los siguientes comandos al puerto de ZooKeeper:

  1. Ejecuta el comando de cuatro letras ruok para probar si el servidor se está ejecutando en un estado sin errores. Una respuesta correcta muestra "imok". 
    echo ruok | nc host 2181

    Se muestra lo siguiente:

    imok
  2. Ejecuta el comando de cuatro letras, stat, para enumerar el rendimiento del servidor y las estadísticas de los clientes conectados: 
    echo stat | nc host 2181

    Se muestra lo siguiente:

    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) no está disponible, puedes usar python como alternativa. Crea un archivo llamado zookeeper.py que contenga lo siguiente: 
    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)

    Ahora, ejecuta las siguientes líneas de Python:

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

Prueba a nivel de LDAP

Puedes supervisar OpenLDAP para ver si las solicitudes específicas se entregan correctamente. En otras palabras, busca una búsqueda específica que muestre el resultado correcto.

  1. Usa ldapsearch (yum install openldap-clients) para consultar la entrada del administrador del sistema. Esta entrada se usa para autenticar todas las llamadas a la 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

    Luego, se te solicitará la contraseña de administrador de LDAP:

    Enter LDAP Password:

    Después de ingresar la contraseña, verás una respuesta en el formulario:

    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. Verifica si el Servidor de administración aún está conectado a LDAP con el siguiente comando: 
    curl -u userEMail:password http://localhost:8080/v1/users/ADMIN

    Se muestra lo siguiente:

    {
  "emailId" : ADMIN,
  "firstName" : "admin",
  "lastName" : "admin"
}

También puedes supervisar las cachés de OpenLDAP, que ayudan a reducir la cantidad de accesos al disco y, por lo tanto, mejoran el rendimiento del sistema. Supervisar y, luego, ajustar el tamaño de la caché en el servidor OpenLDAP puede afectar en gran medida el rendimiento del servidor de directorio. Puedes ver los archivos de registro (opt/apigee/var/log) para obtener información sobre la caché.