Monitoraggio dell'applicazione utilizzando le metriche di Envoy - AWS App Mesh
Esempi di metriche applicative

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Monitoraggio dell'applicazione utilizzando le metriche di Envoy

Importante

Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post del blog Migrazione da AWS App Mesh ad Amazon ECS Service Connect.

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 in uscita e alle richieste 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 contenitore di servizi sono classificate come traffico a valle da Envoy. Per distinguere tra questi diversi tipi di traffico upstream e downstream, App Mesh classifica ulteriormente le metriche di Envoy in base alla direzione del traffico relativa al servizio:

  • Ingress: metriche e risorse relative alle connessioni e alle richieste che affluiscono al contenitore di servizi.

  • Uscita: metriche e risorse relative alle connessioni e alle richieste che provengono dal tuo container di servizi e, in ultima analisi, escono dal tuo ECS task Amazon o dal pod Kubernetes.

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

Diagram showing proxy and service containers within an Amazon ECS task or Kubernetes Pod with ingress and egress flow.

Convenzioni di denominazione delle risorse

È utile capire come Envoy visualizza la tua mesh e come le sue risorse vengono mappate alle risorse che definisci in App Mesh. Queste sono le risorse Envoy principali 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 in ingresso per il traffico in entrata nel tuo ECS task Amazon o nel pod Kubernetes e un listener in uscita per il traffico in uscita dal tuo container di servizi.

  • Cluster: un gruppo denominato di endpoint upstream a cui il proxy si connette e 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 mesh. Contengono le condizioni in base alle quali il proxy soddisfa una richiesta e il cluster di destinazione a cui viene inviata la richiesta.

  • Endpoint e assegnazioni di carico del cluster: gli indirizzi IP dei cluster upstream. Quando viene utilizzato AWS 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: questi includono, a titolo esemplificativo, le chiavi e i certificati di crittografia. TLS Quando viene utilizzato AWS Certificate Manager come fonte per 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 Envoy che puoi utilizzare per ricollegarti alla tua mesh.

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

Nomi degli ascoltatori

I nomi degli ascoltatori vengono utilizzati nel seguente formato:

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

In genere vedrai i seguenti listener configurati in Envoy:

  • lds_ingress_0.0.0.0_15000

  • lds_egress_0.0.0.0_15001

Utilizzando un CNI plug-in Kubernetes o le regole delle tabelle IP, il traffico nell'ECSattività Amazon o nel pod Kubernetes viene indirizzato alle porte e. 15000 15001 App Mesh configura Envoy con questi due listener 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 in ingresso.

Nomi dei cluster

La maggior parte dei cluster utilizza il seguente formato:

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 denominato my-virtual-node che ascolta il traffico http sulla porta 8080 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 verso il contenitore my-virtual-node di servizi.

App Mesh può anche creare i seguenti tipi di cluster speciali aggiuntivi. Questi altri cluster non corrispondono necessariamente a risorse definite esplicitamente nella mesh.

  • Cluster utilizzati per raggiungere altri servizi. AWS Questo tipo consente alla mesh di raggiungere la maggior parte dei AWS 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 è l'endpoint che puoi definire, ad esempioTLS, quando recuperi segreti utilizzando il Secret Discovery Service di Envoy:. static_cluster_sds_unix_socket

Esempi di metriche applicative

Per illustrare le metriche disponibili in Envoy, la seguente applicazione di esempio ha tre nodi virtuali. I servizi virtuali, i router virtuali e i percorsi della 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.

Diagram showing Envoy proxies in product-details, cart, and website services of an online store mesh.

Ti consigliamo di aggiungere la variabile di ambiente ENABLE_ENVOY_STATS_TAGS=1 ai contenitori proxy Envoy in esecuzione nella tua mesh. Ciò aggiunge le seguenti dimensioni metriche a tutte le metriche emesse dal proxy:

  • appmesh.mesh

  • appmesh.virtual_node

  • appmesh.virtual_gateway

Questi tag sono impostati sul nome di mesh, nodo virtuale o gateway virtuale per consentire il filtraggio delle metriche utilizzando i nomi delle risorse nella mesh.

Nomi delle risorse

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

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

    • lds_ingress_0.0.0.0_15000

    • lds_egress_0.0.0.0_15001

  • Due cluster in 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 di servizi del sito Web:

    • cds_ingress_online-store_website_http_8080

Esempio di metriche 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 dei listener, consulta Statistics 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 di. cluster.<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 HTTP 2xx risposte ricevute dal sito Web dai dettagli del prodotto.

Per il set completo di HTTP metriche, consulta Statistics 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, incluse le modifiche alla mesh effettuate tramite App Mesh. APIs

  • 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. Di solito sono dovuti a una configurazione errata dell'utente. Ad esempio, se configuri App Mesh per leggere un TLS certificato da un file che non può essere letto da Envoy, l'aggiornamento contenente il percorso di quel certificato viene rifiutato.

    • Per Listener updated rejected, le statistiche saranno. listener_manager.lds.update_rejected

    • Per Cluster updated refected, le statistiche sarannocluster_manager.cds.update_rejected.

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

    • In caso di successo dell'aggiornamento di Listener, le statistiche saranno. listener_manager.lds.update_success

    • Se Cluster Updated ha successo, le statistiche sarannocluster_manager.cds.update_success.

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