Edge para nuvem privada v4.18.01
Geralmente, em uma configuração de produção, é necessário ativar mecanismos de monitoramento em uma implantação do Apigee Edge para nuvem privada. Essas técnicas de monitoramento avisam os administradores (ou operadores) da rede sobre um erro ou uma falha. Cada erro gerado é relatado como um alerta na Apigee Edge. Para mais informações sobre alertas, consulte Práticas recomendadas de monitoramento.
Para facilitar, os componentes da Apigee são classificados principalmente em duas categorias:
- Serviços de servidor Java específicos da Apigee: incluem o servidor de gerenciamento, o processador de mensagens, o servidor Qpid e o servidor Postgres.
- Serviços de terceiros: incluem o roteador Nginx, o Apache Cassandra, o Apache ZooKeeper, o OpenLDAP, o banco de dados PostgreSQL e o Qpid.
Em uma implantação no local do Apigee Edge, a tabela a seguir fornece uma visão rápida dos parâmetros que podem ser monitorados:
|
Componente |
Verificações do sistema |
Estatísticas no nível do processo |
Verificações no nível da API |
Verificações de fluxo de mensagens |
Específico do componente |
|
|---|---|---|---|---|---|---|
|
Serviços Java específicos da Apigee |
Servidor de gerenciamento |
? |
? |
? |
||
|
processador de mensagens |
? |
? |
? |
? |
||
|
Servidor Qpid |
? |
? |
? |
|||
|
Servidor Postgres |
? |
? |
? |
|||
|
Serviços de terceiros |
Apache Cassandra |
? |
? |
|||
|
Apache ZooKeeper |
? |
? |
||||
|
OpenLDAP |
? |
? |
||||
|
Banco de dados PostgreSQL |
? |
? |
||||
|
Qpid |
? |
? |
||||
|
Roteador Nginx |
? |
? |
? |
|||
Em geral, depois que o Apigee Edge é instalado, é possível realizar as seguintes tarefas de monitoramento para acompanhar o desempenho de uma instalação do Apigee Edge para nuvem privada.

Verificações de integridade do sistema
É muito importante medir os parâmetros de integridade do sistema, como uso da CPU, uso da memória e conectividade de portas em um nível mais alto. É possível monitorar os seguintes parâmetros para entender os princípios básicos da integridade do sistema.
- Uso da CPU: especifica as estatísticas básicas (usuário/sistema/espera de E/S/ocioso) sobre o uso da CPU. Por exemplo, o total de CPU usado pelo sistema.
- Memória livre/usada: especifica o uso da memória do sistema em bytes. Por exemplo, a memória física usada pelo sistema.
- Uso de espaço em disco: especifica as informações do sistema de arquivos com base no uso atual do disco. Por exemplo, o espaço em disco rígido usado pelo sistema.
- Média de carga: especifica o número de processos aguardando para serem executados.
- Estatísticas de rede: pacotes de rede e/ou bytes transmitidos e recebidos, além dos erros de transmissão sobre um componente especificado.
Verificações de processos/aplicativos
No nível do processo, é possível ver informações importantes sobre todos os processos em execução. Por exemplo, isso inclui estatísticas de uso de memória e CPU que um processo ou aplicativo utiliza. Para processos como qpidd, postgres postmaster, java e assim por diante, é possível monitorar o seguinte:
- Identificação do processo: identifique um processo específico da Apigee. Por exemplo, é possível monitorar a existência de um processo Java do servidor da Apigee.
- Estatísticas de linhas de execução: confira os padrões de linhas de execução que um processo usa. Por exemplo, é possível monitorar o pico de contagem de linhas de execução e a contagem de linhas de execução de todos os processos.
- Uso da memória: confira o uso da memória em todos os processos da Apigee. Por exemplo, é possível monitorar parâmetros como o uso da memória heap e o uso da memória não heap usada por um processo.
Verificações no nível da API
No nível da API, é possível monitorar se o servidor está em execução para chamadas de API usadas com frequência e que têm proxy da Apigee. Por exemplo, é possível realizar a verificação da API no servidor de gerenciamento, no roteador e no processador de mensagens invocando o seguinte comando cURL:
curl http://<host>:<port>/v1/servers/self/up
Em que <host> é o endereço IP do componente da Apigee Edge. O número <port> é específico para cada componente do Edge. Exemplo:
Servidor de gerenciamento: 8080
- Roteador: 8081
- Processador de mensagens: 8082
- etc.
Consulte as seções individuais abaixo para saber como executar esse comando para cada componente.
Essa chamada retorna "true" e "false". Para melhores resultados, também é possível emitir chamadas de API diretamente no back-end (com o qual o software da Apigee interage) para determinar rapidamente se há um erro no ambiente de software da Apigee ou no back-end.
Observação: para monitorar seus proxies de API, use também a integridade da API da Apigee. A integridade da API faz chamadas programadas para seus proxies de API e notifica você quando e como eles falham. Quando as chamadas são bem-sucedidas, a integridade da API mostra os tempos de resposta e pode até notificar você quando a latência de resposta é alta. A integridade da API pode fazer chamadas de diferentes locais do mundo para comparar o comportamento da API entre as regiões.
Verificações do fluxo de mensagens
É possível coletar dados de roteadores e processadores de mensagens sobre o padrão/as estatísticas do fluxo de mensagens. Isso permite monitorar o seguinte:
- Número de clientes ativos
- Número de respostas (10X, 20X, 30X, 40X e 50X)
- Falhas de conexão
Isso ajuda a fornecer painéis para o fluxo de mensagens da API. Para mais informações, consulte:
- Como monitorar o processador de mensagens
- Visão geral da versão Beta do painel de monitoramento da Apigee para o roteador
Verificação de integridade do roteador do processador de mensagens
O roteador implementa um mecanismo de verificação de integridade para determinar quais processadores de mensagens estão funcionando conforme o esperado. Se um processador de mensagens for detectado como inativo ou lento, o roteador poderá retirá-lo automaticamente da rotação. Se isso acontecer, o roteador vai gravar uma mensagem "Mark Down" no arquivo de registro do roteador em /opt/apigee/var/log/edge-router/logs/system.log.
É possível monitorar o arquivo de registro do roteador para ver essas mensagens. Por exemplo, se o roteador remover um processador de mensagens da rotação, ele vai gravar uma mensagem no registro no formato:
2014-05-06 15:51:52,159 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now DISCONNECTED. handle = <MP_IP> at 1399409512159 2014-04-17 12:54:48,512 org: env: nioEventLoopGroup-2-2 INFO HEARTBEAT - HBTracker.gotResponse() : No HeartBeat detected from /<MP_IP>:<PORT> Mark Down
em que /<MP_IP>:<PORT> é o endereço IP e o número da porta do processador de mensagens.
Se, mais tarde, o roteador realizar uma verificação de integridade e determinar que o processador de mensagens está funcionando corretamente, ele vai colocar o processador de mensagens de volta em rotação. O roteador também grava uma mensagem "Mark Up" no registro no formato:
2014-05-06 16:07:29,054 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now CONNECTED. handle = <IP> at 1399410449054 2014-04-17 12:55:06,064 org: env: nioEventLoopGroup-4-1 INFO HEARTBEAT - HBTracker.updateHB() : HeartBeat detected from /<IP>:<PORT> Mark Up