Memecahkan masalah Managed Service for Prometheus

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

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

  • 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 oleh kesalahan konfigurasi Grafana.

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

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

Untuk melihat halaman ini, lakukan tindakan berikut:

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

  2. Di konsol Google Cloud, buka halaman  Metrics explorer:

    Buka Metrics explorer

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

  3. Di toolbar panel pembuat kueri, pilih tombol yang namanya adalah  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 mengatasi 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 mengatasi masalah ini, lihat Masalah sisi proses transfer.

Firewall juga dapat menyebabkan masalah penyerapan dan kueri; untuk mengetahui informasi selengkapnya, lihat Firewall.

Halaman Pengelolaan Metrik Cloud Monitoring memberikan informasi yang dapat membantu Anda mengontrol jumlah yang Anda belanjakan untuk metrik yang dapat ditagih tanpa memengaruhi visibilitas. Halaman Pengelolaan Metrik melaporkan informasi berikut:

  • Volume transfer untuk penagihan berbasis byte dan sampel, di seluruh domain metrik dan untuk setiap metrik.
  • Data tentang label dan kardinalitas metrik.
  • Jumlah pembacaan untuk setiap metrik.
  • Penggunaan metrik dalam kebijakan pemberitahuan dan dasbor kustom.
  • Rasio error penulisan metrik.

Anda juga dapat menggunakan Pengelolaan Metrik untuk mengecualikan metrik yang tidak diperlukan, sehingga menghilangkan biaya penyerapannya.

Untuk melihat halaman Pengelolaan Metrik, lakukan tindakan berikut:

  1. Di konsol Google Cloud, buka halaman  Metrics management:

    Buka Pengelolaan metrik

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

  2. Di toolbar, pilih jangka waktu. Secara default, halaman Pengelolaan Metrik menampilkan informasi tentang metrik yang dikumpulkan dalam satu hari sebelumnya.

Untuk informasi selengkapnya tentang halaman Pengelolaan Metrik, lihat 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 dengan cermat berdasarkan petunjuk penyiapan untuk kueri.

  • Jika Anda menggunakan Workload Identity Federation untuk GKE, pastikan akun layanan Anda memiliki izin yang benar dengan melakukan tindakan berikut;

    1. Di konsol Google Cloud, buka halaman IAM:

      Buka IAM

      Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah IAM & Admin.

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

    3. Pilih kolom Role, lalu klik Currently used dan telusuri peran Monitoring Viewer. Jika akun layanan tidak memiliki peran ini, tambahkan sekarang.

Jika masalah masih berlanjut, pertimbangkan kemungkinan berikut:

Secret yang salah dikonfigurasi atau salah ketik

Jika Anda melihat salah satu hal berikut, Anda mungkin memiliki secret yang hilang atau salah diketik:

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

    • "Peringatan: Status respons tidak terduga saat mengambil waktu server: Dilarang"
    • "Peringatan: Error saat mengambil daftar metrik: Status respons tidak terduga saat mengambil nama metrik: Dilarang"

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

Jika Anda menggunakan penyinkron 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 Grafana API 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 kredensial akun layanan Anda.

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

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

  5. Pastikan tidak ada error dalam 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 Federation untuk GKE, 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 ID project UI frontend ke cakupan metrik atau project yang sama dengan kredensial akun layanan Anda.

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

  3. Pastikan akun layanan Anda memiliki peran Monitoring Viewer untuk ID project 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 tersebut ada:

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

  7. Pastikan secret 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 secret diteruskan dengan benar ke penampung: 

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

Metode HTTP 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 untuk menggunakan permintaan GET dengan mengikuti petunjuk di Mengonfigurasi sumber data.

Waktu tunggu habis pada kueri besar atau yang berjalan lama

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

  • "Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers"

Managed Service for Prometheus tidak akan habis waktu tunggunya hingga kueri melebihi 120 detik, sedangkan Grafana akan habis waktu tunggunya setelah 30 detik secara default. Untuk memperbaikinya, naikkan waktu tunggu di Grafana menjadi 120 detik dengan mengikuti petunjuk di Mengonfigurasi sumber data.

Error validasi label

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

  • "Validasi: label selain name belum didukung"
  • "Templating [job]: Error updating options: labels other than name are not supported yet."

Managed Service for Prometheus hanya mendukung endpoint /api/v1/$label/values 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 informasi selengkapnya tentang endpoint yang didukung, lihat kompatibilitas API.

Kuota melampaui batas

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

  • "429: RESOURCE_EXHAUSTED: Kuota terlampaui untuk metrik kuota 'Time series queries ' dan batas 'Time series queries per minute' dari layanan 'monitoring.googleapis.com' untuk konsumen 'project_number:...'."

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

Metrik dari beberapa project

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

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

Tidak ada jenis resource yang dimonitor yang ditentukan

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

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

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

Nilai mentah penghitung, histogram, dan ringkasan tidak cocok antara UI kolektor dan konsol Google Cloud

Anda mungkin melihat perbedaan antara nilai di UI Prometheus kolektor lokal dan konsol Google Cloud saat membuat kueri nilai mentah metrik Prometheus kumulatif, termasuk penghitung, histogram, dan ringkasan. Perilaku ini normal.

Monarch memerlukan stempel waktu mulai, tetapi Prometheus tidak memiliki stempel waktu mulai. Managed Service for Prometheus menghasilkan stempel waktu awal dengan melewati titik pertama yang diserap dalam deret waktu apa pun dan mengonversinya menjadi stempel waktu awal. Titik berikutnya memiliki nilai titik awal yang dilewati dikurangi dari nilainya untuk memastikan tarifnya benar. Hal ini menyebabkan defisit persisten dalam nilai mentah titik tersebut.

Perbedaan antara angka di UI kolektor dan angka di konsol Google Cloud sama dengan nilai pertama yang dicatat di UI kolektor, yang diharapkan karena sistem melewati nilai awal tersebut, dan menguranginya dari titik berikutnya.

Hal ini dapat diterima karena tidak ada kebutuhan produksi untuk menjalankan kueri untuk nilai mentah untuk metrik kumulatif; semua kueri yang berguna memerlukan fungsi rate() atau yang serupa, dalam hal ini perbedaan selama jangka waktu apa pun akan identik di antara kedua UI. Metrik kumulatif hanya akan meningkat, sehingga Anda tidak dapat menetapkan pemberitahuan pada kueri mentah karena deret waktu hanya akan mencapai nilai minimum satu kali. Semua pemberitahuan dan diagram yang berguna melihat perubahan atau laju perubahan nilai.

Pengumpul hanya menyimpan data sekitar 10 menit secara lokal. Perbedaan dalam nilai kumulatif mentah juga dapat terjadi karena reset yang terjadi sebelum rentang waktu 10 menit. Untuk mengesampingkan kemungkinan ini, coba tetapkan periode lihat balik kueri 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 memutar 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 dari metric_name_foo). Anda dapat mengonfirmasinya jika data muncul setelah Anda menambahkan fungsi rate ke kueri (misalnya, rate(metric_name_foo[5m])).

Anda mungkin juga melihat bahwa sampel yang ditransfer telah meningkat tajam tanpa perubahan besar pada volume scrape atau 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 JENIS metrik Prometheus. Karena Monarch memiliki jenis yang kuat, Managed Service for Prometheus mempertimbangkan metrik tanpa jenis dengan menambahkan akhiran "unknown" dan menyerapnya dua kali, sekali sebagai pengukur dan sekali sebagai penghitung. Mesin kueri kemudian memilih apakah akan membuat kueri metrik pengukur atau penghitung pokok berdasarkan fungsi kueri yang Anda gunakan.

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

Alasan umum TYPE mungkin tidak ditetapkan meliputi:

  • Tidak sengaja mengonfigurasi kolektor Managed Service for Prometheus sebagai server federasi. Federasi tidak didukung saat menggunakan Managed Service for Prometheus. Karena federasi sengaja menghapus informasi TYPE, menerapkan federasi akan menyebabkan metrik berjenis "unknown".
  • Menggunakan Prometheus Remote Write kapan saja dalam pipeline penyerapan. Protokol ini juga sengaja menghapus informasi TYPE.
  • Menggunakan aturan pemberian label ulang yang mengubah nama metrik. Tindakan ini menyebabkan metrik yang diganti namanya tidak lagi dikaitkan dengan informasi TYPE yang terkait dengan nama metrik asli.
  • Eksporter tidak memunculkan TYPE untuk setiap metrik.
  • Masalah sementara saat TYPE dihapus saat kolektor pertama kali dimulai.

Untuk menyelesaikan masalah ini, lakukan tindakan berikut:

  • Berhenti menggunakan federasi dengan Managed Service for Prometheus. Jika Anda ingin mengurangi kardinalitas dan biaya dengan "menggabungkan" data sebelum mengirimkannya ke Monarch, lihat Mengonfigurasi agregasi lokal.
  • Berhenti menggunakan Prometheus Remote Write di jalur pengumpulan Anda.
  • Pastikan kolom # TYPE ada untuk setiap metrik dengan membuka endpoint /metrics.
  • Hapus aturan pemberian label 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 pemrosesan penghitung lainnya.

Data Grafana tidak dipertahankan setelah pod dimulai ulang

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

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

Mengimpor dasbor Grafana

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

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

Masalah sisi transfer

Masalah sisi penyerapan dapat terkait dengan pengumpulan atau evaluasi aturan. Mulailah dengan melihat log error untuk koleksi 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 pengambilan data. Untuk 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 memiliki salah satu masalah berikut:

  • Managed Service for Prometheus tidak dapat menjangkau kolektor di 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 pengambilan data Anda.

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

Fraksi kolektor kurang dari 1

Jika telah mengaktifkan fitur status target, Anda akan mendapatkan informasi status tentang resource. Nilai Status.Endpoint Statuses.Collectors Fraction dari resource PodMonitoring atau ClusterPodMonitoring Anda 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, berarti satu atau beberapa kolektor tidak dapat dijangkau, dan metrik di salah satu node tersebut mungkin tidak di-scrap. 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 berfungsi dengan baik, 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 yang tidak sehat

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

Lihat kolom Sample Groups, yang mengelompokkan target berdasarkan pesan error, dan temukan kolom Last Error. Kolom Last Error berasal dari Prometheus dan memberi tahu Anda alasan target tidak dapat di-scrap. Untuk mengatasi masalah ini, dengan menggunakan target sampel sebagai referensi, periksa apakah endpoint pengambilan Anda berjalan.

Endpoint scraping tidak sah

Jika Anda melihat salah satu error berikut dan target pengambilan memerlukan otorisasi, berarti kolektor Anda tidak disiapkan untuk menggunakan jenis otorisasi yang benar atau menggunakan payload otorisasi yang salah:

  • server returned HTTP status 401 Unauthorized
  • x509: certificate signed by unknown authority

Untuk mengatasi masalah ini, lihat Mengonfigurasi endpoint scrape yang diotorisasi.

Kuota melampaui batas

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

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

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

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

Izin tidak ada di akun layanan default node

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

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

Koleksi 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 evaluasi aturan dan pengumpulan gagal.

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 dalam Akun layanan yang salah dikonfigurasi.

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

    1. Di konsol Google Cloud, buka halaman Kubernetes clusters:

      Buka Cluster Kubernetes

      Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Kubernetes Engine.

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

    3. Klik Details.

    4. Klik link Instance VM.

    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 mengkueri cakupan metrik yang diinginkan, lihat Mengubah project yang dikueri.

Akun layanan yang salah dikonfigurasi

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

  • "code = PermissionDenied desc = Izin 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 mengetahui informasi selengkapnya."

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

  1. Di konsol Google Cloud, buka halaman IAM:

    Buka IAM

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah IAM & Admin.

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

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

Jika Anda menjalankan Kubernetes non-GKE, Anda harus meneruskan kredensial secara eksplisit 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. Menggunakan satu akun layanan untuk menulis data metrik untuk beberapa project — misalnya, saat satu evaluator aturan terkelola mengkueri cakupan metrik multi-project — dapat menyebabkan error izin ini. Jika Anda menggunakan akun layanan default, sebaiknya konfigurasikan akun layanan khusus sehingga Anda dapat menambahkan izin monitoring.timeSeries.create dengan aman untuk beberapa project. Jika tidak dapat memberikan izin ini, Anda dapat menggunakan pemberian label ulang metrik untuk menulis ulang label project_id ke nama lain. Project ID kemudian ditetapkan secara default ke project Google Cloud tempat server Prometheus atau evaluator aturan Anda berjalan.

Konfigurasi scraping tidak valid

Jika Anda melihat error berikut, berarti PodMonitoring atau ClusterPodMonitoring Anda tidak dibentuk dengan benar:

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

Untuk mengatasinya, pastikan resource kustom Anda dibuat dengan benar sesuai dengan spesifikasi.

Webhook akses tidak dapat mengurai atau konfigurasi klien HTTP tidak valid

Pada versi Managed Service for Prometheus yang lebih lama dari 0.12, Anda mungkin melihat error yang mirip dengan berikut, yang terkait dengan injeksi secret di namespace non-default:

  • "admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" menolak permintaan: definisi tidak valid untuk endpoint dengan indeks 0: tidak dapat mengurai atau konfigurasi klien HTTP Prometheus tidak valid: harus menggunakan namespace "my-custom-namespace", mendapatkan: "default""

Untuk mengatasi masalah ini, upgrade ke versi 0.12 atau yang lebih baru.

Masalah terkait interval dan waktu tunggu pengambilan

Saat menggunakan Managed Service for Prometheus, waktu tunggu pengambilan tidak boleh lebih besar dari interval pengambilan. 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 pengambilan lebih besar dari interval pengambilan untuk konfigurasi pengambilan dengan nama tugas "PodMonitoring/gmp-system/example-app/go-metrics""

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

TYPE tidak ada pada metrik

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

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

Untuk memverifikasi bahwa informasi jenis yang tidak ada adalah masalahnya, periksa output /metrics aplikasi ekspor. Jika tidak ada baris seperti berikut, informasi jenis tidak ada:

# 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 Managed Service for Prometheus.

Tabrakan deret waktu

Jika Anda 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 sampling maksimum yang dikonfigurasi untuk metrik."
  • "Satu atau beberapa TimeSeries tidak dapat ditulis: Titik harus ditulis secara berurutan. Satu atau beberapa titik yang ditentukan memiliki waktu akhir yang lebih lama daripada titik terbaru."

Berikut adalah penyebab dan solusi yang paling umum:

  • Menggunakan pasangan ketersediaan tinggi. Managed Service for Prometheus tidak mendukung pengumpulan ketersediaan tinggi tradisional. 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 pemberian label ulang, terutama yang beroperasi pada tugas atau instance. Managed Service for Prometheus mengidentifikasi sebagian deret waktu unik dengan kombinasi label {project_id, location, cluster, namespace, job, instance}. Menggunakan aturan pemberian label ulang untuk menghapus label ini, terutama label job dan instance, sering kali dapat menyebabkan konflik. Penulisan ulang label ini tidak direkomendasikan.

    Untuk mengatasi masalah ini, hapus aturan yang menyebabkannya; hal ini sering kali dilakukan oleh aturan metricRelabeling yang menggunakan tindakan labeldrop. Anda dapat mengidentifikasi aturan yang bermasalah dengan mengomentari semua aturan pemberian label ulang, lalu mengaktifkannya kembali, satu per satu, hingga error terulang.

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

Melebihi batas jumlah label

Jika Anda 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 mengubah definisi metrik dengan cepat sehingga satu nama metrik secara efektif memiliki beberapa kumpulan kunci label independen selama seluruh masa aktif metrik Anda. Cloud Monitoring memberlakukan batas jumlah label untuk setiap metrik; untuk mengetahui informasi selengkapnya, lihat batas untuk metrik yang ditentukan pengguna.

Ada tiga langkah untuk mengatasi masalah ini:

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

  2. Atasi sumber masalah, yang mungkin melibatkan penyesuaian aturan pemberian label ulang PodMonitoring, mengubah eksportir, atau memperbaiki instrumentasi.

  3. Hapus deskripsi metrik untuk metrik ini (yang akan menyebabkan hilangnya 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 eksportir atau aplikasi yang melampirkan label dinamis pada metrik. Misalnya, cAdvisor yang di-deploy sendiri dengan label penampung dan variabel lingkungan tambahan atau agen DataDog, yang memasukkan anotasi dinamis.

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

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

    Untuk mengatasi masalah ini, hapus entri aturan yang menyebabkannya.

Batas kapasitas untuk membuat dan memperbarui metrik dan label

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

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

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

Kuota ini bersifat tetap, tetapi masalah apa pun akan otomatis teratasi saat metrik baru dan label metrik dibuat hingga batas per menit.

Batasan jumlah deskripsi metrik

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

  • "Kuota deskripsi metrik Anda telah habis."

Secara default, batas ini ditetapkan ke 25.000. Meskipun kuota ini dapat dicabut berdasarkan permintaan jika metrik Anda dibentuk dengan baik, kemungkinan besar Anda akan mencapai batas ini karena memasukkan nama metrik yang tidak terbentuk dengan benar ke dalam sistem.

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

Cloud Monitoring maupun Managed Service for Prometheus tidak mendukung metrik non-dimensi, seperti yang diformat untuk StatsD atau Graphite. Meskipun sebagian besar eksportir Prometheus dikonfigurasi dengan benar secara default, eksportir tertentu, seperti eksportir StatsD, eksportir Vault, atau Envoy Proxy yang disertakan dengan Istio, harus dikonfigurasi secara eksplisit untuk menggunakan label, bukan menyisipkan informasi dalam nama metrik. Contoh nama metrik yang salah formatnya 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 konsol Google Cloud, pilih project Google Cloud yang ditautkan ke error.

  2. Di konsol Google Cloud, buka halaman  Metrics management:

    Buka Pengelolaan metrik

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

  3. Pastikan jumlah metrik Aktif dan Tidak Aktif lebih dari 25.000. Dalam sebagian besar situasi, Anda akan melihat banyak metrik Tidak aktif.
  4. Pilih "Inactive" di panel Quick Filters, lihat halaman daftar, dan cari pola.
  5. Pilih "Active" di panel Quick Filters, urutkan menurut Samples billable volume menurun, lihat daftar per halaman, dan cari pola.
  6. Urutkan menurut Volume contoh yang dapat ditagih dari atas ke bawah, lihat daftar per halaman, dan cari pola.

Atau, Anda dapat mengonfirmasi masalah ini menggunakan Metrics Explorer:

  1. Di konsol Google Cloud, pilih project Google Cloud yang ditautkan ke error.

  2. Di konsol Google Cloud, buka halaman  Metrics explorer:

    Buka Metrics explorer

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

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

Setelah mengidentifikasi pola yang menunjukkan metrik yang salah format, Anda dapat memitigasi masalah dengan memperbaiki eksportir di sumber, lalu menghapus deskripsi metrik yang melanggar.

Untuk mencegah masalah ini terjadi lagi, Anda harus mengonfigurasi eksportir yang relevan terlebih dahulu agar tidak lagi memunculkan metrik yang salah format. Sebaiknya konsultasikan dokumentasi untuk eksportir Anda guna mendapatkan bantuan. Anda dapat mengonfirmasi bahwa masalah telah diperbaiki dengan mengunjungi endpoint /metrics secara manual dan memeriksa nama metrik yang diekspor.

Kemudian, Anda dapat mengosongkan kuota dengan menghapus metrik yang salah formatnya 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 Anda yang salah format dan menghapus deskripsi metrik yang cocok dengan pola. Karena penghapusan metrik tidak dapat dibatalkan, sebaiknya jalankan skrip terlebih dahulu menggunakan mode uji coba.

Tidak ada error dan tidak ada metrik

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

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

Akar masalahnya bisa jadi apa saja. Sebaiknya periksa hal berikut:

  • PodMonitoring Anda mereferensikan port yang valid.

  • Spesifikasi Deployment eksportir Anda memiliki port yang diberi nama dengan benar.

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

  • 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 Anda ambil. Jangan menginstal resource atau aplikasi kustom di namespace gmp-system atau gke-gmp-system.

  • Nama metrik dan label Anda cocok dengan ekspresi reguler yang memvalidasi Prometheus. Managed Service for Prometheus tidak mendukung nama label yang dimulai dengan karakter _.

  • Anda tidak menggunakan kumpulan filter yang menyebabkan semua data difilter. Pastikan 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 mengekspos jenis metrik OpenMetrics seperti Info, Stateset, dan GaugeHistogram, tetapi jenis metrik ini tidak didukung oleh Managed Service for Prometheus dan dihapus secara otomatis.

Beberapa metrik tidak ada untuk target yang berjalan singkat

Google Cloud Managed Service for Prometheus di-deploy dan tidak ada error konfigurasi; tetapi, beberapa metrik tidak ada.

Tentukan deployment yang menghasilkan metrik yang tidak ada sebagian. Jika deployment adalah CronJob Google Kubernetes Engine, tentukan berapa lama tugas biasanya berjalan:

  1. Temukan file yaml deployment tugas cron dan temukan status, yang tercantum di akhir file. Status dalam contoh ini menunjukkan bahwa tugas berjalan selama satu menit:

      status:
    lastScheduleTime: "2024-04-03T16:20:00Z"
    lastSuccessfulTime: "2024-04-03T16:21:07Z"

  2. Jika waktu proses kurang dari lima menit, tugas tidak berjalan cukup lama agar data metrik dapat di-scrape secara konsisten.

    Untuk mengatasi situasi ini, coba langkah berikut:

    • Konfigurasikan tugas untuk memastikan bahwa tugas tidak keluar hingga setidaknya lima menit berlalu sejak tugas dimulai.

    • Konfigurasikan tugas untuk mendeteksi apakah metrik telah di-scraping sebelum keluar. Kemampuan ini memerlukan dukungan library.

    • Pertimbangkan untuk membuat metrik nilai distribusi berbasis log, bukan mengumpulkan data metrik. Pendekatan ini disarankan jika data dipublikasikan dengan kecepatan rendah. Untuk informasi selengkapnya, lihat Metrik berbasis log.

  3. Jika waktu prosesnya lebih dari lima menit atau jika tidak konsisten, lihat bagian Target yang tidak responsif dalam dokumen ini.

Masalah terkait pengumpulan dari eksportir

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

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

    Misalnya, untuk memeriksa apakah pod dengan pemilih app.kubernetes.io/name=redis di namespace test memunculkan metrik di endpoint /metrics di port 9121, Anda dapat melakukan port-forward sebagai 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 ditampilkan oleh eksportir untuk scraping.

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

  • Pastikan kolektor terkelola dapat meng-scrape eksportir dengan memeriksa antarmuka web Prometheus yang ditampilkan kolektor.

    1. Identifikasi kolektor terkelola yang berjalan di node yang sama dengan tempat eksporter Anda berjalan. Misalnya, jika eksportir 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 di 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 eksportir tercantum sebagai salah satu target, berarti kolektor terkelola Anda berhasil meng-scrape eksportir.

Error Collector Out Of Memory (OOM)

Jika Anda menggunakan pengumpulan terkelola dan mengalami error Out Of Memory (OOM) pada kolektor, pertimbangkan untuk mengaktifkan penskalaan otomatis pod vertikal.

Operator memiliki error Out Of Memory (OOM)

Jika Anda menggunakan pengumpulan terkelola dan mengalami error Kehabisan Memori (OOM) pada operator, pertimbangkan untuk menonaktifkan fitur status target. Fitur status target dapat menyebabkan masalah performa operator di cluster yang lebih besar.

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 akan teratasi setelah beberapa menit. Hal ini biasanya disebabkan oleh penghapusan aturan pemberian label ulang yang memengaruhi banyak metrik yang berbeda. Penghapusan ini menyebabkan pembentukan antrean update pada deskripsi metrik di project Anda. Error akan hilang saat antrean diproses.

Untuk mengetahui informasi selengkapnya, lihat Batas pembuatan dan pembaruan metrik serta label.

Kueri diblokir dan dibatalkan oleh Monarch

Jika Anda melihat error berikut, berarti Anda telah mencapai batas internal untuk jumlah kueri serentak yang dapat dijalankan untuk project tertentu:

  • "internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500."

Untuk melindungi dari penyalahgunaan, sistem menerapkan batas mutlak pada jumlah kueri dari satu project yang dapat berjalan secara serentak dalam Monarch. Dengan penggunaan Prometheus yang umum, kueri akan cepat dan batas ini tidak akan pernah tercapai.

Anda mungkin mencapai batas ini jika mengeluarkan banyak kueri serentak yang berjalan selama waktu yang lebih lama dari yang diharapkan. Kueri yang meminta data lebih dari 25 jam biasanya lebih lambat dieksekusi daripada kueri yang meminta data kurang dari 25 jam, dan semakin lama lihat balik kueri, semakin lambat kueri diperkirakan.

Biasanya masalah ini dipicu dengan menjalankan banyak aturan lihat balik panjang dengan cara yang tidak efisien. Misalnya, Anda mungkin memiliki banyak aturan yang berjalan satu kali setiap menit dan meminta tarif 4 minggu. Jika setiap aturan ini memerlukan waktu lama untuk dijalankan, hal ini pada akhirnya dapat menyebabkan cadangan kueri menunggu untuk dijalankan untuk project Anda, yang kemudian menyebabkan Monarch membatasi kueri.

Untuk mengatasi masalah ini, Anda perlu meningkatkan interval evaluasi aturan lihat balik panjang agar tidak berjalan setiap 1 menit. Tidak perlu menjalankan kueri untuk rasio 4 minggu setiap 1 menit; ada 40.320 menit dalam 4 minggu, sehingga setiap menit hampir tidak memberi Anda sinyal tambahan (data Anda akan berubah maksimal sebesar 1/40.320). Menggunakan interval evaluasi 1 jam seharusnya sudah memadai untuk kueri yang meminta tarif 4 minggu.

Setelah Anda menyelesaikan bottleneck yang disebabkan oleh kueri yang berjalan lama dan tidak efisien yang terlalu sering dijalankan, masalah ini akan teratasi dengan sendirinya.

Jenis nilai tidak kompatibel

Jika Anda melihat error berikut setelah penyerapan atau kueri, berarti Anda memiliki inkompatibilitas jenis nilai dalam metrik:

  • "Jenis nilai untuk metrik prometheus.googleapis.com/metric_name/gauge harus INT64, tetapi DOUBLE"
  • "Jenis nilai untuk metrik prometheus.googleapis.com/metric_name/gauge harus DOUBLE, tetapi INT64"
  • "Satu atau beberapa TimeSeries tidak dapat ditulis: Jenis nilai untuk metrik prometheus.googleapis.com/target_info/gauge bertentangan dengan jenis nilai yang ada (INT64)"

Anda mungkin melihat error ini setelah penyerapan, karena Monarch tidak mendukung penulisan data berjenis DOUBLE ke metrik berjenis INT64, atau tidak mendukung penulisan data berjenis INT64 ke metrik berjenis DOUBLE. Anda mungkin juga melihat error ini saat membuat kueri menggunakan cakupan metrik multi-project, karena Monarch tidak dapat menggabungkan metrik berjenis DOUBLE dalam satu project dengan metrik berjenis INT64 di project lain.

Error ini hanya terjadi jika Anda memiliki pengumpulan OpenTelemetry yang melaporkan data, dan error ini lebih cenderung terjadi jika Anda memiliki OpenTelemetry (menggunakan eksportir googlemanagedprometheus) dan Prometheus yang melaporkan data untuk metrik yang sama seperti yang biasa terjadi untuk metrik target_info.

Penyebabnya mungkin salah satu dari hal berikut:

  • Anda mengumpulkan metrik OTLP, dan library metrik OTLP mengubah jenis nilainya dari DOUBLE menjadi INT64, seperti yang terjadi dengan metrik Java OpenTelemetry. Versi baru library metrik kini tidak kompatibel dengan jenis nilai metrik yang dibuat oleh versi lama library metrik.
  • Anda mengumpulkan metrik target_info menggunakan Prometheus dan OpenTelemetry. Prometheus mengumpulkan metrik ini sebagai DOUBLE, sedangkan OpenTelemetry mengumpulkan metrik ini sebagai INT64. Pengumpul Anda kini menulis dua jenis nilai ke metrik yang sama dalam project yang sama, dan hanya pengumpul yang pertama kali membuat deskripsi metrik yang berhasil.
  • Anda mengumpulkan target_info menggunakan OpenTelemetry sebagai INT64 dalam satu project, dan Anda mengumpulkan target_info menggunakan Prometheus sebagai DOUBLE dalam project lain. Menambahkan kedua metrik ke cakupan metrik yang sama, lalu mengkueri metrik tersebut melalui cakupan metrik, akan menyebabkan penggabungan yang tidak valid antara jenis nilai metrik yang tidak kompatibel.

Masalah ini dapat diatasi dengan memaksa semua jenis nilai metrik menjadi DOUBLE dengan melakukan hal berikut:

  1. Konfigurasi ulang kolektor OpenTelemetry untuk memaksa semua metrik menjadi DOUBLE dengan mengaktifkan tanda exporter.googlemanagedprometheus.intToDouble gate fitur.
  2. Hapus semua deskripsi metrik INT64 dan biarkan dibuat ulang sebagai DOUBLE. Anda dapat menggunakan skrip delete_metric_descriptors.go untuk mengotomatiskan hal ini.

Mengikuti langkah-langkah ini akan menghapus semua data yang disimpan sebagai metrik INT64. Tidak ada alternatif untuk menghapus metrik INT64 yang sepenuhnya menyelesaikan masalah ini.