Memecahkan masalah Monitoring API

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

Monitoring API adalah salah satu dari serangkaian 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 bagian Menangani error.

Menggunakan APIs Explorer untuk proses debug

APIs Explorer adalah widget yang dibuat di 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 saat pemanggilan metode, gunakan widget APIs Explorer (Coba API ini) di halaman referensi untuk metode tersebut guna men-debug masalah Anda. Untuk mengetahui informasi selengkapnya, lihat APIs Explorer.

Error API umum

Berikut 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": Sebagian URL salah. Bandingkan URL dengan URL untuk metode yang ditampilkan di halaman referensi metode. Error ini mungkin berarti ada kesalahan ejaan, seperti "project" dan bukan "projects", atau kesalahan penggunaan huruf besar, seperti "TimeSeries" dan bukan "timeSeries".

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

    Jika Anda tidak menggunakan APIs Explorer, coba gunakan. Jika panggilan API Anda berfungsi di APIs Explorer, kemungkinan 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 Memantau Filter.

  • 400 INVALID_ARGUMENT dengan "Request was missing field interval.endTime": Anda melihat pesan ini saat waktu berakhir tidak ada, atau saat waktu berakhir 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

Jika 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 verifikasi bahwa Anda mendapatkan hasil. Tambahkan komponen filter lainnya satu per satu untuk membuat permintaan Anda.
  • Saat bekerja dengan metrik kustom, pastikan bahwa project yang menentukan metrik tersebut 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 disebarkan ke Monitoring. 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 berakhir. Jika waktu mulai tidak ada atau salah format, API akan menetapkan start-time ke end-time. Untuk metrik GAUGE, interval waktu ini hanya cocok dengan titik yang waktu mulai dan 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 lagi 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 yang bersifat sementara atau berlangsung singkat.
  • 429 RESOURCE_EXHAUSTED: percobaan ulang berguna, setelah penundaan, untuk pekerjaan latar belakang yang berjalan lama dengan kuota berbasis waktu seperti n panggilan 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 mentoleransi kegagalan. Untuk masalah terkait kuota, pertimbangkan untuk mengurangi penggunaan kuota atau meminta penambahan kuota.

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

Apakah permintaan aman untuk dicoba lagi?

Jika permintaan Anda bersifat idempoten, maka aman untuk mencoba lagi. Tindakan idempoten 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 nilai belum 10, tetapi nilai saat ini tidak menjadi masalah. Dan tidak masalah berapa kali Anda mencoba menetapkan nilai.
  • Penambahan x tidak bersifat 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. Jika sistem kelebihan beban, pendekatan ini akan memperparah masalah.

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

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

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

    Interval biasanya ditingkatkan dengan beberapa fungsi dari pangkat jumlah percobaan ulang, sehingga menjadikannya penundaan eksponensial.

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

Tabel berikut menunjukkan interval percobaan ulang menggunakan nilai awal:

  • Penundaan minimum = 1 dtk = 1000 md
  • Backoff awal = 2 md
Jumlah percobaan ulang Penundaan tambahan (milidetik) Coba lagi setelah (mdtk)
0 20 = 1 1001
1 21 = 2 1002
2 22 = 4 1004
3 23 = 8 1008
4 24 = 16 1016
... ... ...
n 2n 1000 + 2n

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

Untuk mengetahui informasi selengkapnya, lihat artikel Wikipedia tentang Backoff eksponensial.