Menggunakan SLI Config Sync

Halaman ini menjelaskan cara menggunakan indikator tingkat layanan Config Sync (SLI).

Untuk menerima notifikasi saat Config Sync tidak berfungsi sebagaimana mestinya, siapkan Aturan pemberitahuan Prometheus berdasarkan SLI ini. Setiap SLI menyertakan contoh cara membuat pemberitahuan aturan. Untuk mempelajari lebih lanjut cara menggunakan Prometheus dengan Config Sync, lihat Memantau Config Sync dengan metrik.

Pod Config Sync dengan jumlah container yang salah

Jika jumlah container Config Sync Pod lebih rendah dari yang diharapkan, maka Config Sync mungkin tidak berjalan. Anda bisa menyetel pemberitahuan untuk mendeteksi hal ini dan memeriksa Pod Config Sync untuk mencari tahu mengapa beberapa container tidak ada. Saat menetapkan pemberitahuan, sebaiknya tetapkan interval waktu hingga setidaknya lima menit untuk menghindari peringatan yang tidak perlu. Misalnya, selama mengupgrade, jumlah container Pod mungkin turun di bawah target.

Jika Anda belum mengetahui jumlah penampung yang diharapkan, lihat Deployment Sinkronisasi, Pod, dan container.

Contoh aturan pemberitahuan Prometheus

Bagian ini mencakup contoh yang akan memberi tahu Anda jika ada Pod dengan jumlah penampung yang salah.

  • Untuk menerima notifikasi saat jumlah container dari Pod rekonsiliasi root berada di bawah jumlah yang diharapkan, buat aturan pemberitahuan berikut:

    alert: RootReconcilerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"root-reconciler-.*"}) < 4
# Setting the for field to 5m to avoid unnecessary alerts.
for: 5m

  • Untuk menerima notifikasi saat jumlah penampung pada rekonsiliasi namespace Pod berada di bawah jumlah yang diharapkan, buat aturan pemberitahuan berikut:

    alert: NamespaceReconcilerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"ns-reconciler-.*"}) < 4
for: 5m

  • Untuk menerima notifikasi saat jumlah container pod pengelola rekonsiliasi berada di bawah jumlah yang diharapkan, buat aturan pemberitahuan berikut:

    alert: ReconcilerManagerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"reconciler-manager-.*"}) < 2
for: 5m

Penampung Config Sync yang tidak responsif

Jika jumlah mulai ulang container Config Sync mencapai ambang batas, ada yang salah. Misalnya, penampung rekonsiliasi {i>root<i} yang tidak memiliki resource memori yang cukup akan memulai ulang dengan error OOMKilled sampai mendapatkan cukup memori.

Contoh aturan pemberitahuan Prometheus

Untuk menerima notifikasi saat penampung Config Sync telah dimulai ulang lainnya lebih dari tiga kali, buat aturan pemberitahuan berikut:

alert: TooManyContainerRestarts
expr: kubernetes_io:container_restart_count{namespace_name=~"config-management-system|config-management-monitoring|resource-group-system"} > 3

Config Sync mengalami error persisten

Jika Config Sync terus mengalami error, berarti ada yang salah. Kapan Config Sync mengalami error, klien akan terus mencoba menyinkronkan konfigurasi dari sumber ke cluster berhasil. Namun, beberapa error tidak dapat diperbaiki dengan mencoba lagi dan memerlukan intervensi.

Contoh aturan pemberitahuan Prometheus

Untuk menerima notifikasi saat rekonsiliasi root atau namespace bertemu error persisten selama dua jam, buat aturan pemberitahuan berikut:

alert: PersistentConfigSyncErrors
expr: sum by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace, errorclass) (config_sync_reconciler_errors) > 0
for: 2h

Dalam contoh ini:

  • Label configsync_sync_kind dapat memiliki nilai berikut: RootSync atau RepoSync.
  • Label configsync_sync_name menunjukkan nama RootSync atau RepoSync .
  • Label configsync_sync_namespace menunjukkan namespace RootSync atau RepoSync.

  • Label errorclass dapat memiliki tiga nilai: 1xxx, 2xxx, dan 9xxx. Masing-masing label sesuai dengan jenis kesalahan yang berbeda:

    • 1xxx error: error konfigurasi yang dapat Anda perbaiki
    • 2xxx error: error sisi server yang mungkin tidak dapat Anda perbaiki
    • 9xxx error: error internal yang tidak dapat Anda perbaiki

Config Sync macet dalam tahap sinkronisasi

Upaya sinkronisasi di Config Sync tidak dapat terganggu. Jika konfigurasi pada terlalu besar atau rumit (misalnya, sumber berisi banyak resource Config Connector), perlu waktu lebih dari satu jam untuk menyelesaikan sinkronisasi konfigurasi ini ke cluster. Namun, jika dua jam telah berlalu sejak sinkronisasi terakhir berhasil, mungkin ada yang salah.

Anda dapat memeriksa apakah upaya sinkronisasi saat ini masih berlangsung dengan memeriksa Status RootSync atau RepoSync. Jika upaya sinkronisasi saat ini masih berlangsung, Anda dapat memilih untuk memecah sumber tepercaya Anda sehingga setiap sumber tepercaya dapat disinkronkan lebih cepat, atau meningkatkan ambang batas peringatan dari dua jam menjadi sesuatu yang lebih lama. Jika tidak ada sinkronisasi mencoba terus, rekonsiliasi Config Sync rusak karena seharusnya untuk terus mencoba lagi hingga menyinkronkan konfigurasi dari sumber ke cluster memulai proyek. Jika ini terjadi, eskalasikan ke Dukungan Google Cloud.

Contoh aturan pemberitahuan Prometheus

Untuk menerima notifikasi saat sinkronisasi terakhir yang berhasil dari rekonsiliasi root atau namespace lebih dari dua jam yang lalu, buat aturan pemberitahuan:

  alert: OldLastSyncTimestamp
  # The status label indicates whether the last sync succeeded or not.
  # Possible values: success, error.
  expr: time() - topk by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace) (1, config_sync_last_sync_timestamp{status="success"}) > 7200

Config Sync mengalami regresi performa

Config Sync mungkin mengalami regresi performa setelah diupgrade. Tujuan regresi performa dapat terjadi dengan cara berikut:

  • Peningkatan overhead waktu merekonsiliasi RootSync atau RepoSync objek
  • Peningkatan overhead waktu merekonsiliasi objek ResourceGroup
  • Peningkatan overhead waktu sinkronisasi konfigurasi dari sumber ke cluster

Overhead waktu merekonsiliasi objek RootSync atau RepoSync

Deployment reconciler-manager merekonsiliasi objek RootSync dan RepoSync. Anda dapat menggunakan persentil kesembilan puluh dari overhead waktu merekonsiliasi RootSync atau RepoSync untuk mendeteksi regresi performa.

Contoh aturan pemberitahuan Prometheus

Bagian ini mencakup contoh aturan pemberitahuan Prometheus yang memberi tahu Anda ketika Deployment reconciler-manager mengalami regresi performa.

Contoh berikut mengirimi Anda notifikasi saat persentil kesembilan puluh overhead waktu merekonsiliasi objek RootSync atau RepoSync selama 5 detik jam lebih dari 0,1 detik selama 10 menit. Anda dapat membuat aturan peringatan yang memantau semua cluster, atau satu cluster.

  • Buat aturan berikut untuk memantau semua cluster:

    alert: HighLatencyReconcileRootSyncAndRepoSyncOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_reconcile_duration_seconds_bucket[5h]))) > 0.1
for: 10m

  • Buat aturan berikut untuk memantau satu cluster:

    alert: HighLatencyReconcileRootSyncAndRepoSyncClusterLevel
expr: histogram_quantile(0.9, sum by (cluster, le) (rate(config_sync_reconcile_duration_seconds_bucket[5h]))) > 0.1
for: 10m

Overhead waktu merekonsiliasi objek ResourceGroup

Deployment resource-group-controller-manager merekonsiliasi ResourceGroup objek terstruktur dalam jumlah besar. Anda dapat menggunakan persentil kesembilan puluh dari overhead waktu merekonsiliasi ResourceGroup untuk menangkap regresi performa.

Contoh aturan pemberitahuan Prometheus

Bagian ini mencakup aturan peringatan Prometheus yang akan memberi tahu Anda ketika resource-group-controller-manager Deployment mengalami regresi performa.

Contoh berikut mengirimi Anda notifikasi saat persentil kesembilan puluh overhead waktu merekonsiliasi objek ResourceGroup selama 5 jam terakhir berdurasi lebih dari 5 detik selama 10 menit. Anda dapat membuat aturan peringatan yang memantau semua cluster, atau satu cluster.

  • Buat aturan berikut untuk memantau semua cluster:

    alert: HighLatencyReconcileResourceGroupOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_rg_reconcile_duration_seconds_bucket[5h]))) > 5
for: 10m

  • Buat aturan berikut untuk memantau satu cluster:

    alert: HighLatencyReconcileResourceGroupClusterLevel
expr: histogram_quantile(0.9, sum by (cluster, le) (rate(config_sync_rg_reconcile_duration_seconds_bucket[5h]))) > 5
for: 10m

Overhead waktu sinkronisasi konfigurasi dari sumber ke cluster

Rekonsiliasi root atau namespace menyinkronkan konfigurasi dari sumber tepercaya ke cluster. Anda dapat menggunakan persentil kesembilan puluh dari overhead waktu sinkronisasi konfigurasi dari sumber ke cluster untuk mendeteksi regresi performa.

Contoh aturan pemberitahuan Prometheus

Bagian ini mencakup aturan pemberitahuan Prometheus yang akan memberi tahu Anda saat root atau Deployment rekonsiliasi namespace mengalami regresi performa.

Contoh berikut mengirimi Anda notifikasi saat persentil kesembilan puluh overhead waktu sinkronisasi konfigurasi di semua cluster selama lima jam lebih dari satu jam selama lima menit.Anda bisa membuat aturan peringatan yang memantau semua cluster, atau satu cluster.

  • Buat aturan berikut untuk memantau semua cluster:

    alert: HighApplyDurationOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_apply_duration_seconds_bucket[5h]))) > 3600
for: 5m

  • Buat aturan berikut untuk memantau satu cluster:

    alert: HighApplyDurationRootSyncRepoSyncLevel
expr: histogram_quantile(0.9, sum by (cluster, configsync_sync_kind,configsync_sync_name, configsync_sync_namespace, le) (rate(config_sync_apply_duration_seconds_bucket[5h]))) > 3600
for: 5m