Überwachung Ihrer Anwendung mithilfe von Envoy-Metriken - AWS App Mesh
Beispiele für Anwendungsmetriken

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Überwachung Ihrer Anwendung mithilfe von Envoy-Metriken

Envoy unterteilt seine Kennzahlen in die folgenden Hauptkategorien:

  • Downstream — Metriken, die sich auf Verbindungen und Anfragen beziehen, die in den Proxy eingehen.

  • Upstream — Metriken, die sich auf ausgehende Verbindungen und Anfragen des Proxys beziehen.

  • Server — Metriken, die den internen Status von Envoy beschreiben. Dazu gehören Metriken wie Verfügbarkeit oder zugewiesener Speicher.

In App Mesh fängt der Proxy Upstream- und Downstream-Verkehr ab. Beispielsweise werden Anfragen, die Sie von Ihren Kunden erhalten, sowie Anfragen, die von Ihrem Service-Container gestellt werden, von Envoy als Downstream-Traffic eingestuft. Um zwischen diesen verschiedenen Arten von Upstream- und Downstream-Traffic zu unterscheiden, kategorisiert App Mesh die Envoy-Metriken in Abhängigkeit von der Verkehrsrichtung im Verhältnis zu Ihrem Dienst weiter:

  • Ingress — Metriken und Ressourcen in Bezug auf Verbindungen und Anfragen, die an Ihren Service-Container fließen.

  • Egress — Metriken und Ressourcen in Bezug auf Verbindungen und Anfragen, die aus Ihrem Service-Container und letztendlich aus Ihrer Amazon ECS-Aufgabe oder Ihrem Kubernetes-Pod fließen.

Das folgende Bild zeigt die Kommunikation zwischen dem Proxy und den Service-Containern.

Konventionen zur Benennung von Ressourcen

Es ist hilfreich zu verstehen, wie Envoy Ihr Mesh betrachtet und wie seine Ressourcen den Ressourcen zugeordnet werden, die Sie in App Mesh definieren. Dies sind die primären Envoy-Ressourcen, die App Mesh konfiguriert:

  • Listener — Die Adressen und Ports, auf denen der Proxy auf Downstream-Verbindungen wartet. In der vorherigen Abbildung erstellt App Mesh einen Eingangs-Listener für Datenverkehr, der in Ihre Amazon ECS-Aufgabe oder Ihren Kubernetes-Pod eingeht, und einen Ausgangs-Listener für Datenverkehr, der Ihren Service-Container verlässt.

  • Cluster — Eine benannte Gruppe von Upstream-Endpunkten, zu denen der Proxy eine Verbindung herstellt und an die der Datenverkehr weitergeleitet wird. In App Mesh wird Ihr Service-Container als Cluster dargestellt, ebenso wie alle anderen virtuellen Knoten, mit denen Ihr Service eine Verbindung herstellen kann.

  • Routen —Diese entsprechen den Routen, die Sie in Ihrem Mesh definieren. Sie enthalten die Bedingungen, unter denen der Proxy einer Anfrage entspricht, sowie den Zielcluster, an den eine Anfrage gesendet wird.

  • Endpunkte und Cluster-Ladezuweisungen — Die IP-Adressen der Upstream-Cluster. Wenn Sie App MeshAWS Cloud Map als Service Discovery-Mechanismus für virtuelle Knoten verwenden, sendet App Mesh entdeckte Service-Instanzen als Endpunktressourcen an Ihren Proxy.

  • Geheimnisse — Dazu gehören, ohne darauf beschränkt zu sein, Ihre Verschlüsselungsschlüssel und TLS-Zertifikate. Bei VerwendungAWS Certificate Manager als Quelle für Client- und Serverzertifikate sendet App Mesh öffentliche und private Zertifikate als geheime Ressourcen an Ihren Proxy.

App Mesh verwendet ein konsistentes Schema für die Benennung von Envoy-Ressourcen, mit denen Sie eine Beziehung zu Ihrem Mesh herstellen können.

Das Benennungsschema für Listener und Cluster zu verstehen, ist wichtig, um die Metriken von Envoy in App Mesh zu verstehen.

Namen der Zuhörer

Listener werden mit folgendem Format benannt:

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

In der Regel werden die folgenden Listener in Envoy konfiguriert sehen:

  • lds_ingress_0.0.0.0_15000

  • lds_egress_0.0.0.0_15001

Mithilfe eines Kubernetes-CNI-Plug-ins oder IP-Tabellenregeln wird der Datenverkehr in Ihrer Amazon ECS-Aufgabe oder Ihrem Kubernetes-Pod an die Ports15000 und geleitet15001. App Mesh konfiguriert Envoy mit diesen beiden Listenern so, dass eingehender (eingehender) und ausgehender (ausgehender) Verkehr akzeptiert werden. Wenn Sie auf Ihrem virtuellen Knoten keinen Listener konfiguriert haben, sollten Sie keinen Ingress-Listener sehen.

Clusternamen

Die meisten Cluster verwenden das folgende Format:

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

Virtuelle Knoten, mit denen Ihre Dienste kommunizieren, haben jeweils ihren eigenen Cluster. Wie bereits erwähnt, erstellt App Mesh einen Cluster für den Dienst, der neben Envoy ausgeführt wird, sodass der Proxy eingehenden Datenverkehr an ihn senden kann.

Wenn Sie beispielsweise einen virtuellen Knoten benanntmy-virtual-node haben, der auf HTTP-Verkehr am Port wartet,8080 und dieser virtuelle Knoten sich in einem Mesh mit dem Namen befindetmy-mesh, erstellt App Mesh einen Cluster mit dem Namencds_ingress_my-mesh_my-virtual-node_http_8080. Dieser Cluster dient als Ziel für den Datenverkehr inmy-virtual-node den Service-Container.

App Mesh kann auch die folgenden Typen zusätzlicher Spezialcluster erstellen. Diese anderen Cluster entsprechen nicht unbedingt Ressourcen, die Sie explizit in Ihrem Mesh definieren.

  • Cluster, die verwendet werden, um andereAWS Dienste zu erreichen. Mit diesem Typ kann Ihr Mesh standardmäßig die meistenAWS Dienste erreichen:cds_egress_<mesh name>_amazonaws.

  • Cluster, der zum Routing für virtuelle Gateways verwendet wird. Dies kann im Allgemeinen getrost ignoriert werden:.

    • Für einzelne Zuhörer:cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<protocol>_<port>

    • Für mehrere Zuhörer:cds_ingress_<mesh name>_<virtual gateway name>_self_redirect_<ingress_listener_port>_<protocol>_<port>

  • Den Cluster, dessen Endpunkt Sie definieren können, z. B. TLS, wenn Sie Secrets mit dem Secret Discovery Service von Envoy abrufen:static_cluster_sds_unix_socket.

Beispiele für Anwendungsmetriken

Zur Veranschaulichung der in Envoy verfügbaren Metriken verfügt die folgende Beispielanwendung über drei virtuelle Knoten. Die virtuellen Dienste, virtuellen Router und Routen im Mesh können ignoriert werden, da sie sich nicht in den Metriken von Envoy widerspiegeln. In diesem Beispiel warten alle Dienste auf HTTP-Verkehr auf Port 8080.

Wir empfehlen, die UmgebungsvariableENABLE_ENVOY_STATS_TAGS=1 zu den Envoy-Proxy-Containern hinzuzufügen, die in Ihrem Mesh ausgeführt werden. Dadurch werden alle vom Proxy ausgegebenen Metriken um die folgenden Metrik-Dimensionen erweitert:

  • appmesh.mesh

  • appmesh.virtual_node

  • appmesh.virtual_gateway

Diese Tags sind auf den Namen des Meshs, des virtuellen Knotens oder des virtuellen Gateways festgelegt, um das Filtern von Metriken anhand der Namen der Ressourcen in Ihrem Mesh zu ermöglichen.

Namen der Ressourcen

Der Proxy des virtuellen Knotens der Website verfügt über die folgenden Ressourcen:

  • Zwei Listener für eingehenden und ausgehenden Traffic:

    • lds_ingress_0.0.0.0_15000

    • lds_egress_0.0.0.0_15001

  • Zwei Ausgangscluster, die die beiden virtuellen Knoten-Backends darstellen:

    • cds_egress_online-store_product-details_http_8080

    • cds_egress_online-store_cart_http_8080

  • Ein Ingress-Cluster für den Website-Service-Container:

    • cds_ingress_online-store_website_http_8080

Beispiel für Listener-Metriken

  • listener.0.0.0.0_15000.downstream_cx_active— Anzahl der aktiven eingehenden Netzwerkverbindungen zu Envoy.

  • listener.0.0.0.0_15001.downstream_cx_active— Anzahl der aktiven ausgehenden Netzwerkverbindungen zu Envoy. Verbindungen, die Ihre Anwendung zu externen Diensten herstellt, sind in dieser Zählung enthalten.

  • listener.0.0.0.0_15000.downstream_cx_total— Gesamtzahl der eingehenden Netzwerkverbindungen zu Envoy.

  • listener.0.0.0.0_15001.downstream_cx_total— Gesamtzahl der ausgehenden Netzwerkverbindungen zu Envoy.

Die vollständigen Listener-Metriken finden Sie unter Statistiken in der Envoy-Dokumentation.

Beispiel für Cluster-Metriken

  • cluster_manager.active_clusters— Die Gesamtzahl der Cluster, zu denen Envoy mindestens eine Verbindung hergestellt hat.

  • cluster_manager.warming_clusters— Die Gesamtzahl der Cluster, zu denen Envoy noch keine Verbindung hergestellt hat.

Die folgenden Cluster-Metriken verwenden das Format voncluster.<cluster name>.<metric name>. Diese Metriknamen gelten nur für das Anwendungsbeispiel und werden vom Envoy-Container der Website ausgegeben:

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_total—Gesamtzahl der Verbindungen zwischen Website und Produktdetails.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_cx_connect_fail— Gesamtzahl der fehlgeschlagenen Verbindungen zwischen Website und Produktdetails.

  • cluster.cds_egress_online-store_product-details_http_8080.health_check.failure—Gesamtzahl der fehlgeschlagenen Zustandsprüfungen zwischen Website und Produktdetails.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_total—Gesamtzahl der Anfragen, die zwischen Website und Produktdetails gestellt wurden.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_time—Zeit, die für Anfragen zwischen Website und Produktdetails benötigt wird.

  • cluster.cds_egress_online-store_product-details_http_8080.upstream_rq_2xx—Anzahl der HTTP-2xx-Antworten, die die Website von product details erhalten hat.

Den vollständigen Satz der HTTP-Metriken finden Sie unter Statistiken in der Envoy-Dokumentation.

Metriken für Management-Server

Envoy gibt auch Metriken im Zusammenhang mit seiner Verbindung zur App Mesh-Steuerungsebene aus, die als Managementserver von Envoy fungiert. Wir empfehlen, einige dieser Metriken zu überwachen, um Sie zu benachrichtigen, wenn Ihre Proxys für längere Zeit von der Steuerungsebene desynchronisiert werden. Ein Verlust der Konnektivität zur Steuerungsebene oder fehlgeschlagene Updates verhindern, dass Ihre Proxys neue Konfigurationen von App Mesh erhalten, einschließlich Mesh-Änderungen, die über App Mesh Mesh-APIs vorgenommen wurden.

  • control_plane.connected_state— Diese Metrik wird auf 1 gesetzt, wenn der Proxy mit App Mesh verbunden ist, andernfalls ist sie 0.

  • *.update_rejected— Gesamtzahl der Konfigurationsupdates, die von Envoy abgelehnt wurden. Diese sind normalerweise auf eine Fehlkonfiguration des Benutzers zurückzuführen. Wenn Sie App Mesh beispielsweise so konfigurieren, dass ein TLS-Zertifikat aus einer Datei gelesen wird, die von Envoy nicht gelesen werden kann, wird das Update, das den Pfad zu diesem Zertifikat enthält, abgelehnt.

    • Wenn der Listener aktualisiert wurde, werden die Statistiken abgelehntlistener_manager.lds.update_rejected.

    • Für den abgelehnten Cluster-Update gelten die Statistikencluster_manager.cds.update_rejected.

  • *.update_success— Anzahl der erfolgreichen Konfigurationsupdates, die App Mesh an Ihrem Proxy vorgenommen hat. Dazu gehört die Nutzlast der Erstkonfiguration, die gesendet wird, wenn ein neuer Envoy-Container gestartet wird.

    • Wenn der Listener erfolgreich aktualisiert wurde, werden die Statistiken wie folgt aussehenlistener_manager.lds.update_success.

    • Bei erfolgreicher Cluster-Aktualisierung werden die Statistiken wie folgt lautencluster_manager.cds.update_success.

Eine Reihe von Management-Server-Metriken finden Sie unter Management Server in der Envoy-Dokumentation.