Como monitorar

Edge para nuvem privada v4.18.05

Neste documento, descrevemos as técnicas de monitoramento de componentes compatíveis com uma implantação local do Apigee Edge.

Visão geral

O Edge oferece suporte a várias maneiras de receber detalhes sobre os serviços e verificar os statuses deles. A tabela a seguir lista os tipos de verificações que podem ser realizadas em cada serviço qualificado:

Serviço JMX:*
Uso da memória
API Mgmt:
Verificação de serviço
API Mgmt:
Status do usuário/organização/ implantação
API Mgmt:
axstatus
Verificação do banco de dados Status de apigee-service
Servidor de gerenciamento
processador de mensagens
Postgres
Qpid
Roteador
Mais informações Mais informações Mais informações Mais informações Mais informações Mais informações
* Antes de usar o JMX, é necessário ativá-lo, conforme descrito em Ativar JMX.

Portas de monitoramento da JMX e da API Management

Cada componente oferece suporte a chamadas de monitoramento da API Management e JMX em portas diferentes. A tabela a seguir lista as portas JMX e da API Management para cada tipo de servidor:

Componente Porta JMX Porta da API Management
Servidor de gerenciamento 1099 8080
Roteador 1100 8081
processador de mensagens 1101 8082
Qpid 1102 8083
Postgres 1103 8084

Usar o JMX

Os processos de monitoramento do servidor de gerenciamento, do processador de mensagens, do Qpid e do Postgres usam JMX. No entanto, a JMX é ativada por padrão apenas para o Cassandra e desativada por padrão para todos os outros componentes do Edge. Portanto, é necessário ativar o JMX individualmente para cada componente antes de monitorá-los.

A autenticação JMX não está ativada por padrão. É possível ativar a autenticação JMX para todos os componentes, exceto o Cassandra.

Ativar o JMX

A JMX é ativada por padrão apenas para o Cassandra e desativada por padrão para todos os outros componentes do Edge. Esta seção descreve como ativar o JMX para os outros componentes do Edge.

Para ativar o JMX:

  1. Edite o arquivo de configuração do componente. Esse arquivo está localizado em opt/apigee/edge-component_name/bin/start. Em ambientes de produção, esses arquivos de configuração estarão em máquinas diferentes.

    Escolha um dos seguintes locais de arquivo em cada servidor:

    • Servidor de gerenciamento: /opt/apigee/edge-management-server/bin/start
    • Processador de mensagens: /opt/apigee/edge-message-processor/bin/start
    • Postgres: /opt/apigee/edge-postgres-server/bin/start
    • Qpid: /opt/apigee/edge-qpid-server/bin/start
    • Roteador: /opt/apigee/edge-router/bin/start

    Por exemplo, o arquivo de configuração do servidor de gerenciamento no servidor está em /opt/apigee/edge-management-server/bin/start.

  2. Adicione as seguintes opções com.sun.management.jmxremote à linha exec que inicia o 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

    Em que port_number é a porta JMX do serviço. Para conferir o número da porta JMX do seu serviço, consulte Portas de monitoramento da API JMX e Management.

    Por exemplo, para ativar o JMX no servidor de gerenciamento, adicione o seguinte ao arquivo de configuração do servidor de gerenciamento:

    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

    Este exemplo especifica a porta 1099 para o servidor de gerenciamento. Conforme dito anteriormente, cada serviço tem o próprio número de porta.

    A linha editada no arquivo de configuração fica assim:

    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. Salve o arquivo de configuração.
  4. Reinicie o componente com o comando restart.

    Por exemplo, para reiniciar o servidor de gerenciamento, execute o seguinte comando:

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

A autenticação para JMX não está ativada por padrão. É possível ativar a autenticação JMX para todos os componentes, exceto o Cassandra, conforme descrito em Ativar a autenticação JMX.

Ativar a autenticação JMX

A autenticação JMX não está ativada por padrão. É possível ativar a autenticação JMX para todos os componentes, exceto o Cassandra.

Para ativar a autenticação JMX, execute a seguinte ação change_jmx_auth em todos os nós:

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

Em que:

  • component é um dos seguintes:
    • edge-management-server
    • edge-message-processor
    • edge-postgres-server
    • edge-qpid-server
    • edge-router
  • options especifica o seguinte:
    • -u username
    • -p password
    • -e [y|n] (ativar ou desativar)
  • config_file especifica o local de um arquivo de configuração em que você define o seguinte:
    • JMX_USERNAME=username
    • JMX_ENABLED=y|n
    • JMX_PASSWORD=password (se não for definido ou não for transmitido com -p, você receberá uma solicitação)

É possível usar as opções de linha de comando ou o arquivo de configuração para definir o nome de usuário, a senha e o estado de ativação/desativação. Não é possível especificar um conjunto de opções e um arquivo de configuração.

O exemplo a seguir ativa a autenticação JMX para o servidor de gerenciamento usando as opções de linha de comando:

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

O exemplo a seguir usa um arquivo de configuração em vez de opções de linha de comando:

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

Se você estiver executando o Edge em vários nós, execute o comando em todos os nós, especificando o mesmo nome de usuário e senha.

Para desativar a autenticação JMX na linha de comando, use a opção "-e n", conforme mostrado no exemplo abaixo:

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

Monitorar com o JConsole

Use o JConsole (uma ferramenta compatível com JMX) para gerenciar e monitorar a verificação de integridade e processar estatísticas. Com o JConsole, é possível consumir estatísticas JMX expostas pelos servidores e exibi-las em uma interface gráfica. Para mais informações, consulte Como usar o JConsole.

O JConsole usa o seguinte URL de serviço para monitorar os atributos JMX (MBeans) oferecidos pelo JMX:

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

Em que:

  • IP_address é o endereço IP do servidor que você quer monitorar.
  • port_number é o número da porta JMX do servidor que você quer monitorar.

Por exemplo, para monitorar o servidor de gerenciamento, emita um comando como este (supondo que o endereço IP do servidor seja 216.3.128.12):

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

Este exemplo especifica a porta 1099, que é a porta JMX do servidor de gerenciamento. Para outras portas, consulte Portas de monitoramento da API Management e JMX.

A tabela a seguir mostra as estatísticas genéricas do JMX:

MBeans do JMX Atributos JMX

Memória

HeapMemoryUsage

NonHeapMemoryUsage

Uso

Monitorar com a API Management

O Edge inclui várias APIs que podem ser usadas para realizar verificações de serviço nos servidores, além de conferir usuários, organizações e implantações. Esta seção descreve essas APIs.

Executar verificações de serviço

A API de gerenciamento fornece vários endpoints para monitorar e diagnosticar problemas nos serviços. Esses endpoints incluem:

Endpoint Descrição
/servers/self/up

Verifica se um serviço está em execução. Essa chamada de API não exige autenticação.

Se o serviço estiver em execução, esse endpoint vai retornar a seguinte resposta:

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

Se o serviço não estiver em execução, você receberá uma resposta semelhante a esta, dependendo do serviço e de como você o verificou:

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

Retorna informações sobre o serviço, incluindo:

  • Propriedades de configuração
  • Horário de início e horário de atividade
  • Informações sobre build, RPM e UUID
  • Nome de host interno e externo e endereço IP
  • Região e pod
  • Propriedade <isUp>, que indica se o serviço está em execução

Esta chamada de API exige que você faça a autenticação com suas credenciais de administrador da Apigee.

Para usar esses endpoints, invoque um utilitário, como curl, com comandos que usam a seguinte sintaxe:

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

Em que:

  • host é o endereço IP do servidor que você quer verificar. Se você estiver conectado ao servidor, use "localhost". Caso contrário, especifique o endereço IP do servidor, bem como o nome de usuário e a senha.
  • port_number é a porta da API Management para o servidor que você quer verificar. Essa porta é diferente para cada tipo de componente. Por exemplo, a porta da API Management do servidor de gerenciamento é 8080. Para conferir uma lista de números de porta da API Management a serem usados, consulte Portas de monitoramento da API Management e JMX.

Para mudar o formato da resposta, especifique o cabeçalho Accept como "application/json" ou "application/xml".

O exemplo a seguir recebe o status do roteador no localhost (porta 8081):

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

O exemplo a seguir mostra informações sobre o processador de mensagens em 216.3.128.12 (porta 8082):

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

Monitorar o status do usuário, da organização e da implantação

Use a API de gerenciamento para monitorar o status do usuário, da organização e da implantação de seus proxies em servidores de gerenciamento e processadores de mensagens executando os seguintes 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

Em que port_number é 8080 para o servidor de gerenciamento ou 8082 para o processador de mensagens.

Essa chamada exige que você faça a autenticação com o nome de usuário e a senha de administração do sistema.

O servidor retornará o status "implantado" em todas as chamadas. Se eles falharem, faça o seguinte:

  1. Verifique se há erros nos registros do servidor. Os registros estão localizados em:
    • Servidor de gerenciamento: opt/apigee/var/log/edge-management-server
    • Processador de mensagens: opt/apigee/var/log/edge-message-processor
  2. Faça uma chamada para verificar se o servidor está funcionando corretamente.
  3. Remova o servidor do ELB e reinicie-o:
    /opt/apigee/apigee-service/bin/apigee-service service_name restart

    Onde service_name é:

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

Verificar o status com o comando apigee-service

É possível resolver problemas nos serviços do Edge usando o comando apigee-service quando você está conectado ao servidor que executa o serviço.

Para verificar o status de um serviço com apigee-service:

  1. Faça login no servidor e execute o seguinte comando:
    /opt/apigee/apigee-service/bin/apigee-service service_name status

    Em que service_name é um dos seguintes:

    • Servidor de gerenciamento: edge-management-server
    • Processador de mensagens: edge-message-processor
    • Postgres: edge-postgres-server
    • Qpid: edge-qpid-server
    • Roteador: edge-router

    Exemplo:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor status
  2. Se o serviço não estiver em execução, inicie-o:
    /opt/apigee/apigee-service/bin/apigee-service service_name start
  3. Depois de reiniciar o serviço, verifique se ele está funcionando usando o comando apigee-service status usado anteriormente ou a API Management descrita em Monitorar com a API Management.

    Exemplo:

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

    em que port_number é a porta da API Management para o serviço.

    Neste exemplo, presumimos que você tenha feito login no servidor e possa usar "localhost" como nome do host. Para verificar o status remotamente com a API de gerenciamento, você precisa especificar o endereço IP do servidor e incluir o nome de usuário e a senha do administrador do sistema na chamada de API.

Monitoramento do Postgres

O Postgres é compatível com vários utilitários que você pode usar para verificar o status dele. Esses utilitários são descritos nas seções a seguir.

Verificar organizações e ambientes no Postgres

É possível verificar os nomes de organização e ambiente integrados no servidor Postgres emitindo o seguinte comando curl:

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

O sistema mostra o nome da organização e do ambiente.

Verificar o status da análise

É possível verificar o status dos servidores de análise do Postgres e do Qpid emitindo o seguinte comando curl:

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

O sistema vai mostrar um status de sucesso para todos os servidores de análise, como mostra o exemplo abaixo:

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

Banco de dados PostgreSQL

Nesta seção, descrevemos as técnicas que podem ser usadas especificamente para monitorar o banco de dados do Postgres.

Usar o script check_postgres.pl

Para monitorar o banco de dados PostgreSQL, use um script de monitoramento padrão, check_postgres.pl. Para mais informações, consulte http://bucardo.org/wiki/Check_postgres.

Antes de executar o script:

  1. Você precisa instalar o script check_postgres.pl em cada nó do Postgres.
  2. Verifique se você instalou o perl-Time-HiRes.x86_64, um módulo Perl que implementa timers de alarme, suspensão, gettimeofday e intervalo de alta resolução. Por exemplo, é possível instalá-lo usando o seguinte comando:
    yum install perl-Time-HiRes.x86_64
  3. CentOS 7: antes de usar o check_postgres.pl no CentOS v7, instale o RPM perl-Data-Dumper.x86_64.

saída de check_postgres.pl

A saída padrão das chamadas de API que usam check_postgres.pl é compatível com Nagios. Depois de instalar o script, faça as seguintes verificações:

  1. Verifique o tamanho do banco de dados:
    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. Confira o número de conexões recebidas no banco de dados e compare com o número máximo de conexões permitidas:
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends
  3. Verifique se o banco de dados está em execução e disponível:
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection
  4. Verifique o espaço em disco:
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'
  5. Confira o número de organizações e ambientes integrados em um nó do 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

Executar verificações do banco de dados

É possível verificar se as tabelas corretas foram criadas no banco de dados do PostgreSQL. Faça login no banco de dados PostgreSQL usando o seguinte comando:

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

Depois, execute:

\d analytics."org.env.fact"

Verificar o status de integridade do processo postgres

Para fazer verificações de API na máquina Postgres, invoque o seguinte comando curl:

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

Esse comando retorna o status ACTIVE quando o processo postgres está ativo. Se o processo do Postgres não estiver em execução, ele retornará o status INACTIVE.

Recursos do Postgres

Para mais informações sobre como monitorar o serviço do Postgres, consulte:

Apache Cassandra

Use o JConsole: monitore as estatísticas das tarefas

Use o JConsole e o URL de serviço a seguir para monitorar os atributos JMX (MBeans) oferecidos pelo JMX:

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

Em que IP_address é o IP do servidor do Cassandra.

O JMX é ativado por padrão para o Cassandra, e o acesso remoto do JMX ao Cassandra não requer uma senha.

Estatísticas do JMX do Cassandra

MBeans do JMX Atributos JMX

ColumnFamilies/apprepo/environments

ColumnFamilies/apprepo/organizations

ColumnFamilies/apprepo/apiproxy_revisions

ColumnFamilies/apprepo/apiproxies

ColumnFamilies/auditoria/auditorias

ColumnFamilies/audit/audits_ref

PendingTasks

MemtableColumnsCount

MemtableDataSize

ReadCount

RecentReadLatencyMicros

TotalReadLatencyMicros

WriteCount

RecentWriteLatencyMicros

TotalWriteLatencyMicros

TotalDiskSpaceUsed

LiveDiskSpaceUsed

LiveSSTableCount

BloomFilterFalsePositives

RecentBloomFilterFalseRatio

BloomFilterFalseRatio

Usar o nodetool para gerenciar nós de cluster

O utilitário nodetool é uma interface de linha de comando do Cassandra que gerencia nós de cluster. O utilitário pode ser encontrado em /opt/apigee/apigee-cassandra/bin.

As seguintes chamadas podem ser feitas em todos os nós de cluster do Cassandra:

  1. Informações gerais do anel (também possível para um único nó do Cassandra): procure "Up" e "Normal" para todos os nós.
    nodetool -h localhost ring

    A saída do comando acima tem a seguinte aparência:

    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. Informações gerais sobre nós (chamada por nó)
    nodetool -h localhost info

    A saída do comando acima vai ser semelhante a esta:

    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. Status do servidor thrift (servindo a API do cliente)
    nodetool -h localhost statusthrift

    A saída do comando acima é semelhante a esta:

    running

  4. Status das operações de streaming de dados: observe o tráfego dos nós do Cassandra:
    nodetool -h localhost netstats

    A saída do comando acima é semelhante a esta:

    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 mais informações sobre nodetool, consulte Sobre o utilitário nodetool.

Monitoramento do Cassandra (interface)

Consulte o URL do Datastax OpsCenter: http://www.datastax.com/products/opscenter.

Recurso do Cassandra

Acesse o seguinte URL: http://www.datastax.com/docs/1.0/operations/monitoring.

Apache ZooKeeper

Verificar o status do ZooKeeper

  1. Verifique se o processo ZooKeeper está em execução. O ZooKeeper grava um arquivo PID em opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid.
  2. Teste as portas do ZooKeeper para garantir que você possa estabelecer uma conexão TCP com as portas 2181 e 3888 em todos os servidores do ZooKeeper.
  3. Verifique se você consegue ler valores do banco de dados do ZooKeeper. Conecte-se usando uma biblioteca de cliente do ZooKeeper (ou /opt/apigee/apigee-zookeeper/bin/zkCli.sh) e leia um valor do banco de dados.
  4. Verifique o status:
    /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

Usar palavras de quatro letras do ZooKeeper

O ZooKeeper pode ser monitorado por um pequeno conjunto de comandos (palavras de quatro letras) enviados para a porta 2181 usando o netcat (nc) ou o telnet.

Para mais informações sobre os comandos do ZooKeeper, consulte: Referência de comandos do Apache ZooKeeper.

Exemplo:

  • srvr: lista os detalhes completos do servidor.
  • stat: lista detalhes breves do servidor e dos clientes conectados.

Os comandos a seguir podem ser emitidos para a porta do ZooKeeper:

  1. Execute o comando de quatro letras "ruok" para testar se o servidor está em execução sem erros. Uma resposta bem-sucedida retorna "imok".
    echo ruok | nc host 2181

    Retorna:

    imok
  2. Execute o comando de quatro letras, stat, para listar a performance do servidor e as estatísticas dos clientes conectados:
    echo stat | nc host 2181

    Retorna:

    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. Se o netcat (nc) não estiver disponível, use o Python como alternativa. Crie um arquivo chamado zookeeper.py que contenha o seguinte:
    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)

    Agora, execute as seguintes linhas do Python:

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

Teste no nível do LDAP

É possível monitorar o OpenLDAP para saber se as solicitações específicas são atendidas corretamente. Em outras palavras, verifique se há uma pesquisa específica que retorna o resultado correto.

  1. Use ldapsearch (yum install openldap-clients) para consultar a entrada do administrador do sistema. Essa entrada é usada para autenticar todas as chamadas de 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

    Em seguida, você precisará digitar a senha de administrador do LDAP:

    Enter LDAP Password:

    Depois de inserir a senha, você verá uma resposta no formulário:

    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. Verifique se o servidor de gerenciamento ainda está conectado ao LDAP com o seguinte comando:
    curl -u userEMail:password http://localhost:8080/v1/users/ADMIN

    Retorna:

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

Também é possível monitorar os caches do OpenLDAP, que ajudam a reduzir o número de acessos ao disco e, portanto, melhoram o desempenho do sistema. Monitorar e ajustar o tamanho do cache no servidor OpenLDAP pode afetar bastante o desempenho do servidor de diretório. Você pode ver os arquivos de registro (opt/apigee/var/log) para conseguir informações sobre o cache.