Messwerte aufrufen

In diesem Thema wird erläutert, wie Sie Apigee-Hybrid-Messwerte in einem Stackdriver-Dashboard aufrufen.

Informationen zu Stackdriver

Weitere Informationen zu Messwerten, Dashboards und Stackdriver finden Sie unter:

Hybridmesswerte aktivieren

Damit Hybridmesswerte an Stackdriver gesendet werden können, müssen Sie zuerst die Erfassung von Messwerten aktivieren. Weitere Informationen zu diesem Verfahren finden Sie unter Messwerterfassung konfigurieren.

Namen und Labels von hybriden Messwerten

Wenn diese Option aktiviert ist, werden die Stackdriver-Messwerte automatisch ausgefüllt. Das Domainnamenpräfix der von Hybrid erstellten Messwerte lautet:

apigee.googleapis.com/

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

apigee.googleapis.com/proxy/request_count

Mit Stackdriver 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

Im folgenden Beispiel wird gezeigt, wie Sie Messwerte in Stackdriver ansehen:

Öffnen Sie den Monitoring-Messwert-Explorer in einem Browser. Alternativ können Sie auch Metrics Explorer auswählen, wenn Sie sich bereits in der Stackdriver-Konsole befinden.
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. Beispiel: Sie suchen nach proxy/latencies:
Wählen Sie den gewünschten Messwert aus.
Wenden Sie den Filter an. Die Filteroptionen für jeden Messwert sind unter Available metrics aufgeführt. Für den Messwert proxy_latencies lauten beispielsweise die Optionen org=org_name.
Das Diagramm für den ausgewählten Messwert wird in Stackdriver angezeigt.
Klicken Sie auf Speichern.

Dashboard erstellen

Mit Dashboards können Sie relevante Messwertdaten ansehen und analysieren. Stackdriver bietet vordefinierte Dashboards für die von Ihnen verwendeten Ressourcen und Dienste. 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 in Stackdriver ein Dashboard erstellen und dann Diagramme hinzufügen, um Messwertdaten anzuzeigen:

Öffnen Sie den Monitoring Metrics Explorer in einem Browser und wählen Sie Dashboards aus.
Wählen Sie + Dashboard erstellen aus.
Geben Sie einen Namen für das Dashboard ein. Beispiel: Anfragetraffic des Hybridproxys
Klicken Sie auf Bestätigen.
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. Stackdriver 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
`/proxy/request_count`	`method`	Die Gesamtzahl der erhaltenen API-Proxyanfragen.
`/proxy/response_count`	`method` `response_code`	Die Gesamtzahl der empfangenen API-Proxy-Antworten.
`/proxy/latencies`	`method`	Gesamtzahl der Millisekunden, die für die Beantwortung eines Anrufs benötigt wurden. Diese Zeit umfasst den Apigee-API-Proxy-Overhead und die Uhrzeit Ihres Zielservers.
`/target/request_count`	`method` `target_type` `target_endpoint`	Die Gesamtzahl der Anforderungen, die an den Ziel-Proxy gesendet wurden.
`/target/response_count`	`method` `response_code` `target_type` `target_endpoint`	Die Gesamtzahl der Antworten, die vom Ziel des Proxys empfangen wurden.
`/target/latencies`	`method` `response_code` `target_type` `target_endpoint`	Gesamtzahl der Millisekunden, die für die Beantwortung eines Anrufs benötigt wurden. Dies umfasst nicht den Apigee-API-Proxy-Overhead.
`/policy/latencies`	`policy_name`	Die Gesamtzahl der Millisekunden, die diese benannte Richtlinie ausgeführt hat.
`/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 sich verzögert. `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.