In diesem Dokument sind die Kontingente und Systemlimits für Cloud Monitoring aufgeführt.
- Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
- Systemlimits sind feste Werte, die nicht geändert werden können.
Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einerGoogle Cloud Ressource Ihr Google Cloud Projekt nutzen kann. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt nebenläufig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community derGoogle Cloud Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud Ressourcen.
Das Cloud-Kontingentsystem tut Folgendes:
- Es überwacht Ihren Verbrauch von Google Cloud Produkten und Diensten.
- Es schränkt Ihren Verbrauch dieser Ressourcen ein.
- Es bietet eine Möglichkeit, Änderungen am Kontingentwert zu beantragen und Kontingentanpassungen zu automatisieren.
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie auszuführen versuchen, schlägt dann fehl.
Kontingente gelten in der Regel auf Google Cloud Projektebene. Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Weitere Informationen finden Sie unter Cloud-Kontingente – Übersicht.
Die meisten Kontingente können Sie in der Google Cloud Console anpassen. Weitere Informationen finden Sie unter Kontingentanpassung anfordern.
Für Monitoring-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.
Benutzerdefinierte Messwerte
Auf der Cloud Monitoring-Seite Messwertverwaltung können Sie den Betrag steuern, den Sie für abrechenbare Messwerte ausgeben, ohne die Beobachtbarkeit zu beeinträchtigen. Die Seite Messwertverwaltung enthält die folgenden Informationen:
- Aufnahmevolumen für byte- und probenbasierte Abrechnung für Messwertdomains und einzelne Messwerte
- Daten zu Labels und zur Kardinalität von Messwerten
- Anzahl der Lesevorgänge für jeden Messwert
- Nutzung von Messwerten in Benachrichtigungsrichtlinien und benutzerdefinierten Dashboards
- Fehlerrate beim Schreiben von Messwerten
Auf der Seite Messwertverwaltung können Sie auch nicht benötigte Messwerte ausschließen, um unnötige Kosten bei der Datenaufnahme zu vermeiden. Weitere Informationen zur Seite Messwertverwaltung finden Sie unter Messwertnutzung ansehen und verwalten.
| Kategorie | Höchstwert |
|---|---|
| Benutzerdefinierte Messwertdeskriptoren pro Projekt1 | 10.000 |
| Labels pro benutzerdefiniertem, externem und Arbeitslast-Messwertdeskriptor | 30 |
| Labels pro Prometheus-Messwert-Deskriptor | 200 |
| Stringlänge für den Labelschlüssel | 100 |
| Stringlänge für den Labelwert | 1.024 |
| Zeitreihen in einer Schreibanfrage2 | 200 |
| Rate, mit der Daten in eine einzelne Zeitreihe geschrieben werden können3 | 1 Datenpunkt pro 5 Sekunden |
| Histogramm-Buckets pro benutzerdefiniertem Verteilungsmesswert | 200 |
| Arbeitslast-, Prometheus- und externe4 Messwertdeskriptoren pro Projekt | 25.000 |
| Aktive Zeitachsen aus benutzerdefinierten Messwerten pro überwachter Ressource5 | 200.000 |
| Aktive Zeitachsen aus Arbeitslastmesswerten pro überwachter Ressource5 | 200.000 |
| Aktive Zeitreihen aus Prometheus pro überwachter Ressource5 | 1.000.000 |
| Aktive Zeitachsen aus externen Messwerten pro überwachter Ressource5 | 200.000 |
| Rate, mit der Messwertdeskriptoren erstellt werden können | 6.000 pro Minute und Projekt |
1 Dieses Limit wird durch Cloud Monitoring festgelegt. Andere Dienste können niedrigere Höchstwerte vorschreiben. Benutzerdefinierte Messwerte sind solche, die in custom.googleapis.com geschrieben werden.
2 Pro Zeitreihe in einer Anfrage kann nur ein Datenpunkt geschrieben werden. Der genannte Höchstwert entspricht also zugleich der maximalen Anzahl von Datenpunkten, die pro Anfrage geschrieben werden können.
3 Bei der Cloud Monitoring API müssen zwischen den Endzeiten von Punkten, die in eine Zeitreihe geschrieben werden, mindestens fünf Sekunden liegen. Wenn die Datenpunkte in der richtigen Reihenfolge in die Zeitreihe geschrieben werden, können Sie dafür einen Batchvorgang nutzen.
4
Externe Messwerte sind Messwerte, die in external.googleapis.com geschrieben werden.
5 Eine Zeitreihe ist aktiv, wenn Sie in den vergangenen 24 Stunden Datenpunkte darauf geschrieben haben.
Das in der Zeile angegebene Limit ist die Gesamtzahl der aktiven Zeitreihen für eine einzelne überwachte Ressource (z. B. eine einzelne gce_instance-VM oder ein einzelner k8s_container-Container) für alle benutzerdefinierten Messwerte in dieser Zeile (benutzerdefiniert, Arbeitslast, Prometheus oder extern). Eine Ausnahme ist die überwachte Ressource global, für die das Limit für jeden benutzerdefinierten Messwert separat gilt. Dies ist ein systemweiter Sicherheitsgrenzwert und kann nicht angepasst werden.
Kontingente und Limits der Monitoring API
| Kategorie | Höchstwert |
|---|---|
| Limits der API-Nutzung |
So finden Sie die API-Kontingente und -Limits:
|
| Lebensdauer der API-Seitentoken | 24 Stunden |
| Maximale Antwortgröße | 200 MB Gilt für die Größe der serialisierten Antwortnutzlast, die sowohl die Rohdaten als auch die Labelschlüssel und -werte für jede zurückgegebene Zeitreihe enthält. Wenn die Antwort einer Abfrage 200 MB überschreitet, schlägt die Anfrage mit dem Fehler So verhindern oder beheben Sie
|
Kontingente der Monitoring API
Für die Monitoring API gelten Kontingentlimits für die Anzahl der Zeitreihenanforderungen zur Aufnahme von Daten und für Zeitreihenabfragen. Anforderungen zur Aufnahme von Daten sind Aufrufe, die Zeitreihendaten schreiben, und Abfragen sind Aufrufe, die Zeitreihendaten abrufen. Auch für andere Monitoring API-Endpunkte gelten interne Limits. Solche Endpunkte sind nicht darauf ausgelegt, eine hohe Anzahl an Anforderungen zu verarbeiten.
Wenn Sie die Anzahl der API-Anfragen reduzieren möchten, die Ihre Dienste beim Schreiben von Zeitreihendaten senden, können Sie eine API-Anfrage verwenden, um Daten für mehrere Zeitreihen zu schreiben.
Wir empfehlen, mindestens 10 Objekte pro Anfrage zu schreiben.
Weitere Informationen zum Erstellen von Batch-API-Anfragen finden Sie unter timeSeries.create.
Wenn Sie nach dem Batching Ihrer API-Anfragen weiterhin höhere Monitoring API-Kontingentlimits benötigen, wenden Sie sich an den Google Cloud -Support.
Die anderen Limits sind fest und werden in diesem Dokument beschrieben.
Weitere Informationen finden Sie in der Dokumentation zu Cloud-Kontingenten.
Telemetry API-Kontingente und -Limits für die Messwertaufnahme
In diesem Abschnitt werden die Kontingente und Limits beschrieben, die für die Telemetry (OTLP) API gelten, wenn sie für die Messwertaufnahme verwendet wird. Die Telemetry API implementiert die OpenTelemetry-OTLP-Spezifikation.
| Beschreibung | Wert | Notiz |
|---|---|---|
| Maximale Anzahl von Datenpunkten pro Anfrage | 200 | Limit |
| Maximale Anzahl von ResourceMetrics pro Anfrage | 200 | Limit |
| Maximale Anzahl von Quantilen pro Zusammenfassungsmesswert | 10 | Limit |
| Anzahl der Anfragen zur Messwertaufnahme pro Minute und Region (Kontingent) | 60.000 | Kontingent |
Die Verwendung der Telemetry API verbraucht kein Kontingent für die Cloud Monitoring API-Aufnahme. Nachdem Messwerte aufgenommen wurden, gelten die anderen in diesem Dokument beschriebenen Cloud Monitoring-Kontingente und -Limits.
Datenaufbewahrung
Messwertdatenpunkte, deren Aufbewahrungsdauer überschritten wurde, werden aus Zeitreihen gelöscht.
| Kategorie | Wert |
|---|---|
Aufbewahrung von Datenpunkten aus benutzerdefinierten, externen und Agent-Messwerten, darunter:
|
24 Monate1 |
Aufbewahrung von Datenpunkten für einige Google Cloud -Dienste, einschließlich der meisten Messwerte in den folgenden Kategorien:
|
24 Monate1 |
| Aufbewahrung von Datenpunkten aus allen anderen Messwerttypen, einschließlich | 6 Wochen |
| Lebensdauer der API-Seitentoken | 24 Stunden |
† Messwertdaten werden – bei ursprünglicher Frequenz der Probenahme – für einen Zeitraum von 6 Wochen aufbewahrt. Die Frequenz wird anschließend zur erweiterten Speicherung auf 10-Minuten-Intervalle herabgestuft.
2 Messwertdaten von Google Cloud Managed Service for Prometheus und OTLP werden eine Woche lang mit der ursprünglichen Abtastfrequenz gespeichert, dann für die nächsten fünf Wochen auf 1-Minuten-Intervalle herabgestuft und dann für die erweiterte Speicherung auf 10-Minuten-Intervalle herabgestuft.
Ressourcengruppen
| Kategorie | Wert |
|---|---|
| Anzahl der Ressourcengruppen pro Messwertbereich | 500 |
| Maximale Anzahl an Gruppen in einem E-Mail-Bericht1 | 10 |
1 Bei der Konfiguration von Cloud Monitoring-E-Mail-Berichten können Sie Informationen zur Nutzung Ihrer Ressourcengruppen anfordern. Aufgrund von Einschränkungen innerhalb des Tools für die E-Mail-Berichte können die generierten Berichte jedoch nur Daten zu maximal zehn Gruppen enthalten.
Überwachte Projektlimits
Cloud Monitoring unterstützt offiziell bis zu 375 Google Cloud -Projekte pro Messwertbereich .
Sie können bis zu 3.500 Google Cloud Projekte pro Messwertbereich hinzufügen. Es können jedoch Leistungsprobleme auftreten, insbesondere beim Abfragen benutzerdefinierter Messwerte oder Verlaufsdaten. Cloud Monitoring garantiert leistungsstarke Abfragen und Diagramme nur für 375 Google Cloud -Projekte pro Messwertbereich .
Wenn Sie das Kontingent für Google Cloud Projekte pro Messwertbereich erhöhen möchten, können Sie eine Erhöhung des Kontingents „Beobachtete Projekte / Monitoring-Messwertbereich“ anfordern. Weitere Informationen finden Sie in der Dokumentation zum Verwalten Ihres Kontingents.
Limits für das Erstellen und Aktualisieren von Messwertdeskriptoren
Cloud Monitoring erzwingt beim Erstellen neuer Messwerte, beim Hinzufügen neuer Labelnamen zu vorhandenen Messwerten und beim Löschen von Messwerten ein Ratenlimit pro Minute. Diese Ratenbegrenzung wird normalerweise nur erreicht, wenn Sie zum ersten Mal eine Einbindung in Cloud Monitoring vornehmen, z. B. beim Migrieren einer vorhandenen, ausgereiften Prometheus-Bereitstellung zu Cloud Monitoring. Dies ist keine Ratenbegrenzung für die Aufnahme von Datenpunkten. Dieses Ratenlimit gilt nur, wenn noch-nie-dagewesene Messwerte erstellt oder neue Messwerte zu vorhandenen Messwerten hinzugefügt werden.
Dieses Kontingent ist fest, aber alle Probleme sollten automatisch behoben werden, wenn neue Messwerte und Messwertlabels bis zum Limit pro Minute erstellt werden.
Limits für Benachrichtigungen
In den ersten beiden Spalten der folgenden Tabelle sind eine Kategorie und ein Limitwert aufgeführt. In der dritten Spalte sind die Richtlinientypen aufgeführt, für die das Limit gilt:
- Messwert: Gilt für Benachrichtigungsrichtlinien, die Messwertdaten überwachen, einschließlich logbasierter Messwerte.
- LBA: Gilt für Benachrichtigungsrichtlinien, mit denen Logeinträge überwacht werden. Diese Richtlinien werden als logbasierte Benachrichtigungsrichtlinien bezeichnet.
- SQL: Gilt für Benachrichtigungsrichtlinien, die ein SQL-Abfrageergebnis überwachen.
- Alle: Gilt für alle Benachrichtigungsrichtlinien.
| Kategorie | Wert | Richtlinientyp |
|---|---|---|
| Benachrichtigungsrichtlinien (Summe aus Messwert und Log) pro Messwertbereich 1 | 2.000 | Messwert, LBA |
| Bedingungen pro messwertbasierter Benachrichtigungsrichtlinie | 6 | Messwert |
| Bedingungen pro SQL-basierter Benachrichtigungsrichtlinie (Öffentliche Vorschau) |
1 | SQL |
| Maximale Abfrageausführungszeit für eine SQL-basierte Benachrichtigungsrichtlinie (Öffentliche Vorschau) |
5 Minuten | SQL |
| Maximaler Zeitraum, den eine Bedingung für das Fehlen von Messwerten auswertet2 |
1 Tag | Messwert |
| Maximaler Zeitraum, den eine Messwert-Schwellenwertbedingung auswertet2 |
25 Stunden | Messwert |
| Maximaler Zeitraum, den eine PromQL-Bedingung von auswertet |
2 Jahre | Messwert |
| Maximale Länge des Filters, der in einer Messwertschwellenwert-Bedingung verwendet wird |
2.048 Unicode-Zeichen | Messwert |
| Maximale Anzahl von Zeitreihen , die von einer Prognosebedingung überwacht werden |
64 | Messwert |
| Mindestprognosefenster | 1 Stunde (3.600 Sekunden) | Messwert |
| Maximales Prognosefenster | 2,5 Tage (216.000 Sekunden) | Messwert |
| Benachrichtigungskanäle pro Benachrichtigungsrichtlinie | 16 | Alle |
| Maximale Anzahl neuer Benachrichtigungen pro logbasierter Benachrichtigungsrichtlinie |
20 Benachrichtigungen pro Tag | LBA |
| Maximale Anzahl von Benachrichtigungen3 pro logbasierter Benachrichtigungsrichtlinie |
20 Benachrichtigungen pro Tag | LBA |
| Maximale Rate neuer Benachrichtigungen pro logbasierter Benachrichtigungsrichtlinie |
2 neue Benachrichtigungen pro Minute | LBA |
| Mindestintervall zwischen Benachrichtigungen für eine offene Benachrichtigung4 pro logbasierter Benachrichtigungsrichtlinie |
5 Minuten | LBA |
| Maximale Anzahl gleichzeitig ausgelöster Benachrichtigungsrichtlinien pro Projekt: |
80.000 | Alle |
| Maximale Anzahl gleichzeitig offener Benachrichtigungen pro Benachrichtigungsrichtlinie |
1.000 | Alle |
| Zeitraum, nach dem eine Benachrichtigung ohne neue Daten automatisch geschlossen wird |
7 Tage | Messwert, SQL |
| Maximale Dauer einer Benachrichtigung, wenn sie nicht manuell geschlossen wird | 7 Tage | LBA |
| Aufbewahrung geschlossener Benachrichtigungen | 13 Monate | Nicht zutreffend |
| Aufbewahrung offener Benachrichtigungen | Unbefristet | Nicht zutreffend |
| Benachrichtigungskanäle pro Messwertbereich | 4.000 | Nicht zutreffend |
| Maximale Anzahl von Benachrichtigungsrichtlinien pro Schlummerfunktion | 16 | Alle |
| Beibehaltung einer Schlummerfunktion | 13 Monate | Nicht zutreffend |
2Der maximale Zeitraum, den eine Bedingung auswertet, ist die Summe der Werte für den Ausrichtungszeitraum und das Dauerfenster. Wenn für den Ausrichtungszeitraum beispielsweise 15 Stunden festgelegt sind und das Dauerfenster 15 Stunden beträgt, sind 30 Stunden für die Bewertung der Bedingung erforderlich.
3Monitoring generiert Benachrichtigungen für eine offene Warnung, wenn die Mindestzeit zwischen Benachrichtigungen verstrichen ist und ein Logeintrag mit den Warnungs-Labels übereinstimmt. Wenn eine logbasierte Benachrichtigungsrichtlinie deaktiviert ist, wenn Monitoring eine Benachrichtigung generiert, wird die Benachrichtigung verworfen und nicht an die Benachrichtigungskanäle der Richtlinie gesendet. Andernfalls sendet Monitoring die Benachrichtigung an die Benachrichtigungskanäle der Benachrichtigungsrichtlinie. Alle von Monitoring generierten Benachrichtigungen werden auf das Limit der Benachrichtigungsrichtlinie von 20 Benachrichtigungen pro Tag angerechnet.
4Wenn die Abfrage Ihrer logbasierten Benachrichtigungsrichtlinie Labels extrahiert, stellt jede Kombination von extrahierten Labelwerten eine eigene Benachrichtigungszeitachse dar. Daher können Sie innerhalb von 5 Minuten mehrere Benachrichtigungen erhalten.
Limits für SMS-Nachrichten
Die SMS-Limits gelten für einen rollierenden Zeitraum von 24 Stunden.
| Kategorie | Wert |
|---|---|
| Anzahl der SMS-Bestätigungscodes | 40 |
| Anzahl der SMS-Bestätigungscodes pro Telefonnummer | 5 |
| Anzahl der SMS-Benachrichtigungen | 2.500 |
| Anzahl der SMS-Benachrichtigungen pro Telefonnummer | 200 |
Limits für synthetische Monitore
| Kategorie | Wert |
|---|---|
| Verfügbarkeitsdiagnosen pro Messwertbereich * | 100 |
| Maximale Anzahl von ICMP-Pings pro öffentlicher Verfügbarkeitsdiagnose | 3 |
| Synthetisches Monitoring pro Messwertbereich | 100† |
†Informationen zum Erhöhen dieses Limits finden Sie unter Kontingentanpassung anfordern.
Limits für Diagramme
| Kategorie | Wert |
|---|---|
| Dashboards pro Messwertbereich | 1000 |
| Diagramme in einem Dashboard | 100 |
| Aufbewahrung des Versionsverlaufs von Dashboards | 90 Tage |
| Linien in einem Diagramm | 50* |
| Zeilen in einer Tabelle | 300 |
| Maximale Anzahl von Benachrichtigungsrichtlinien pro Benachrichtigungs-Widget | 20 |
| Maximale Anzahl von Ressourcen pro Benachrichtigungs-Widget | 20 |
| Maximale Anzahl von Zeichen in der Abfrage eines Logbereich-Widgets | 2.000 |
To improve performance, we've limited the time series displayed in this chart angezeigt.
Wenn Sie alle Zeitreihen anzeigen möchten, maximieren Sie die Kurzinfo und wählen Sie den Button Alle Zeitreihen anzeigen aus.
Service Level Objectives
| Kategorie | Wert |
|---|---|
| Anzahl der SLOs pro Dienst | 500 |
Limits für Tags
| Kategorie | Wert |
|---|---|
| Maximale Anzahl von Teams pro Projekt bei Verwendung von Tags für die Zugriffssteuerung | 250 |