O que monitorar

Edge para nuvem privada v. 4.17.09

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 alertam os administradores de rede (ou operadores) sobre um erro ou falha. Todos os erros gerados são informados como um alerta no Apigee Edge. Para mais informações sobre alertas, consulte Práticas recomendadas de monitoramento.

Para facilitar, os componentes do 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 roteador Nginx, Apache Cassandra, Apache ZooKeeper, OpenLDAP, banco de dados PostgreSQL e Qpid.

Em uma implantação local do Apigee Edge, a tabela a seguir mostra rapidamente os 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

?

?

Nginx Router

?

?

?

Em geral, depois que o Apigee Edge for instalado, você pode realizar as seguintes tarefas de monitoramento para acompanhar o desempenho de uma instalação do Apigee Edge for Private Cloud.

Verificações de integridade do sistema

É muito importante medir os parâmetros de integridade do sistema, como a utilização da CPU, da memória e a conectividade da porta em um nível mais alto. É possível monitorar os parâmetros a seguir para conferir os conceitos básicos de integridade do sistema.

  • Utilização da CPU: especifica as estatísticas básicas (Espera de usuário/Sistema/E/S) sobre a utilização da CPU. Por exemplo, a CPU total usada pelo sistema.
  • Memória livre/usada: especifica a utilização 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.
  • Load average: especifica o número de processos que aguardam a execução.
  • 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 conferir informações importantes sobre todos os processos que estão em execução. Por exemplo, elas incluem 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 de processo: identifica 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 linha de execução: confira os padrões de linha de execução usados por um processo. Por exemplo, é possível monitorar a contagem máxima de linhas e a contagem de linhas de todos os processos.
  • Utilização de memória: confira o uso de memória de todos os processos da Apigee. Por exemplo, é possível monitorar parâmetros como o uso de memória heap e o uso de memória não-heap usado por um processo.

Verificações no nível da API

No nível da API, é possível monitorar se o servidor está ativo para chamadas de API usadas com frequência que são proxied pelo Apigee. Por exemplo, é possível fazer 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 do 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 em cada componente.

Essa chamada retorna "true" e "false". Para melhores resultados, você também pode 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 do software da Apigee ou no back-end.

Observação: para monitorar os proxies de API, você também pode usar a API Health da Apigee. A integridade da API faz chamadas programadas para os proxies da API e notifica você quando elas falham e como. Quando as chamadas são concluídas, a API Health mostra os tempos de resposta e pode até mesmo notificar quando a latência de resposta é alta. A API Health pode fazer chamadas de diferentes locais do mundo para comparar o comportamento da API entre regiões.

Verificações de 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 você a fornecer painéis para o fluxo de mensagens da API. Para mais informações, consulte:

Verificação de integridade do roteador do processador de mensagens

O roteador implementa um mecanismo de verificação de integridade para determinar quais dos processadores de mensagens estão funcionando conforme o esperado. Se um processador de mensagens for detectado como inativo ou lento, o roteador poderá tirar o processador de mensagens da rotação automaticamente. 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 essas mensagens. Por exemplo, se o roteador tirar um processador de mensagens da rotação, ele gravará a 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 fizer uma verificação de integridade e determinar que o processador de mensagens está funcionando corretamente, o roteador vai colocar o processador de mensagens de volta na rotação automaticamente. O roteador também grava uma mensagem "Marcação" 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