Monitoraggio dell'applicazione utilizzando le metriche Envoy

Envoy classifica le sue metriche nelle seguenti categorie principali:

• Downstream: metriche relative alle connessioni e alle richieste che arrivano al proxy.

• Upstream: metriche relative alle connessioni e alle richieste in uscita effettuate dal proxy.

• Server: metriche che descrivono lo stato interno di Envoy. Queste includono metriche come l'uptime o la memoria allocata.

In App Mesh, il proxy intercetta il traffico a monte e a valle. Ad esempio, le richieste ricevute dai tuoi clienti e le richieste effettuate dal tuo container di servizio sono classificate come traffico downstream da Envoy. Per distinguere tra questi diversi tipi di traffico a monte e a valle, App Mesh classifica ulteriormente le metriche Envoy in base alla direzione del traffico relativa al servizio:

• Ingress: metriche e risorse relative alle connessioni e alle richieste che fluiscono verso il contenitore di servizi.

• Uscita: metriche e risorse relative alle connessioni e alle richieste che fluiscono dal contenitore di servizi e, infine, dall'attività Amazon ECS o dal pod Kubernetes.

L'immagine seguente mostra la comunicazione tra il proxy e i contenitori di servizio.

Convenzioni di denominazione delle risorse

È utile capire in che modo Envoy visualizza la tua mesh e in che modo le sue risorse si ricollegano alle risorse che definisci in App Mesh. Queste sono le principali risorse Envoy configurate da App Mesh:

• Listener: gli indirizzi e le porte su cui il proxy ascolta le connessioni downstream. Nell'immagine precedente, App Mesh crea un listener di ingresso per il traffico in entrata nel task Amazon ECS o nel pod Kubernetes e un listener in uscita per il traffico in uscita dal container di servizi.

• Cluster: un gruppo denominato di endpoint upstream a cui il proxy si connette e a cui indirizza il traffico. In App Mesh, il contenitore di servizi è rappresentato come un cluster, così come tutti gli altri nodi virtuali a cui il servizio può connettersi.

• Percorsi: corrispondono ai percorsi definiti nella rete. Contengono le condizioni in base alle quali il proxy soddisfa una richiesta e il cluster di destinazione a cui viene inviata una richiesta.

• Endpoint e assegnazioni di carico dei cluster: gli indirizzi IP dei cluster upstream. Quando viene utilizzatoAWS Cloud Map come meccanismo di rilevamento dei servizi per i nodi virtuali, App Mesh invia le istanze di servizio rilevate come risorse endpoint al proxy.

• Segreti: includono, a titolo esemplificativo ma non esaustivo, le chiavi di crittografia e i certificati TLS. Quando viene utilizzatoAWS Certificate Manager come fonte per i certificati client e server, App Mesh invia certificati pubblici e privati al proxy come risorse segrete.

App Mesh utilizza uno schema coerente per denominare le risorse di Envoy che puoi utilizzare per ricollegarti alla tua mesh.

Comprendere lo schema di denominazione per ascoltatori e cluster è importante per comprendere le metriche di Envoy in App Mesh.

Nomi degli ascoltatori

Gli ascoltatori sono denominati utilizzando il formato seguente:

lds_<traffic direction>_<listener IP address>_<listening port>

In genere vedrai i seguenti ascoltatori configurati in Envoy:

• lds_ingress_0.0.0.0_15000

• lds_egress_0.0.0.0_15001

Utilizzando un plug-in Kubernetes CNI o le regole delle tabelle IP, il traffico nel task Amazon ECS o nel pod Kubernetes viene indirizzato alle porte15000 e15001. App Mesh configura Envoy con questi due ascoltatori per accettare il traffico in ingresso (in entrata) e in uscita (in uscita). Se non hai un listener configurato sul tuo nodo virtuale, non dovresti vedere un listener di ingresso.

Nomi dei cluster

La maggior parte dei cluster utilizza il formato seguente:

cds_<traffic direction>_<mesh name>_<virtual node name>_<protocol>_<port>

I nodi virtuali con cui comunicano i tuoi servizi hanno ciascuno il proprio cluster. Come accennato in precedenza, App Mesh crea un cluster per il servizio in esecuzione accanto a Envoy in modo che il proxy possa inviargli traffico in ingresso.

Ad esempio, se hai un nodo virtuale denominatomy-virtual-node che ascolta il traffico http sulla porta8080 e quel nodo virtuale si trova in una mesh denominatamy-mesh, App Mesh crea un cluster denominatocds_ingress_my-mesh_my-virtual-node_http_8080. Questo cluster funge da destinazione per il traffico versomy-virtual-node il contenitore di servizio.

App Mesh può anche creare i seguenti tipi di cluster speciali aggiuntivi. Questi altri cluster non corrispondono necessariamente alle risorse definite in modo esplicito nella mesh.

• Cluster utilizzati per raggiungere altriAWS servizi. Questo tipo consente alla tua mesh di raggiungere la maggior parte deiAWS servizi per impostazione predefinita:cds_egress_<mesh name>_amazonaws.

• Cluster utilizzato per eseguire il routing per i gateway virtuali. Questo può generalmente essere tranquillamente ignorato:.

  • Per ascoltatori singoli:cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<protocol>_<port>

  • Per più ascoltatori:cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<ingress_listener_port>_<protocol>_<port>

• Il cluster il cui endpoint puoi definire, ad esempio TLS, quando recuperi segreti utilizzando Envoy's Secret Discovery Service:static_cluster_sds_unix_socket.

Parametri dell'applicazione di esempio

Per illustrare le metriche disponibili in Envoy, la seguente applicazione di esempio dispone di tre nodi virtuali. I servizi virtuali, i router virtuali e i percorsi nella mesh possono essere ignorati poiché non si riflettono nelle metriche di Envoy. In questo esempio, tutti i servizi ascoltano il traffico http sulla porta 8080.

Ti consigliamo di aggiungere la variabileENABLE_ENVOY_STATS_TAGS=1 di ambiente ai contenitori proxy Envoy in esecuzione nella tua mesh. Questo aggiunge le seguenti dimensioni dei parametri a tutti i parametri emessi dal proxy:

• appmesh.mesh

• appmesh.virtual_node

• appmesh.virtual_gateway

Questi tag sono impostati sul nome della mesh, del nodo virtuale o del gateway virtuale per consentire di filtrare le metriche utilizzando i nomi delle risorse nella mesh.

Nomi delle risorse

Il proxy del nodo virtuale del sito Web dispone delle seguenti risorse:

• Due ascoltatori per il traffico in entrata e in uscita:

  • lds_ingress_0.0.0.0_15000

  • lds_egress_0.0.0.0_15001

• Due cluster di uscita, che rappresentano i due backend dei nodi virtuali:

  • cds_egress_online-store_product-details_http_8080

  • cds_egress_online-store_cart_http_8080

• Un cluster di ingresso per il contenitore dei servizi del sito Web:

  • cds_ingress_online-store_website_http_8080

Metriche di esempio per gli ascoltatori

• listener.0.0.0.0_15000.downstream_cx_active—Numero di connessioni di rete in ingresso attive a Envoy.

• listener.0.0.0.0_15001.downstream_cx_active—Numero di connessioni di rete in uscita attive verso Envoy. Le connessioni effettuate dall'applicazione a servizi esterni sono incluse in questo conteggio.

• listener.0.0.0.0_15000.downstream_cx_total—Numero totale di connessioni di rete in ingresso a Envoy.

• listener.0.0.0.0_15001.downstream_cx_total—Numero totale di connessioni di rete in uscita verso Envoy.

Per il set completo di metriche degli ascoltatori, consulta le statistiche nella documentazione di Envoy.

Esempio di metriche del cluster

• cluster_manager.active_clusters—Il numero totale di cluster a cui Envoy ha stabilito almeno una connessione.

• cluster_manager.warming_clusters—Il numero totale di cluster a cui Envoy deve ancora connettersi.

Le seguenti metriche del cluster utilizzano il formato dicluster.<cluster name>.<metric name>. Questi nomi di metriche sono univoci per l'esempio dell'applicazione e vengono emessi dal contenitore Envoy del sito Web:

• cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_total—Numero totale di connessioni tra il sito Web e i dettagli del prodotto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_connect_fail—Numero totale di connessioni non riuscite tra il sito Web e i dettagli del prodotto.

• cluster.cds_egress_online-store_product-details_http_8080.health_check.failure—Numero totale di controlli sanitari non riusciti tra il sito Web e i dettagli del prodotto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_total—Numero totale di richieste effettuate tra il sito Web e i dettagli del prodotto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_time—Tempo impiegato dalle richieste effettuate tra il sito Web e i dettagli del prodotto.

• cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_2xx—Numero di risposte HTTP 2xx ricevute dal sito Web dai dettagli del prodotto.

Per il set completo di metriche HTTP, consulta le statistiche nella documentazione di Envoy.

Metriche del server di gestione

Envoy emette anche metriche relative alla sua connessione al piano di controllo App Mesh, che funge da server di gestione di Envoy. Ti consigliamo di monitorare alcune di queste metriche per avvisarti quando i tuoi proxy vengono desincronizzati dal piano di controllo per lunghi periodi di tempo. La perdita di connettività al piano di controllo o gli aggiornamenti non riusciti impediscono ai proxy di ricevere nuove configurazioni da App Mesh, comprese le modifiche alla mesh apportate tramite le API App Mesh.

• control_plane.connected_state—Questa metrica è impostata su 1 quando il proxy è connesso ad App Mesh, altrimenti è 0.

• *.update_rejected—Numero totale di aggiornamenti di configurazione rifiutati da Envoy. Questi sono in genere dovuti a una configurazione errata dell'utente. Ad esempio, se configuri App Mesh per leggere un certificato TLS da un file che non può essere letto da Envoy, l'aggiornamento contenente il percorso di quel certificato viene rifiutato.

  • Se il Listener aggiornato viene rifiutato, le statistiche sarannolistener_manager.lds.update_rejected.

  • Se il Cluster aggiornato viene rifiutato, le statistiche sarannocluster_manager.cds.update_rejected.

• *.update_success—Numero di aggiornamenti di configurazione effettuati con successo da App Mesh al tuo proxy. Questi includono il payload di configurazione iniziale inviato all'avvio di un nuovo contenitore Envoy.

  • Per il successo dell'aggiornamento di Listener, le statistiche sarannolistener_manager.lds.update_success.

  • Affinché l'aggiornamento del Cluster abbia successo, le statistiche sarannocluster_manager.cds.update_success.

Per il set di metriche del server di gestione, vedere Management Server nella documentazione di Envoy.