Questa pagina è stata tradotta dall'API Cloud Translation.

Che cosa monitorare

Edge for Private Cloud versione 4.16.09

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 gli amministratori (o gli operatori) della rete di un errore o di un malfunzionamento. 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 fornisce un rapido riepilogo dei parametri che puoi monitorare:

Componente		Controlli di sistema	Statistiche a livello di processo	Controlli a livello di API	Controlli del flusso di messaggi	Specifico per componente
Servizi Java specifici per Apigee	Server di gestione	?	?	?
	processore di messaggi	?	?	?	?
	Server Qpid	?	?	?
	Server Postgres	?	?	?
Servizi di terze parti	Apache Cassandra	?				?
	Apache ZooKeeper	?				?
	OpenLDAP	?				?
	Database PostgreSQL	?				?
	Qpid	?				?
	Router Nginx	?	?		?

In generale, dopo aver installato Apigee Edge, puoi eseguire le seguenti attività di monitoraggio per monitorare il rendimento di un'installazione di Apigee Edge for Private Cloud.

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 nozioni di base sull'integrità del sistema.

Utilizzo CPU: specifica le statistiche di base (in attesa/inutilizzata/utente/sistema/IO) sull'utilizzo della CPU. Ad esempio, 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, 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 utilizzate da un processo o da un'applicazione. Per processi come qpidd, postgres postmaster, java e così via, puoi monitorare quanto segue:

Identificazione del processo: identifica un determinato 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 della memoria: visualizza l'utilizzo della memoria per tutti i processi Apigee. Ad esempio, puoi monitorare parametri come l'utilizzo della memoria heap e l'utilizzo della memoria non heap impiegato da 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 <host> è l'indirizzo IP del componente Apigee Edge. <port> è specifico di ogni componente Edge. Ad esempio:

Server di gestione: 8080

Router: 8081
Message Processor: 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 lo stato dell'API 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 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 diverse località in tutto il mondo per confrontare il comportamento delle API tra le regioni.

Controlli del flusso dei messaggi

Puoi raccogliere dati da router e processori 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

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

Controllo di integrità del router del router Processore

Il router implementa un meccanismo di controllo di integrità per determinare quale processore di messaggi funzionino 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 /<inst root>/apigee4/var/log/apigee/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 /<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 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

Per configurare il router in modo che esegua il controllo di integrità, imposta la seguente proprietà su true in /<inst root>/apigee4/conf/apigee/router/router.properties:

Client.pool.heartBeat.use.http=true

Quindi, riavvia il router:

> /<inst-root>/apigee4/bin/apigee-service router restart