Che cosa monitorare

Edge per Private Cloud v. 4.17.01

In genere, in una configurazione di produzione, è necessario abilitare i meccanismi di monitoraggio all'interno di un Deployment di Apigee Edge per il cloud privato. Queste tecniche di monitoraggio avvisano la rete amministratori (o operatori) di un errore o un errore. Ogni errore generato viene segnalato come su Apigee Edge. Per ulteriori informazioni sugli avvisi, consulta le best practice sul monitoraggio.

Per facilità, i componenti di Apigee sono classificati principalmente in due categorie:

• Servizi Java Server specifici di Apigee – Questi includono i servizi di gestione Server, Message Processor, Qpid Server e Postgres.
• Servizi di terze parti: tra questi ci sono router Nginx, Apache Cassandra, Apache ZooKeeper, OpenLDAP, database PostgreSQL e Qpid.

In un deployment on-premise di Apigee Edge, la tabella seguente offre una rapida panoramica i parametri che puoi monitorare:

In generale, dopo aver installato Apigee Edge, puoi eseguire il seguente monitoraggio per tenere traccia delle prestazioni di un'installazione di Apigee Edge per il cloud privato.

Controlli di integrità del sistema

È molto importante misurare i parametri di integrità del sistema, come l'utilizzo della CPU, l'utilizzo e la connettività delle porte. Puoi monitorare i seguenti parametri nozioni di base sull'integrità del sistema.

• Utilizzo CPU: specifica le statistiche di base (utente/sistema/IO) attesa/inattività) sull'utilizzo della CPU. Ad esempio, la CPU totale utilizzata dal sistema.
• Memoria libera/utilizzata: specifica l'utilizzo della memoria di sistema come byte. Ad esempio, la memoria fisica utilizzata dal sistema.
• Utilizzo spazio su disco: specifica le informazioni del file system in base a l'utilizzo attuale del disco. Ad esempio, spazio sul disco rigido utilizzato dal sistema.
• Load average: specifica il numero di processi in attesa fino a vengono eseguiti tutti i test delle unità.
• Statistiche di rete: pacchetti di rete e/o byte trasmessi e ricevuti, insieme agli errori di trasmissione relativi a un componente specifico.

Processi/controlli delle richieste

A livello di processo, puoi visualizzare informazioni importanti su tutti i processi in esecuzione. Ad esempio, sono incluse le statistiche sull'utilizzo della memoria e della CPU che un processo o un'applicazione utilizzato. Per processi come qpidd, postgres postmaster, java e così via, puoi monitorare seguenti:

• Identificazione dei processi: identifica un particolare processo Apigee. Ad esempio: puoi monitorare l'esistenza di un processo Java del server Apigee.
• Statistiche sui thread: visualizza i pattern di thread sottostanti utilizzati da un processo utilizzi. Ad esempio, puoi monitorare il numero di thread di picco, il numero di thread per tutti i processi.
• Utilizzo memoria: visualizza l'utilizzo della memoria per tutti i processi Apigee. Ad esempio, puoi monitorare parametri come utilizzo della memoria heap e memoria non heap utilizzata in base a un processo.

Controlli a livello di API

A livello di API, puoi monitorare se il server è attivo e in esecuzione per le API utilizzate di frequente inviate tramite proxy da Apigee. Ad esempio, puoi eseguire il controllo delle API sul server di gestione, sul router e il processore di messaggi richiamando il seguente comando cURL:

curl http://<host>:<port>/v1/servers/self/up

Dove &lt;host&gt; è l'IP del componente Apigee Edge. <port> è specifico di ogni componente Edge. Ad esempio:

Server di gestione: 8080

• Router: 8081
• Processore di messaggi: 8082
• e così via

Consulta le singole sezioni riportate di seguito per informazioni sull'esecuzione di questo comando per ogni componente

Questa chiamata restituisce il valore "true" e "false". Per ottenere risultati ottimali, puoi anche effettuare chiamate API direttamente sul backend (con cui interagisce il software Apigee) per determinare rapidamente se esiste un errore all'interno dell'ambiente software Apigee o nel backend.

Nota: per monitorare i proxy API, puoi anche utilizzare API Health di Apigee. L'integrità delle API rende di chiamate pianificate ai proxy API e ti avvisa in caso di errori e in che modo. Quando le chiamate hanno esito positivo, API Health mostra i tempi di risposta e può persino inviarti una notifica quando la latenza di risposta è elevata. API Health può effettuare chiamate da diverse località in tutto il mondo per confrontare il comportamento delle API tra regioni.

Controlli del flusso dei messaggi

Puoi raccogliere i dati dai router e dai processori di messaggi sul flusso dei messaggi modello/statistica. In questo modo puoi monitorare quanto segue:

• Numero di client attivi
• Numero di risposte (10X, 20X, 30X, 40X e 50X)
• Errori di connessione

Questo ti aiuta a fornire dashboard per il flusso dei messaggi delle API.

Controllo di integrità del router del processore di messaggi

Il router implementa un meccanismo di controllo di integrità per determinare quale processore di messaggi funzionino come previsto. Se un processore di messaggi viene rilevato come inattivo o lento, il router automaticamente dalla rotazione il processore di messaggi. In questo caso, il router scrive "Annota" al file di log del router all'indirizzo /opt/apigee/var/log/edge-router/logs/system.log.

Puoi monitorare il file di log del router per questi messaggi. Ad esempio, se il router prende una Il processore di messaggi fuori rotazione scrive il messaggio nel log nel 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

dove /&lt;MP_IP&gt;:&lt;PORT&gt; è l'indirizzo IP e di porta del processore di messaggi.

Se in un secondo momento il router esegue un controllo di integrità e determina che il processore di messaggi è funzionando correttamente, il router rimette automaticamente in rotazione il processore di messaggi. La Il router scrive anche un "markup" al log nel modulo:

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