Übersicht
In diesem Leitfaden finden Sie Richtlinien zum Monitoring einer Apigee Hybrid-Bereitstellung. Es richtet sich an Hybrid-Cluster-Administratoren und Organisationsadministratoren.
Wenn Sie mit Google Cloud Monitoring nicht vertraut sind, lesen Sie die Google Cloud Monitoring-Dokumentation für Diagramme mit dem Metrics Explorer erstellen und Funktionsweise von Benachrichtigungen.
Apigee Hybrid-Cluster bieten SLI-Messwerte (Service Level Indicator), mit denen Sie die Leistung von Anwendungs- und Systemdiensten zu einem bestimmten Zeitpunkt nachvollziehen können. Eine vollständige Liste der verfügbaren Messwerte finden Sie hier.
Google Cloud Monitoring verwendet Ressourcentyp, um jeden SLI-Messwert zu identifizieren. Für alle Apigee Hybrid-Messwerte werden drei gängige Ressourcentypen verwendet.
k8s_containerfür Messwerte auf Systemebene.ProxyV2für Apigee API-Proxy-Messwerte.TargetV2für Apigee API-Zielmesswerte
Die Ressourcentypen haben allgemeine Labels, die für alle zugehörigen Messwerte gelten. Zusätzlich zu den Messwertlabels stehen beispielsweise für alle Messwerte mit dem Ressourcentyp k8s_container die Labels cluster_name, pod_name und container_name zur Verfügung. Eine Kombination aus Ressourcentyplabels und Messwertlabels sollte verwendet werden, um den Zustand und die Leistung des Clusters effektiv zu überwachen.
Benachrichtigungsgrenzwert: Optimal wäre es, wenn Grenzwerte für Benachrichtigungen offensichtlich wären und die bereitgestellte Dokumentation die Werte auflisten würde, die Benachrichtigungen auslösen sollen. Tatsächlich ist es für Apigee jedoch weniger offensichtlich zu definieren, was akzeptable Leistung und was eine gefährliche Ressourcennutzung von Diensten und Infrastrukturen ist. Die Grenzwerte für Benachrichtigungen können abhängig von bestimmten Trafficmustern und SLO/SLA-Vereinbarungen stark variieren.
Eine Optimierung und Bestimmung des Grenzwerts für Benachrichtigungen ist ein fortlaufender Prozess, der sich mit der Dienst- und Infrastrukturnutzung ändern kann. Verwenden Sie die Grenzwerte „Warnung“ und „Kritisch“ für Benachrichtigungen.
- Fehlerfrei: Der Wert liegt unter dem Grenzwert „Warnung“.
- Bedenklich: Der Wert liegt über dem Grenzwert „Warnung“, aber unter dem Grenzwert „Kritisch“.
- Kritisch: Der Wert liegt über dem Grenzwert „Kritisch“.
Kunden sollten die bereitgestellten Tools verwenden, um den optimalen Grenzwert zu bestimmen, unabhängig davon, ob es sich um die Cloud Monitoring-Dashboards handelt, die Kunden mit der unten aufgeführten MQL erstellen können, oder um die Apigee-Analyse, um zu ermitteln, wie „normal“ aussieht, und dann die Grenzwerte entsprechend zu optimieren.
Das Monitoring von Hybrid-Clustern kann in vier verschiedene allgemeine Gruppen unterteilt werden, z. B. Traffic, Datenbank, Apigee-Steuerungsebene und Infrastruktur. Diese Gruppen werden in den folgenden Abschnitten ausführlich beschrieben:
Traffic
Die Apigee-Proxy- und Ziel-SLI-Messwerte geben die Anzahl der Anfragen/Antworten und Latenzen für den API-Proxy und Ziele an. Der SLI-Messwert für die Apigee-Richtlinienlatenz zeigt Richtlinienantwortlatenzen. Diese SLI-Messwerte ermöglichen ein umfassendes Monitoring des Apigee API-Traffics.
Anfragerate
Anzahl der Proxyanfragen
Anwendungsfall: Verwenden Sie proxyv2/request_count, um die Anzahl der Proxyanfragen zu überwachen. Das Diagramm proxyv2/request_count zeigt die Anfragerate für Proxys an. Dieses Diagramm ist nützlich, um zu ermitteln, welcher Proxy eine höhere Anfragerate, Muster für die Anfragerate und ungewöhnliche Anstiege bei den Anfrageaufrufen für einen bestimmten Proxy empfängt. Jeder unerwartete ungewöhnliche Anstieg des API-Traffics kann ein Sicherheitsproblem bei einem Bot oder ein Angriff auf API-Proxys sein. Ein bedeutender Rückgang der allgemeinen Traffic-Cloud weist auf Probleme mit Clients oder der Konnektivität von Upstream-Komponenten von Apigee hin.
| Ressourcentypen | ProxyV2 |
| Messwert | proxyv2/request_count |
| Gruppieren nach | method und alle ProxyV2- -Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Ereignisse wie Benachrichtigungen zu einem ungewöhnlichen request_count-Anstieg/Rückgang |
| Benachrichtigungsgrenzwert | Keine |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch apigee.googleapis.com/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/request_count' | align rate(1m) | every 1m | group_by [metric.method], [value_request_count_aggregate: aggregate(value.request_count)] |
|
Anzahl der Zielanfragen
Anwendungsfall: Verwenden Sie den Wert für targetv2/request_count, um die Anzahl der Apigee-Laufzeitzielanfragen zu überwachen. Das Diagramm „targetv2/request_count“ zeigt die vom Apigee-Ziel empfangene Anfragerate an. Dieses Diagramm kann nützlich sein, um zu sehen, welches Ziel eine höhere Anfragerate, ein Muster der Anfragerate und einen ungewöhnlichen Anstieg der Anfrageaufrufe für ein bestimmtes Ziel erhält.
| Ressourcentypen | TargetV2 |
| Messwert | targetv2/request_count |
| Gruppieren nach | method und alle TargetV2-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Ereignisse wie Benachrichtigungen zu einem ungewöhnlichen request_count-Anstieg/Rückgang |
| Benachrichtigungsgrenzwert | Keine |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch apigee.googleapis.com/TargetV2 | metric 'apigee.googleapis.com/targetv2/request_count' | align rate(1m) | every 1m | group_by [metric.method, metric.type, metric.endpoint], [value_request_count_aggregate: aggregate(value.request_count)] |
|
Fehlerrate
Anzahl der Proxy-Fehlerantworten
Anwendungsfall: Verwenden Sie proxyv2/response_count, um die Antwortrate des Proxys zu überwachen. Das Diagramm proxyv2/response_count zeigt die Anfragerate für den API-Proxy an. Dieses Diagramm ist hilfreich, um nachzuvollziehen, welcher Proxy eine höhere Anfragefehlerrate oder einen ungewöhnlichen Anstieg bei Anfrageaufrufen für einen bestimmten Proxy erhält.
| Ressourcentypen | ProxyV2 |
| Messwert | proxyv2/response_count |
| Filtern nach | response_code != 200
Verwenden Sie einen regulären Ausdruck, um alle Werte für 2xx- und 3xx- "response_code !=~ 1.*| 2.*|3.*" |
| Gruppieren nach | method, response_code, fault_code, fault_source, apigee_fault und alle ProxyV2-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Das Verhältnis der Proxy-Antwortfehler: Gesamtzahl der Antwortfehler ÷ Gesamtzahl der Antworten.
|
| Benachrichtigungsgrenzwert | Hängt vom SLO für die Installation ab. Produktions- und Nicht-Produktionsinstallationen können unterschiedliche Grenzwerte haben. Beispiel: Lösen Sie für die Produktion eine Ereignisbenachrichtigung aus, wenn das 500-Fehlerverhältnis der Proxy-Antwort 5 Minuten lang 5 % beträgt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch apigee.googleapis.com/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/response_count' | filter (metric.response_code != '200') | align rate(1m) | every 1m | group_by [metric.method, metric.response_code, metric.fault_code, metric.fault_source, metric.apigee_fault], [value_response_count_aggregate: aggregate(value.response_count)] |
|
Beispiel für eine MQL-Benachrichtigungsrichtlinie für Google Cloud-Vorgänge:
fetch apigee.googleapis.com/ProxyV2::apigee.googleapis.com/proxyv2/response_count
| {
filter (metric.response_code == '500')
;
ident
}
| group_by drop[metric.response_code ], sliding(5m), .sum
| ratio
| scale '%'
| every (30s)
| condition val() > 5'%'
|
|
Anzahl der Zielfehlerantworten
Anwendungsfall: Verwenden Sie den targetv2/response_count, um die Fehlerantwortrate des API-Ziels zu überwachen. Das Diagramm „targetv2/response_count“ zeigt die Anfragerate vom API-Ziel an. Dieses Diagramm kann nützlich sein, um zu ermitteln, welches Ziel eine höhere Anfragerate oder ungewöhnliche Fehlerspitzen bei Anfrageaufrufen aufweist.
| Ressourcentypen | TargetV2 |
| Messwert | targetv2/response_count |
| Filtern nach | response_code != 200
Verwenden Sie einen regulären Ausdruck, um alle Werte für 2xx- und 3xx- "response_code !=~ 1.*| 2.*|3.*" |
| Gruppieren nach | method und alle TargetV2-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Das Verhältnis der Proxy-Antwortfehler, z. B. Gesamtzahl der Antwortfehler / Gesamtzahl der Antworten.
|
| Benachrichtigungsgrenzwert | Hängt vom SLO für die Installation ab. Beispiel: Lösen Sie für die Produktion eine Ereignisbenachrichtigung aus, wenn das Zielantwortverhältnis 3 Minuten lang 5 % beträgt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch apigee.googleapis.com/TargetV2 | metric 'apigee.googleapis.com/targetv2/response_count' | filter (metric.response_code != '200') | align rate(1m) | every 1m | group_by [metric.method, metric.type, metric.endpoint, metric.response_code], [value_response_count_aggregate: aggregate(value.response_count)] |
|
Latenzen
Latenzperzentil des Proxys
Anwendungsfall: Verwenden Sie das proxyv2/latencies_percentile, um das Latenzperzentil (p50, p90, p95 und p99) aller API-Proxy-Antworten auf eine Anfrage zu überwachen. Das Diagramm „proxyv2/latencies_percentile“ kann nützlich sein, um die Latenz im Apigee API-Proxy zur Gesamtlatenz der API-Proxy-Anfrage zu ermitteln.
| Ressourcentypen | ProxyV2 |
| Messwert | proxyv2/latencies_percentile |
| Filtern nach | percentile = p99 |
| Gruppieren nach | method, Perzentil und alle ProxyV2-Ressourcentyplabels |
| Aggregator | p99 (99. Perzentil) |
| Hinweis zur Benachrichtigung | Hoher Wert von p99 latencies_percentile. |
| Benachrichtigungsgrenzwert | Hängt vom SLO für die Installation ab. Beispiel: Lösen Sie für die Produktion eine Ereignisbenachrichtigung aus, wenn der Wert des p99 latencies_percentile des Proxys 5 Minuten lang 5 Sekunden beträgt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
[value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
[value_latencies_percentile_mean_percentile:
percentile(value_latencies_percentile_mean, 99)]
|
|
Latenzperzentil des Ziels
Anwendungsfall: Verwenden Sie das targetv2/latencies_percentile, um das Latenzperzentil (p50, p90, p95 und p99) aller Antworten des API-Proxy-Ziels auf eine Anfrage zu überwachen. Das Diagramm „targetv2/latencies_percentile“ gibt die Gesamtzeit an, in der das Ziel des Apigee API-Proxys auf eine Anfrage antworten kann. Dieser Wert umfasst nicht den Apigee-API-Proxy-Overhead.
| Ressourcentypen | TargetV2 |
| Messwert | targetv2/latencies_percentile |
| Filtern nach | percentile = p99 |
| Gruppieren nach | method, Perzentil und alle TargetV2-Ressourcentyplabels |
| Aggregator | p99 (99. Perzentil) |
| Hinweis zur Benachrichtigung | Hoher Wert von p99 latencies_percentile. |
| Benachrichtigungsgrenzwert | Hängt vom SLO für die Installation ab. Beispiel: Lösen Sie für die Produktion eine Ereignisbenachrichtigung aus, wenn der Wert des p99 latencies_percentile für das Ziel 5 Minuten lang 5 Sekunden beträgt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
[value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
[value_latencies_percentile_mean_percentile:
percentile(value_latencies_percentile_mean, 99)]
|
|
Latenzperzentil der Richtlinie
Anwendungsfall: Verwenden Sie das policyv2/latencies_percentile, um das Verarbeitungslatenzperzentil (p50, p90, p95 und p99) aller Apigee-Richtlinien zu überwachen. Das Diagramm policyv2/latencies_percentile kann nützlich sein, um die Latenz in der Apigee API-Richtlinie für die Gesamtlatenz der API-Proxyanfragen des Kunden zu identifizieren.
| Ressourcentypen | ProxyV2 |
| Messwert | proxyv2/latencies_percentile |
| Filtern nach | percentile = p99 |
| Gruppieren nach | method, Perzentil und alle ProxyV2-Ressourcentyplabels |
| Aggregator | p99 (99. Perzentil) |
| Hinweis zur Benachrichtigung | Hoher Wert von p99 latencies_percentile. |
| Benachrichtigungsgrenzwert | Hängt vom SLO für die Installation ab. Beispiel: Lösen Sie für die Produktion eine Ereignisbenachrichtigung aus, wenn der Wert des p99 latencies_percentile des Proxys 5 Minuten lang 5 Sekunden beträgt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/policyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
[value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.policy_name, metric.percentile],
[value_latencies_percentile_mean_aggregate:
aggregate(value_latencies_percentile_mean)]
|
|
Datenbank
Cassandra
Der Apigee Cassandra-Datenbankdienst hat mehrere Cassandra-SLI-Messwerte. Diese SLI-Messwerte können ein umfassendes Monitoring für den Apigee Cassandra-Dienst ermöglichen. Zusammen mit der Cassandra-Ressourcennutzung (CPU, Speicher und Festplatten-Volume) sollte mindestens die Latenz der Lese- und Schreibanfragen des Clients auf den Zustand des Cassandra-Dienstes überwacht werden.
Cassandra-Leseanfragerate
Anwendungsfall: Die cassandra/clientrequest_rate (mit scope=Read) Der SLI-Messwert bietet Einblicke in die durchschnittliche Leseanfragerate der Cassandra-Dienste zu einem bestimmten Zeitpunkt. Dieser Messwert hilft Ihnen, die Trends der Leseaktivität von Clients zu verstehen.
| Ressourcentypen | k8s_container |
| Messwert | cassandra/clientrequest_rate |
| Filtern nach | scope = Read und unit = OneMinuteRate |
| Gruppieren nach | scope, unit und alle k8s_container-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Bei potenziellen Problemen oder erheblichen Änderungen bei Anfragemustern der Clients; z. B. ein plötzlicher unerwarteter Anstieg oder Rückgang der Leseanfragerate. |
| Benachrichtigungsgrenzwert | – |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate')
| group_by 1m,
[value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
[value_clientrequest_latency_mean_aggregate:
aggregate(value_clientrequest_latency_mean)]
|
|
Cassandra-Schreibanfragerate
Anwendungsfall: Der SLI-Messwert cassandra/clientrequest_rate (mit scope=Write) gibt Einblicke in die durchschnittliche Schreibanfragerate für Cassandra-Dienste zu einem bestimmten Zeitpunkt. Dieser Messwert hilft Ihnen, die Trends der Schreibanfrageaktivität von Clients zu verstehen.
| Ressourcentypen | k8s_container |
| Messwert | cassandra/clientrequest_rate |
| Filtern nach | scope = Read und unit = OneMinuteRate |
| Gruppieren nach | scope, unit und alle k8s_container-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Bei potenziellen Problemen oder erheblichen Änderungen bei Abfragemustern von Clients; z. B. plötzliche unerwartete Anstiege oder Rückgänge bei Schreibanfragen, die untersucht werden sollten. |
| Benachrichtigungsgrenzwert | Keine |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate')
| group_by 1m,
[value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
[value_clientrequest_latency_mean_aggregate:
aggregate(value_clientrequest_latency_mean)]
|
|
Cassandra-Leseanfragelatenz
Anwendungsfall: Der SLI-Messwert cassandra/clientrequest_latency (mit scope=Read) bietet eine Latenz der Cassandra-Dienste für Leseanfragen (bei 99. Perzentil, 95. Perzentil oder 75. Perzentil). Diese Messwerte helfen bei der Gesamtansicht der Cassandra-Leistung und können auf Änderungen der Nutzungsmuster oder ein Problem hinweisen, das sich im Laufe der Zeit zeigt.
| Ressourcentypen | k8s_container |
| Messwert | cassandra/clientrequest_latency |
| Filtern nach | scope = Read und unit = 99thPercentile |
| Gruppieren nach | scope, unit und alle k8s_container-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Wenn der Latenz-SLI für Leseanfragen konsistent eine kontinuierlich ansteigende Latenz des 99. Perzentils zeigt. |
| Benachrichtigungsgrenzwert | Hängt von Ihrem SLO für Cassandra-Dienste ab. Beispiel: Lösen Sie in der Produktion eine Ereignisbenachrichtigung aus, wenn der Lesewert clientrequest_latency des 99. Perzentils 3 Minuten lang 5 Sekunden beträgt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == '99thPercentile')
| group_by 1m,
[value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
[value_clientrequest_latency_mean_aggregate:
aggregate(value_clientrequest_latency_mean)]
|
|
Cassandra-Schreibanfragelatenz
Anwendungsfall: Der SLI-Messwert cassandra/clientrequest_latency (mit scope=write) zeigt die Schreibanfragelatenz der Cassandra-Dienste (bei 99. Perzentil, 95. Perzentil oder 75. Perzentil). Diese Messwerte helfen bei der Gesamtansicht der Cassandra-Leistung und können auf Änderungen der Nutzungsmuster oder ein Problem hinweisen, das sich im Laufe der Zeit zeigt.
| Ressourcentypen | k8s_container |
| Messwert | cassandra/clientrequest_latency |
| Filtern nach | scope = Write und unit = 99thPercentile |
| Gruppieren nach | scope, unit und alle k8s_container-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Wenn der Latenz-SLI für Schreibanfragen konsistent eine kontinuierlich ansteigende Latenz des 99. Perzentils zeigt. |
| Benachrichtigungsgrenzwert | Hängt von Ihrem SLO für Cassandra-Dienste ab. Beispiel: Lösen Sie in der Produktion eine Ereignisbenachrichtigung aus, wenn der Schreibwert clientrequest_latency des 99. Perzentils 3 Minuten lang 5 Sekunden beträgt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == '99thPercentile')
| group_by 1m,
[value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
[value_clientrequest_latency_mean_aggregate:
aggregate(value_clientrequest_latency_mean)]
|
|
Apigee-Steuerungsebene
Die SLI-Messwerte des Apigee Synchronizer-Dienstes zeigen die Anzahl der Anfragen und Antworten zwischen der Apigee-Steuerungsebene und der Hybrid-Laufzeitebene. Synchronizer-Instanzen, die in der Laufzeitebene ausgeführt werden, sollten regelmäßig die Steuerungsebene abfragen, die Verträge herunterladen und diese den lokalen Laufzeitinstanzen zur Verfügung stellen.
Anfragerate
Anzahl der Upstream-Anfragen
Anwendungsfall: Die upstream/request_count-Messwerte geben die Anzahl der Anfragen an, die vom Synchronizer-Dienst an die Apigee-Steuerungsebene gesendet wurden.
| Ressourcentypen | k8s_container |
| Messwert | upstream/request_count |
| Filtern nach | container_name = apigee-synchronizer und type = CONTRACT |
| Gruppieren nach | method, type, container_name und alle k8s_container-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | request_count-Anstieg/Rückgang |
| Benachrichtigungsgrenzwert | Keine |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch k8s_container | metric 'apigee.googleapis.com/upstream/request_count' | filter (resource.container_name == 'apigee-synchronizer') && (metric.type == 'CONTRACT') | align rate(1m) | every 1m | group_by [metric.method, metric.type, resource.container_name], [value_request_count_aggregate: aggregate(value.request_count)] |
|
Fehlerrate
Anzahl der Upstream-Antworten
Anwendungsfall: Der SLI-Messwert upstream/response_count gibt die Anzahl der Antworten an, die die Synchronizer-Dienste von der Apigee-Steuerungsebene erhalten haben. Dieses Diagramm kann nützlich sein, um Verbindungs- oder Konfigurationsprobleme zwischen der Apigee Hybrid-Laufzeitebene und der Steuerungsebene zu identifizieren.
| Ressourcentypen | k8s_container |
| Messwert | upstream/request_count |
| Filtern nach | method, response_type, container_name und alle k8s_container-Ressourcentyplabels |
| Gruppieren nach | |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Bei Fehlern in upstream/response_count-Messwerten mit Nicht-200-Antwortcodes, die von der Apigee-Steuerungsebene zurückgegeben werden, sind weitere Untersuchungen dieser Fehler erforderlich. |
| Benachrichtigungsgrenzwert | Hängt von Ihrem SLO für Cassandra-Dienste ab. Beispiel: Lösen Sie in der Produktion eine Ereignisbenachrichtigung aus, wenn in Synchronizer alle drei Minuten ein response_code-Fehler auftritt. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch k8s_container | metric 'apigee.googleapis.com/upstream/response_count' | filter (resource.container_name == 'apigee-synchronizer') && (metric.response_code != '200' && metric.type == 'CONTRACT') | align rate(1m) | every 1m | group_by [metric.method, metric.response_code, metric.type, resource.container_name], [value_response_count_aggregate: aggregate(value.response_count)] |
|
Infrastruktur
GKE und andere Kubernetes-Plattformen bieten SLI-Messwerte auf Systemebene. Die SLI-Messwertlabels können gefiltert und gruppiert werden, um einen bestimmten Container und seine Ressourcennutzung zu überwachen. Zum Monitoring des Zustands und der Verfügbarkeit der Infrastruktur von Apigee-Laufzeitclustern kann ein Clusteradministrator die gemeinsame Ressourcennutzung von Containern und Pods wie CPU, Speicher, Laufwerk und Anzahl der Containerneustarts überwachen. Weitere Informationen zu verfügbaren Messwerten und Labels finden Sie in der GKE-Dokumentation.
In der folgenden Tabelle sind einige Dienste und Container aufgeführt, die Sie für die einzelnen Dienste überwachen können.
| Dienstname | Containername |
|---|---|
| Cassandra | apigee-cassandra |
| Message Processor (MP) | apigee-runtime |
| Synchronizer | apigee-synchronizer |
| Telemetrie | apigee-prometheus-appapigee-prometheus-proxyapigee-prometheus-aggapigee-stackdriver-exporter |
Container/Pods
Anzahl der Neustarts
Anwendungsfall: Der System-SLI-Messwert kubernetes.io/container/restart_count gibt an, wie oft ein Container neu gestartet wurde. Dieses Diagramm kann hilfreich sein, um zu ermitteln, ob ein Container häufig abstürzt/neu startet. Der spezifische Dienstcontainer kann nach Messwertlabels für das Container-Monitoring eines bestimmten Dienstes herausgefiltert werden.
Im Folgenden wird der Messwert kubernetes.io/container/restart_count für den Cassandra-Container verwendet. Sie können diesen Messwert für jeden Container in der obigen Tabelle verwenden.
| Ressourcentypen | k8s_container |
| Messwert | kubernetes.io/container/restart_count |
| Filtern nach | namespace_name = apigee und container_name =~ .*cassandra.* |
| Gruppieren nach | cluster_name, namespace_name, pod_name, container_name und alle k8s_container-Ressourcentyplabels |
| Aggregator | Summe |
| Hinweis zur Benachrichtigung | Wenn ein Container häufig neu gestartet wird, ist eine weitere Untersuchung der Ursache erforderlich. Es gibt mehrere Gründe für einen Neustart eines Containers, z. B. OOMKilled, das Datenlaufwerk ist voll und Konfigurationsprobleme. |
| Benachrichtigungsgrenzwert | Hängt vom SLO für die Installation ab. Beispiel: Lösen Sie für die Produktion eine Ereignisbenachrichtigung aus, wenn ein Container innerhalb von 30 Minuten mehr als fünfmal neu gestartet wird. |
MQL-Abfrage des Cloud Monitoring-Dashboards:
fetch k8s_container | metric 'kubernetes.io/container/restart_count' | filter (resource.container_name =~ '.*cassandra.*' && resource.namespace_name == 'apigee') | align rate(1m) | every 1m | group_by [resource.cluster_name, resource.namespace_name, resource.pod_name, resource.container_name], [value_restart_count_aggregate: aggregate(value.restart_count)] |
|