Edge for Private Cloud versione 4.17.09
In genere, in una configurazione di produzione è necessario attivare i meccanismi di monitoraggio all'interno di un deployment di Apigee Edge for Private Cloud. Queste tecniche di monitoraggio avvisano gli amministratori (o gli operatori) della rete di un errore o di un malfunzionamento. Ogni errore generato viene segnalato come avviso in 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: tra cui Management Server, Message Processor, Qpid Server e Postgres Server.
- Servizi di terze parti: questi includono 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 dei parametri che puoi monitorare:
Componente |
Controlli di sistema |
Statistiche a livello di processo |
Controlli a livello di API |
Controlli del flusso dei messaggi |
Specifico per componente |
|
---|---|---|---|---|---|---|
Servizi Java specifici di Apigee |
Server di gestione |
? |
? |
? |
||
processore di messaggi |
? |
? |
? |
? |
||
Qpid Server |
? |
? |
? |
|||
Server Postgres |
? |
? |
? |
|||
Servizi di terze parti |
Apache Cassandra |
? |
? |
|||
Apache ZooKeeper |
? |
? |
||||
OpenLDAP |
? |
? |
||||
Database PostgreSQL |
? |
? |
||||
Qpid |
? |
? |
||||
Router Nginx |
? |
? |
? |
In generale, dopo l'installazione di Apigee Edge, puoi eseguire le seguenti attività di 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 della memoria e la connettività delle porte a un livello superiore. Puoi monitorare i seguenti parametri per avere informazioni di base sullo stato del sistema.
- Utilizzo CPU: specifica le statistiche di base (utente/sistema/attesa IO/inattività) sull'utilizzo della CPU. Ad esempio, la CPU totale utilizzata dal sistema.
- Memoria libera/utilizzata: specifica l'utilizzo della memoria di sistema in byte. Ad esempio, la memoria fisica utilizzata dal sistema.
- Utilizzo spazio su disco: specifica le informazioni sul file system in base all'utilizzo corrente del disco. Ad esempio, lo spazio sul disco rigido utilizzato dal sistema.
- Carico medio: specifica il numero di processi in attesa di essere eseguiti.
- Statistiche di rete: pacchetti e/o byte di rete trasmessi e ricevuti, insieme agli errori di trasmissione relativi a un componente specificato.
Controlli di processi/applicazioni
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 utilizzate da un processo o da un'applicazione. Per processi come qpidd, postgres postmaster, java e così via, puoi monitorare quanto segue:
- Identificazione dei processi: identifica un particolare processo Apigee. Ad esempio, puoi monitorare l'esistenza di un processo Java del server Apigee.
- Statistiche thread: visualizza i pattern di threading sottostanti utilizzati da un processo. Ad esempio, puoi monitorare il numero di thread di picco e 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 l'utilizzo della memoria heap e la memoria non heap utilizzata da un processo.
Controlli a livello di API
A livello di API, puoi monitorare se il server è attivo e funzionante per le chiamate API di uso frequente con proxy di Apigee. Ad esempio, puoi eseguire il controllo dell'API sul server di gestione, sul router e sul gestore dei messaggi richiamando il seguente comando cURL:
curl http://<host>:<port>/v1/servers/self/up
dove <host> è l'indirizzo IP del componente Apigee Edge. Il numero <port> è specifico per ogni componente Edge. Ad esempio:
Server di gestione: 8080
- Router: 8081
- Message Processor: 8082
- e così via
Consulta le singole sezioni di seguito per informazioni sull'esecuzione di questo comando per ciascun componente.
Questa chiamata restituisce "true" e "false". Per risultati ottimali, puoi anche emettere chiamate API direttamente sul backend (con cui interagisce il software Apigee) per determinare rapidamente se esiste un errore nell'ambiente software Apigee o nel backend.
Nota: per monitorare i proxy API, puoi anche utilizzare API Health di Apigee. Lo stato dell'API effettua chiamate programmate ai proxy API e ti avvisa quando non vanno a buon fine e in che modo. Quando le chiamate vanno a buon fine, lo stato dell'API mostra i tempi di risposta e può persino inviarti una notifica quando la latenza di risposta è elevata. API Health può effettuare chiamate da località diverse in tutto il mondo per confrontare il comportamento delle API tra regioni.
Controlli del flusso dei messaggi
Puoi raccogliere dati da router e elaboratori di messaggi relativi a pattern/statistiche sul flusso di messaggi. In questo modo puoi monitorare quanto segue:
- Numero di client attivi
- Numero di risposte (10X, 20X, 30X, 40X e 50X)
- Errori di connessione
In questo modo puoi fornire dashboard per il flusso di messaggi dell'API. Per saperne di più, consulta:
- Istruzioni per il monitoraggio del processore di messaggi
- Panoramica della dashboard di monitoraggio Apigee beta per il router
Controllo di integrità del router del Message Processor
Il router implementa un meccanismo di controllo di integrità per determinare quali elaboratori di messaggi funzionano come previsto. Se un Message Processor viene rilevato come inattivo o lento, il Router può ritirarlo automaticamente dalla rotazione. In questo caso, il router scrive un messaggio "Mark Down" nel file di log del router in /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 disattiva un processore di messaggi, scrive un 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 /<MP_IP>:<PORT> sono l'indirizzo IP e il numero di porta del processore di messaggi.
Se in un secondo momento il router esegue un controllo di integrità e determina che il Message Processor funziona correttamente, lo inserisce automaticamente di nuovo nella rotazione. Il router scrive anche un messaggio "Mark Up" nel log nel seguente 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