Memecahkan masalah Monitoring API

Panduan ini menjelaskan beberapa masalah yang mungkin muncul saat Anda menggunakan Monitoring API.

Monitoring API adalah salah satu kumpulan Cloud API. API ini memiliki serangkaian kode error yang sama. Untuk mengetahui daftar kode error yang ditentukan oleh Cloud API dan saran umum tentang penanganan error, lihat Menangani error.

Menggunakan API Explorer untuk proses debug

API Explorer adalah widget yang disertakan dalam halaman referensi untuk metode API. Dengan bantuan tombol ini, Anda dapat memanggil metode dengan mengisi kolom; Anda tidak perlu menulis kode.

Jika Anda mengalami masalah dengan pemanggilan metode, gunakan widget API Explorer (Coba API ini) di halaman referensi untuk metode tersebut guna men-debug masalah Anda. Untuk informasi selengkapnya, lihat APIs Explorer.

Error API umum

Berikut adalah beberapa error dan pesan Monitoring API yang mungkin Anda lihat dari panggilan API:

• 404 NOT_FOUND dengan "URL yang diminta tidak ditemukan di server ini": Beberapa bagian URL salah. Bandingkan URL dengan URL untuk metode yang ditampilkan di halaman referensi metode. Error ini mungkin berarti ada kesalahan ejaan, seperti "project", bukan "projects", atau kesalahan penggunaan huruf besar, seperti "TimeSeries", bukan "timeSeries".

• 401 UNAUTHENTICATED dengan "Pengguna tidak diberi otorisasi untuk mengakses project (atau metrik)": Kode error ini biasanya menunjukkan masalah otorisasi, tetapi dapat berarti ada error dalam ID project atau nama jenis metrik. Verifikasi ejaan dan kapitalisasi.

  Jika Anda belum menggunakan API Explorer, coba gunakan. Jika panggilan API Anda berfungsi di API Explorer, mungkin ada masalah otorisasi di lingkungan tempat Anda melakukan panggilan API. Buka halaman pengelola API untuk memverifikasi bahwa Monitoring API diaktifkan untuk project Anda.

• 400 INVALID_ARGUMENT dengan "Filter kolom memiliki nilai yang tidak valid": Verifikasi ejaan dan format filter pemantauan. Untuk mengetahui informasi selengkapnya, lihat Filter Pemantauan.

• 400 INVALID_ARGUMENT dengan "Permintaan tidak memiliki kolom interval.endTime": Anda melihat pesan ini saat waktu berakhir tidak ada, atau saat ada tetapi tidak diformat dengan benar. Jika Anda menggunakan API Explorer, jangan kutip nilai kolom waktu.

  Berikut beberapa contoh spesifikasi waktu yang valid:

  2024-05-11T01:23:45Z
  2024-05-11T01:23:45.678Z
  2024-05-11T01:23:45.678+05:00
  2024-05-11T01:23:45.678-04:30
  

Hasil tidak ada

Saat panggilan API menampilkan kode status 200 dan respons kosong, pertimbangkan hal berikut:

• Jika panggilan menggunakan filter, filter mungkin tidak cocok dengan apa pun. Pencocokan filter peka huruf besar/kecil. Untuk mengatasi masalah filter, mulailah dengan menentukan hanya satu komponen filter, seperti metric.type, dan pastikan Anda mendapatkan hasil. Tambahkan komponen filter lainnya satu per satu untuk membuat permintaan Anda.

• Saat menggunakan metrik kustom, pastikan project yang menentukan metrik telah ditentukan.

Ada beberapa alasan mengapa titik data mungkin tidak ada saat Anda menggunakan metode timeSeries.list:

• Data mungkin sudah tidak berlaku. Untuk mengetahui informasi selengkapnya, lihat Retensi data.

• Data mungkin belum diterapkan ke Pemantauan. Untuk mengetahui informasi selengkapnya, lihat Latensi data metrik.

• Interval tidak valid:

  • Pastikan waktu berakhir sudah benar.
  • Pastikan waktu mulai sudah benar dan lebih awal dari waktu akhir. Jika waktu mulai tidak ada atau salah format, API akan menetapkan waktu mulai ke waktu berakhir. Untuk metrik GAUGE, interval waktu ini hanya cocok dengan titik yang waktu mulai dan waktu akhirnya sama persis dengan waktu akhir interval. Untuk metrik CUMULATIVE atau DELTA, yang mengukur di seluruh interval waktu, tidak ada titik yang cocok. Untuk mengetahui informasi selengkapnya, lihat Interval waktu.

Mencoba ulang error API

Dua kode error Cloud API menunjukkan situasi yang mungkin berguna untuk mencoba ulang permintaan:

• 503 UNAVAILABLE: percobaan ulang berguna jika masalahnya adalah kondisi sementara atau bersifat sementara.
• 429 RESOURCE_EXHAUSTED: percobaan ulang berguna, setelah penundaan, untuk pekerjaan latar belakang yang berjalan lama dengan kuota berbasis waktu seperti panggilan n per t detik. Percobaan ulang tidak berguna jika masalahnya adalah kondisi sementara atau berumur pendek, atau jika Anda telah menghabiskan kuota berbasis volume. Untuk kondisi sementara, pertimbangkan untuk menoleransi kegagalan. Untuk masalah terkait kuota, pertimbangkan untuk mengurangi penggunaan kuota atau meminta penambahan kuota.

Saat menulis kode yang mungkin mencoba ulang permintaan, pastikan terlebih dahulu bahwa permintaan tersebut aman untuk dicoba ulang.

Apakah permintaan aman untuk dicoba ulang?

Jika permintaan Anda idempoten, Anda dapat mencobanya lagi dengan aman. Tindakan idempotent adalah tindakan yang perubahan statusnya tidak bergantung pada status saat ini. Contoh:

• Membaca x bersifat idempoten; tidak ada perubahan pada nilai.
• Menetapkan x ke 10 bersifat idempoten; hal ini dapat mengubah status, jika nilainya belum 10, tetapi tidak masalah nilai saat ini. Dan tidak masalah berapa kali Anda mencoba menetapkan nilai.
• Menambahkan x tidak idempoten; nilai baru bergantung pada nilai saat ini.

Mencoba lagi dengan backoff eksponensial

Saat menerapkan kode untuk mencoba ulang permintaan, Anda tidak ingin mengeluarkan permintaan baru dengan cepat tanpa batas waktu. Jika sistem kelebihan beban, pendekatan ini akan berkontribusi pada masalah.

Sebagai gantinya, gunakan pendekatan backoff eksponensial terpotong. Jika permintaan gagal karena kelebihan beban sementara, bukan karena ketidaktersediaan yang sebenarnya, solusinya adalah mengurangi beban. Backoff eksponensial terpotong mengikuti pola umum ini:

• Tentukan berapa lama Anda bersedia menunggu saat mencoba lagi atau berapa banyak upaya yang bersedia Anda lakukan. Jika batas ini terlampaui, anggap layanan tidak tersedia dan tangani kondisi tersebut dengan tepat untuk aplikasi Anda. Hal inilah yang membuat backoff terpotong; Anda berhenti mencoba ulang pada suatu titik.

• Coba lagi permintaan dengan jeda yang semakin lama untuk menunda frekuensi percobaan ulang. Coba lagi hingga permintaan berhasil atau batas yang Anda tetapkan tercapai.

  Interval biasanya ditingkatkan oleh beberapa fungsi dari pangkat jumlah percobaan ulang, sehingga menjadi backoff eksponensial.

Ada banyak cara untuk menerapkan backoff eksponensial. Berikut adalah contoh yang menambahkan penundaan backoff yang meningkat ke penundaan minimum 1.000 md. Penundaan backoff awal adalah 2 md, dan akan meningkat menjadi 2^retry_count md dengan setiap percobaan.

Tabel berikut menunjukkan interval percobaan ulang menggunakan nilai awal:

• Penundaan minimum = 1 detik = 1.000 md
• Backoff awal = 2 md

Jumlah percobaan ulang	Penundaan tambahan (milidetik)	Coba lagi setelah (mdtk)
0	2^0 = 1	1001
1	2^1 = 2	1002
2	2^2 = 4	1004
3	2^3 = 8	1008
4	2^4 = 16	1016
...	...	...
n	2^n	1000 + 2^n

Anda dapat memotong siklus percobaan ulang dengan berhenti setelah n percobaan atau saat waktu yang dihabiskan melebihi nilai yang wajar untuk aplikasi Anda.

Untuk informasi selengkapnya, lihat artikel Backoff eksponensial di Wikipedia.