Richtlinien für das Cluster-Monitoring

Überblick

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.

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 sum
Hinweis zur Benachrichtigung Ereignisse wie Benachrichtigungen zu einem ungewöhnlichen request_count-Anstieg/Rückgang
Benachrichtigungsgrenzwert
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 sum
Hinweis zur Benachrichtigung Ereignisse wie Benachrichtigungen zu einem ungewöhnlichen request_count-Anstieg/Rückgang
Benachrichtigungsgrenzwert
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_codes auszuschließen, zum Beispiel:


"response_code !=~ 1.*| 2.*|3.*"
Gruppieren nach method, response_code, fault_code, fault_source, apigee_fault und alle ProxyV2-Ressourcentyplabels
Aggregator sum
Hinweis zur Benachrichtigung Das Verhältnis der Proxy-Antwortfehler: Gesamtzahl der Antwortfehler ÷ Gesamtzahl der Antworten.
  • Gesamtzahl der Antwortfehler = Summe von proxyv2/response_count mit Filter-response_code != 200
  • Gesamtzahl der Antworten = Summe von proxyv2/response_count
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_codes auszuschließen, zum Beispiel:


"response_code !=~ 1.*| 2.*|3.*"
Gruppieren nach method und alle TargetV2-Ressourcentyplabels
Aggregator sum
Hinweis zur Benachrichtigung Das Verhältnis der Proxy-Antwortfehler, z. B. Gesamtzahl der Antwortfehler / Gesamtzahl der Antworten.
  • Gesamtzahl der Antwortfehler = Summe von targetv2/response_count mit Filter-response_code != 200
  • Gesamtzahl der Antworten = Summe von targetv2/response_count
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 sum
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 sum
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
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 sum
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 sum
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 sum
Hinweis zur Benachrichtigung Verwenden Sie diese Option für Traffic-Anomalien, z. B. eine Benachrichtigung über einen ungewöhnlichen request_count-Anstieg oder -Rückgang.
Benachrichtigungsgrenzwert
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 sum
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-app
apigee-prometheus-proxy
apigee-prometheus-agg
apigee-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 sum
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)]