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

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 Envoy

Envoy classifica le sue metriche nelle seguenti categorie principali:

  • A valle—Metriche relative alle connessioni e alle richieste che arrivano nel proxy.

  • Upstream—Metriche relative alle connessioni e alle richieste in uscita effettuate dal proxy.

  • Server—Metriche che descrivono lo stato interno di Envoy. Questi includono metriche come il tempo di attività o la memoria allocata.

In App Mesh, il proxy intercetta il traffico upstream e downstream. Ad esempio, le richieste ricevute dai tuoi clienti e le richieste effettuate dal tuo container di servizio 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 arrivano al contenitore del servizio.

  • Egress—Metriche e risorse relative alle connessioni e alle richieste che fluiscono dal container del servizio e, in ultima analisi, dal task Amazon ECS o dal pod Kubernetes.

La figura 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 come le sue risorse siano riconducibili alle risorse che definisci in App Mesh. Queste sono le principali risorse di 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 in ingresso per il traffico in arrivo nel task Amazon ECS o nel pod Kubernetes e un listener in uscita per il traffico in uscita dal container del servizio.

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

  • Route—Corrispondono ai percorsi che definisci nella tua mesh. Contengono le condizioni in base alle quali il proxy corrisponde a una richiesta e al cluster di destinazione a cui viene inviata una richiesta.

  • Assegnazione degli endpoint e del carico del cluster—Gli indirizzi IP dei cluster upstream. Quando si utilizzaAWS Cloud Mapcome meccanismo di scoperta dei servizi per i nodi virtuali, App Mesh invia le istanze di servizio rilevate come risorse endpoint al tuo proxy.

  • Segreti—Questi includono, a titolo esemplificativo, le chiavi di crittografia e i certificati TLS. Quando si utilizzaAWS Certificate Managercome fonte di 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 usare per relazionarti con la tua mesh.

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

Nomi dei listener

I listener vengono denominati utilizzando il seguente formato:

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 tabelle IP (regole), il traffico nel task Amazon ECS o nel pod Kubernetes viene indirizzato alle porte.15000e15001. 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 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 inviare traffico in ingresso ad esso.

Ad esempio, se si dispone di un nodo virtuale denominatomy-virtual-nodeche ascolta il traffico http sulla porta8080e quel nodo virtuale è 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-nodecontenitore di servizio.

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 usati per raggiungere altriAWSServizi . Questo tipo consente alla rete di raggiungere la maggior parteAWSservizi per impostazione predefinita:cds_egress_<mesh name>_amazonaws.

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

    • 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 che è l'endpoint che puoi definire, ad esempio TLS, quando recuperi i segreti utilizzando il Secret Discovery Service di Envoy:static_cluster_sds_unix_socket.

Parametri di 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 variabile di ambienteENABLE_ENVOY_STATS_TAGS=1ai contenitori proxy Envoy in esecuzione nella tua mesh. In questo modo vengono aggiunte le seguenti dimensioni delle metriche a tutte le metriche emesse 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 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 ascoltatori per il traffico in ingresso 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 back-end 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 del servizio del sito Web:

    • cds_ingress_online-store_website_http_8080

Esempio di listener

  • 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, vediStatistichenella documentazione Envoy.

Esempio di parametri 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 metrica 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 sito Web e 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 sito Web e 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, consultaStatistichenella documentazione Envoy.

Parametri del server di gestione

Envoy emette anche metriche relative alla sua connessione al piano di controllo di 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 effettuate tramite le API App Mesh.

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

  • control_plane.update_rejected—Numero totale di aggiornamenti di configurazione rifiutati da Envoy. Questi sono generalmente 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.

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

Per il set di metriche del server di gestione, vedereServer di gestionenella documentazione Envoy.