Memecahkan masalah Monitoring API

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

Monitoring API adalah salah satu rangkaian Cloud API. API ini berbagi kumpulan kode error yang umum. Untuk mengetahui daftar kode error yang ditentukan oleh Cloud API dan saran umum terkait penanganan error, baca bagian Menangani error.

Menggunakan APIs Explorer untuk proses debug

APIs Explorer adalah widget yang dibangun ke dalam halaman referensi untuk metode API. Ini memungkinkan Anda memanggil metode dengan mengisi kolom; tanpa mengharuskan Anda menulis kode.

Jika Anda mengalami masalah dengan pemanggilan metode, gunakan widget APIs Explorer (Try this API) di halaman referensi untuk metode tersebut guna men-debug masalah Anda. Untuk mengetahui 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 dapat berarti adanya error ejaan, seperti "project", bukan "projects", atau error kapitalisasi, seperti "TimeSeries", 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 di project ID atau nama jenis metrik. Periksa ejaan dan kapitalisasi.

    Jika Anda tidak menggunakan APIs Explorer, coba gunakan API tersebut. Jika panggilan API Anda berfungsi di APIs Explorer, mungkin ada masalah otorisasi di lingkungan tempat Anda melakukan panggilan API. Buka halaman pengelola API untuk memastikan Monitoring API diaktifkan untuk project Anda.

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

  • 400 INVALID_ARGUMENT dengan "Request was missing field interval.endTime"": Anda akan melihat pesan ini saat waktu berakhir tidak ada, atau jika ada, tetapi tidak diformat dengan benar. Jika Anda menggunakan Penjelajah API, jangan mengutip 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:

  • Saat panggilan menggunakan filter, filter mungkin tidak cocok dengan apa pun. Pencocokan filter peka huruf besar/kecil. Untuk mengatasi masalah filter, mulai dengan menentukan satu komponen filter saja, seperti metric.type, dan verifikasi bahwa Anda mendapatkan hasilnya. Tambahkan komponen filter lainnya satu per satu untuk membuat permintaan Anda.
  • Saat menggunakan metrik kustom, pastikan bahwa project yang menentukan metrik tersebut telah ditentukan.

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

  • Datanya mungkin telah usang. Untuk mengetahui informasi selengkapnya, lihat Retensi data.

  • Data mungkin belum disebarkan ke Monitoring. Untuk mengetahui informasi selengkapnya, lihat Latensi data metrik.

  • Interval tidak valid:

    • Verifikasi bahwa 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 waktu mulai ke waktu berakhir. Untuk metrik GAUGE, interval waktu ini hanya cocok dengan titik yang waktu mulai dan berakhir persis dengan waktu berakhir interval. Untuk metrik CUMULATIVE atau DELTA yang mengukur di berbagai interval waktu, tidak ada titik yang cocok. Untuk informasi selengkapnya, lihat Interval waktu.

Mencoba ulang error API

Dua kode error Cloud API menunjukkan keadaan di mana permintaan tersebut dapat dicoba ulang:

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

Saat menulis kode yang mungkin meminta ulang permintaan, pertama-tama pastikan bahwa permintaan tersebut aman untuk dicoba lagi.

Apakah permintaan aman untuk dicoba lagi?

Jika permintaan Anda bersifat idempoten, Anda dapat mencoba lagi dengan aman. Tindakan idempoten adalah tindakan saat perubahan status tidak bergantung pada status saat ini. Contoh:

  • Pembacaan x bersifat idempoten; tidak ada perubahan pada nilai.
  • Menetapkan x ke 10 bersifat idempoten. Ini dapat mengubah status, jika nilainya belum 10, tetapi berapa pun nilai saat ini tidak penting. Selain itu, 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 mengimplementasikan kode untuk mencoba ulang permintaan, Anda tidak ingin mengeluarkan permintaan baru dengan cepat tanpa batas. Jika sistem kelebihan beban, pendekatan ini akan berkontribusi pada masalah.

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

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

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

    Interval biasanya ditingkatkan oleh beberapa fungsi daya jumlah percobaan ulang, menjadikannya backoff eksponensial.

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

Tabel berikut menunjukkan interval percobaan ulang menggunakan nilai awal:

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

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

Untuk informasi selengkapnya, lihat artikel Wikipedia Backoff eksponensial.