Menggunakan metrik bidang kontrol

Anda dapat mengonfigurasi cluster Google Kubernetes Engine (GKE) untuk mengirim metrik tertentu yang dikeluarkan oleh server Kubernetes API, Scheduler, dan Controller Manager ke Cloud Monitoring menggunakan Google Cloud Managed Service for Prometheus. Dokumen ini menjelaskan cara metrik ini diformat saat ditulis ke Cloud Monitoring dan cara membuat kuerinya. Dokumen ini juga menyediakan tabel yang mencantumkan metrik di setiap kumpulan dan memberikan informasi tentang cara menggunakan metrik ini.

Sebelum dapat menggunakan metrik bidang kontrol, Anda harus mengaktifkan pengumpulannya.

Format metrik

Semua metrik bidang kontrol Kubernetes yang ditulis ke Cloud Monitoring menggunakan jenis resource prometheus_target. Setiap nama metrik diawali dengan prometheus.googleapis.com/ dan memiliki akhiran yang menunjukkan jenis metrik Prometheus, seperti /gauge, /histogram, atau /counter. Jika tidak, setiap nama metrik akan identik dengan nama metrik yang diekspos oleh Kubernetes open source.

Mengekspor dari Cloud Monitoring

Metrik bidang kontrol dapat diekspor dari Cloud Monitoring menggunakan Cloud Monitoring API. Karena semua metrik bidang kontrol diserap menggunakan Google Cloud Managed Service for Prometheus, metrik bidang kontrol dapat dikueri dengan menggunakan Prometheus Query Language (PromQL). Kueri juga dapat dibuat menggunakan menggunakan Bahasa Kueri Monitoring (MQL).

Membuat kueri metrik

Saat Anda membuat kueri metrik bidang kontrol, nama yang Anda gunakan bergantung pada apakah Anda menggunakan fitur berbasis PromQL atau Cloud Monitoring seperti MQL atau antarmuka berbasis menu Metrics Explorer.

Tabel metrik bidang kontrol berikut menampilkan dua versi dari setiap nama metrik:

  • Nama metrik PromQL: Saat menggunakan PromQL di halaman Cloud Monitoring pada Konsol Google Cloud atau di kolom PromQL Cloud Monitoring API, gunakan nama metrik PromQL.
  • Nama metrik Cloud Monitoring Saat menggunakan fitur Cloud Monitoring lainnya, gunakan nama metrik Cloud Monitoring pada tabel di bawah. Nama ini harus diawali dengan prometheus.googleapis.com/, yang telah dihilangkan dari entri dalam tabel.

Metrik server API

Bagian ini menyediakan daftar metrik server API dan informasi tambahan tentang cara menafsirkan dan menggunakan metrik.

Daftar metrik server API

Jika metrik server API diaktifkan, semua metrik yang ditampilkan dalam tabel berikut diekspor ke Cloud Monitoring dalam project yang sama dengan cluster GKE.

Nama metrik Cloud Monitoring dalam tabel ini harus diawali dengan prometheus.googleapis.com/. Awalan tersebut telah dihilangkan dari entri dalam tabel.

Nama metrik PromQL Tahap peluncuran
Nama metrik Cloud Monitoring
Jenis, Jenis, Unit
Resource yang dipantau
Versi GKE yang diperlukan		 Deskripsi
Label
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Jumlah maksimum dari batas permintaan inflight yang saat ini digunakan di apiserver ini per jenis permintaan dalam detik terakhir.

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ 		Konkurensi (jumlah slot) yang ditempati oleh permintaan yang sedang dijalankan (tahap awal untuk WATCH, tahap apa pun jika tidak) di subsistem Prioritas dan Keadilan API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ untuk versi minor sebelumnya) 		Jumlah permintaan yang saat ini tertunda dalam antrean subsistem Prioritas dan Keadilan API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BETA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.26.11+, 1.27.8+ untuk versi minor sebelumnya) 		Jumlah nominal slot eksekusi yang dikonfigurasi untuk setiap tingkat prioritas.

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ untuk versi minor sebelumnya) 		Jumlah permintaan yang ditolak oleh subsistem Prioritas dan Keadilan API.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ untuk versi minor sebelumnya) 		Lamanya waktu yang dihabiskan oleh permintaan untuk menunggu dalam antreannya.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1,23,6+ 		Distribusi latensi respons dalam hitungan detik untuk setiap verb, nilai uji coba, grup, versi, resource, subresource, cakupan, dan komponen.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Penghitung permintaan apiserver yang dikelompokkan untuk setiap kata kerja, nilai uji coba, grup, versi, resource, cakupan, komponen, dan kode respons HTTP.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Distribusi ukuran respons dalam byte untuk setiap grup, versi, verb, resource, subresource, cakupan, dan komponen.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Jumlah objek yang disimpan pada saat pemeriksaan terakhir yang dibagi berdasarkan jenis.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1,23,6+ 		Histogram latensi pengontrol masuk dalam hitungan detik, diidentifikasi berdasarkan nama dan dikelompokkan untuk setiap operasi serta resource dan jenis API (validasi atau setujui).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histogram latensi sub-langkah masuk dalam hitungan detik, yang dikelompokkan untuk setiap operasi dan resource API serta jenis langkah (validasi atau setujui).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histogram latensi webhook masuk dalam hitungan detik, diidentifikasi berdasarkan nama dan dikelompokkan untuk setiap operasi serta resource dan jenis API (validasi atau setujui).

name
operation
rejected
type

Bagian berikut ini memberikan informasi tambahan tentang metrik server API.

apiserver_request_duration_seconds

Gunakan metrik ini untuk memantau latensi di server API. Durasi permintaan yang dicatat oleh metrik ini mencakup semua fase pemrosesan permintaan, mulai dari saat permintaan diterima hingga server menyelesaikan responsnya terhadap klien. Secara khusus, artikel ini mencakup waktu yang dihabiskan untuk hal berikut:

  • Autentikasi dan otorisasi permintaan.
  • Memanggil webhook pihak ketiga dan sistem yang terkait dengan permintaan.
  • Mengambil objek yang diminta dari cache dalam memori (untuk permintaan yang menentukan parameter URL resourceVersion) atau dari etcd (untuk semua permintaan lainnya).
  • Anda dapat menggunakan label group, version, resource, dan subresource untuk mengidentifikasi permintaan lambat secara unik untuk penyelidikan lebih lanjut.
  • Menulis respons kepada klien dan menerima respons klien.

Untuk mengetahui informasi selengkapnya tentang penggunaan metrik ini, lihat Latensi.

Metrik ini memiliki kardinalitas sangat tinggi. Saat menggunakan metrik ini, Anda harus menggunakan filter atau pengelompokan untuk menemukan sumber latensi tertentu.

apiserver_admission_controller_admission_duration_seconds

Metrik ini mengukur latensi di webhook akses masuk bawaan, bukan webhook pihak ketiga. Untuk mendiagnosis masalah latensi dengan Webook pihak ketiga, gunakan metrik apiserver_admission_webhook_admission_duration_seconds.

apiserver_admission_webhook_admission_duration_seconds dan
apiserver_admission_step_admission_duration_seconds

Metrik ini mengukur latensi di webhook akses masuk pihak ketiga eksternal. Metrik apiserver_admission_webhook_admission_duration_seconds umumnya merupakan metrik yang lebih berguna. Untuk mengetahui informasi selengkapnya tentang penggunaan metrik ini, lihat Latensi.

apiserver_request_total

Gunakan metrik ini untuk memantau traffic permintaan di server API Anda. Anda juga dapat menggunakannya untuk menentukan tingkat keberhasilan dan kegagalan permintaan. Untuk mengetahui informasi lebih lanjut mengenai penggunaan metrik ini, lihat Rasio traffic dan error.

Metrik ini memiliki kardinalitas sangat tinggi. Saat menggunakan metrik ini, Anda harus menggunakan filter atau pengelompokan untuk mengidentifikasi sumber error.

apiserver_storage_objects

Gunakan metrik ini untuk mendeteksi saturasi sistem dan mengidentifikasi kemungkinan kebocoran resource. Untuk informasi selengkapnya, lihat Saturasi.

apiserver_current_inflight_requests

Metrik ini mencatat jumlah maksimum permintaan yang secara aktif ditayangkan dalam periode satu detik terakhir. Untuk informasi selengkapnya, lihat Saturasi.

Metrik ini tidak mencakup permintaan yang berjalan lama seperti "smartwatch".

Memantau server API

Metrik server API dapat memberi Anda insight tentang sinyal utama untuk kesehatan sistem:

  • Latensi: Berapa lama waktu yang diperlukan untuk melayani permintaan?
  • Traffic: Berapa banyak permintaan yang dialami sistem?
  • Tingkat error: Seberapa sering permintaan gagal?
  • Saturasi: Seberapa penuh sistemnya?

Bagian ini menjelaskan cara menggunakan metrik server API untuk memantau kondisi server API Anda.

Latensi

Jika server API kelebihan beban, latensi permintaan akan meningkat. Untuk mengukur latensi permintaan ke server API, gunakan metrik apiserver_request_duration_seconds. Untuk mengidentifikasi sumber latensi secara lebih spesifik, Anda dapat mengelompokkan metrik berdasarkan label verb atau resource.

Batas atas yang disarankan untuk panggilan resource tunggal seperti GET, POST, atau PATCH adalah 1 detik. Batas atas yang disarankan untuk panggilan LIST cakupan namespace dan cluster adalah 30 detik. Ekspektasi batas atas ditetapkan oleh SLO yang ditentukan oleh komunitas Kubernetes open source; untuk mengetahui informasi lebih lanjut, baca detail SLI/SLO latensi panggilan API.

Jika nilai metrik apiserver_request_duration_seconds meningkat melebihi durasi yang diharapkan, selidiki kemungkinan penyebab berikut:

  • Bidang kontrol Kubernetes mungkin kelebihan beban. Untuk memeriksanya, lihat metrik apiserver_request_total dan apiserver_storage_objects.
    • Gunakan label code untuk menentukan apakah permintaan berhasil diproses atau tidak. Untuk informasi tentang kemungkinan nilai, lihat Kode Status HTTP.
    • Gunakan label group, version, resource, dan subresource untuk mengidentifikasi permintaan secara unik.

  • Webhook akses masuk pihak ketiga berjalan lambat atau tidak responsif. Jika nilai metrik apiserver_admission_webhook_admission_duration_seconds meningkat, beberapa webhook akses masuk pihak ketiga atau yang ditentukan pengguna berjalan lambat atau tidak responsif. Latensi dalam WebP penerimaan dapat menyebabkan penundaan dalam penjadwalan tugas.

    • Untuk membuat kueri latensi webhook persentil ke-99 per instance bidang kontrol Kubernetes, gunakan kueri PromQL berikut:

      sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))

      Sebaiknya lihat juga persentil ke-50, ke-90, ke-95, dan ke-99,9.Anda dapat menyesuaikan kueri ini dengan mengubah nilai 0.99.

    • Webhook eksternal memiliki batas waktu tunggu sekitar 10 detik. Anda dapat menetapkan kebijakan pemberitahuan pada metrik apiserver_admission_webhook_admission_duration_seconds untuk memberi tahu Anda saat waktu tunggu webhook hampir habis.

    • Anda juga dapat mengelompokkan metrik apiserver_admission_webhook_admission_duration_seconds pada label name untuk mendiagnosis kemungkinan masalah dengan webhook tertentu.

  • Anda mencantumkan banyak objek. Latensi panggilan LIST diperkirakan akan meningkat seiring bertambahnya jumlah objek dari jenis tertentu (ukuran respons).

  • Masalah sisi klien:

    • Klien mungkin tidak memiliki cukup sumber daya untuk menerima respons secara tepat waktu. Untuk memeriksanya, lihat metrik penggunaan CPU untuk pod klien.
    • Klien memiliki koneksi jaringan yang lambat. Hal ini mungkin terjadi saat klien berjalan di perangkat seperti ponsel, tetapi kemungkinan kecil bagi klien yang berjalan di jaringan Compute Engine.
    • Klien keluar secara tiba-tiba tetapi koneksi TCP memiliki periode waktu tunggu dalam puluhan detik. Sebelum waktu koneksi habis, resource server diblokir, yang dapat meningkatkan latensi.

Rasio traffic dan error

Untuk mengukur traffic serta jumlah permintaan yang berhasil dan gagal di server API, gunakan metrik apiserver_request_total. Misalnya, untuk mengukur traffic server API per instance bidang kontrol Kubernetes, gunakan kueri PromQL berikut:

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

  • Untuk membuat kueri permintaan yang gagal, filter label code untuk nilai 4xx dan 5xx dengan menggunakan kueri PromQL berikut:

    sum(rate(apiserver_request_total{code=~"[45].."}[5m]))

  • Untuk membuat kueri permintaan yang berhasil, filter label code untuk nilai 2xx dengan menggunakan kueri PromQL berikut:

    sum(rate(apiserver_request_total{code=~"2.."}[5m]))

  • Untuk membuat kueri permintaan yang ditolak oleh server API per instance bidang kontrol Kubernetes, filter label code untuk nilai 429 (http.StatusTooManyRequests) menggunakan kueri PromQL berikut:

    sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))

Saturasi

Anda dapat mengukur saturasi dalam sistem menggunakan metrik apiserver_current_inflight_requests dan apiserver_storage_objects .

Jika nilai metrik apiserver_storage_objects meningkat, Anda mungkin mengalami masalah dengan pengontrol kustom yang membuat objek tetapi tidak menghapusnya. Anda dapat memfilter atau mengelompokkan metrik menurut label resource untuk mengidentifikasi resource yang mengalami/ peningkatan.

Evaluasi metrik apiserver_current_inflight_requests sesuai dengan setelan Prioritas dan Keadilan API Anda; setelan ini memengaruhi cara permintaan diprioritaskan, sehingga Anda tidak dapat menarik kesimpulan hanya dari nilai metrik. Untuk informasi selengkapnya, lihat Prioritas dan Keadilan API.

Metrik Scheduler

Bagian ini menyediakan daftar metrik penjadwal dan informasi tambahan tentang cara menafsirkan dan menggunakan metrik.

Daftar metrik penjadwal

Jika metrik penjadwal diaktifkan, semua metrik yang ditampilkan dalam tabel berikut akan diekspor ke Cloud Monitoring dalam project yang sama dengan cluster GKE.

Nama metrik Cloud Monitoring dalam tabel ini harus diawali dengan prometheus.googleapis.com/. Awalan tersebut telah dihilangkan dari entri dalam tabel.

Nama metrik PromQL Tahap peluncuran
Nama metrik Cloud Monitoring
Jenis, Jenis, Unit
Resource yang dipantau
Versi GKE yang diperlukan		 Deskripsi
Label
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Jumlah pod yang tertunda, berdasarkan jenis antrean. 'active' berarti jumlah pod dalam activeQ; 'backoff' berarti jumlah pod di backoffQ; 'unschedulable' berarti jumlah pod dalam activePods yang tidak dapat dijadwalkan.

queue
scheduler_pod_scheduling_duration_seconds GA
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.25.1+ (1.22.17-gke.3100+, 1.23.11+, dan 1.24.5+ untuk versi minor sebelumnya) 		Latensi E2e untuk pod yang sedang dijadwalkan yang dapat mencakup beberapa percobaan penjadwalan.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Total percobaan preemption dalam cluster hingga saat ini
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Jumlah korban preemption yang dipilih
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1,23,6+ 		Latensi percobaan penjadwalan dalam hitungan detik (algoritma penjadwalan + binding).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Jumlah percobaan untuk menjadwalkan pod, berdasarkan hasil. 'unschedulable' (tidak dapat dijadwalkan) berarti pod tidak dapat dijadwalkan, sedangkan 'error' berarti masalah penjadwal internal.

profile
result

Bagian berikut ini memberikan informasi tambahan tentang metrik server API.

scheduler_pending_pods

Anda dapat menggunakan metrik scheduler_pending_pods untuk memantau beban pada penjadwal. Meningkatnya nilai dalam metrik ini dapat mengindikasikan adanya masalah resource. Penjadwal memiliki tiga antrean, dan metrik ini melaporkan jumlah permintaan yang tertunda berdasarkan antrean. Antrean berikut telah didukung:

  • Antrean active
    • Kumpulan pod yang coba dijadwalkan oleh penjadwal; pod dengan prioritas tertinggi berada di kepala antrean.
  • Antrean backoff
    • Kumpulan pod tidak dapat dijadwalkan saat terakhir kali penjadwal mencoba, tetapi mungkin dapat dijadwalkan di lain waktu.
    • Pod pada antrean ini harus menunggu periode backoff (maksimum 10 detik), setelah itu dipindahkan kembali ke antrean active untuk upaya penjadwalan lainnya. Untuk informasi selengkapnya tentang pengelolaan antrean backoff, lihat permintaan implementasi, masalah Kubernetes 75417.

  • unschedulable disetel

    • Kumpulan pod yang coba dijadwalkan oleh penjadwal, tetapi telah dipastikan tidak dapat dijadwalkan. Penempatan pada antrean ini dapat menunjukkan masalah kesiapan atau kompatibilitas dengan node Anda atau konfigurasi pemilih node Anda.

      Jika batasan resource mencegah pod dijadwalkan, pod tidak akan terkena penanganan back-off. Sebagai gantinya, jika cluster penuh, pod baru akan gagal dijadwalkan dan dimasukkan ke antrean unscheduled.

    • Kehadiran pod yang tidak terjadwal dapat menunjukkan bahwa Anda memiliki resource yang tidak memadai atau Anda memiliki masalah konfigurasi node. Pod dipindahkan ke antrean backoff atau active setelah peristiwa yang mengubah status cluster. Pod pada antrean ini menunjukkan bahwa tidak ada yang berubah dalam cluster yang akan membuat pod dapat dijadwalkan.

    • Afinitas menentukan aturan tentang cara pod ditetapkan ke node. Penggunaan aturan afinitas atau anti-afinitas dapat menjadi alasan untuk peningkatan pod yang tidak terjadwal.

    • Beberapa peristiwa, misalnya ADD/UPDATE PVC/Layanan, penghentian pod, atau pendaftaran node baru, memindahkan beberapa atau semua pod yang tidak terjadwal ke antrean backoff atau active. Untuk mengetahui informasi selengkapnya, lihat Masalah Kubernetes 81214.

Untuk mengetahui informasi selengkapnya, lihat Latensi penjadwal dan Masalah resource.

scheduler_scheduling_attempt_duration_seconds

Metrik ini mengukur durasi satu upaya penjadwalan dalam penjadwal itu sendiri dan diperinci berdasarkan hasilnya: terjadwal, tidak dapat dijadwalkan, atau error. Durasi berjalan sejak penjadwal mengambil pod hingga saat penjadwal menemukan node dan menempatkan pod pada node, menentukan bahwa pod tidak dapat dijadwalkan, atau mengalami error. Durasi penjadwalan mencakup waktu dalam proses penjadwalan serta waktu binding. Binding adalah proses saat penjadwal mengomunikasikan penetapan node-nya ke server API. Untuk mengetahui informasi selengkapnya, lihat Latensi penjadwal.

Metrik ini tidak mencatat waktu yang dihabiskan pod dalam kontrol penerimaan atau validasi.

Untuk informasi selengkapnya tentang penjadwalan, lihat Menjadwalkan Pod.

scheduler_schedule_attempts_total

Metrik ini mengukur jumlah percobaan penjadwalan; setiap percobaan untuk menjadwalkan sebuah pod akan meningkatkan nilainya. Anda dapat menggunakan metrik ini untuk menentukan apakah penjadwal tersedia: jika nilainya meningkat, maka penjadwal akan beroperasi. Anda dapat menggunakan label result untuk menentukan keberhasilan; pod bisa berupa scheduled atau unschedulable.

Metrik ini berkorelasi kuat dengan metrik scheduler_pending_pods: jika ada banyak pod yang tertunda, Anda akan melihat banyak upaya untuk menjadwalkan pod. Untuk mengetahui informasi selengkapnya, lihat Masalah resource.

Metrik ini tidak meningkat jika penjadwal tidak memiliki pod untuk dijadwalkan, yang dapat terjadi jika Anda memiliki penjadwal sekunder kustom.

scheduler_preemption_attempts_total dan scheduler_preemptions_victims

Anda dapat menggunakan metrik preemption untuk membantu menentukan apakah Anda perlu menambahkan resource.

Anda mungkin memiliki pod dengan prioritas lebih tinggi yang tidak dapat dijadwalkan karena tidak ada ruang untuk pod tersebut. Dalam hal ini, penjadwal akan mengosongkan resource dengan melakukan preemption terhadap satu atau beberapa pod yang berjalan pada sebuah node. Metrik scheduler_preemption_attempts_total melacak berapa kali penjadwal mencoba melakukan preemption terhadap pod.

Metrik scheduler_preemptions_victims menghitung pod yang dipilih untuk preemption.

Jumlah upaya preemption berkorelasi kuat dengan nilai metrik scheduler_schedule_attempts_total jika nilai label result adalah unschedulable. Kedua nilai tersebut tidak setara: misalnya, jika cluster memiliki 0 node, tidak ada upaya preemption, tetapi mungkin ada upaya penjadwalan yang gagal.

Untuk mengetahui informasi selengkapnya, lihat Masalah resource.

Memantau penjadwal

Metrik penjadwal dapat memberi Anda insight tentang performa penjadwal:

  • Latensi penjadwal: Apakah penjadwal sedang berjalan? Berapa lama waktu yang diperlukan untuk menjadwalkan pod?
  • Masalah resource: Apakah upaya untuk menjadwalkan pod mencapai batasan resource?

Bagian ini menjelaskan cara menggunakan metrik penjadwal untuk memantau penjadwal Anda.

Latensi penjadwal

Tugas penjadwal adalah memastikan pod berjalan, sehingga Anda ingin tahu kapan penjadwal macet atau berjalan lambat.

  • Untuk memastikan bahwa penjadwal sedang berjalan dan menjadwalkan pod, gunakan metrik scheduler_schedule_attempts_total.

  • Saat penjadwal berjalan lambat, selidiki kemungkinan penyebab berikut:

    • Jumlah pod yang tertunda meningkat. Gunakan metrik scheduler_pending_pods untuk memantau jumlah pod yang tertunda. Kueri PromQL berikut menampilkan jumlah pod yang tertunda per antrean dalam sebuah cluster:

      sum by (queue)
(delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))

    • Setiap percobaan untuk menjadwalkan pod berjalan lambat. Gunakan metrik scheduler_scheduling_attempt_duration_seconds untuk memantau latensi upaya penjadwalan.

      Sebaiknya amati metrik ini setidaknya pada persentil ke-50 dan ke-95. Kueri PromQL berikut mengambil nilai persentil ke-95, tetapi dapat disesuaikan:

      sum by (instance) (histogram_quantile(0.95, rate(
scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))

Masalah resource

Metrik penjadwal juga dapat membantu Anda menilai apakah Anda memiliki resource yang cukup. Jika nilai metrik scheduler_preemption_attempts_total meningkat, periksa nilai scheduler_preemption_victims menggunakan kueri PromQL berikut:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

Jumlah upaya preemption dan jumlah korban preemption meningkat jika ada pod prioritas yang lebih tinggi untuk dijadwalkan. Metrik preemption tidak memberi tahu Anda apakah pod berprioritas tinggi yang memicu preemption dijadwalkan, sehingga saat melihat peningkatan nilai metrik preemption, Anda juga dapat memantau nilai metrik scheduler_pending_pods. Jika jumlah pod yang tertunda juga meningkat, Anda mungkin tidak memiliki resource yang cukup untuk menangani pod yang berprioritas lebih tinggi. Anda mungkin perlu meningkatkan skala resource yang tersedia, membuat pod baru dengan klaim resource yang lebih rendah, atau mengubah pemilih node.

  • Jika jumlah korban preemption tidak meningkat, tidak ada pod tersisa dengan prioritas rendah yang dapat dihapus. Dalam hal ini, pertimbangkan untuk menambahkan lebih banyak node sehingga pod baru dapat dialokasikan.

  • Jika jumlah korban preemption meningkat, maka ada pod dengan prioritas lebih tinggi yang menunggu untuk dijadwalkan, sehingga penjadwal akan melakukan preemption terhadap beberapa pod yang berjalan. Metrik preemption tidak memberi tahu Anda apakah pod dengan prioritas lebih tinggi telah dijadwalkan dan berhasil.

    Untuk menentukan apakah pod dengan prioritas lebih tinggi sedang dijadwalkan, cari nilai metrik scheduler_pending_pods yang menurun. Jika nilai metrik ini meningkat, Anda mungkin perlu menambahkan lebih banyak node.

Anda akan melihat lonjakan sementara pada nilai untuk metrik scheduler_pending_pods saat beban kerja akan dijadwalkan di cluster, misalnya, selama peristiwa seperti update atau penskalaan. Jika Anda memiliki resource yang cukup di cluster Anda, lonjakan ini bersifat sementara. Jika jumlah pod yang tertunda tidak berkurang, lakukan hal berikut:

  • Pastikan node tidak diblokir; node yang digabungkan tidak menerima pod baru.
  • Periksa perintah penjadwalan berikut, yang dapat salah dikonfigurasi dan dapat merender pod yang tidak dapat dijadwalkan:
    • Afinitas dan pemilih node.
    • Taint dan toleransi.
    • Batasan penyebaran topologi pod.

Jika pod tidak dapat dijadwalkan karena resource tidak mencukupi, sebaiknya kosongkan beberapa node yang ada atau tambah jumlah node.

Metrik Pengelola Pengontrol

Jika metrik pengelola pengontrol diaktifkan, semua metrik yang ditampilkan dalam tabel berikut akan diekspor ke Cloud Monitoring dalam project yang sama dengan cluster GKE.

Nama metrik Cloud Monitoring dalam tabel ini harus diawali dengan prometheus.googleapis.com/. Awalan tersebut telah dihilangkan dari entri dalam tabel.

Nama metrik PromQL Tahap peluncuran
Nama metrik Cloud Monitoring
Jenis, Jenis, Unit
Resource yang dipantau
Versi GKE yang diperlukan		 Deskripsi
Label
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1,24+ 		Jumlah penghapusan Node yang terjadi sejak instance NodeController saat ini dimulai.

zone