Memecahkan masalah monitor sintetis dan cek uptime

Dokumen ini memberikan informasi tentang cara menemukan data log dan cara memecahkan masalah kegagalan monitor sintetis dan pemeriksaan uptime:

Menemukan log

Bagian ini memberikan informasi tentang cara menemukan log untuk pemantau sintetis dan pemeriksaan waktu aktif:

  1. Di konsol Google Cloud, buka halaman Logs Explorer:

    Buka Logs Explorer

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

  2. Lakukan salah satu tindakan berikut:

    • Untuk menemukan semua log yang terkait dengan monitor sintetis atau pemeriksaan uptime, buat kueri menurut jenis resource. Anda dapat menggunakan menu Resource atau memasukkan kueri.

      Untuk pemeriksaan uptime, di menu Resource, pilih Uptime Check URL, atau masukkan kueri berikut ke editor kueri, lalu klik Run query:

      resource.type="uptime_url"

      Untuk monitor sintetis, di menu Resource, pilih Cloud Run Revision, atau masukkan kueri berikut ke editor kueri, lalu klik Run query:

      resource.type="cloud_run_revision"

    • Log temuan yang berisi informasi tentang respons yang diterima selama pemantauan sintetis atau eksekusi pemeriksaan waktu aktif, lakukan salah satu hal berikut:

      • Untuk membuat kueri menggunakan ID monitor sintetis atau pemeriksaan uptime, gunakan format berikut saat memasukkan ID ke editor kueri, lalu klik Run query

        labels.check_id="my-check-id"

      • Untuk membuat kueri log yang berisi data respons untuk permintaan yang dikeluarkan oleh monitor sintetis dan pemeriksaan waktu aktif, masukkan kueri berikut ke editor kueri, lalu klik Run query

        "UptimeCheckResult"

        Kueri sebelumnya cocok dengan semua entri log yang menyertakan string "UptimeCheckResult".

      Log ini mencakup:

      • ID monitor sintetis atau pemeriksaan uptime, yang disimpan di kolom labels.check_id.

      • Untuk monitor sintetis, nama fungsi Cloud Run Anda, yang disimpan di kolom resource.labels.service_name.

      • Saat data rekaman aktivitas dikumpulkan, ID rekaman aktivitas terkait, yang disimpan di kolom trace.

    • Untuk memverifikasi bahwa layanan Anda menerima permintaan dari server Google Cloud, salin kueri berikut ke editor kueri, lalu klik Jalankan kueri:

      "GoogleStackdriverMonitoring-UptimeChecks"

      Kolom protoPayload.ip berisi salah satu alamat yang digunakan oleh server pemeriksaan waktu aktif. Untuk mengetahui informasi tentang cara mencantumkan semua alamat IP, lihat Mencantumkan alamat IP.

Memecahkan masalah notifikasi

Bagian ini menjelaskan beberapa error yang mungkin Anda alami saat mengonfigurasi kebijakan pemberitahuan dan memberikan informasi untuk mengatasinya.

Satu pemeriksa gagal, tetapi yang lainnya tidak

Anda meninjau metrik pemeriksaan uptime dan melihat bahwa satu pemeriksa melaporkan kegagalan saat semua pemeriksa lainnya melaporkan keberhasilan.

Anda tidak perlu melakukan tindakan apa pun untuk menyelesaikan situasi ini.

Jika hanya satu pemeriksa yang melaporkan kegagalan, kegagalan tersebut mungkin disebabkan oleh waktu tunggu perintah pemeriksa yang habis karena masalah jaringan. Artinya, perintah tidak gagal, tetapi tidak selesai dalam waktu tunggu yang ditentukan.

Kebijakan pemberitahuan yang menggunakan konfigurasi default memerlukan kegagalan dari setidaknya dua pemeriksa sebelum membuat insiden dan mengirim notifikasi. Kegagalan yang dilaporkan oleh satu pemeriksa tidak akan menghasilkan notifikasi.

Anda menerima notifikasi dan ingin men-debug kegagalan

  1. Untuk mengidentifikasi kapan kegagalan dimulai, lakukan salah satu tindakan berikut:

    • Untuk pemeriksaan uptime, guna menentukan kapan kegagalan terjadi, lihat halaman Detail uptime:

      1. Di konsol Google Cloud, buka halaman  Pemeriksaan waktu aktif:

        Buka Cek uptime

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

      2. Cari dan pilih pemeriksaan uptime.

        Diagram Pemeriksaan yang lulus menampilkan histori pemeriksaan. Untuk mengidentifikasi kapan pemeriksaan uptime pertama kali gagal, Anda mungkin perlu mengubah rentang waktu untuk diagram. Pemilih rentang waktu berada di toolbar halaman Detail waktu aktif.

    • Untuk monitor sintetis, guna menentukan kapan kegagalan terjadi, lihat halaman Detail uptime:

      1. Di konsol Google Cloud, buka halaman  Synthetic monitoring:

        Buka Pemantauan sintetis

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

      2. Cari dan pilih monitor sintetis.

  2. Untuk mengetahui informasi tentang cara menemukan data log terkait, lihat bagian halaman ini yang berjudul Menemukan log.

Anda tidak diberi tahu bahwa cek uptime gagal

Anda telah mengonfigurasi cek uptime dan melihat halaman Detail uptime untuk pemeriksaan tersebut. Anda melihat bahwa grafik Pemeriksaan yang lulus menunjukkan bahwa setidaknya satu pemeriksa gagal. Namun, Anda tidak menerima notifikasi.

Secara default, kebijakan pemberitahuan dikonfigurasi untuk membuat insiden dan mengirim notifikasi saat pemeriksa di minimal dua region gagal menerima respons terhadap pemeriksaan uptime. Kegagalan ini harus terjadi secara bersamaan.

Anda dapat mengedit kondisi kebijakan pemberitahuan sehingga Anda akan diberi tahu saat satu region gagal menerima respons. Namun, sebaiknya Anda menggunakan konfigurasi default, yang akan mengurangi jumlah notifikasi yang mungkin Anda terima karena kegagalan sementara.

Untuk melihat atau mengedit kebijakan pemberitahuan, lakukan tindakan berikut:

  1. Di konsol Google Cloud, buka halaman  Alerting:

    Buka Pemberitahuan

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

  2. Klik Lihat semua kebijakan di panel Kebijakan.

  3. Temukan kebijakan yang ingin Anda lihat atau edit, lalu klik nama kebijakan.

    Anda dapat melihat dan mengedit kebijakan dari halaman Detail kebijakan.

Memecahkan masalah cek uptime publik

Bagian ini menjelaskan beberapa error yang mungkin Anda temui saat menggunakan pemeriksaan waktu aktif publik dan memberikan informasi untuk mengatasinya.

Cek uptime publik Anda gagal

Anda mengonfigurasi pemeriksaan uptime publik, tetapi menerima error saat melakukan langkah verifikasi.

Berikut adalah beberapa kemungkinan penyebab kegagalan pemeriksaan waktu aktif:

  • Error Koneksi - Ditolak: Jika Anda menggunakan jenis koneksi HTTP default, pastikan Anda telah menginstal server web yang merespons permintaan HTTP. Error koneksi dapat terjadi pada instance baru jika Anda belum menginstal server web; lihat Panduan memulai untuk Compute Engine. Jika menggunakan jenis koneksi HTTPS, Anda mungkin harus melakukan langkah-langkah konfigurasi tambahan. Untuk masalah firewall, lihat Mencantumkan alamat IP server cek uptime.
  • Nama atau layanan tidak ditemukan: Nama host mungkin salah.
  • 403 Dilarang: Layanan menampilkan kode error ke pemeriksa uptime. Misalnya, konfigurasi server web Apache default menampilkan kode ini di Amazon Linux, tetapi menampilkan kode 200 (Sukses) di beberapa versi Linux lainnya. Lihat tutorial LAMP untuk Amazon Linux atau dokumentasi server web Anda.
  • 404 Not found: Jalur mungkin salah.
  • 408 Waktu tunggu permintaan habis, atau tidak ada respons: Nomor port mungkin salah, layanan mungkin tidak berjalan, layanan mungkin tidak dapat diakses, atau waktu tunggu mungkin terlalu rendah. Pastikan firewall Anda mengizinkan traffic dari server uptime; lihat Mencantumkan alamat IP server cek uptime. Batas waktu tunggu ditentukan sebagai bagian dari opsi Validasi Respons.

Untuk membantu memecahkan masalah kegagalan cek uptime publik, Anda dapat mengonfigurasi cek uptime untuk mengirim hingga 3 ping ICMP selama pemeriksaan. Ping dapat membantu Anda membedakan antara kegagalan yang disebabkan, misalnya, oleh masalah konektivitas jaringan dan waktu tunggu habis di aplikasi Anda. Untuk informasi selengkapnya, lihat Menggunakan ping ICMP.

Memecahkan masalah cek uptime pribadi

Bagian ini menjelaskan beberapa error yang mungkin Anda alami saat menggunakan pemeriksaan waktu aktif pribadi dan memberikan informasi untuk mengatasinya.

Pembuatan cek uptime gagal

Setelan project Google Cloud Anda mungkin mencegah perubahan peran yang ditetapkan ke akun layanan yang digunakan pemeriksaan uptime untuk mengelola interaksi dengan layanan Service Directory. Dalam situasi ini, pembuatan pemeriksaan uptime akan gagal.

Bagian ini menjelaskan cara memberikan peran yang diperlukan akun layanan:

Konsol Google Cloud

Saat Anda menggunakan konsol Google Cloud untuk membuat pemeriksaan uptime pribadi, konsol Google Cloud akan mengeluarkan perintah untuk memberikan peran Direktori Layanan ke akun layanan.

Untuk mengetahui informasi tentang cara memberikan peran ke akun layanan, lihat Memberikan otorisasi ke akun layanan.

API: Cakupan project

Saat pertama kali membuat pemeriksaan uptime pribadi untuk layanan Direktori Layanan dan resource pribadi dalam satu project Google Cloud, permintaan mungkin berhasil atau gagal. Hasilnya bergantung pada apakah Anda telah menonaktifkan pemberian peran otomatis untuk akun layanan di project Anda:

  • Pembuatan pemeriksaan waktu aktif pertama berhasil jika project Anda mengizinkan pemberian peran otomatis untuk akun layanan. Akun layanan dibuat untuk Anda dan diberi peran yang diperlukan.

  • Pembuatan pemeriksaan waktu aktif pertama gagal jika project Anda tidak mengizinkan pemberian peran otomatis untuk akun layanan. Akun layanan dibuat, tetapi tidak ada peran yang diberikan.

Jika pembuatan pemeriksaan uptime gagal, lakukan hal berikut:

  1. Berikan otorisasi ke akun layanan.
  2. Tunggu beberapa menit hingga izin diterapkan.
  3. Coba buat lagi pemeriksaan uptime pribadi.

API: Project yang dipantau

Saat pertama kali Anda membuat pemeriksaan uptime pribadi yang menargetkan layanan Directory Layanan di project yang dipantau atau resource pribadi di project Google Cloud yang berbeda, permintaan akan gagal dan menghasilkan pembuatan akun layanan Monitoring.

Cara Anda memberikan otorisasi ke akun layanan bergantung pada jumlah project Google Cloud yang Anda gunakan dan hubungannya. Anda mungkin memiliki hingga empat project yang terlibat:

  • Project tempat Anda menentukan pemeriksaan uptime pribadi.
  • Project yang dipantau tempat Anda mengonfigurasi layanan Direktori Layanan.
  • Project tempat Anda mengonfigurasi jaringan VPC.
  • Project tempat resource jaringan seperti VM atau load balancer dikonfigurasi. Project ini tidak memiliki peran dalam otorisasi akun layanan yang dibahas di sini.

Jika pembuatan pemeriksaan uptime pertama gagal, lakukan tindakan berikut:

  1. Berikan otorisasi ke akun layanan.
  2. Tunggu beberapa menit hingga izin diterapkan.
  3. Coba buat lagi pemeriksaan uptime pribadi.

Akses ditolak

Pemeriksaan uptime Anda gagal dengan hasil VPC_ACCESS_DENIED. Hasil ini berarti beberapa aspek konfigurasi jaringan atau otorisasi akun layanan Anda salah.

Periksa otorisasi akun layanan Anda untuk menggunakan project cakupan atau project yang dipantau seperti yang dijelaskan dalam Pembuatan pemeriksaan waktu aktif gagal.

Untuk mengetahui informasi selengkapnya tentang cara mengakses jaringan pribadi, lihat Mengonfigurasi project jaringan.

Hasil yang tidak normal dari pemeriksaan uptime pribadi

Anda memiliki layanan Direktori Layanan dengan beberapa VM, dan konfigurasi layanan Anda berisi beberapa endpoint. Saat Anda menonaktifkan salah satu VM, pemeriksaan uptime masih menunjukkan keberhasilan.

Jika konfigurasi layanan Anda berisi beberapa endpoint, salah satu endpoint tersebut akan dipilih secara acak. Jika VM yang terkait dengan endpoint yang dipilih sedang berjalan, pemeriksaan uptime akan berhasil meskipun salah satu VM sedang tidak aktif.

Header default

Pemeriksaan uptime Anda menampilkan error atau hasil yang tidak terduga. Hal ini mungkin terjadi jika Anda telah mengganti nilai header default.

Saat permintaan dikirim untuk pemeriksaan uptime pribadi ke endpoint target, permintaan tersebut menyertakan header dan nilai berikut:

Header Nilai
HTTP_USER_AGENT GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
HTTP_CONNECTION keep-alive
HTTP_HOST IP endpoint Direktori Layanan
HTTP_ACCEPT_ENCODING gzip, deflate, br
CONTENT_LENGTH Dihitung dari data postingan uptime

Jika Anda mencoba mengganti nilai ini, hal berikut mungkin terjadi:

  • Pemeriksaan uptime melaporkan error
  • Nilai penggantian dihapus dan diganti dengan nilai dalam tabel

Tidak ada data yang terlihat

Anda tidak melihat data apa pun di dasbor pemeriksaan waktu beroperasi saat pemeriksaan waktu beroperasi berada di project Google Cloud yang berbeda dengan layanan Service Directory.

Pastikan project Google Cloud yang berisi pemeriksaan waktu aktif memantau project Google Cloud yang berisi layanan Direktori Layanan.

Untuk mengetahui informasi selengkapnya tentang cara mencantumkan project yang dipantau dan menambahkan project tambahan, lihat Mengonfigurasi cakupan metrik untuk beberapa project.

Memecahkan masalah monitor sintetis

Bagian ini memberikan informasi yang dapat Anda gunakan untuk membantu memecahkan masalah monitor sintetis.

Pesan error setelah mengaktifkan API

Anda membuka alur pembuatan untuk monitor sintetis dan diminta untuk mengaktifkan minimal satu API. Setelah Anda mengaktifkan API, pesan yang mirip dengan berikut ini akan ditampilkan:

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

Pesan error merekomendasikan agar Anda memverifikasi bahwa API diaktifkan, lalu menyarankan agar Anda menunggu dan mencoba kembali tindakan tersebut.

Untuk memverifikasi bahwa API sudah diaktifkan, buka halaman API & Layanan untuk project Anda:

Buka API & Layanan

Setelah memverifikasi bahwa API diaktifkan, Anda dapat melanjutkan dengan alur pembuatan. Kondisi ini akan otomatis diselesaikan setelah pengaktifan API diberlakukan melalui backend.

Permintaan HTTP keluar tidak dilacak

Anda mengonfigurasi monitor sintetis untuk mengumpulkan data rekaman aktivitas untuk permintaan HTTP output. Data rekaman aktivitas Anda hanya menampilkan satu span, mirip dengan screenshot berikut:

Cloud Trace hanya menampilkan satu rekaman aktivitas.

Untuk mengatasi situasi ini, pastikan akun layanan Anda telah diberi peran Cloud Trace Agent (roles/cloudtrace.agent). Peran Editor (roles/editor) juga sudah cukup.

Untuk melihat peran yang diberikan ke akun layanan Anda, 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. Pilih Sertakan pemberian peran yang disediakan Google.

  3. Jika akun layanan yang digunakan oleh monitor sintetis Anda tidak tercantum, atau jika akun layanan tersebut belum diberi peran yang menyertakan izin dalam peran Agen Cloud Trace (roles/cloudtrace.agent), berikan peran ini ke akun layanan Anda.

    Jika Anda tidak tahu nama akun layanan, di menu navigasi, pilih Akun Layanan.

Status dalam proses

Halaman Synthetic monitors mencantumkan monitor sintetis dengan status In progress. Status In progress berarti bahwa monitor sintetis baru saja dibuat dan tidak ada data yang akan ditampilkan, atau fungsi gagal di-deploy.

Untuk menentukan apakah fungsi gagal di-deploy, coba langkah berikut:

  • Pastikan nama fungsi Cloud Run Anda tidak berisi garis bawah. Jika ada garis bawah, hapus garis bawah tersebut dan deploy ulang fungsi Cloud Run.

  • Buka halaman Detail monitor sintetis untuk monitor sintetis.

    Jika Anda melihat pesan berikut, hapus monitor sintetis.

    Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.

    Pesan error menunjukkan bahwa fungsi telah dihapus sehingga monitor sintetis tidak dapat menjalankan fungsi.

  • Buka halaman fungsi Cloud Run untuk fungsi tersebut. Untuk membuka halaman ini dari halaman Synthetic monitor details, klik Code, lalu klik nama fungsi.

    Jika Anda melihat pesan yang mirip dengan berikut ini, berarti fungsi gagal di-deploy.

    This function has failed to deploy and will not work correctly. Please edit and redeploy

    Untuk mengatasi kegagalan ini, tinjau kode fungsi dan perbaiki error yang mencegah fungsi di-build atau di-deploy.

Saat Anda membuat monitor sintetis, mungkin perlu waktu beberapa menit hingga fungsi di-deploy dan dieksekusi.

Status peringatan

Synthetic monitors mencantumkan monitor sintetis dengan status Warning. Status Warning berarti bahwa hasil eksekusi tidak konsisten. Hal ini mungkin menunjukkan masalah desain pada pengujian Anda, atau mungkin menunjukkan bahwa hal yang sedang diuji memiliki perilaku yang tidak konsisten.

Status gagal

Monitor sintetis mencantumkan monitor sintetis dengan status Failing. Untuk mendapatkan informasi selengkapnya tentang alasan kegagalan, lihat histori eksekusi terbaru.

  • Jika pesan error Request failed with status code 429 ditampilkan, target permintaan HTTP menolak perintah. Untuk mengatasi kegagalan ini, Anda harus mengubah target monitor sintetis.

    Endpoint https://www.google.com menolak permintaan yang dibuat oleh monitor sintetis.

  • Jika kegagalan menampilkan waktu eksekusi 0ms, fungsi Cloud Run mungkin kehabisan memori. Untuk mengatasi kegagalan ini, edit fungsi Cloud Run, lalu tingkatkan memori setidaknya menjadi 2 GiB dan tetapkan kolom CPU ke 1.

Penghapusan gagal untuk monitor sintetis

Anda menggunakan Cloud Monitoring API untuk menghapus monitor sintetis, tetapi panggilan API gagal dengan respons yang mirip dengan berikut:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

Untuk mengatasi kegagalan, hapus kebijakan pemberitahuan yang memantau hasil monitor sintetis, lalu hapus monitor sintetis.

Tidak dapat mengedit konfigurasi pemeriksa link rusak

Anda telah membuat pemeriksa link rusak menggunakan konsol Google Cloud, dan ingin mengubah elemen HTML yang diuji, atau ingin mengubah waktu tunggu URI, percobaan ulang, tunggu pemilih, dan opsi per link. Namun, saat Anda mengedit pemeriksa link rusak, konsol Google Cloud tidak menampilkan kolom konfigurasi.

Untuk mengatasi kegagalan ini, lakukan tindakan berikut:

  1. Di konsol Google Cloud, buka halaman  Synthetic monitoring:

    Buka Pemantauan sintetis

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

  2. Cari monitor sintetis yang ingin diedit, klik More options, lalu pilih Edit.
  3. Klik Edit function.

  4. Edit objek options dalam file index.js, lalu klik Terapkan fungsi.

    Untuk mengetahui informasi tentang kolom dan sintaksis untuk objek ini, lihat broken-links-ok/index.js.

  5. Klik Simpan.

Konsol Google Cloud menampilkan bahwa penyimpanan screenshot gagal

Anda telah membuat pemeriksa link rusak dan mengonfigurasinya untuk menyimpan screenshot. Namun, konsol Google Cloud menampilkan salah satu pesan peringatan berikut bersama dengan informasi yang lebih mendetail:

  • InvalidStorageLocation
  • StorageValidationError
  • BucketCreationError
  • ScreenshotFileUploadError

Untuk mengatasi kegagalan ini, coba langkah berikut:

  • Jika Anda melihat pesan InvalidStorageLocation, verifikasi keberadaan bucket Cloud Storage yang ditentukan di kolom bernama options.screenshot_options.storage_location.

  • Melihat log yang terkait dengan fungsi Cloud Run Anda. Untuk mengetahui informasi selengkapnya, lihat Menemukan log.

  • Pastikan akun layanan yang digunakan dalam fungsi Cloud Run yang sesuai memiliki peran Identity and Access Management yang memungkinkannya membuat, mengakses, dan menulis ke bucket Cloud Storage.