Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini memberikan informasi tentang berapa lama Cloud Monitoring menyimpan data metrik Anda dan informasi tentang latensi antara pengumpulan data dan visibilitasnya kepada Anda.
Kuota dan batas memberikan informasi tambahan tentang batas pada data metrik.
Retensi data metrik
Cloud Monitoring memperoleh data metrik dan menyimpannya dalam deret waktu jenis metrik selama jangka waktu tertentu. Periode waktu ini bervariasi menurut
jenis metrik; Lihat Retensi data untuk mengetahui detailnya.
Pada akhir periode tersebut, Cloud Monitoring akan menghapus titik data yang sudah tidak berlaku.
Jika semua titik dalam deret waktu telah berakhir masa berlakunya, Cloud Monitoring akan menghapus deret waktu tersebut. Deret waktu yang dihapus tidak akan muncul di diagram Cloud Monitoring atau dalam hasil dari Monitoring API.
Latensi data metrik
Latensi mengacu pada
keterlambatan antara waktu Cloud Monitoring mengambil sampel metrik dan waktu
titik data metrik terlihat sebagai data deret waktu. Latensi bergantung
pada apakah metrik tersebut adalah metrik dari Google Cloud layanan atau
metrik yang ditentukan pengguna:
Google Cloud metrics: DaftarGoogle Cloud metrics
menyertakan jenis metrik dari Google Cloud layanan. Banyak dari
deskripsi ini menyertakan pernyataan seperti berikut: “Disaring setiap
60 detik. Setelah pengambilan sampel, data tidak akan terlihat selama maksimal 240
detik.”
Nilai dalam pernyataan bervariasi untuk metrik tertentu.
Contoh pernyataan ini berarti Cloud Monitoring mengumpulkan satu pengukuran setiap menit (interval pengambilan sampel), tetapi karena beberapa metrik ini menerima pemrosesan tambahan sebelum diekspos, mungkin perlu waktu tambahan (latensi) sebelum Anda dapat mengambil data untuk metrik ini. Dalam contoh ini, latensi dapat
berlangsung hingga 4 menit. Jadi, stempel waktu yang mencatat waktu pengumpulan mungkin
berumur hingga 4 menit untuk metrik ini.
Latensi ini tidak berlaku untuk metrik yang ditentukan pengguna.
Metrik yang ditentukan pengguna: Jika Anda menulis data ke metrik yang ditentukan pengguna, termasuk metrik kustom, metrik yang dikumpulkan OpenTelemetry, metrik aplikasi yang dikumpulkan oleh Agen Ops, dan metrik Prometheus, data dari metrik ini biasanya terlihat dan dapat dikueri dalam waktu 3 hingga 7 detik, tidak termasuk latensi jaringan.
Dalam beberapa situasi, Anda mungkin perlu menyesuaikan cara menggunakan metrik dengan latensi.
Contoh:
Saat menggunakan library klien untuk mengambil data metrik, Anda mungkin perlu menggunakan offset dalam interval kueri untuk memperhitungkan latensi.
Saat menggunakan metrik untuk mendorong pengelolaan resource seperti saat penskalaan otomatis,
latensi metrik dapat memengaruhi responsivitas penskalaan otomatis.
Misalnya, beberapa metrik Pub/Sub memiliki latensi
yang berkisar antara 2 hingga 4 menit.
Saat menggunakan kebijakan pemberitahuan, perhatikan bahwa latensi dapat memengaruhi waktu pembuatan insiden untuk kebijakan pemberitahuan berbasis metrik. Misalnya, jika metrik yang dipantau memiliki latensi hingga 180 detik, Cloud Monitoring tidak akan membuat insiden hingga 180 detik setelah metrik tersebut melanggar nilai minimum kondisi kebijakan pemberitahuan.
Cloud Monitoring secara otomatis memperhitungkan latensi, jika ada, dari metrik pokok saat mengevaluasi kebijakan pemberitahuan.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
