Questa pagina è stata tradotta dall'API Cloud Translation.

Che cosa monitorare

Edge per Private Cloud v. 4.17.09

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

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

Servizi server Java specifici di Apigee: questi includono server di gestione, processore di messaggi, Qpid Server e server Postgres.
Servizi di terze parti: tra cui 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 del sistema	Statistiche a livello di processo	Controlli a livello di API	Controlli del flusso dei messaggi	Specifico del componente
Servizi Java specifici per Apigee	Server di gestione	?	?	?
	processore di messaggi	?	?	?	?
	Server Qpid	?	?	?
	Server Postgres	?	?	?
Servizi di terze parti	Apache Cassandra	?				?
	ZooKeeper Apache	?				?
	OpenLDAP	?				?
	Database PostgreSQL	?				?
	Qpid	?				?
	Router Nginx	?	?		?

In generale, dopo l'installazione di Apigee Edge, puoi eseguire le seguenti attività di monitoraggio per monitorare le prestazioni di un'installazione 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 acquisire le nozioni di base sull'integrità del sistema.

Utilizzo CPU: specifica le statistiche di base (Utente/Sistema/IO Attendi/Inattivo) 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 all'utilizzo attuale del disco. Ad esempio, lo spazio su disco rigido utilizzato dal sistema.
Load Media: specifica il numero di processi in attesa di esecuzione.
Statistiche di rete: pacchetti e/o byte di rete trasmessi e ricevuti, insieme agli errori di trasmissione relativi a un componente specificato.

Processi/controlli delle applicazioni

A livello di processo, puoi visualizzare informazioni importanti su tutti i processi in esecuzione. Ad esempio, includono 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 dei thread: visualizza i pattern di threading sottostanti utilizzati da un processo. Ad esempio, puoi monitorare il numero massimo di thread e il numero di thread per tutti i processi.
Utilizzo memoria: visualizza la memoria utilizzata per tutti i processi Apigee. Ad esempio, puoi monitorare parametri come l'utilizzo della memoria heap e l'utilizzo della memoria non heap utilizzata da un processo.

Controlli a livello di API

A livello di API, puoi monitorare se il server è attivo e in esecuzione per le chiamate API utilizzate di frequente inviate tramite proxy da Apigee. Ad esempio, puoi eseguire il controllo delle API sul server di gestione, sul router e sul 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. Il numero <port> è specifico per ogni componente Edge. Ad esempio:

Server di gestione: 8080

Router: 8081
Processore di messaggi: 8082
E così via

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

Questa chiamata restituisce i valori "true" e "false". Per ottenere risultati ottimali, puoi anche eseguire chiamate API direttamente sul backend (con cui interagisce il software Apigee) per determinare rapidamente se esiste un errore nell'ambiente software Apigee o sul backend.

Nota: per monitorare i proxy API, puoi anche utilizzare l'integrità delle API di Apigee. API Health effettua chiamate programmate 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 avvisarti 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 di messaggi

Puoi raccogliere dati da router e processori di messaggi su pattern/statistiche del flusso dei 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 dei messaggi dell'API. Per ulteriori informazioni, vedi:

Come monitorare il processore di messaggi
Panoramica beta della dashboard di monitoraggio di Apigee per il router

Controllo di integrità del router del processore di messaggi

Il router implementa un meccanismo di controllo di integrità per determinare quali processori di messaggi funzionano come previsto. Se un processore di messaggi viene rilevato come inattivo o lento, il router può sospenderlo automaticamente dalla rotazione. In questo caso, il router scrive un messaggio di "Mark down" nel 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 elimina un processore di messaggi, 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> è l'indirizzo IP e il numero di porta del processore di messaggi.

Se in seguito il router esegue un controllo di integrità e determina che il processore di messaggi funziona correttamente, il router rimette automaticamente in rotazione il processore di messaggi. Il router scrive anche un messaggio "Markup" nel 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