Messwerte aufrufen

Sie sehen sich gerade die Version 1.10 der Apigee Hybrid-Dokumentation an. Weitere Informationen finden Sie unter Unterstützte Versionen.

Version 1.10 

Unterstützte Versionen:

• v1.13 (aktuellste Version)                        
• v1.12                         
• v1.11                         
• Liste der unterstützten Versionen

Nicht unterstützte Versionen:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

In diesem Thema wird erklärt, wie Sie Apigee-Hybridmesswerte in einem Cloud Operations-Dashboard aufrufen können.

Informationen zu Cloud Operations

Weitere Informationen zu Messwerten, Dashboards und Cloud Operations finden Sie unter:

• Dokumentation zum Metrics Explorer
• Einführung in Benachrichtigungen
• Diagramme erstellen

Hybridmesswerte aktivieren

Bevor Sie Hybridmesswerte an Cloud Operations senden können, müssen Sie zuerst die Messwerterfassung aktivieren. Weitere Informationen zu diesem Verfahren finden Sie unter Messwerterfassung konfigurieren.

Hinweis: Messwerte für das Apigee-Ingress-Gateway werden nicht unterstützt. Siehe Bekannte Probleme.

Namen und Labels von Hybridmesswerten

Wenn diese Option aktiviert ist, werden Hybridmesswerte von Cloud Operations automatisch eingefügt. Das Domainnamenpräfix der von Hybrid erstellten Messwerte lautet:

apigee.googleapis.com/

Der Messwert /proxyv2/request_count enthält beispielsweise die Gesamtzahl der Anfragen, die von einem API-Proxy empfangen werden. Der Messwertname in Cloud Operations lautet daher:

apigee.googleapis.com/proxyv2/request_count

Mit Cloud Operations können Sie Messwertdaten nach Labels filtern und gruppieren. Einige Labels sind vordefiniert und andere werden explizit durch Hybrid hinzugefügt. Im Abschnitt Verfügbare Messwerte weiter unten werden alle verfügbaren Hybridmesswerte und alle Labels aufgeführt, die speziell für einen Messwert hinzugefügt wurden, den Sie zum Filtern und Gruppieren verwenden können.

Messwerte ansehen

Das folgende Beispiel zeigt, wie Messwerte in Cloud Operations aufgerufen werden:

1. Öffnen Sie den Monitoring-Messwert-Explorer in einem Browser. Wenn Sie sich bereits in der Cloud Operations Console befinden, wählen Sie Metrics Explorer aus.

2. Suchen Sie unter Find resource type and metric den Messwert, den Sie untersuchen möchten. Wählen Sie einen bestimmten Messwert aus, der unter Available Metrics aufgeführt ist, oder suchen Sie nach einem Messwert.

3. Wählen Sie den gewünschten Messwert aus.
4. Wenden Sie den Filter an. Die Filteroptionen für jeden Messwert sind unter Available metrics aufgeführt.
5. Cloud Operations zeigt das Diagramm für den ausgewählten Messwert an.
6. Klicken Sie auf Speichern.

Dashboard erstellen

Mit Dashboards können Sie relevante Messwertdaten ansehen und analysieren. Cloud Operations bietet vordefinierte Dashboards für die von Ihnen verwendeten Ressourcen und Dienste und Sie können auch benutzerdefinierte Dashboards erstellen.

Sie verwenden ein Diagramm, um einen Apigee-Messwert in Ihrem benutzerdefinierten Dashboard anzuzeigen. Mit benutzerdefinierten Dashboards haben Sie die volle Kontrolle über die angezeigten Diagramme und deren Konfiguration. Weitere Informationen zum Erstellen von Diagrammen finden Sie unter Diagramme erstellen.

Das folgende Beispiel zeigt, wie Sie ein Dashboard in Cloud Operations erstellen und dann Diagramme hinzufügen, um Messwertdaten anzuzeigen:

1. Öffnen Sie den Monitoring Metrics Explorer in einem Browser und wählen Sie Dashboards aus.
2. Wählen Sie + Dashboard erstellen aus.
3. Geben Sie einen Namen für das Dashboard ein. Beispiel: Anfragetraffic des Hybridproxys
4. Klicken Sie auf Bestätigen.

5. Führen Sie für jedes Diagramm, das Sie dem Dashboard hinzufügen möchten, die folgenden Schritte aus:

   1. Wählen Sie im Dashboard Diagramm hinzufügen aus.
   2. Wählen Sie den gewünschten Messwert aus, wie oben unter Messwerte ansehen beschrieben.
   3. Schließen Sie das Dialogfeld ab, um das Diagramm zu definieren.
   4. Klicken Sie auf Speichern. Cloud Operations zeigt Daten für den ausgewählten Messwert an.

Verfügbare Messwerte

In den folgenden Tabellen werden Messwerte zur Analyse des Proxy-Traffics aufgeführt.

Proxy-, Ziel- und Server-Traffic-Messwerte

Der Prometheus-Dienst erfasst und verarbeitet Messwerte (wie unter Messwerterfassung beschrieben) für Proxy-, Ziel- und Server-Traffic.

In der folgenden Tabelle werden die von Prometheus verwendeten Messwerte und Labels beschrieben. Diese Labels werden in den Messwert-Logeinträgen verwendet.

Messwertname	Label	Verwendung
/proxyv2/request_count	method	Die Gesamtzahl der erhaltenen API-Proxyanfragen.
/proxyv2/response_count	method response_code	Die Gesamtzahl der empfangenen API-Proxy-Antworten.
/proxyv2/latencies_percentile	method	Perzentil aller API-Richtlinienantworten auf eine Anfrage.
/targetv2/request_count	method target_type target_endpoint	Die Gesamtzahl der Anforderungen, die an den Ziel-Proxy gesendet wurden.
/targetv2/response_count	method response_code target_type target_endpoint	Die Gesamtzahl der Antworten, die vom Ziel des Proxys empfangen wurden.
/server/fault_count	source	Die Gesamtzahl der Fehler für die Serveranwendung. Die Anwendung kann beispielsweise apigee-runtime, apigee-synchronizer oder apigee-udca sein. Verwenden Sie das Label pod_name, um Ergebnisse nach Anwendung zu filtern.
/server/nio	state	Die Anzahl der offenen Sockets.
/server/num_threads		Die Anzahl der aktiven Nicht-Daemon-Threads auf dem Server.
/server/request_count	method type	Die Gesamtzahl der Anfragen, die von der Serveranwendung empfangen wurden. Die Anwendung kann beispielsweise apigee-runtime, apigee-synchronizer oder apigee-udca sein. Verwenden Sie das Label pod_name, um Ergebnisse nach Anwendung zu filtern.
/server/response_count	method response_code type	Gesamtzahl der von der Serveranwendung gesendeten Antworten. Die Anwendung kann beispielsweise apigee-runtime, apigee-synchronizer oder apigee-udca sein. Verwenden Sie das Label pod_name, um Ergebnisse nach Anwendung zu filtern.
/server/latencies	method response_code type	Latenz ist die Latenz in Millisekunden, die von der Serveranwendung verursacht wird. Die Anwendung kann beispielsweise apigee-runtime, apigee-synchronizer oder apigee-udca sein. Verwenden Sie das Label pod_name, um Ergebnisse nach Anwendung zu filtern.
/upstream/request_count	method type	Die Anzahl der Anfragen, die von der Serveranwendung an die vorgelagerte Anwendung gesendet werden. Bei apigee-synchronizer ist die Steuerungsebene beispielsweise vorgelagert. Daher ist upstream/request_count für apigee-synchronizer ein Messwert, der die Anfragen angibt, die apigee-synchronizer an die Steuerungsebene gesendet hat.
/upstream/response_count	method response_code type	Die Anzahl der Antworten, die von der Serveranwendung von seiner vorgelagerten Anwendung empfangen wurden. Für apigee-synchronizer ist die Steuerungsebene beispielsweise vorgeliefert. upstream/response_count für apigee-synchronizer ist also ein Messwert, der die Anfragen angibt, die apigee-synchronizer von der Steuerungsebene erhalten hat.
/upstream/latencies	method response_code type	Die Latenz, die durch die Upstream-Serveranwendung in Millisekunden verursacht wird. Bei apigee-synchronizer ist die Steuerungsebene beispielsweise vorgelagert. upstream/latencies für apigee-synchronizer ist also ein Messwert, der die Latenz auf der Steuerungsebene angibt.

UDCA-Messwerte

Der Prometheus-Dienst erfasst und verarbeitet Messwerte (wie unter Messwertsammlung beschrieben) für den UDCA-Dienst wie bei anderen Hybriddiensten.

In der folgenden Tabelle werden die Messwerte und Labels beschrieben, die Prometheus in den UDCA-Messwertdaten verwendet. Diese Labels werden in den Messwert-Logeinträgen verwendet.

Messwertname	Label	Verwendung
/udca/server/local_file_oldest_ts	dataset state	Der Zeitstempel in Millisekunden seit dem Start der Unix-Epoche für die älteste Datei im Dataset. Dieser wird alle 60 Sekunden berechnet und spiegelt den Status nicht in Echtzeit wider. Wenn der UDCA aktuell ist und bei der Berechnung dieses Messwerts keine Dateien zum Hochladen warten, lautet der Wert 0. Wenn dieser Wert kontinuierlich ansteigt, bleiben alte Dateien auf der Festplatte.
/udca/server/local_file_latest_ts	dataset state	Der Zeitstempel in Millisekunden seit Beginn der Unix-Epoche, für die neueste Datei auf der Festplatte nach Status. Dieser wird alle 60 Sekunden berechnet und spiegelt den Status nicht in Echtzeit wider. Wenn der UDCA aktuell ist und bei der Berechnung dieses Messwerts keine Dateien zum Hochladen warten, lautet der Wert 0.
/udca/server/local_file_count	dataset state	Die Anzahl der Dateien auf dem Datenträger im Datenerfassungs-Pod. Im Idealfall liegt der Wert nahe 0. Ein konstant hoher Wert gibt an, dass Dateien nicht hochgeladen werden oder dass die UDCA sie nicht schnell genug hochladen kann. Dieser Wert wird alle 60 Sekunden berechnet und reflektiert nicht den Status des UDCA in Echtzeit.
/udca/server/total_latencies	dataset	Das Zeitintervall in Sekunden zwischen der erstellten Datendatei und der hochgeladenen Datendatei. Die Buckets sind 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s und 64 s. Histogramm für die Gesamtlatenz vom Zeitpunkt der Dateierstellung bis zum erfolgreichen Upload.
/udca/server/upload_latencies	dataset	Die Gesamtzeit in Sekunden, die von der UDCA für das Hochladen einer Datendatei aufgewendet wurde. Die Buckets sind 100 ms, 250 ms, 500  ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s und 64 s. Die Messwerte zeigen ein Histogramm für die gesamte Upload-Latenz an, einschließlich aller Upstream-Aufrufe.
/udca/upstream/http_error_count	service dataset response_code	Die Gesamtzahl der von UDCA aufgetretenen HTTP-Fehler. Dieser Messwert ist hilfreich, um zu bestimmen, welcher Teil der externen UDCA-Abhängigkeiten aus welchem Grund fehlschlagen. Diese Fehler können für verschiedene Dienste (getDataLocation, Cloud storage, Token generator) und für verschiedene Datasets (z. B. api und trace) mit unterschiedlichen Antwortcodes auftreten, um die Option zu aktivieren.
/udca/upstream/http_latencies	service dataset	Die vorgelagerte Latenz von Diensten in Sekunden. Die Buckets sind 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s und 64 s. Histogramm für die Latenz von vorgelagerten Diensten.
/udca/upstream/uploaded_file_sizes	dataset	Die Größe der Datei, die in Apigee-Dienste hochgeladen wird, in Byte. Buckets sind 1 KB, 10 KB, 100 KB, 1 MB, 10 MB, 100 MB und 1 GB. Histogramm für die Dateigröße nach Dataset, Organisation und Umgebung.
/udca/upstream/uploaded_file_count	dataset	Eine Anzahl der Dateien, die UDCA in die Apigee-Dienste hochgeladen hat. Hinweis: Der Wert des Datasets event sollte weiterhin wachsen. Der Dataset-Wert api sollte weiterhin wachsen, wenn "org/env" konstanten Traffic hat. Der Dataset-Wert trace sollte sich erhöhen, wenn Sie die Apigee-Trace-Tools zum Debuggen oder Prüfen Ihrer Anfragen verwenden.
/udca/disk/used_bytes	dataset state	Der Speicherplatz, der von den Datendateien auf dem Laufwerk des Datenerfassungs-Pods belegt wird, in Byte. Eine Erhöhung dieses Werts im Laufe der Zeit: ready_to_upload impliziert, dass der Agent hinter der Verzögerung zurückliegt. failed impliziert, dass Dateien auf dem Laufwerk gespeichert und nicht hochgeladen werden. Dieser Wert wird alle 60 Sekunden berechnet.
/udca/server/pruned_file_count	dataset state	Anzahl der gelöschten Dateien, da ihre Gültigkeitsdauer (TTL) über einen festgelegten Schwellenwert lag. Das Dataset kann API, Trace und andere enthalten und der Status kann UPLOADED, FAILED oder DISCARDED sein.
/udca/server/retry_cache_size	dataset	Gibt an, wie viele Dateien pro Dataset von UDCA hochgeladen werden können. Nach drei Wiederholungsversuchen wird die Datei von UDCA in das Unterverzeichnis /failed verschoben und aus dem Cache entfernt. Eine Erhöhung dieses Werts im Laufe der Zeit bedeutet, dass der Cache nicht gelöscht wird, was dann geschieht, wenn Dateien nach drei Wiederholungsversuchen in das Unterverzeichnis /failed verschoben werden.

Cassandra-Messwerte

Der Prometheus-Dienst erfasst und verarbeitet Messwerte (wie unter Messwertsammlung beschrieben) für Cassandra wie bei anderen Hybriddiensten.

In der folgenden Tabelle werden die Messwerte und Labels beschrieben, die Prometheus in den Cassandra-Messwertdaten verwendet. Diese Labels werden in den Messwert-Logeinträgen verwendet.

Messwertname (ohne Domain)	Label	Verwendung
/cassandra/process_max_fds		Maximale Anzahl geöffneter Dateideskriptoren.
/cassandra/process_open_fds		Dateideskriptoren öffnen.
/cassandra/jvm_memory_pool_bytes_max	pool	Maximale JVM-Speicherauslastung für den Pool.
/cassandra/jvm_memory_pool_bytes_init	pol	Anfängliche Speichernutzung der JVM für den Pool.
/cassandra/jvm_memory_bytes_max	area	Maximale Arbeitsspeicherauslastung der JVM-Instanz.
/cassandra/process_cpu_seconds_total		Nutzer- und System-CPU-Zeit in Sekunden.
/cassandra/jvm_memory_bytes_used	area	Auslastung des JVM Heap-Speichers
/cassandra/compaction_pendingtasks	unit	Offene Komprimierungen für Cassandra-SSTables. Weitere Informationen finden Sie unter Verdichtung.
/cassandra/jvm_memory_bytes_init	area	Arbeitsspeichernutzung für JVM-Heap-Speicher.
/cassandra/jvm_memory_pool_bytes_used	pool	Auslastung des JVM-Pools.
/cassandra/jvm_memory_pool_bytes_committed	pool	Vom JVM-Pool zugesicherte Speichernutzung.
/cassandra/clientrequest_latency	scope unit	Latenz der Leseanfrage im 75. Perzentilbereich in Mikrosekunden.
/cassandra/jvm_memory_bytes_committed	area	Arbeitsspeichernutzung für JVM-Heap-Speicher.

Mit Cassandra-Messwerten arbeiten

Apigee empfiehlt die folgenden Messwerte, die für die Überwachung Ihrer Cassandra-Datenbank wichtig sind:

• Cassandra-Anfragerate: Verwenden Sie diesen Messwert, um die Cassandra-Lese- und Schreibanfragerate zu überwachen.

  Messwert:	apigee.googleapis.com/cassandra/clientrequest_latency
  Ressourcenlabels:	project_id, location, cluster_name, namespace_name, pod_name, container_name
  Messwertlabels:	scope, unit Damit können Sie die Ressource filtern oder gruppieren.

  Wenden Sie den folgenden Filter an, um die Cassandra-Leseanfragerate zu überwachen.

  Filter:

  metric.scope == 'Read' metric.unit == 'OneMinuteRate'

  Wenden Sie den folgenden Filter an, um die Cassandra-Schreibanfragerate zu beobachten.

  Filter:

  metric.scope == 'Write' metric.unit == 'OneMinuteRate'

• Cassandra-Anfragelatenz: Verwenden Sie diesen Messwert, um die Cassandra-Lese- und Schreibanfragelatenz zu überwachen. Dies ist der gleiche Messwert wie die Anfragerate (apigee.googleapis.com/cassandra/clientrequest_latency mit unterschiedlichen Filtern).

  Wenden Sie den folgenden Filter an, um die Cassandra-Leseanfragelatenz zu überwachen.

  Filter:

  metric.scope == 'Read' metric.unit == '99thPercentile' oder '95thPercentile' oder '75thPercentile'

  Wenden Sie den folgenden Filter an, um die Latenz für cassandra-Schreibanfragen zu überwachen.

  Filter:

  metric.scope == 'Write' metric.unit == '99thPercentile' oder '95thPercentile' oder '75thPercentile'

• Cassandra-Pod-CPU-Anfrageauslastung

  Messwert:	kubernetes.io/container/cpu/request_utilization (GKE) kubernetes.io/anthos/container/cpu/request_utilization (Anthos)
  Ressourcenlabels:	project_id, location, cluster_name, namespace_name, pod_name, container_name Damit können Sie die Ressource filtern oder gruppieren.

• Cassandra-Datenvolumenauslastung

  Messwert:	kubernetes.io/pod/volume/utilization (GKE) kubernetes.io/anthos/pod/volume/utilization (Anthos)
  Ressourcenlabels:	project_id, location, cluster_name, namespace_name, pod_name
  Messwertlabels:	volume_name Damit können Sie die Ressource filtern oder gruppieren.

Empfehlungen zum Skalieren des Cassandra-Clusters

Die folgenden Richtlinien können als empfohlene Cluster für die Entscheidung dienen, Ihren Cassandra-Cluster zu skalieren. Im Allgemeinen gilt: Wenn Lese- oder Schreibanfragen konsistent eine Latenz des 99. Perzentils zeigen oder die Latenz kontinuierlich ansteigt und Sie entsprechende Spitzen bei der CPU-Anfrageauslastung und die Lese- oder Schreibanfrageraten feststellen, kann Ihr Cassandra-Cluster auch unter Stress stehen. Sie sollten den Cluster skalieren. Weitere Informationen finden Sie unter Cassandra skalieren.

Messwert	Grenzwert	Triggerdauer
kubernetes.io/pod/volume/utilization	85 %	5 Min.
kubernetes.io/container/cpu/request_utilization	85 %	3 Min.
Read request Latency 99thPercentile	5s	3 Min.
Write request Latency 99thPercentile	5s	3 Min.