Pemecahan Masalah Google Cloud Managed Service for Prometheus

Dokumen ini menjelaskan beberapa masalah yang mungkin Anda alami saat menggunakan Google Cloud Managed Service for Prometheus serta memberikan informasi tentang cara mendiagnosis dan menyelesaikan masalah tersebut.

Anda telah mengonfigurasi Google Cloud Managed Service for Prometheus, tetapi tidak melihat data metrik apa pun di UI Grafana atau Prometheus. Pada tingkat tinggi, penyebabnya mungkin salah satu dari hal berikut:

  • Ada masalah di sisi kueri, sehingga data tidak dapat dibaca. Masalah sisi kueri sering kali disebabkan oleh izin yang salah pada akun layanan yang membaca data atau karena kesalahan konfigurasi Grafana.

  • Masalah di sisi penyerapan, sehingga tidak ada data yang dikirim. Masalah sisi penyerapan dapat disebabkan oleh masalah konfigurasi pada akun layanan, kolektor, atau evaluasi aturan.

Untuk menentukan apakah masalahnya ada di sisi penyerapan atau sisi kueri, coba buat kueri data menggunakan tab Metrics Explorer PromQL di Konsol Google Cloud. Halaman ini dijamin tidak akan memiliki masalah apa pun terkait izin baca atau setelan Grafana.

Untuk melihat halaman ini, lakukan hal berikut:

  1. Gunakan pemilih project konsol Google Cloud untuk memilih project yang datanya tidak Anda lihat.

  2. Di panel navigasi Konsol Google Cloud, pilih Monitoring, lalu pilih  Metrics Explorer:

    Buka Metrics Explorer

  3. Di toolbar panel pembuat kueri, pilih tombol dengan nama  MQL atau  PromQL.

  4. Pastikan PromQL dipilih di tombol Language. Tombol bahasa berada di toolbar yang sama yang memungkinkan Anda memformat kueri.

  5. Masukkan kueri berikut ke editor, lalu klik Run query:

    up

Jika Anda membuat kueri metrik up dan melihat hasilnya, berarti masalahnya ada di sisi kueri. Untuk informasi tentang cara menyelesaikan masalah ini, lihat Masalah sisi kueri.

Jika Anda membuat kueri metrik up dan tidak melihat hasil apa pun, masalahnya ada di sisi penyerapan. Untuk informasi tentang cara menyelesaikan masalah ini, lihat Masalah sisi penyerapan.

Firewall juga dapat menyebabkan masalah penyerapan dan kueri. Untuk mengetahui informasi lebih lanjut, baca Firewall.

Halaman Metrics Management Cloud Monitoring menyediakan informasi yang dapat membantu Anda mengontrol jumlah biaya yang dikeluarkan untuk metrik yang dapat dikenakan biaya tanpa memengaruhi kemampuan observasi. Halaman Pengelolaan Metrik melaporkan informasi berikut:

  • Volume penyerapan untuk penagihan berbasis byte dan sampel, di seluruh domain metrik dan untuk masing-masing metrik.
  • Data tentang label dan kardinalitas metrik.
  • Penggunaan metrik dalam kebijakan pemberitahuan dan dasbor kustom.
  • Rasio error penulisan metrik.

Untuk menampilkan halaman Metrics Management, lakukan hal berikut:

  1. Di panel navigasi konsol Google Cloud, pilih Monitoring, lalu pilih  Metrics management:

    Buka Pengelolaan metrik

  2. Di toolbar, pilih periode waktu. Secara default, halaman Metrics Management menampilkan informasi tentang metrik yang dikumpulkan dalam satu hari sebelumnya.

Untuk informasi selengkapnya tentang halaman Metrics Management, baca artikel Melihat dan mengelola penggunaan metrik.

Masalah sisi kueri

Penyebab sebagian besar masalah sisi kueri adalah salah satu dari hal berikut:

Mulailah dengan melakukan hal berikut:

  • Periksa konfigurasi Anda secara cermat berdasarkan petunjuk penyiapan untuk membuat kueri.

  • Jika Anda menggunakan Workload Identity, pastikan akun layanan Anda memiliki izin yang benar dengan melakukan hal berikut;

    1. Pada panel navigasi Konsol Google Cloud, pilih IAM:

      Buka IAM

    2. Identifikasi nama akun layanan dalam daftar akun utama. Pastikan nama akun layanan sudah dieja dengan benar. Lalu, klik Edit.

    3. Pilih kolom Peran, lalu klik Saat ini digunakan dan telusuri peran Monitoring Viewer. Jika akun layanan tidak memiliki peran ini, tambahkan sekarang.

Jika masalah masih berlanjut, pertimbangkan kemungkinan berikut:

Rahasia yang salah dikonfigurasi atau salah ketik

Jika melihat salah satu dari hal berikut, rahasia Anda mungkin hilang atau salah ketik:

  • Salah satu error "dilarang" ini di Grafana atau UI Prometheus:

    • "Peringatan: Status respons tak terduga saat mengambil waktu server: Terlarang"
    • "Peringatan: Terjadi error saat mengambil daftar metrik: Status respons yang tidak terduga saat mengambil nama metrik: Dilarang"

  • Pesan seperti ini di log Anda:
    "Unable read credentials file: open /gmp/key.json: no these file or directory"

Jika Anda menggunakan sinkronisasi sumber data untuk mengautentikasi dan mengonfigurasi Grafana, coba langkah berikut untuk mengatasi error ini:

  1. Pastikan Anda telah memilih endpoint Grafana API, UID sumber data Grafana, dan token API Grafana yang benar. Anda dapat memeriksa variabel di CronJob dengan menjalankan perintah kubectl describe cronjob datasource-syncer.

  2. Pastikan Anda telah menetapkan project ID sinkronisasi sumber data ke cakupan metrik atau project yang sama dengan yang kredensial akun layanan Anda miliki.

  3. Pastikan akun layanan Grafana Anda memiliki peran "Admin" dan masa berlaku token API Anda belum berakhir.

  4. Pastikan akun layanan Anda memiliki peran Monitoring Viewer untuk project ID yang dipilih.

  5. Pastikan tidak ada error di log untuk Tugas sinkronisasi sumber data dengan menjalankan kubectl logs job.batch/datasource-syncer-init. Perintah ini harus segera dijalankan setelah menerapkan file datasource-syncer.yaml.

  6. Jika menggunakan Workload Identity, pastikan Anda tidak salah mengetik kunci akun atau kredensial, dan pastikan Anda telah mengikatnya ke namespace yang benar.

Jika Anda menggunakan proxy UI frontend lama, coba langkah berikut untuk mengatasi error ini:

  1. Pastikan Anda telah menetapkan project ID UI frontend ke cakupan metrik atau project yang sama dengan project yang kredensialnya dimiliki akun layanan Anda.

  2. Verifikasi project ID yang telah Anda tentukan untuk setiap flag --query.project-id.

  3. Pastikan akun layanan Anda memiliki peran Monitoring Viewer untuk project ID yang dipilih.

  4. Pastikan Anda telah menetapkan project ID yang benar saat men-deploy UI frontend dan tidak membiarkannya ditetapkan ke string literal PROJECT_ID.

  5. Jika menggunakan Workload Identity, pastikan Anda tidak salah mengetik kunci akun atau kredensial, dan pastikan Anda telah mengikatnya ke namespace yang benar.

  6. Jika memasang secret Anda sendiri, pastikan secret ada:

    kubectl get secret gmp-test-sa -o json | jq '.data | keys'

  7. Pastikan rahasia telah terpasang dengan benar:

    kubectl get deploy frontend -o json | jq .spec.template.spec.volumes

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts

  8. Pastikan rahasia diteruskan dengan benar ke container: 

    kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args

Metode HTTP yang salah untuk Grafana

Jika Anda melihat error API berikut dari Grafana, berarti Grafana dikonfigurasi untuk mengirim permintaan POST, bukan permintaan GET:

  • "{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

Untuk mengatasi masalah ini, konfigurasikan Grafana agar menggunakan permintaan GET dengan mengikuti petunjuk dalam Mengonfigurasi sumber data.

Waktu tunggu pada kueri yang besar atau berjalan lama

Jika Anda melihat error berikut di Grafana, berarti waktu tunggu kueri default Anda terlalu rendah:

  • "Posting "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout promosi header respons"

Layanan Terkelola untuk Prometheus tidak akan kehabisan waktu hingga kueri melebihi 120 detik, sementara waktu tunggu Grafana akan habis setelah 30 detik secara default. Untuk memperbaikinya, naikkan waktu tunggu di Grafana menjadi 120 detik dengan mengikuti petunjuk dalam Mengonfigurasi sumber data.

Error validasi label

Jika melihat salah satu error berikut di Grafana, Anda mungkin menggunakan endpoint yang tidak didukung:

  • "Validasi: label selain nama belum didukung"
  • "Membuat template [tugas]: Terjadi error saat memperbarui opsi: label selain nama belum didukung."

Google Cloud Managed Service for Prometheus mendukung endpoint /api/v1/$label/values hanya untuk label __name__. Batasan ini menyebabkan kueri yang menggunakan variabel label_values($label) di Grafana gagal.

Sebagai gantinya, gunakan formulir label_values($metric, $label). Kueri ini direkomendasikan karena membatasi nilai label yang ditampilkan berdasarkan metrik, yang mencegah pengambilan nilai yang tidak terkait dengan konten dasbor. Kueri ini memanggil endpoint yang didukung untuk Prometheus.

Untuk mengetahui informasi selengkapnya tentang endpoint yang didukung, lihat Kompatibilitas API.

Kuota melampaui batas

Jika Anda melihat error berikut, berarti Anda telah melebihi kuota baca untuk Cloud Monitoring API:

  • "429: RESOURCE_EXHAUSTED: Kuota terlampaui untuk metrik kuota 'Kueri deret waktu ' dan membatasi 'Kueri deret waktu per menit' dari layanan 'monitoring.googleapis.com' untuk konsumen 'project_number:...'."

Untuk mengatasi masalah ini, kirim permintaan guna menambah kuota baca untuk Monitoring API. Untuk mendapatkan bantuan, hubungi Dukungan Google Cloud. Untuk mengetahui informasi lebih lanjut tentang kuota, lihat Mengelola kuota.

Metrik dari beberapa project

Jika ingin melihat metrik dari beberapa project Google Cloud, Anda tidak harus mengonfigurasi beberapa penyinkron sumber data atau membuat beberapa sumber data di Grafana.

Sebagai gantinya, buat cakupan metrik Cloud Monitoring dalam satu project Google Cloud, yakni project pencakupan, yang berisi project yang ingin Anda pantau. Saat mengonfigurasi sumber data Grafana dengan project pencakupan, Anda mendapatkan akses ke data dari semua project dalam cakupan metrik. Untuk informasi selengkapnya, lihat Cakupan kueri dan metrik.

Tidak ada jenis resource yang dipantau yang ditentukan

Jika melihat error berikut, Anda perlu menentukan jenis resource yang dimonitor saat menggunakan PromQL untuk membuat kueri metrik sistem Google Cloud:

  • "metrik dikonfigurasi untuk digunakan dengan lebih dari satu jenis resource yang dipantau; pemilih seri harus menentukan pencocok label pada nama resource yang dipantau"

Anda dapat menentukan jenis resource yang dipantau dengan memfilter menggunakan label monitored_resource. Untuk informasi selengkapnya terkait cara mengidentifikasi dan memilih jenis resource yang dimonitor dan valid, lihat Menentukan jenis resource yang dimonitor.

Jumlah penghitung yang tidak sama antara UI kolektor dan Konsol Google Cloud

Anda mungkin melihat perbedaan antara nilai di UI kolektor lokal Prometheus dan Konsol Google Cloud Google Cloud saat membuat kueri penghitung mentah atau jumlah penghitung. Perilaku ini wajar.

Monarch memerlukan stempel waktu mulai, tetapi Prometheus tidak memiliki stempel waktu awal. Google Cloud Managed Service for Prometheus menghasilkan stempel waktu awal dengan melewati titik pertama yang diserap dalam deret waktu mana pun, lalu mengubahnya menjadi stempel waktu mulai. Hal ini menyebabkan defisit persisten dalam jumlah penghitung.

Perbedaan antara angka di UI kolektor dan angka di Konsol Google Cloud sama dengan nilai pertama yang tercatat dalam UI kolektor, yang diharapkan karena sistem melewati nilai awal tersebut.

Hal ini dapat diterima karena menjalankan kueri untuk nilai penghitung mentah tidak diperlukan; semua kueri yang berguna pada penghitung memerlukan fungsi rate() atau yang serupa, dalam hal ini perbedaan setiap horizon waktu identik di antara kedua UI. Penghitung hanya meningkat, sehingga Anda tidak dapat menetapkan pemberitahuan pada kueri mentah karena deret waktu hanya mencapai batas satu kali. Semua pemberitahuan dan diagram yang berguna melihat perubahan atau laju perubahan nilai.

Kolektor hanya menyimpan sekitar 10 menit data secara lokal. Perbedaan dalam jumlah penghitung mentah juga dapat muncul karena reset penghitung yang terjadi sebelum rentang waktu 10 menit. Untuk menutup kemungkinan ini, coba tetapkan periode lihat balik kueri selama 10 menit saja saat membandingkan UI kolektor dengan Konsol Google Cloud.

Perbedaan juga dapat disebabkan oleh adanya beberapa thread pekerja di aplikasi Anda, masing-masing dengan endpoint /metrics. Jika aplikasi Anda menjalankan beberapa thread, Anda harus menempatkan library klien Prometheus dalam mode multiproses. Untuk informasi selengkapnya, lihat dokumentasi untuk menggunakan mode multiproses di library klien Python Prometheus.

Data penghitung tidak ada atau histogram rusak

Sinyal paling umum dari masalah ini adalah tidak melihat data atau melihat kesenjangan data saat membuat kueri metrik penghitung biasa (misalnya, kueri PromQL metric_name_foo). Anda dapat mengonfirmasi hal ini jika data muncul setelah menambahkan fungsi rate ke kueri (misalnya, rate(metric_name_foo[5m])).

Anda mungkin juga mendapati bahwa sampel yang diserap telah meningkat tajam tanpa perubahan besar pada volume scrape atau bahwa metrik baru dibuat dengan akhiran "unknown" atau "unknown:counter" di Cloud Monitoring.

Anda mungkin juga melihat bahwa operasi histogram, seperti fungsi quantile(), tidak berfungsi seperti yang diharapkan.

Masalah ini terjadi saat metrik dikumpulkan tanpa TYPE metrik Prometheus. Karena Monarch diketik dengan ketat, Managed Service for Prometheus memperhitungkan metrik tidak berjenis yang diakhiri dengan "tidak diketahui" dan menyerapnya dua kali, sekali sebagai pengukur dan sekali sebagai penghitung. Mesin kueri kemudian memilih apakah akan membuat kueri alat ukur yang mendasarinya atau metrik penghitung berdasarkan fungsi kueri yang Anda gunakan.

Meskipun heuristik ini biasanya berfungsi dengan cukup baik, heuristik ini dapat menyebabkan masalah seperti hasil yang aneh saat membuat kueri metrik "unknown:counter" mentah. Selain itu, karena histogram adalah objek yang diketik secara khusus di Monarch, penyerapan tiga metrik histogram yang diperlukan karena metrik penghitung individual menyebabkan fungsi histogram tidak berfungsi. Karena metrik berjenis "tidak diketahui" diserap dua kali, tanpa menyetel TYPE akan menggandakan sampel yang diserap.

Alasan umum mengapa TYPE mungkin tidak ditetapkan meliputi:

  • Tidak sengaja mengonfigurasi Google Cloud Managed Service for Prometheus sebagai server federasi. Federation tidak didukung saat menggunakan Managed Service for Prometheus. Karena federasi sengaja menghapus informasi TYPE, menerapkan federasi akan menyebabkan metrik berjenis "tidak diketahui".
  • Menggunakan Prometheus Remote Write kapan saja dalam pipeline penyerapan. Protokol ini juga sengaja menghapus informasi TYPE.
  • Menggunakan aturan pelabelan ulang yang mengubah nama metrik. Hal ini menyebabkan metrik yang diganti namanya terpisah dari informasi TYPE yang terkait dengan nama metrik asli.
  • Pengekspor tidak memunculkan TYPE untuk setiap metrik.
  • Masalah sementara ketika TYPE dilepas saat kolektor pertama kali dimulai.

Untuk mengatasi masalah ini, lakukan langkah berikut:

  • Berhenti menggunakan penggabungan dengan Google Cloud Managed Service for Prometheus. Jika Anda ingin mengurangi kardinalitas dan biaya dengan "menampilkan" data sebelum mengirimkannya ke Monarch, lihat artikel Mengonfigurasi agregasi lokal.
  • Hentikan penggunaan Prometheus Remote Write di jalur koleksi Anda.
  • Pastikan terdapat kolom # TYPE untuk setiap metrik dengan membuka endpoint /metrics.
  • Menghapus semua aturan pelabelan ulang yang mengubah nama metrik.
  • Hapus metrik yang bertentangan dengan akhiran "unknown" atau "unknown:counter" dengan memanggil DeleteMetricDescriptor.
  • Atau, selalu buat kueri penghitung menggunakan rate atau fungsi penghitung lainnya.

Data Grafana tidak dipertahankan setelah pod dimulai ulang

Jika data Anda tampak hilang dari Grafana setelah pod dimulai ulang, tetapi masih terlihat di Cloud Monitoring, berarti Anda menggunakan Grafana untuk membuat kueri instance Prometheus lokal, bukan Managed Service for Prometheus.

Untuk informasi tentang cara mengonfigurasi Grafana agar menggunakan layanan terkelola sebagai sumber data, lihat Grafana.

Mengimpor dasbor Grafana

Untuk mengetahui informasi tentang cara menggunakan dan memecahkan masalah pengimpor dasbor, lihat Mengimpor dasbor Grafana ke Cloud Monitoring.

Untuk mengetahui informasi tentang masalah konversi konten dasbor, lihat file README pengimpor.

Masalah sisi penyerapan

Masalah sisi penyerapan dapat terkait dengan evaluasi aturan atau pengumpulan. Mulailah dengan melihat log error untuk pengumpulan terkelola. Anda dapat menjalankan perintah berikut:

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

Di cluster GKE Autopilot, Anda dapat menjalankan perintah berikut:

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

Fitur status target dapat membantu Anda men-debug target scrape Anda. Untuk mengetahui informasi selengkapnya, lihat informasi status target.

Status endpoint tidak ada atau terlalu lama

Jika Anda telah mengaktifkan fitur status target, tetapi satu atau beberapa resource PodMonitoring atau ClusterPodMonitoring Anda tidak memiliki kolom atau nilai Status.Endpoint Statuses, Anda mungkin mengalami salah satu masalah berikut:

  • Google Cloud Managed Service for Prometheus tidak dapat menjangkau kolektor pada node yang sama dengan salah satu endpoint Anda.
  • Satu atau beberapa konfigurasi PodMonitoring atau ClusterPodMonitoring Anda tidak menghasilkan target yang valid.

Masalah serupa juga dapat menyebabkan kolom Status.Endpoint Statuses.Last Update Time memiliki nilai yang lebih lama dari beberapa menit ditambah interval salinan Anda.

Untuk mengatasi masalah ini, mulailah dengan memeriksa apakah pod Kubernetes yang terkait dengan endpoint scrape Anda sudah berjalan. Jika pod Kubernetes Anda sedang berjalan, pemilih label akan cocok, dan Anda dapat mengakses endpoint scrape secara manual (biasanya dengan membuka endpoint /metrics), lalu periksa apakah kolektor Managed Service for Prometheus sudah berjalan.

Pecahan kolektor kurang dari 1

Jika fitur status target diaktifkan, Anda akan mendapatkan informasi status tentang resource. Nilai Status.Endpoint Statuses.Collectors Fraction resource PodMonitoring atau ClusterPodMonitoring mewakili fraksi kolektor, yang dinyatakan dari 0 hingga 1, yang dapat dijangkau. Misalnya, nilai 0.5 menunjukkan bahwa 50% kolektor Anda dapat dijangkau, sedangkan nilai 1 menunjukkan bahwa 100% kolektor Anda dapat dijangkau.

Jika kolom Collectors Fraction memiliki nilai selain 1, satu atau beberapa kolektor tidak dapat dijangkau, dan metrik di salah satu node tersebut mungkin tidak disalin. Pastikan semua kolektor berjalan dan dapat dijangkau melalui jaringan cluster. Anda dapat melihat status pod kolektor dengan perintah berikut:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

Di cluster GKE Autopilot, perintah ini terlihat sedikit berbeda:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

Anda dapat menyelidiki setiap pod kolektor (misalnya, pod kolektor bernama collector-12345) dengan perintah berikut:

kubectl -n gmp-system describe pods/collector-12345

Di cluster GKE Autopilot, jalankan perintah berikut:

kubectl -n gke-gmp-system describe pods/collector-12345

Jika kolektor tidak responsif, lihat pemecahan masalah workload GKE.

Jika kolektor responsif, periksa log operator. Untuk memeriksa log operator, jalankan perintah berikut terlebih dahulu untuk menemukan nama pod operator:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Di cluster GKE Autopilot, jalankan perintah berikut:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Kemudian, periksa log operator (misalnya, pod operator bernama gmp-operator-12345) dengan perintah berikut:

kubectl -n gmp-system logs pods/gmp-operator-12345

Di cluster GKE Autopilot, jalankan perintah berikut:

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

Target tidak responsif

Jika Anda telah mengaktifkan fitur status target, tetapi satu atau beberapa resource PodMonitoring atau ClusterPodMonitoring Anda memiliki kolom Status.Endpoint Statuses.Unhealthy Targets dengan nilai selain 0, kolektor tidak dapat menyalin satu atau beberapa target Anda.

Lihat kolom Sample Groups, yang mengelompokkan target berdasarkan pesan error, lalu cari kolom Last Error. Kolom Last Error berasal dari Prometheus dan memberi tahu Anda alasan target tidak dapat disalin. Untuk mengatasi masalah ini, dengan menggunakan target contoh sebagai referensi, periksa apakah endpoint scrape Anda berjalan.

Kuota melampaui batas

Jika Anda melihat error berikut, berarti Anda telah melebihi kuota penyerapan untuk Cloud Monitoring API:

  • "429: Kuota terlampaui untuk metrik kuota 'Permintaan penyerapan deret waktu' dan membatasi 'Permintaan penyerapan deret waktu per menit' layanan 'monitoring.googleapis.com' untuk konsumen 'project_number:PROJECT_NUMBER'., rateLimitLimited"

Error ini paling sering muncul saat pertama kali menampilkan layanan terkelola. Kuota default akan habis sebesar 100.000 sampel per detik yang diserap.

Untuk mengatasi masalah ini, kirim permintaan untuk menambah kuota penyerapan untuk Monitoring API. Untuk mendapatkan bantuan, hubungi Dukungan Google Cloud. Untuk mengetahui informasi lebih lanjut tentang kuota, lihat Mengelola kuota.

Izin tidak ada di akun layanan default node

Jika Anda melihat salah satu error berikut, akun layanan default pada node mungkin tidak memiliki izin:

  • "eksekusi query: Error querying Prometheus: client_error: client error: 403"
  • "Pemeriksaan kesiapan gagal: Pemeriksaan HTTP gagal dengan kode status: 503"
  • "Terjadi error saat membuat kueri instance Prometheus"

Kumpulan terkelola dan evaluator aturan terkelola di Managed Service for Prometheus menggunakan akun layanan default di node. Akun ini dibuat dengan semua izin yang diperlukan, tetapi pelanggan terkadang menghapus izin Monitoring secara manual. Penghapusan ini menyebabkan kegagalan pengumpulan dan evaluasi aturan.

Untuk memverifikasi izin akun layanan, lakukan salah satu hal berikut:

  • Identifikasi nama node Compute Engine yang mendasarinya, lalu jalankan perintah berikut:

    gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts

    Cari string https://www.googleapis.com/auth/monitoring. Jika perlu, tambahkan Monitoring seperti yang dijelaskan di Akun layanan yang salah dikonfigurasi.

  • Buka VM yang mendasari di cluster dan periksa konfigurasi akun layanan node:

    1. Di panel navigasi konsol Google Cloud, pilih Kubernetes Engine, kemudian pilih Clusters:

      Buka Cluster Kubernetes

    2. Pilih Nodes, lalu klik nama node di tabel Nodes.

    3. Klik Details.

    4. Klik link VM Instance.

    5. Cari panel API and identity management, lalu klik Show details.

    6. Cari Stackdriver Monitoring API dengan akses penuh.

Mungkin juga sinkronisasi sumber data atau UI Prometheus telah dikonfigurasi untuk melihat project yang salah. Untuk mengetahui informasi tentang cara memverifikasi bahwa Anda membuat kueri cakupan metrik yang diinginkan, lihat Mengubah project yang dikueri.

Akun layanan yang salah dikonfigurasi

Jika Anda melihat salah satu pesan error berikut, berarti akun layanan yang digunakan oleh kolektor tidak memiliki izin yang benar:

  • "code = PermissionDenied desc = Permission Monitoring.timeSeries.create ditolak (atau resource mungkin tidak ada)"
  • "google: tidak dapat menemukan kredensial default. Lihat https://developers.google.com/accounts/docs/application-default-credentials untuk informasi selengkapnya."

Untuk memverifikasi bahwa akun layanan Anda memiliki izin yang benar, lakukan hal berikut:

  1. Pada panel navigasi Konsol Google Cloud, pilih IAM:

    Buka IAM

  2. Identifikasi nama akun layanan dalam daftar akun utama. Pastikan nama akun layanan sudah dieja dengan benar. Lalu, klik Edit.

  3. Pilih kolom Role, lalu klik Current used dan telusuri peran Monitoring Metric Writer atau peran Monitoring Editor. Jika akun layanan tidak memiliki salah satu peran ini, berikan peran Monitoring Metric Writer (roles/monitoring.metricWriter) ke akun layanan.

Jika menjalankan di Kubernetes non-GKE, Anda harus secara eksplisit meneruskan kredensial ke kolektor dan evaluator aturan. Anda harus mengulangi kredensial di bagian rules dan collection. Untuk mengetahui informasi selengkapnya, lihat Memberikan kredensial secara eksplisit (untuk pengumpulan) atau Memberikan kredensial secara eksplisit (untuk aturan).

Akun layanan sering kali dicakupkan ke satu project Google Cloud. Penggunaan satu akun layanan untuk menulis data metrik bagi beberapa project — misalnya, saat satu evaluator aturan terkelola membuat kueri cakupan metrik multi-project — dapat menyebabkan error izin ini. Jika menggunakan akun layanan default, pertimbangkan untuk mengonfigurasi akun layanan khusus sehingga Anda dapat dengan aman menambahkan izin monitoring.timeSeries.create untuk beberapa project. Jika tidak dapat memberikan izin ini, Anda dapat menggunakan pelabelan ulang metrik untuk menulis ulang label project_id ke nama yang lain. Selanjutnya, project ID secara default ditetapkan ke project Google Cloud tempat server Prometheus atau evaluator aturan Anda dijalankan.

Konfigurasi scrape tidak valid

Jika Anda melihat error berikut, berarti PodMonitoring atau ClusterPodMonitoring Anda tidak memiliki format yang benar:

  • "Error internal terjadi: gagal memanggil webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Posting "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

Untuk mengatasi hal ini, pastikan resource kustom Anda diformat dengan benar sesuai dengan spesifikasi.

Masalah pada interval scraping dan waktu tunggu

Saat menggunakan Google Cloud Managed Service for Prometheus, waktu tunggu scrape tidak boleh lebih besar dari interval scrape. Untuk memeriksa log Anda terkait masalah ini, jalankan perintah berikut:

kubectl -n gmp-system logs ds/collector prometheus

Di cluster GKE Autopilot, jalankan perintah berikut:

kubectl -n gke-gmp-system logs ds/collector prometheus

Cari pesan ini:

  • "waktu tunggu scrape lebih besar dari interval scrape untuk konfigurasi scrape dengan nama tugas "PodMonitoring/gmp-system/example-app/go-metrics""

Untuk mengatasi masalah ini, tetapkan nilai interval scrape sama dengan atau lebih besar dari nilai waktu tunggu scrape.

TYPE tidak ada di metrik

Jika Anda melihat error berikut, berarti metrik tidak memiliki informasi jenis:

  • "tidak ada metadata yang ditemukan untuk nama metrik "{metric_name}""

Untuk memastikan bahwa informasi jenis yang tidak ada adalah masalahnya, periksa output /metrics dari aplikasi pengekspor. Jika tidak ada baris seperti berikut, maka informasi jenisnya akan hilang:

# TYPE {metric_name} <type>

Library tertentu, seperti library dari VictoriaMetrics yang lebih lama dari versi 1.28.0, sengaja menghapus informasi jenis. Library ini tidak didukung oleh Google Cloud Managed Service for Prometheus.

Tabrakan deret waktu

Jika melihat salah satu error berikut, Anda mungkin memiliki lebih dari satu kolektor yang mencoba menulis ke deret waktu yang sama:

  • "Satu atau beberapa TimeSeries tidak dapat ditulis: Satu atau beberapa titik ditulis lebih sering daripada periode pengambilan sampel maksimum yang dikonfigurasi untuk metrik."
  • "Satu atau beberapa TimeSeries tidak dapat ditulis: Poin harus ditulis secara berurutan. Satu atau beberapa titik yang ditentukan memiliki waktu berakhir yang lebih lama dari titik terbaru."

Berikut ini penyebab dan solusi yang paling umum:

  • Menggunakan pasangan ketersediaan tinggi. Google Cloud Managed Service for Prometheus tidak mendukung koleksi tradisional dengan ketersediaan tinggi. Penggunaan konfigurasi ini dapat membuat beberapa kolektor yang mencoba menulis data ke deret waktu yang sama, sehingga menyebabkan error ini.

    Untuk mengatasi masalah ini, nonaktifkan kolektor duplikat dengan mengurangi jumlah replika menjadi 1, atau gunakan metode ketersediaan tinggi yang didukung.

  • Menggunakan aturan pelabelan ulang, khususnya yang beroperasi pada tugas atau instance. Google Cloud Managed Service for Prometheus mengidentifikasi sebagian deret waktu unik dengan kombinasi label {project_id, location, cluster, namespace, job, instance}. Penggunaan aturan pelabelan ulang untuk menghapus label ini, terutama label job dan instance, sering kali dapat menyebabkan konflik. Sebaiknya jangan menulis ulang label ini.

    Untuk mengatasi masalah ini, hapus aturan yang menyebabkan masalah tersebut. Hal ini sering kali dapat dilakukan oleh aturan metricRelabeling yang menggunakan tindakan labeldrop. Anda dapat mengidentifikasi aturan yang bermasalah dengan menjadikan semua aturan pelabelan ulang sebagai komentar dan mengaktifkannya kembali, satu per satu, sampai error tersebut terulang.

Penyebab yang kurang umum dari tabrakan deret waktu adalah menggunakan interval scrape yang kurang dari 5 detik. Interval scrape minimum yang didukung oleh Managed Service for Prometheus adalah 5 detik.

Melebihi batas jumlah label

Jika melihat error berikut, Anda mungkin memiliki terlalu banyak label yang ditentukan untuk salah satu metrik:

  • "Satu atau beberapa TimeSeries tidak dapat ditulis: Label baru akan menyebabkan metrik prometheus.googleapis.com/METRIC_NAME memiliki lebih dari PER_PROJECT_LIMIT label".

Error ini biasanya terjadi saat Anda dengan cepat mengubah definisi metrik, sehingga satu nama metrik secara efektif memiliki beberapa kumpulan kunci label independen selama masa aktif metrik. Cloud Monitoring memberlakukan batas jumlah label untuk setiap metrik; untuk mengetahui informasi lebih lanjut, lihat batas untuk metrik yang ditentukan pengguna.

Ada tiga langkah untuk mengatasi masalah ini:

  1. Identifikasi alasan metrik tertentu memiliki terlalu banyak atau sering mengubah label.

  2. Atasi sumber masalah, yang mungkin melibatkan penyesuaian aturan pelabelan kembali PodMonitoring, mengubah eksportir, atau memperbaiki instrumentasi.

  3. Hapus deskriptor metrik untuk metrik ini (yang akan menyebabkan kehilangan data), sehingga dapat dibuat ulang dengan kumpulan label yang lebih kecil dan lebih stabil. Anda dapat menggunakan metode metricDescriptors.delete untuk melakukannya.

Sumber masalah yang paling umum adalah:

  • Mengumpulkan metrik dari pengekspor atau aplikasi yang melampirkan label dinamis pada metrik. Misalnya, cAdvisor yang di-deploy sendiri dengan label container dan variabel lingkungan tambahan atau agen DataDog, yang memasukkan anotasi dinamis.

    Untuk mengatasi hal ini, Anda dapat menggunakan bagian metricRelabeling di PodMonitoring untuk menyimpan atau menghapus label. Beberapa aplikasi dan pengekspor juga mengizinkan konfigurasi yang mengubah metrik yang diekspor. Misalnya, cAdvisor memiliki sejumlah setelan runtime lanjutan yang dapat menambahkan label secara dinamis. Saat menggunakan koleksi terkelola, sebaiknya gunakan koleksi kubelet otomatis bawaan.

  • Menggunakan aturan pelabelan ulang, khususnya yang melampirkan nama label secara dinamis, yang dapat menyebabkan jumlah label yang tidak terduga.

    Untuk mengatasi masalah tersebut, hapus entri aturan yang menyebabkannya.

Batas kapasitas dalam membuat dan memperbarui metrik dan label

Jika melihat error berikut, berarti Anda telah mencapai batas kapasitas per menit untuk membuat metrik baru dan menambahkan label metrik baru ke metrik yang ada:

  • "Permintaan dibatasi. Anda telah mencapai batas per project untuk perubahan definisi metrik atau definisi label per menit."

Batas kapasitas ini biasanya hanya tercapai saat pertama kali berintegrasi dengan Google Cloud Managed Service for Prometheus, misalnya saat Anda memigrasikan deployment Prometheus matang yang sudah ada untuk menggunakan koleksi yang di-deploy sendiri. Ini bukanlah batas kapasitas untuk menyerap titik data. Batas kapasitas ini hanya berlaku saat membuat metrik yang belum pernah dilihat sebelumnya atau saat menambahkan label baru ke metrik yang ada.

Kuota ini telah diperbaiki, tetapi masalah apa pun akan otomatis diselesaikan saat metrik dan label metrik baru dibuat hingga batas per menit.

Batasan jumlah deskriptor metrik

Jika melihat error berikut, berarti Anda telah mencapai batas kuota untuk jumlah deskriptor metrik dalam satu project Google Cloud:

  • "Kuota deskriptor metrik Anda telah habis."

Secara default, batas ini ditetapkan ke 25.000. Meskipun kuota ini dapat dicabut berdasarkan permintaan jika metrik Anda diformat dengan baik, kemungkinan besar Anda mencapai batas ini karena Anda menyerap nama metrik yang salah format ke dalam sistem.

Prometheus memiliki model data dimensi dengan informasi seperti nama cluster atau namespace harus dienkode sebagai nilai label. Jika informasi dimensi disematkan dalam nama metrik itu sendiri, jumlah deskriptor metrik akan meningkat tanpa batas. Selain itu, karena dalam skenario ini, label tidak digunakan dengan benar, sehingga akan jauh lebih sulit untuk membuat kueri dan menggabungkan data di seluruh cluster, namespace, atau layanan.

Cloud Monitoring atau Managed Service for Prometheus tidak mendukung metrik non-dimensi, seperti yang diformat untuk StatsD atau Graphite. Meskipun sebagian besar pengekspor Prometheus dikonfigurasi dengan benar dan siap digunakan, eksportir tertentu, seperti pengekspor StatsD, pengekspor Vault, atau Envoy Proxy yang disertakan dengan Istio, harus dikonfigurasi secara eksplisit untuk menggunakan label, bukan menyematkan informasi dalam nama metrik. Contoh nama metrik yang salah format meliputi:

  • request_path_____path_to_a_resource____istio_request_duration_milliseconds
  • envoy_cluster_grpc_method_name_failure
  • envoy_cluster_clustername_upstream_cx_connect_ms_bucket
  • vault_rollback_attempt_path_name_1700683024
  • service__________________________________________latency_bucket

Untuk mengonfirmasi masalah ini, lakukan hal berikut:

  1. Di dalam Konsol Google Cloud, pilih project Google Cloud yang ditautkan ke error tersebut.

  2. Di panel navigasi konsol Google Cloud, pilih Monitoring, lalu pilih  Metrics management:

    Buka Pengelolaan metrik

  3. Konfirmasi bahwa jumlah metrik Aktif ditambah Tidak aktif melebihi 25.000. Dalam sebagian besar situasi, Anda akan melihat sejumlah besar metrik Tidak aktif.
  4. Urutkan berdasarkan Samples billable volume yang diurutkan secara naik, telusuri daftar, dan cari pola.

Atau, Anda dapat mengonfirmasi masalah ini menggunakan Metrics Explorer:

  1. Di dalam Konsol Google Cloud, pilih project Google Cloud yang ditautkan ke error tersebut.

  2. Di panel navigasi Konsol Google Cloud, pilih Monitoring, lalu pilih  Metrics Explorer:

    Buka Metrics Explorer

  3. Di builder kueri, klik pilih metrik, lalu hapus centang pada kotak "Aktif".
  4. Ketik "prometheus" di kotak penelusuran.
  5. Cari pola apa pun dalam nama metrik.

Setelah mengidentifikasi pola yang menunjukkan metrik dalam format yang salah, Anda dapat mengurangi masalah dengan memperbaiki pengekspor di sumber, lalu menghapus deskriptor metrik yang melanggar.

Agar masalah ini tidak terjadi lagi, Anda harus terlebih dahulu mengonfigurasi pengekspor yang relevan agar tidak lagi menampilkan metrik dengan format yang salah. Sebaiknya baca dokumentasi pengekspor Anda untuk mendapatkan bantuan. Anda dapat mengonfirmasi bahwa Anda telah memperbaiki masalah dengan membuka endpoint /metrics secara manual dan memeriksa nama metrik yang diekspor.

Kemudian, Anda dapat mengosongkan kuota dengan menghapus metrik dengan format yang salah menggunakan metode projects.metricDescriptors.delete. Agar lebih mudah melakukan iterasi pada daftar metrik yang salah format, kami menyediakan skrip Golang yang dapat Anda gunakan. Skrip ini menerima ekspresi reguler yang dapat mengidentifikasi metrik dalam format yang salah dan menghapus deskriptor metrik yang cocok dengan pola tersebut. Karena penghapusan metrik tidak dapat dibatalkan, sebaiknya jalankan skrip terlebih dahulu menggunakan mode uji coba.

Tidak ada error dan tidak ada metrik

Jika menggunakan koleksi terkelola, Anda tidak melihat error apa pun, tetapi data tidak muncul di Cloud Monitoring. Kemungkinan besar penyebabnya adalah pengekspor metrik atau konfigurasi scrape Anda tidak dikonfigurasi dengan benar. Google Cloud Managed Service for Prometheus tidak mengirimkan data deret waktu apa pun, kecuali jika Anda menerapkan konfigurasi scrape yang valid terlebih dahulu.

Untuk mengidentifikasi apakah hal ini adalah penyebabnya, coba deploy aplikasi contoh dan contoh resource PodMonitoring. Jika sekarang Anda melihat metrik up (mungkin memerlukan waktu beberapa menit), berarti masalahnya ada pada konfigurasi scrape atau pengekspor Anda.

Akar masalah bisa berupa berbagai hal. Sebaiknya periksa hal berikut:

  • PodMonitoring Anda merujuk ke port yang valid.

  • Spesifikasi Deployment pengekspor Anda telah menamai port dengan benar.

  • Pemilih Anda (paling sering app) cocok dengan resource Deployment dan PodMonitoring Anda.

  • Anda dapat melihat data di endpoint dan port yang diharapkan dengan membukanya secara manual.

  • Anda telah menginstal resource PodMonitoring di namespace yang sama dengan aplikasi yang ingin disalin. Jangan menginstal resource atau aplikasi kustom apa pun di namespace gmp-system atau gke-gmp-system.

  • Nama metrik dan label Anda cocok dengan validasi ekspresi reguler Prometheus. Google Cloud Managed Service for Prometheus tidak mendukung nama label yang diawali dengan karakter _.

  • Anda tidak menggunakan kumpulan filter yang menyebabkan semua data difilter. Berhati-hatilah agar Anda tidak memiliki filter yang bertentangan saat menggunakan filter collection di resource OperatorConfig.

  • Jika berjalan di luar Google Cloud, project atau project-id ditetapkan ke project Google Cloud yang valid dan location ditetapkan ke region Google Cloud yang valid. Anda tidak dapat menggunakan global sebagai nilai untuk location.

  • Metrik Anda adalah salah satu dari empat jenis metrik Prometheus. Beberapa library seperti Kube State Metrics menampilkan jenis metrik OpenMetrics seperti Info, Stateset, dan GaugeHistogram, tetapi jenis metrik ini tidak didukung oleh Managed Service for Prometheus dan dihapus secara otomatis.

Masalah terkait pengumpulan dari pengekspor

Jika metrik Anda dari pengekspor tidak diserap, periksa hal berikut:

  • Pastikan bahwa pengekspor berfungsi dan mengekspor metrik menggunakan perintah kubectl port-forward.

    Misalnya, untuk memeriksa apakah pod dengan pemilih app.kubernetes.io/name=redis dalam namespace test memunculkan metrik di endpoint /metrics pada port 9121, Anda dapat meneruskan port dengan cara berikut:

    kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121

    Akses endpoint localhost:9121/metrics menggunakan browser atau curl di sesi terminal lain untuk memverifikasi bahwa metrik sedang diekspos oleh pengekspor untuk scraping.

  • Periksa apakah Anda dapat membuat kueri metrik di Konsol Google Cloud tetapi tidak di Grafana. Jika demikian, maka masalahnya ada pada Grafana, bukan kumpulan metrik Anda.

  • Pastikan kolektor terkelola dapat menyalin pengekspor dengan memeriksa antarmuka web Prometheus yang diekspos oleh kolektor.

    1. Identifikasi kolektor terkelola yang berjalan di node yang sama tempat pengekspor Anda berjalan. Misalnya, jika pengekspor Anda berjalan di pod dalam namespace test dan pod diberi label dengan app.kubernetes.io/name=redis, perintah berikut akan mengidentifikasi kolektor terkelola yang berjalan pada node yang sama:

      kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'

    2. Siapkan penerusan port dari port 19090 kolektor terkelola:

      kubectl port-forward POD_NAME -n gmp-system 19090

    3. Buka URL localhost:19090/targets untuk mengakses antarmuka web. Jika pengekspor tercantum sebagai salah satu target, berarti kolektor terkelola Anda berhasil menyalin pengekspor.

Firewall

Firewall dapat menyebabkan masalah penyerapan dan kueri. Firewall Anda harus dikonfigurasi untuk mengizinkan permintaan POST dan GET ke layanan Monitoring API, monitoring.googleapis.com, untuk mengizinkan penyerapan dan kueri.

Error terkait pengeditan serentak

Pesan error "Terlalu banyak pengeditan serentak pada konfigurasi project" biasanya bersifat sementara, dan teratasi setelah beberapa menit. Hal ini biasanya disebabkan oleh penghapusan aturan pelabelan ulang yang memengaruhi berbagai metrik. Penghapusan ini akan menyebabkan antrean update pada deskriptor metrik dalam project Anda. Error akan hilang saat antrean diproses.

Untuk informasi selengkapnya, lihat Batasan pembuatan dan update metrik dan label.