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 berikut ini:

• Masalah di sisi kueri, sehingga data tidak dapat dibaca. Masalah di 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 penyerapan dapat disebabkan oleh masalah konfigurasi dengan akun layanan, pengumpul, 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 apa pun terkait 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  MQL atau  PromQL.

4. Pastikan PromQL dipilih di tombol Language. Tombol bahasa ada 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 mengetahui informasi tentang cara mengatasi masalah ini, lihat Masalah sisi kueri.

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

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 kemampuan pengamatan. Halaman Pengelolaan Metrik melaporkan informasi berikut:

• Volume penyerapan 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 halaman Pengelolaan Metrik untuk mengecualikan metrik yang tidak diperlukan, sehingga menghilangkan biaya penyerapan metrik tersebut.

Untuk melihat halaman Pengelolaan Metrik, lakukan hal berikut:

1. Di konsol Google Cloud , buka halaman  Pengelolaan metrik:

   Buka Pengelolaan metrik

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

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

Untuk mengetahui informasi selengkapnya tentang halaman Pengelolaan Metrik, lihat Melihat dan mengelola penggunaan metrik.

Masalah sisi kueri

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

• Izin atau kredensial yang salah untuk akun layanan.
• Salah konfigurasi Workload Identity Federation untuk GKE, jika cluster Anda mengaktifkan fitur ini. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi akun layanan untuk Workload Identity Federation untuk GKE.

Mulailah dengan melakukan hal berikut:

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

• Jika Anda menggunakan Workload Identity Federation untuk GKE, pastikan akun layanan Anda memiliki izin yang benar dengan melakukan 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 prinsipal. Verifikasi bahwa 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 salah dikonfigurasi atau salah ketik

Jika Anda melihat salah satu hal berikut, Anda mungkin tidak memasukkan atau salah mengetik rahasia:

• Salah satu error "dilarang" berikut 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-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 menyetel ID project sinkronisasi sumber data ke cakupan metrik atau project yang sama dengan yang memiliki 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 di log untuk tugas sinkronisasi sumber data dengan menjalankan kubectl logs job.batch/datasource-syncer-init. Perintah ini harus dijalankan segera setelah menerapkan file datasource-syncer.yaml.

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

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

1. Pastikan Anda telah menyetel project ID UI frontend ke cakupan metrik atau project yang sama dengan yang memiliki kredensial akun layanan Anda.

2. Verifikasi ID project yang telah Anda tentukan untuk setiap 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 atau kredensial akun, 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 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 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, konfigurasi Grafana agar 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, berarti 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 mengalami waktu tunggu habis hingga kueri melebihi 120 detik, sedangkan Grafana akan mengalami waktu tunggu habis setelah 30 detik secara default. Untuk memperbaikinya, tingkatkan 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." (Templating [tugas]: Error saat memperbarui opsi: label selain name belum didukung.)

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 menurut 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 melampaui kuota baca untuk Cloud Monitoring API:

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

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

Metrik dari beberapa project

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

Sebagai gantinya, buat cakupan metrik Cloud Monitoring di satu projectGoogle 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 dipantau yang ditentukan

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

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

Anda dapat menentukan jenis resource yang dipantau 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 pengumpul dan konsol Google Cloud

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

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

Perbedaan antara jumlah di UI pengumpul dan jumlah di konsolGoogle Cloud sama dengan nilai pertama yang dicatat di UI pengumpul, yang diharapkan karena sistem melewati nilai awal tersebut, dan mengurangkannya 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 sejenisnya, yang dalam hal ini perbedaan di seluruh cakupan waktu identik di antara kedua UI. Metrik kumulatif hanya bertambah, jadi Anda tidak dapat menyetel pemberitahuan pada kueri mentah karena deret waktu hanya mencapai nilai minimum satu kali. Semua pemberitahuan dan diagram yang berguna melihat perubahan atau tingkat perubahan nilai.

Pengumpul hanya menyimpan data sekitar 10 menit secara lokal. Perbedaan dalam nilai kumulatif mentah juga dapat muncul karena reset terjadi sebelum cakrawala 10 menit. Untuk mengesampingkan kemungkinan ini, coba tetapkan periode lihat kembali kueri 10 menit saja saat membandingkan UI pengumpul dengan konsol Google Cloud .

Perbedaan juga dapat disebabkan oleh adanya beberapa thread pekerja di aplikasi Anda, yang masing-masing memiliki endpoint /metrics. Jika aplikasi Anda meluncurkan beberapa thread, Anda harus menempatkan library klien Prometheus dalam mode multiproses. Untuk mengetahui informasi selengkapnya, lihat dokumentasi tentang penggunaan 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 Anda menambahkan fungsi rate ke kueri (misalnya, rate(metric_name_foo[5m])).

Anda mungkin juga melihat bahwa sampel yang di-ingest telah meningkat tajam tanpa ada perubahan besar pada volume scraping atau metrik baru sedang 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 memiliki jenis yang kuat, Managed Service for Prometheus memperhitungkan metrik yang tidak memiliki jenis dengan menambahkan akhiran "unknown" dan menyerapnya dua kali, sekali sebagai gauge 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, 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 sebagai metrik penghitung individual menyebabkan fungsi histogram tidak berfungsi. Karena metrik berjenis "tidak diketahui" di-ingest dua kali, tidak menetapkan TYPE akan menggandakan sampel yang di-ingest.

Alasan umum TYPE mungkin tidak ditetapkan meliputi:

• Salah mengonfigurasi pengumpul Managed Service for Prometheus sebagai server gabungan. Federasi tidak didukung saat menggunakan Managed Service for Prometheus. Karena penggabungan secara sengaja menghilangkan informasi TYPE, penerapan penggabungan menyebabkan metrik berjenis "tidak diketahui".
• Menggunakan Prometheus Remote Write di titik mana pun dalam pipeline penyerapan. Protokol ini juga sengaja menghilangkan informasi TYPE.
• Menggunakan aturan pelabelan ulang yang mengubah nama metrik. Hal ini menyebabkan metrik yang diganti namanya tidak terkait dengan informasi TYPE yang terkait dengan nama metrik asli.
• Exporter tidak memancarkan TYPE untuk setiap metrik.
• Masalah sementara saat TYPE dihilangkan saat pengumpul 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 pelabelan ulang yang mengubah nama metrik.
• Hapus semua metrik yang bertentangan dengan akhiran "unknown" atau "unknown:counter" dengan memanggil DeleteMetricDescriptor.
• Atau, selalu kueri penghitung menggunakan rate atau fungsi pemrosesan penghitung lainnya.

Anda juga dapat membuat aturan pengecualian metrik dalam Pengelolaan Metrik untuk mencegah metrik yang berakhiran "tidak diketahui" di-ingest dengan menggunakan ekspresi reguler prometheus.googleapis.com/.+/unknown.*. Jika Anda tidak memperbaiki masalah mendasar sebelum menginstal aturan ini, Anda dapat mencegah data metrik yang diinginkan di-ingest.

Data Grafana tidak dipertahankan setelah pod dimulai ulang

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

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

Hasil kueri atau aturan pemberitahuan yang tidak konsisten yang diperbaiki secara otomatis

Anda mungkin melihat pola saat kueri di jendela terbaru, seperti kueri yang dijalankan oleh aturan perekaman atau pemberitahuan, menampilkan lonjakan data yang tidak dapat dijelaskan. Saat menyelidiki lonjakan dengan menjalankan kueri di Grafana atau Metrics Explorer, Anda mungkin melihat bahwa lonjakan telah hilang dan data terlihat normal kembali.

Perilaku ini mungkin lebih sering terjadi jika salah satu hal berikut benar:

• Anda menjalankan banyak kueri yang sangat mirip secara paralel secara konsisten, mungkin dengan menggunakan aturan. Kueri ini mungkin hanya berbeda satu sama lain berdasarkan satu atribut. Misalnya, Anda mungkin menjalankan 50 aturan perekaman yang hanya berbeda berdasarkan VALUE untuk filter {foo="VALUE"}, atau yang hanya berbeda karena memiliki nilai [duration] yang berbeda untuk fungsi rate.
• Anda menjalankan kueri pada time=now tanpa buffer.
• Anda menjalankan kueri instan seperti aturan rekaman atau pemberitahuan. Jika Anda menggunakan aturan perekaman, Anda mungkin melihat bahwa output yang disimpan memiliki lonjakan, tetapi lonjakan tidak dapat ditemukan saat menjalankan kueri pada data mentah.
• Anda membuat kueri dua metrik untuk membuat rasio. Lonjakan lebih terlihat jelas jika jumlah deret waktu rendah dalam kueri pembilang atau penyebut.
• Data metrik Anda berada di region yang lebih besar seperti Google Cloud us-central1 atau us-east4.

Ada beberapa kemungkinan penyebab lonjakan sementara dalam kueri semacam ini:

• (Penyebab paling umum) Kueri paralel yang serupa semuanya meminta data dari set node Monarch yang sama, sehingga menggunakan sejumlah besar memori di setiap node secara keseluruhan. Jika Monarch memiliki resource yang tersedia dalam jumlah yang memadai di region cloud, kueri Anda akan berfungsi. Saat Monarch mengalami tekanan resource di region cloud, setiap node akan membatasi kueri, dan lebih memilih untuk membatasi pengguna yang menggunakan memori paling banyak di setiap node. Saat Monarch memiliki resource yang memadai lagi, kueri Anda akan berfungsi kembali. Kueri ini mungkin berupa SLI yang dibuat secara otomatis dari alat seperti Sloth.
• Anda memiliki data yang terlambat tiba, dan kueri Anda tidak toleran terhadap hal ini. Data yang baru ditulis dapat dikueri dalam waktu sekitar 3-7 detik, tidak termasuk latensi jaringan dan penundaan apa pun yang disebabkan oleh tekanan resource dalam lingkungan Anda. Jika kueri Anda tidak membuat penundaan atau offset untuk memperhitungkan data yang terlambat, maka Anda mungkin secara tidak sengaja membuat kueri selama periode di mana Anda hanya memiliki sebagian data. Setelah data tiba, hasil kueri Anda akan terlihat normal.
• Monarch mungkin memiliki sedikit inkonsistensi saat menyimpan data Anda di replika yang berbeda. Mesin kueri mencoba memilih replika "berkualitas terbaik", tetapi jika kueri yang berbeda memilih replika yang berbeda dengan set data yang sedikit berbeda, hasil Anda mungkin sedikit bervariasi di antara kueri. Hal ini adalah perilaku sistem yang normal, dan pemberitahuan Anda harus toleran terhadap sedikit perbedaan ini.
• Seluruh wilayah Monarch mungkin tidak tersedia untuk sementara. Jika region tidak dapat dijangkau, mesin kueri akan memperlakukan region tersebut seolah-olah tidak pernah ada. Setelah region tersedia, hasil kueri akan terus menampilkan data region tersebut.

Untuk memperhitungkan kemungkinan penyebab utama ini, Anda harus memastikan kueri, aturan, dan pemberitahuan Anda mengikuti praktik terbaik berikut:

• Gabungkan aturan dan notifikasi serupa ke dalam satu aturan yang mengagregasi menurut label, bukan memiliki aturan terpisah untuk setiap permutasi nilai label. Jika ini adalah aturan pemberitahuan, Anda dapat menggunakan pemberitahuan berbasis label untuk merutekan pemberitahuan dari aturan gabungan, bukan mengonfigurasi aturan perutean satu per satu untuk setiap pemberitahuan.

  Misalnya, jika Anda memiliki label foo dengan nilai bar, baz, dan qux, daripada memiliki aturan terpisah untuk setiap nilai label (satu dengan kueri sum(metric{foo="bar"}), satu dengan kueri sum(metric{foo="baz"}), satu dengan kueri sum(metric{foo="qux"})), buat satu aturan yang menggabungkan label tersebut dan secara opsional memfilter nilai label yang Anda inginkan (seperti sum by (foo) metric{foo=~"bar|baz|qux"}).

  Jika metrik Anda memiliki 2 label, dan setiap label memiliki 50 nilai, serta Anda memiliki aturan terpisah untuk setiap kombinasi nilai label, dan kueri aturan Anda adalah rasio, maka setiap periode Anda meluncurkan 50 x 50 x 2 = 5.000 kueri Monarch paralel yang masing-masing mengakses set node Monarch yang sama. Secara keseluruhan, 5.000 kueri paralel ini menggunakan sejumlah besar memori di setiap node Monarch, yang meningkatkan risiko Anda mengalami pembatasan saat region Monarch mengalami tekanan resource.

  Jika Anda menggunakan agregasi untuk menggabungkan aturan ini menjadi satu aturan yang berupa rasio, maka setiap periode Anda hanya meluncurkan 2 kueri Monarch paralel. Kedua kueri paralel ini menggunakan memori yang jauh lebih sedikit secara keseluruhan daripada 5.000 kueri paralel, dan risiko Anda mengalami pembatasan kecepatan jauh lebih rendah.

• Jika aturan Anda melihat kembali lebih dari 1 hari, jalankan aturan tersebut lebih jarang daripada setiap menit. Kueri yang mengakses data yang lebih lama dari 25 jam akan masuk ke repositori data di disk Monarch. Kueri repositori ini lebih lambat dan menggunakan lebih banyak memori daripada kueri atas data yang lebih baru, yang memperparah masalah penggunaan memori dari aturan perekaman paralel.

  Pertimbangkan untuk menjalankan kueri semacam ini sekali per jam, bukan sekali per menit. Menjalankan kueri sepanjang hari setiap menit hanya memberi Anda perubahan 1/1440 = 0,07% dalam hasil setiap periode, yang merupakan perubahan yang tidak signifikan. Menjalankan kueri sepanjang hari setiap jam akan memberi Anda perubahan hasil sebesar 60/1440 = 4% setiap periode, yang merupakan ukuran sinyal yang lebih relevan. Jika Anda perlu mendapatkan notifikasi jika ada perubahan data terbaru, Anda dapat menjalankan aturan lain dengan periode lihat kembali yang lebih singkat (seperti 5 menit) sekali per menit.

• Gunakan kolom for: dalam aturan Anda untuk mentoleransi hasil tidak normal sementara. Kolom for: menghentikan pemberitahuan Anda agar tidak dipicu kecuali jika kondisi pemberitahuan telah terpenuhi selama setidaknya durasi yang dikonfigurasi. Tetapkan kolom ini menjadi dua kali panjang interval evaluasi aturan Anda atau lebih.

  Penggunaan kolom for: membantu karena masalah sementara sering kali dapat diselesaikan dengan sendirinya, yang berarti masalah tersebut tidak terjadi pada siklus pemberitahuan berturut-turut. Jika Anda melihat lonjakan, dan lonjakan tersebut berlanjut di beberapa stempel waktu dan beberapa siklus pemberitahuan, Anda dapat lebih yakin bahwa itu adalah lonjakan nyata dan bukan masalah sementara.

• Gunakan pengubah offset di PromQL untuk menunda evaluasi kueri sehingga tidak beroperasi pada periode data terbaru. Lihat interval pengambilan sampel dan interval evaluasi aturan Anda, lalu identifikasi interval yang lebih panjang. Idealnya, offset kueri Anda setidaknya dua kali panjang interval yang lebih panjang. Misalnya, jika Anda mengirim data setiap 15 detik dan menjalankan aturan setiap 30 detik, maka offset kueri Anda setidaknya 1 menit. Offset 1 menit menyebabkan aturan Anda menggunakan stempel waktu akhir yang setidaknya sudah 60 detik, yang membuat buffer untuk data yang terlambat tiba sebelum menjalankan aturan Anda.

  Hal ini merupakan praktik terbaik Cloud Monitoring (semua pemberitahuan PromQL terkelola memiliki offset minimal 1 menit) dan praktik terbaik Prometheus.

• Kelompokkan hasil menurut label location untuk mengisolasi potensi masalah wilayah yang tidak tersedia. Label yang memiliki Google Cloud region mungkin disebut zone atau region di beberapa metrik sistem.

  Jika Anda tidak mengelompokkan menurut wilayah dan wilayah menjadi tidak tersedia, hasil Anda akan terlihat menurun secara tiba-tiba dan Anda mungkin juga melihat penurunan hasil historis. Jika Anda mengelompokkan menurut wilayah dan suatu wilayah tidak tersedia, Anda tidak akan menerima hasil apa pun dari wilayah tersebut, tetapi hasil dari wilayah lain tidak terpengaruh.

• Jika rasio Anda adalah rasio keberhasilan (seperti respons 2xx terhadap total respons), sebaiknya jadikan rasio tersebut sebagai rasio error (seperti respons 4xx+5xx terhadap total respons). Rasio error lebih toleran terhadap data yang tidak konsisten, karena penurunan sementara pada data membuat hasil kueri lebih rendah daripada nilai minimum Anda dan oleh karena itu tidak memicu pemberitahuan.

• Pisahkan kueri rasio atau aturan perekaman menjadi kueri pembilang dan penyebut yang terpisah, jika memungkinkan. Ini adalah praktik terbaik Prometheus. Penggunaan rasio valid, tetapi karena kueri di pembilang dieksekusi secara terpisah dari kueri di penyebut, penggunaan rasio dapat memperbesar dampak masalah sementara:

  • Jika Monarch membatasi kueri pembilang, tetapi tidak kueri penyebut, Anda mungkin melihat hasil yang lebih rendah dari yang diharapkan. Jika Monarch membatasi kueri penyebut, tetapi tidak membatasi kueri pembilang, Anda mungkin melihat hasil yang sangat tinggi secara tidak terduga.
  • Jika Anda membuat kueri untuk jangka waktu terbaru dan memiliki data yang terlambat tiba, ada kemungkinan bahwa satu kueri dalam rasio dieksekusi sebelum data tiba dan kueri lainnya dalam rasio dieksekusi setelah data tiba.
  • Jika salah satu sisi rasio Anda terdiri dari deret waktu yang relatif sedikit, maka setiap error akan diperbesar. Jika pembilang dan penyebut Anda masing-masing memiliki 100 deret waktu, dan Monarch tidak menampilkan 1 deret waktu dalam kueri pembilang, Anda kemungkinan akan melihat perbedaan 1%. Jika pembilang dan penyebut masing-masing memiliki 1.000.000 deret waktu, dan Monarch tidak menampilkan 1 deret waktu dalam kueri pembilang, Anda kemungkinan tidak akan melihat perbedaan 0,0001%.

• Jika data Anda jarang, gunakan durasi tarif yang lebih lama dalam kueri Anda. Jika data Anda tiba setiap 10 menit dan kueri Anda menggunakan rate(metric[1m]), maka kueri Anda hanya melihat kembali data selama 1 menit dan terkadang Anda mendapatkan hasil kosong. Sebagai aturan praktis, tetapkan [duration] agar setidaknya 4 kali lipat interval crawl Anda.

  Kueri pengukur secara default melihat kembali data selama 5 menit. Untuk membuat mereka melihat kembali lebih jauh, gunakan fungsi x_over_time yang valid seperti last_over_time.

Rekomendasi ini sebagian besar relevan jika Anda melihat hasil kueri yang tidak konsisten saat membuat kueri data terbaru. Jika Anda melihat masalah ini terjadi saat mengirim kueri data yang sudah berusia lebih dari 25 jam, mungkin ada masalah teknis pada Monarch. Jika hal ini terjadi, hubungi Cloud Customer Care agar kami dapat menyelidikinya.

Mengimpor dasbor Grafana

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

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

Masalah sisi penyerapan

Masalah di 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 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:

• Managed Service for Prometheus tidak dapat menjangkau pengumpul 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 pengambilan data Anda sedang berjalan. Jika pod Kubernetes Anda berjalan, pemilih label cocok, dan Anda dapat mengakses endpoint pengambilan data secara manual (biasanya dengan membuka endpoint /metrics), maka periksa apakah pengumpul Managed Service for Prometheus berjalan.

Fraksi pengumpul kurang dari 1

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

Jika kolom Collectors Fraction memiliki nilai selain 1, berarti satu atau beberapa pengumpul tidak dapat dijangkau, dan metrik di salah satu node tersebut mungkin tidak di-scrape. Pastikan semua pengumpul berjalan dan dapat dijangkau melalui jaringan cluster. Anda dapat melihat status pod pengumpul 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 pengumpul (misalnya, pod pengumpul 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 pengumpul tidak responsif, lihat Pemecahan masalah workload GKE.

Jika pengumpul dalam kondisi 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 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, pengumpul tidak dapat meng-scrape satu atau beberapa target Anda.

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

Endpoint scraping yang tidak sah

Jika Anda melihat salah satu error berikut dan target scraping Anda memerlukan otorisasi, berarti pengumpul 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 scraping yang sah.

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 memunculkan layanan terkelola. Kuota default habis pada 100.000 sampel per detik yang di-ingest.

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

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"
• "Readiness probe failed: HTTP probe failed with statuscode: 503" (Pemeriksaan kesiapan gagal: Pemeriksaan HTTP gagal dengan status kode: 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 Pemantauan secara manual. Penghapusan ini menyebabkan pengumpulan dan evaluasi aturan 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 Pemantauan seperti yang dijelaskan dalam Akun layanan yang salah konfigurasi.

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

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

     Buka Kubernetes clusters

     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.

Ada juga kemungkinan bahwa penyinkron 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 dimaksud, lihat Mengubah project yang dikueri.

Akun layanan yang salah dikonfigurasi

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

• "code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist)"
• "google: could not find default credentials. 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 prinsipal. Verifikasi bahwa nama akun layanan dieja dengan benar. Kemudian klik Edit.

3. Pilih kolom Peran, lalu klik Saat ini digunakan dan cari peran Monitoring Metric Writer atau Monitoring Editor. Jika akun layanan tidak memiliki salah satu peran ini, berikan peran Monitoring Metric Writer (roles/monitoring.metricWriter) kepada akun layanan.

Jika Anda menjalankan Kubernetes non-GKE, Anda harus meneruskan kredensial secara eksplisit ke pengumpul 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 dicakup ke satu Google Cloud project. 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, pertimbangkan untuk mengonfigurasi akun layanan khusus agar Anda dapat menambahkan izin monitoring.timeSeries.create dengan aman untuk beberapa project. Jika Anda tidak dapat memberikan izin ini, Anda dapat menggunakan pelabelan ulang metrik untuk menulis ulang label project_id menjadi nama lain. Project ID kemudian akan ditetapkan secara default ke project tempat server Prometheus atau evaluator aturan Anda berjalan. Google Cloud

Konfigurasi pengambilan data tidak valid

Jika Anda melihat error berikut, PodMonitoring atau ClusterPodMonitoring Anda tidak terbentuk 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 diformat dengan benar sesuai dengan spesifikasi.

Webhook penerimaan tidak dapat mengurai atau mengonfigurasi klien HTTP yang tidak valid

Pada Managed Service for Prometheus versi sebelum 0.12, Anda mungkin melihat error yang mirip dengan berikut ini, yang terkait dengan injeksi rahasia di namespace non-default:

• "admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" denied the request: invalid definition for endpoint with index 0: unable to parse or invalid Prometheus HTTP client config: must use namespace "my-custom-namespace", got: "default"" (webhook penerimaan "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", yang didapatkan: "default")

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

Masalah terkait interval dan waktu tunggu pengambilan data

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 data lebih besar daripada interval pengambilan data untuk konfigurasi pengambilan data dengan nama tugas "PodMonitoring/gmp-system/example-app/go-metrics""

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

TYPE tidak ada pada metrik

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

• "no metadata found for metric name "{metric_name}"" (tidak ada metadata yang ditemukan untuk nama metrik "{metric_name}")

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

# TYPE {metric_name} <type>

Library tertentu, seperti yang berasal dari VictoriaMetrics versi lebih lama dari 1.28.0, sengaja menghilangkan 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 pengumpul yang mencoba menulis ke deret waktu yang sama:

• "One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric." (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: Titik harus ditulis secara berurutan. Satu atau beberapa titik yang ditentukan memiliki waktu berakhir 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 data dengan ketersediaan tinggi tradisional. Menggunakan konfigurasi ini dapat membuat beberapa pengumpul yang mencoba menulis data ke deret waktu yang sama, sehingga menyebabkan error ini.

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

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

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

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

Melampaui batas jumlah label

Jika Anda melihat error berikut, berarti Anda mungkin telah menentukan terlalu banyak label 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 set kunci label independen selama masa aktif metrik Anda. Cloud Monitoring memberlakukan batas pada jumlah label untuk setiap metrik; untuk mengetahui informasi selengkapnya, lihat batas untuk metrik yang ditentukan pengguna.

Catatan: Jumlah label (juga disebut nama label, kunci label, atau dimensi) berbeda dengan kardinalitas. Kardinalitas mengacu pada jumlah kombinasi nilai label unik di semua label.

Ada tiga langkah untuk mengatasi masalah ini:

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

   • Anda dapat menggunakan widget APIs Explorer di halaman metricDescriptors.list untuk memanggil metode. Untuk mengetahui informasi selengkapnya, lihat APIs Explorer. Untuk melihat contoh, lihat Mencantumkan metrik dan jenis resource.

2. Atasi sumber masalahnya, yang mungkin melibatkan penyesuaian aturan pelabelan ulang PodMonitoring, mengubah eksportir, atau memperbaiki instrumentasi Anda.

3. Hapus deskriptor metrik untuk metrik ini (yang menyebabkan kehilangan data), sehingga dapat dibuat ulang dengan set label yang lebih kecil dan 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 dan variabel lingkungan tambahan atau agen DataDog, yang menyisipkan anotasi dinamis.

  Untuk mengatasinya, Anda dapat menggunakan bagian metricRelabeling di PodMonitoring untuk mempertahankan atau menghapus label. Beberapa aplikasi dan eksportir juga memungkinkan 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 pelabelan 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 frekuensi pembuatan dan pembaruan metrik dan label

Jika Anda melihat error berikut, berarti Anda telah mencapai batas kecepatan per menit dalam 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 frekuensi 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 kecepatan untuk memproses titik data. Batas frekuensi ini hanya berlaku saat membuat metrik yang belum pernah dilihat sebelumnya atau saat menambahkan label baru ke metrik yang ada.

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

Batasan jumlah deskriptor metrik

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

• "Kuota deskriptor metrik Anda telah habis."

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

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

Baik 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 langsung, eksportir tertentu, seperti eksportir StatsD, eksportir 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 langkah-langkah berikut:

1. Di dalam konsol Google Cloud , pilih project Google Cloud yang terkait dengan error.

2. Di konsol Google Cloud , buka halaman  Pengelolaan metrik:

   Buka Pengelolaan metrik

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

3. Konfirmasi bahwa jumlah metrik Aktif ditambah Tidak aktif lebih dari 25.000. Dalam sebagian besar situasi, Anda akan melihat sejumlah besar metrik Tidak Aktif.
4. Pilih "Nonaktif" di panel Quick Filters, lihat daftar, dan cari pola.
5. Pilih "Aktif" di panel Filter Cepat, urutkan menurut Volume yang dapat ditagih sampel menurun, buka daftar, dan cari pola.
6. Urutkan menurut Volume yang dapat ditagih untuk sampel dari yang terkecil, lihat daftar, dan cari pola.

Atau, Anda dapat mengonfirmasi masalah ini menggunakan Metrics Explorer:

1. Di dalam konsol Google Cloud , pilih project Google Cloud yang terkait dengan 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 "Aktif".
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 mengurangi masalah ini dengan memperbaiki eksportir di sumber, lalu menghapus deskriptor metrik yang bermasalah.

Untuk mencegah masalah ini terjadi lagi, Anda harus mengonfigurasi pengekspor yang relevan terlebih dahulu agar tidak lagi memancarkan metrik yang salah format. Sebaiknya Anda membaca dokumentasi eksportir 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 yang salah bentuk menggunakan metode projects.metricDescriptors.delete. Untuk mengulangi daftar metrik yang salah bentuk dengan lebih mudah, kami menyediakan skrip Golang yang dapat Anda gunakan. Skrip ini menerima ekspresi reguler yang dapat mengidentifikasi metrik yang salah format dan menghapus deskripsi metrik yang cocok dengan pola tersebut. Karena penghapusan metrik tidak dapat dibatalkan, sebaiknya jalankan skrip terlebih dahulu menggunakan mode uji coba.

Beberapa metrik tidak ada untuk target yang berjalan singkat

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

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

1. Temukan file yaml deployment cron job dan temukan statusnya, yang dicantumkan 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, berarti tugas tidak berjalan cukup lama agar data metrik dapat di-scrap secara konsisten.

   Untuk mengatasi situasi ini, coba langkah-langkah berikut:

   • Konfigurasi tugas untuk memastikan tugas tidak keluar hingga setidaknya lima menit telah berlalu sejak tugas dimulai.

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

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

3. Jika waktu proses lebih dari lima menit atau tidak konsisten, lihat bagian Target tidak sehat dalam dokumen ini.

Masalah terkait pengumpulan dari eksportir

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

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

  Misalnya, untuk memeriksa apakah pod dengan pemilih app.kubernetes.io/name=redis di namespace test memancarkan metrik di endpoint /metrics pada port 9121, Anda dapat meneruskan port 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 diekspos oleh exporter untuk scraping.

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

• Pastikan pengumpul terkelola dapat meng-scrape eksportir dengan memeriksa antarmuka web Prometheus yang diekspos oleh pengumpul.

  1. Identifikasi pengumpul terkelola yang berjalan di node yang sama dengan tempat pengekspor Anda berjalan. Misalnya, jika pengekspor Anda berjalan di pod dalam namespace test dan pod diberi label app.kubernetes.io/name=redis, perintah berikut mengidentifikasi pengumpul 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 pengumpul 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 pengumpul terkelola Anda berhasil meng-scraping pengekspor.

Error Collector Out Of Memory (OOM)

Jika Anda menggunakan pengumpulan terkelola dan mengalami error Kehabisan Memori (OOM) pada pengumpul, pertimbangkan untuk mengaktifkan penskalaan otomatis pod vertikal.

Error Operator Out Of Memory (OOM)

Jika Anda menggunakan kumpulan 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.

Terlalu banyak deret waktu atau peningkatan respons 503 dan error batas waktu konteks terlampaui, terutama selama beban puncak

Anda mungkin juga mengalami masalah ini jika melihat pesan error berikut:

• "Resource yang dipantau (abcdefg) memiliki terlalu banyak deret waktu (metrik prometheus)"

"Context deadline exceeded" adalah error 503 umum yang ditampilkan dari Monarch untuk masalah sisi penyerapan yang tidak memiliki penyebab spesifik. Sejumlah kecil error "context deadline exceeded" diperkirakan akan terjadi dengan penggunaan sistem yang normal.

Namun, Anda mungkin melihat pola peningkatan error "context deadline exceeded" yang berdampak signifikan pada penyerapan data Anda. Salah satu kemungkinan penyebab utamanya adalah Anda mungkin salah menetapkan label target. Hal ini lebih mungkin terjadi jika hal berikut berlaku:

• Error "Context deadline exceeded" Anda memiliki pola siklus, yang meningkat selama waktu beban tinggi untuk Anda atau waktu beban tinggi untuk Google Cloud wilayah yang ditentukan oleh label location Anda.
• Anda melihat lebih banyak error saat Anda mengaktifkan lebih banyak volume metrik ke layanan.
• Anda menggunakan statsd_exporter untuk Prometheus, Envoy untuk Istio, SNMP exporter, Prometheus Pushgateway, kube-state-metrics, atau Anda memiliki exporter serupa yang memediasi dan melaporkan metrik atas nama resource lain yang berjalan di lingkungan Anda. Masalah hanya terjadi untuk metrik yang dikeluarkan oleh jenis pengekspor ini.
• Anda melihat bahwa metrik yang terpengaruh cenderung memiliki string localhost dalam nilai untuk label instance, atau hanya ada sedikit nilai untuk label instance.
• Jika memiliki akses ke UI kueri pengumpul Prometheus dalam cluster, Anda dapat melihat bahwa metrik berhasil dikumpulkan.

Jika poin-poin ini benar, kemungkinan eksportir Anda telah salah mengonfigurasi label resource dengan cara yang bertentangan dengan persyaratan Monarch.

Monarch melakukan penskalaan dengan menyimpan data terkait bersama-sama dalam target. Target untuk Managed Service for Prometheus ditentukan oleh jenis resource prometheus_target dan label project_id, location, cluster, namespace, job, dan instance. Untuk mengetahui informasi selengkapnya tentang label ini dan perilaku default, lihat Label yang dicadangkan di Koleksi Terkelola atau Label yang dicadangkan di koleksi yang di-deploy sendiri.

Dari label ini, instance adalah kolom target tingkat terendah dan oleh karena itu paling penting untuk diisi dengan benar. Penyimpanan dan kueri metrik yang efisien di Monarch memerlukan target yang relatif kecil dan beragam, idealnya berukuran sekitar VM atau container biasa. Saat menjalankan Managed Service for Prometheus dalam skenario umum, perilaku default open source yang ada di dalam pengumpul biasanya memilih nilai yang baik untuk label job dan instance, itulah sebabnya topik ini tidak dibahas di tempat lain dalam dokumentasi.

Namun, logika default mungkin gagal saat Anda menjalankan eksportir yang melaporkan metrik atas nama resource lain di cluster Anda, seperti statsd_exporter. Daripada menetapkan nilai instance ke IP:port resource yang memancarkan metrik, nilai instance ditetapkan ke IP:port statsd_exporter itu sendiri. Masalah ini dapat diperparah oleh label job, karena alih-alih terkait dengan paket atau layanan metrik, label ini juga kurang beragam karena ditetapkan ke statsd-exporter.

Jika hal ini terjadi, semua metrik yang berasal dari eksportir ini dalam cluster dan namespace tertentu akan ditulis ke target Monarch yang sama. Saat target ini semakin besar, penulisan mulai gagal, dan Anda melihat peningkatan error 503 "Batas waktu konteks terlampaui".

Anda bisa mendapatkan verifikasi bahwa hal ini terjadi pada Anda dengan menghubungi Cloud Customer Care dan meminta mereka untuk memeriksa "log rawat inap Monarch Quarantiner". Sertakan nilai yang diketahui untuk enam label khusus dalam tiket Anda. Pastikan untuk melaporkan project Google Cloud yang mengirimkan data, bukan project Google Cloud cakupan metrik Anda.

Untuk memperbaiki masalah ini, Anda harus mengubah pipeline pengumpulan data agar menggunakan lebih banyak label target yang beragam. Beberapa potensi strategi, yang tercantum berdasarkan urutan efektivitasnya, meliputi:

• Daripada menjalankan eksportir pusat yang melaporkan metrik atas nama semua VM atau node, jalankan eksportir terpisah untuk setiap VM sebagai agen node atau dengan men-deploy eksportir sebagai Daemonset Kubernetes. Untuk menghindari penetapan label instance ke localhost, jangan jalankan eksportir di node yang sama dengan pengumpul Anda.
  • Jika, setelah membagi pengekspor, Anda masih memerlukan lebih banyak keragaman target, jalankan beberapa pengekspor di setiap VM dan tetapkan secara logis berbagai set metrik ke setiap pengekspor. Kemudian, alih-alih menemukan tugas menggunakan nama statis statsd-exporter, gunakan nama tugas yang berbeda untuk setiap kumpulan metrik logis. Instance dengan nilai job yang berbeda akan ditetapkan ke target yang berbeda di Monarch.
  • Jika Anda menggunakan kube-state-metrics, gunakan sharding horizontal bawaan untuk membuat lebih banyak keragaman target. Eksporter lain mungkin memiliki kemampuan yang serupa.
• Jika Anda menggunakan OpenTelemetry atau pengumpulan yang di-deploy sendiri, gunakan aturan pelabelan ulang untuk mengubah nilai instance dari IP:Port atau nama eksportir menjadi IP:Port atau nama unik resource yang menghasilkan metrik. Kemungkinan besar Anda sudah merekam IP:Port atau nama resource asal sebagai label metrik. Anda juga harus menetapkan kolom honor_labels ke true dalam konfigurasi Prometheus atau OpenTelemetry.
• Jika Anda menggunakan OpenTelemetry atau pengumpulan yang di-deploy sendiri, gunakan aturan pelabelan ulang dengan fungsi hashmod untuk menjalankan beberapa tugas pengambilan data terhadap eksportir yang sama dan memastikan bahwa label instance yang berbeda dipilih untuk setiap konfigurasi pengambilan data.

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, maka kemungkinan besar penyebabnya adalah konfigurasi eksportir metrik atau konfigurasi pengambilan data Anda tidak dikonfigurasi dengan benar. Managed Service for Prometheus tidak mengirimkan data deret waktu apa pun kecuali jika Anda terlebih dahulu menerapkan konfigurasi pengambilan yang valid.

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

Akar masalahnya bisa disebabkan oleh berbagai hal. Sebaiknya periksa hal-hal berikut:

• PodMonitoring Anda mereferensikan port yang valid.

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

• Pemilih Anda (paling umum 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 Anda ambil datanya. 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. Managed Service for Prometheus tidak mendukung nama label yang diawali dengan karakter _.

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

• Jika dijalankan 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 dihilangkan tanpa pemberitahuan.

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 tentang 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 pelabelan ulang yang memengaruhi banyak metrik yang berbeda. Penghapusan ini menyebabkan terbentuknya antrean pembaruan pada deskriptor metrik di project Anda. Error akan hilang saat antrean diproses.

Untuk mengetahui informasi selengkapnya, lihat Batasan dalam membuat dan memperbarui metrik dan 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: Dibatalkan karena jumlah kueri yang evaluasinya diblokir karena menunggu memori adalah 501, yang sama dengan atau lebih besar dari batas 500."

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

Anda mungkin mencapai batas ini jika mengeluarkan banyak kueri serentak yang berjalan 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 periode lihat kembali kueri, semakin lambat kueri tersebut dieksekusi.

Biasanya masalah ini dipicu oleh menjalankan banyak aturan lookback panjang dengan cara yang tidak efisien. Misalnya, Anda mungkin memiliki banyak aturan yang berjalan sekali setiap menit dan meminta tarif 4 minggu. Jika setiap aturan ini membutuhkan waktu yang lama untuk dijalankan, pada akhirnya hal ini dapat menyebabkan penumpukan kueri yang menunggu untuk dijalankan untuk project Anda, yang kemudian menyebabkan Monarch membatasi kueri.

Untuk mengatasi masalah ini, Anda perlu meningkatkan interval evaluasi aturan long-lookback agar tidak berjalan setiap 1 menit. Menjalankan kueri untuk tarif 4 minggu setiap 1 menit tidak diperlukan; ada 40.320 menit dalam 4 minggu, jadi setiap menit hampir tidak memberikan sinyal tambahan (data Anda paling banyak berubah 1/40.320). Menggunakan interval evaluasi 1 jam sudah cukup untuk kueri yang meminta tarif 4 minggu.

Setelah Anda mengatasi hambatan yang disebabkan oleh kueri yang berjalan lama dan tidak efisien yang dieksekusi terlalu sering, masalah ini akan teratasi dengan sendirinya.

Jenis nilai tidak kompatibel

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

• "Jenis nilai untuk metrik prometheus.googleapis.com/metric_name/gauge harus berupa INT64, tetapi DOUBLE"
• "Jenis nilai untuk metrik prometheus.googleapis.com/metric_name/gauge harus DOUBLE, tetapi INT64"
• "One or more TimeSeries could not be written: Value type for metric prometheus.googleapis.com/target_info/gauge conflicts with the existing value type (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 saat penyerapan, karena Monarch tidak mendukung penulisan data berjenis DOUBLE ke metrik berjenis INT64 dan tidak mendukung penulisan data berjenis INT64 ke metrik berjenis DOUBLE. Anda juga mungkin 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 dalam project lain.

Error ini hanya terjadi jika Anda memiliki pengumpul OpenTelemetry yang melaporkan data, dan kemungkinan besar terjadi jika Anda memiliki OpenTelemetry (menggunakan pengekspor googlemanagedprometheus) dan Prometheus yang melaporkan data untuk metrik yang sama seperti yang biasanya terjadi untuk metrik target_info.

Penyebabnya kemungkinan salah satu dari berikut ini:

• Anda mengumpulkan metrik OTLP, dan library metrik OTLP mengubah jenis nilainya dari DOUBLE menjadi INT64, seperti yang terjadi pada 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. Kolektor Anda kini menulis dua jenis nilai ke metrik yang sama dalam project yang sama, dan hanya kolektor yang pertama kali membuat deskriptor 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 mengueri metrik tersebut melalui cakupan metrik, menyebabkan gabungan yang tidak valid antara jenis nilai metrik yang tidak kompatibel.

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

1. Konfigurasi ulang pengumpul OpenTelemetry Anda untuk memaksa semua metrik menjadi DOUBLE dengan mengaktifkan tanda feature-gate exporter.googlemanagedprometheus.intToDouble.
2. Hapus semua deskriptor metrik INT64 dan biarkan deskriptor tersebut dibuat ulang sebagai DOUBLE. Anda dapat menggunakan delete_metric_descriptors.go skrip 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.