Menggunakan SLI Config Sync

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

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

Pod Config Sync dengan jumlah penampung yang salah

Jika jumlah penampung Pod Config Sync lebih rendah dari yang diharapkan, Config Sync mungkin tidak berjalan. Anda dapat menyiapkan pemberitahuan untuk mendeteksi masalah ini dan memeriksa Pod Config Sync untuk mengetahui alasan beberapa penampung hilang. Saat menyetel pemberitahuan, sebaiknya tetapkan interval waktu setidaknya lima menit untuk menghindari pemberitahuan yang tidak perlu. Misalnya, selama upgrade, jumlah penampung Pod mungkin turun di bawah target.

Jika Anda tidak memahami jumlah penampung yang diharapkan, lihat Deployment, Pod, dan penampung Sinkronisasi Konfigurasi.

Contoh aturan pemberitahuan Prometheus

Bagian ini menyertakan contoh yang memberi tahu Anda saat ada Pod dengan jumlah penampung yang salah.

  • Untuk menerima notifikasi saat jumlah penampung Pod penyelesai root 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 Pod penyelesai namespace 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 penampung 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 sehat

Jika jumlah mulai ulang penampung Config Sync mencapai nilai minimum tertentu, ada yang salah. Misalnya, penampung rekonsiliator root yang tidak memiliki resource memori yang cukup akan dimulai ulang dengan error OOMKilled hingga mendapatkan memori yang cukup.

Contoh aturan pemberitahuan Prometheus

Untuk menerima notifikasi saat penampung Config Sync dimulai ulang 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

Sinkronisasi Konfigurasi mengalami error persisten

Jika Sinkronisasi Konfigurasi mengalami error persisten, ada yang salah. Saat mengalami error, Config Sync akan terus mencoba menyinkronkan konfigurasi dari sumber ke cluster hingga berhasil. Namun, beberapa error tidak dapat diperbaiki dengan mencoba lagi dan memerlukan intervensi Anda.

Contoh aturan pemberitahuan Prometheus

Untuk menerima notifikasi saat penyelesai root atau namespace mengalami 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 objek RootSync atau RepoSync.
  • Label configsync_sync_namespace menunjukkan namespace objek RootSync atau RepoSync.

  • Label errorclass dapat memiliki tiga nilai: 1xxx, 2xxx, dan 9xxx. Setiap label sesuai dengan jenis error yang berbeda:

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

Config Sync macet di tahap sinkronisasi

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

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 membagi sumber tepercaya sehingga setiap sumber tepercaya dapat disinkronkan lebih cepat, atau meningkatkan nilai minimum pemberitahuan dari dua jam menjadi lebih lama. Jika tidak ada upaya sinkronisasi yang sedang berlangsung, rekonsiliator Config Sync rusak karena seharusnya terus mencoba lagi hingga berhasil menyinkronkan konfigurasi dari sumber ke cluster. Jika hal ini terjadi, eskalasikan ke Google Cloud Dukungan.

Contoh aturan pemberitahuan Prometheus

Untuk mendapatkan notifikasi saat sinkronisasi terakhir yang berhasil dari root atau namespace reconciler 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. Regresi performa dapat terjadi dengan cara berikut:

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

Overhead waktu untuk merekonsiliasi objek RootSync atau RepoSync

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

Contoh aturan pemberitahuan Prometheus

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

Contoh berikut akan mengirimkan notifikasi kepada Anda saat persentil ke-90 dari overhead waktu untuk merekonsiliasi objek RootSync atau RepoSync selama 5 jam terakhir lebih dari 0,1 detik selama 10 menit. Anda dapat membuat aturan pemberitahuan 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 untuk merekonsiliasi objek ResourceGroup

Deployment resource-group-controller-manager merekonsiliasi objek ResourceGroup. Anda dapat menggunakan persentil ke-90 dari overhead waktu menyelaraskan ResourceGroup untuk menangkap regresi performa.

Contoh aturan pemberitahuan Prometheus

Bagian ini mencakup aturan pemberitahuan Prometheus yang memberi tahu Anda saat Deployment resource-group-controller-manager mengalami regresi performa.

Contoh berikut akan mengirimkan notifikasi kepada Anda saat persentil ke-90 dari overhead waktu untuk merekonsiliasi objek ResourceGroup selama 5 jam terakhir lebih dari 5 detik selama 10 menit. Anda dapat membuat aturan pemberitahuan 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

Penyelesai akar atau namespace menyinkronkan konfigurasi dari sumber tepercaya ke cluster. Anda dapat menggunakan persentil ke-90 dari overhead waktu sinkronisasi konfigurasi dari sumber ke cluster untuk mendeteksi regresi performa.

Contoh aturan pemberitahuan Prometheus

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

Contoh berikut akan mengirimkan notifikasi kepada Anda saat persentil ke-90 dari overhead waktu sinkronisasi konfigurasi di semua cluster selama lima jam terakhir lebih dari satu jam selama lima menit.Anda dapat membuat aturan pemberitahuan 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