Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie Informationen dazu, wie lange Cloud Monitoring Ihre Messwertdaten aufbewahrt, sowie Informationen zur Latenz zwischen der Datenerfassung und ihrer Sichtbarkeit für Sie.
Cloud Monitoring erfasst Messwertdaten und speichert sie für einen bestimmten Zeitraum in der Zeitachse der Messwerttypen. Dieser Zeitraum hängt vom Messwerttyp ab. Weitere Informationen finden Sie unter Datenaufbewahrung.
Am Ende dieses Zeitraums löscht Cloud Monitoring die abgelaufenen Datenpunkte.
Wenn alle Punkte in einer Zeitachse abgelaufen sind, löscht Cloud Monitoring die Zeitachse. Gelöschte Zeitreihen werden weder in Cloud Monitoring-Diagrammen noch in den Ergebnissen der Monitoring API angezeigt.
Latenz von Messwertdaten
Latenz bezieht sich auf die Verzögerung zwischen dem Zeitpunkt, zu dem Cloud Monitoring einen Messwert erfasst, und dem Zeitpunkt, zu dem der Messwert als Zeitreihendaten sichtbar wird. Die Latenz hängt davon ab, ob es sich um einen Messwert aus einem Google Cloud Dienst oder einen benutzerdefinierten Messwert handelt:
Google Cloud -Messwerte: Die Google Cloud Messwertliste enthält die Messwerttypen von Google Cloud -Diensten. Viele dieser Beschreibungen enthalten eine Aussage wie die folgende: „Stichproben alle 60 Sekunden. Nach dem Abruf werden bis zu 240 Sekunden lang keine Daten angezeigt.
Die Werte in der Erklärung variieren je nach Messwert.
Die Beispielanweisung bedeutet, dass in Cloud Monitoring jede Minute eine Messung erfasst wird (das Stichprobenintervall). Da einige dieser Messwerte jedoch vor der Veröffentlichung noch zusätzlich verarbeitet werden, kann es zusätzliche Zeit (Latenz) dauern, bis Sie die Daten für diesen Messwert abrufen können. In diesem Beispiel kann die Latenz bis zu 4 Minuten betragen. Der Zeitstempel der Erfassungszeit kann also bis zu vier Minuten alt sein.
Diese Latenz gilt nicht für benutzerdefinierte Messwerte.
Benutzerdefinierte Messwerte: Wenn Sie Daten in benutzerdefinierte Messwerte schreiben, einschließlich benutzerdefinierter Messwerte, von OpenTelemetry erfasste Messwerte, vom Ops-Agent erfasste Anwendungsmesswerte und Prometheus-Messwerte, sind die Daten aus diesen Messwerten in der Regel innerhalb von 3 bis 7 Sekunden sichtbar und abfragbar, Netzwerklatenz ausgenommen.
In einigen Fällen müssen Sie möglicherweise die Verwendung eines Messwerts mit Latenz anpassen.
Beispiel:
Wenn Sie Clientbibliotheken zum Abrufen von Messdaten verwenden, müssen Sie möglicherweise einen Offset im Abfrageintervall verwenden, um die Latenz zu berücksichtigen.
Wenn Sie einen Messwert für die Ressourcenverwaltung verwenden, z. B. beim Autoscaling, kann sich die Latenz des Messwerts auf die Reaktionsfähigkeit des Autoscaling auswirken.
Beispielsweise haben einige Pub/Sub-Messwerte Latenzen von 2 bis 4 Minuten.
Bei der Verwendung von Benachrichtigungsrichtlinien ist zu beachten, dass sich die Latenz auf die Zeit auswirken kann, zu der bei messwertbasierten Benachrichtigungsrichtlinien ein Vorfall erstellt wird. Wenn ein überwachter Messwert beispielsweise eine Latenz von bis zu 180 Sekunden hat, wird in Cloud Monitoring erst nach bis zu 180 Sekunden nach dem Überschreiten des Schwellenwerts der Bedingung der Benachrichtigungsrichtlinie ein Vorfall erstellt.
Bei der Auswertung von Benachrichtigungsrichtlinien wird in Cloud Monitoring automatisch die gegebenenfalls vorhandene Latenz des zugrunde liegenden Messwerts berücksichtigt.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-28 (UTC)."],[],[],null,["# Retention and latency of metric data\n\nThis page provides information about how long Cloud Monitoring retains\nyour metric data and information about the latency between the collection\nof the data and its visibility to you.\n\n[Quotas and limits](/monitoring/quotas) provides additional information about\nlimits on metric data.\n\nRetention of metric data\n------------------------\n\nCloud Monitoring acquires metric data and holds it in the time series\nof metric types for a period of time. This period of time varies with the\nmetric type; See [Data retention](/monitoring/quotas#data_retention_policy) for details.\n\nAt the end of that period, Cloud Monitoring deletes the expired data points.\n\nWhen all the points in a time series have expired, Cloud Monitoring\ndeletes the time series. Deleted time series don't appear in\nCloud Monitoring charts or in results from the\nMonitoring API.\n\nLatency of metric data\n----------------------\n\n*Latency* refers to the delay between when Cloud Monitoring samples a metric and when the metric data point becomes visible as time series data. The latency depends on whether the metric is a metric from a Google Cloud service or a user-defined metric:\n\n- **Google Cloud metrics** : The [Google Cloud metrics list](/monitoring/api/metrics_gcp)\n includes the metric types from Google Cloud services. Many of these\n descriptions include a statement like the following: \"Sampled every\n 60 seconds. After sampling, data is not visible for up to 240\n seconds.\"\n\n The values in the statement vary for specific metrics.\n The example statement means that Cloud Monitoring collects one\n measurement each minute (the sampling interval), but because some\n of these metrics receive additional processing before they are\n exposed, it can take additional time (latency) before you can retrieve the\n data for this metric. In this example, the latency can be\n up to 4 minutes. So, the timestamp recording the collection time might\n be up to 4 minutes old for this metric.\n This latency doesn't apply to user-defined metrics.\n\n\u003c!-- --\u003e\n\n- **User-defined metrics**: If you are writing data to user-defined metrics, including custom metrics, OpenTelemetry-collected metrics, application metrics collected by the Ops Agent, and Prometheus metrics, then data from these metrics is typically visible and queryable within 3 to 7 seconds, excluding network latency.\n\nIn some situations, you might need to adjust how you use a metric with latency.\nFor example:\n\n- When using client libraries to retrieve metric data, you might need to\n use an offset in the query interval to account for latency.\n\n- When using a metric to drive resource management like when autoscaling,\n the latency of the metric can affect the responsiveness of the autoscaling.\n For example, some [Pub/Sub metrics](/monitoring/api/metrics_gcp_p_z#gcp-pubsub) have latencies\n that range from 2 to 4 minutes.\n\n- When using alerting policies, be aware that latency can affect incident\n creation time for metric-based alerting policies. For example, if a\n monitored metric has a latency of up to 180 seconds, then\n Cloud Monitoring won't create an incident for up to 180 seconds after\n the metric violates the threshold of the alerting policy condition.\n Cloud Monitoring automatically accounts for the latency, if any, of the\n underlying metric when evaluating alerting policies."]]
