Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Memecahkan masalah monitor sintetis dan cek uptime

Jika Anda mengalami masalah saat membuat, menjalankan, atau menghapus monitor sintetis atau pemeriksaan uptime, atau jika Anda tidak menerima notifikasi pemberitahuan yang diharapkan, Anda dapat mendiagnosis penyebabnya dengan memeriksa log eksekusi, metrik, dan rekaman aktivitas. Anda juga dapat mengatasi kesalahan konfigurasi umum yang melibatkan izin IAM, perimeter Kontrol Layanan VPC, dan target jaringan pribadi.

Menemukan log

Untuk membantu Anda mengorelasikan permintaan dengan log, permintaan HTTP dan HTTPS yang dikirim oleh Cloud Monitoring menyertakan header Check-Id yang menyimpan ID monitor sintetis atau pemeriksaan uptime terkait. Untuk menemukan log untuk monitor sintetis dan cek uptime, lakukan hal berikut:

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.
Di toolbar konsol Google Cloud , pilih project Google Cloud Anda. Untuk konfigurasi Pusat Aplikasi, pilih project host atau project pengelolaan Pusat Aplikasi.
Lakukan salah satu tindakan berikut:
- Untuk menemukan semua log yang terkait dengan monitor sintetis atau cek uptime, kueri menurut jenis resource. Anda dapat menggunakan menu Resource atau memasukkan kueri.
  
  Untuk cek 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"
```
- Untuk menemukan log yang berisi informasi tentang respons yang diterima selama eksekusi cek uptime atau monitor sintetis, lakukan salah satu hal berikut:
  - Untuk membuat kueri menggunakan ID monitor sintetis atau cek uptime, gunakan format berikut saat memasukkan ID ke editor kueri, lalu klik Jalankan kueri:
```
labels.check_id="my-check-id"
```
  - Untuk membuat kueri log yang berisi data respons untuk permintaan yang dikeluarkan oleh pemantau sintetis dan cek uptime, 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 hal berikut:
  - ID monitor sintetis atau cek 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 trace dikumpulkan, ID trace 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 uptime. 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 menyelesaikannya.

Satu pemeriksa gagal, tetapi yang lain tidak

Anda sedang meninjau metrik pemeriksaan waktu aktif 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 perintah pemeriksa yang habis karena masalah jaringan. Artinya, alih-alih gagal, perintah tidak selesai dalam waktu tunggu yang ditentukan.

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

Anda menerima notifikasi dan ingin men-debug kegagalan

Untuk mengidentifikasi kapan kegagalan dimulai, lakukan salah satu tindakan berikut:
- Untuk cek uptime, guna menentukan kapan kegagalan terjadi, lihat halaman Detail uptime:
  1. Di konsol Google Cloud , buka halaman Cek uptime:
    Buka Cek uptime
    
    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.
  2. Di toolbar konsol Google Cloud , pilih project Google Cloud Anda. Untuk konfigurasi Pusat Aplikasi, pilih project host atau project pengelolaan Pusat Aplikasi.
  3. Cari dan pilih cek uptime.
    
    Diagram Pemeriksaan lulus menampilkan histori pemeriksaan. Untuk mengidentifikasi kapan pemeriksaan waktu aktif 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 Pemantauan sintetis:
    Buka Pemantauan sintetis
    
    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.
  2. Di toolbar konsol Google Cloud , pilih project Google Cloud Anda. Untuk konfigurasi Pusat Aplikasi, pilih project host atau project pengelolaan Pusat Aplikasi.
  3. Cari dan pilih monitor sintetis.
Untuk mengetahui informasi tentang cara menemukan data log terkait, lihat Menemukan log.

Anda tidak diberi tahu bahwa cek uptime gagal

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

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

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

Untuk melihat atau mengedit kebijakan pemberitahuan, lakukan langkah berikut:

Di konsol Google Cloud , buka halaman Pemberitahuan:
Buka Pemberitahuan

Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.
Di toolbar konsol Google Cloud , pilih project Google Cloud Anda. Untuk konfigurasi Pusat Aplikasi, pilih project host atau project pengelolaan Pusat Aplikasi.
Klik Lihat semua kebijakan di panel Kebijakan.
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 uptime publik dan memberikan informasi untuk menyelesaikannya.

Cek uptime publik Anda gagal

Anda mengonfigurasi pemeriksaan uptime publik, tetapi Anda 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, periksa apakah 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 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 Forbidden: Layanan menampilkan kode error ke pemeriksa uptime. Misalnya, konfigurasi server web Apache default menampilkan kode ini di Amazon Linux, tetapi menampilkan kode 200 (Berhasil) di beberapa versi Linux lainnya. Lihat tutorial LAMP untuk Amazon Linux atau dokumentasi server web Anda.
404 Tidak ditemukan: 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 ditentukan sebagai bagian dari opsi Validasi Respons.

Untuk membantu Anda memecahkan masalah cek uptime publik yang gagal, 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 oleh waktu tunggu habis di aplikasi Anda. Untuk mengetahui informasi selengkapnya, lihat Menggunakan ping ICMP.

Anda tidak dapat membuat cek uptime publik

Anda mencoba membuat cek uptime publik, tetapi tindakan gagal dengan pesan yang mirip dengan berikut:

Public uptime checks cannot be configured in a VPC Service Controls perimeter.

Pesan error ini menunjukkan bahwa project Google Cloud Anda berada dalam perimeter Kontrol Layanan VPC yang diaktifkan. Anda tidak dapat membuat cek uptime publik untuk konfigurasi tersebut.

Untuk mengatasi situasi ini, buat cek uptime pribadi.

Memecahkan masalah cek uptime pribadi

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

Pembuatan cek uptime gagal

Setelan project Google Cloud Anda mungkin mencegah modifikasi peran yang ditetapkan ke akun layanan yang digunakan cek uptime untuk mengelola interaksi dengan layanan Direktori Layanan. Dalam situasi ini, pembuatan cek uptime akan gagal.

Bagian ini menjelaskan cara memberikan peran yang diperlukan akun layanan:

Konsol

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

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

gcloud: Mencakup project

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

Pembuatan pemeriksaan uptime pertama berhasil jika project Anda mengizinkan pemberian peran otomatis untuk akun layanan. Akun layanan dibuat untuk Anda dan diberi peran yang diperlukan.
Pembuatan pemeriksaan uptime pertama akan gagal jika project Anda tidak mengizinkan pemberian peran otomatis untuk akun layanan. Akun layanan dibuat, tetapi tidak ada peran yang diberikan.

Jika pembuatan cek uptime gagal, lakukan hal berikut:

Berikan otorisasi ke akun layanan.
Tunggu beberapa menit hingga izin diterapkan.
Coba buat cek uptime pribadi lagi.

gcloud: Project yang dipantau

Saat pertama kali membuat pemeriksaan uptime pribadi yang menargetkan layanan Service Directory di project yang dipantau atau resource pribadi di project Google Cloud lain, permintaan akan gagal dan mengakibatkan pembuatan akun layanan Monitoring.

Cara Anda mengizinkan akun layanan bergantung pada jumlah projectGoogle Cloud yang Anda gunakan dan hubungannya. Anda mungkin memiliki hingga empat project yang terlibat:

Project tempat Anda menentukan cek uptime pribadi.
Project yang dipantau tempat Anda mengonfigurasi layanan Service Directory.
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 hal berikut:

Berikan otorisasi ke akun layanan.
Tunggu beberapa menit hingga izin diterapkan.
Coba buat cek uptime pribadi lagi.

Tidak dapat menargetkan layanan Cloud Run

Anda ingin menargetkan layanan Cloud Run dengan pemeriksaan uptime pribadi, tetapi layanan Cloud Run tidak memiliki alamat IPv4 di jaringan VPC pelanggan yang dapat Anda daftarkan sebagai endpoint Service Directory.

Untuk menargetkan layanan Cloud Run dengan pemeriksaan uptime pribadi, konfigurasikan Load Balancer Aplikasi internal dengan backend NEG serverless, dan daftarkan alamat IP internal load balancer di Service Directory. Untuk mengetahui contoh cara menyiapkan load balancer, lihat Menyiapkan Load Balancer Aplikasi internal regional dengan Cloud Run.

Akses ditolak

Pemeriksaan uptime Anda gagal dengan hasil VPC_ACCESS_DENIED. Hasil ini berarti ada aspek konfigurasi jaringan atau otorisasi akun layanan yang tidak benar.

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

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

Hasil anomali dari cek uptime pribadi

Anda memiliki layanan Service Directory dengan beberapa VM, dan konfigurasi layanan Anda berisi beberapa endpoint. Saat Anda mematikan salah satu VM, pemeriksaan uptime Anda tetap menunjukkan keberhasilan.

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

Header default

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

Saat permintaan dikirim untuk pemeriksaan uptime pribadi ke endpoint target, permintaan 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 Service Directory
`HTTP_ACCEPT_ENCODING`	`gzip`, `deflate`, `br`
`CONTENT_LENGTH`	Dihitung dari data `POST` 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 aktif saat pemeriksaan waktu aktif Anda berada di project Google Cloud yang berbeda dengan layanan Service Directory.

Pastikan Google Cloud project yang berisi pemeriksaan uptime memantau Google Cloud project yang berisi layanan Service Directory.

Untuk mengetahui informasi selengkapnya tentang cara mencantumkan project yang dipantau dan menambahkan project lainnya, 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 setidaknya 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 lagi tindakan tersebut.

Untuk memverifikasi bahwa API 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 diselesaikan secara otomatis setelah pengaktifan API diterapkan melalui backend.

Permintaan HTTP keluar tidak dilacak

Anda mengonfigurasi monitor sintetis untuk mengumpulkan data rekaman aktivitas untuk permintaan HTTP keluar. Data rekaman aktivitas Anda hanya menampilkan satu rentang, 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:

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.
Di toolbar konsol Google Cloud , pilih project Google Cloud Anda. Untuk konfigurasi Pusat Aplikasi, pilih project host atau project pengelolaan Pusat Aplikasi.
Pilih Sertakan pemberian peran yang disediakan Google.
Jika akun layanan yang digunakan oleh monitor sintetis Anda tidak tercantum, atau jika akun tersebut belum diberi peran yang mencakup izin dalam peran Agen Cloud Trace (roles/cloudtrace.agent), maka berikan peran ini ke akun layanan Anda.

Jika Anda tidak mengetahui nama akun layanan Anda, pilih Service Accounts di menu navigasi.

Status dalam proses

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

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

Pastikan nama fungsi Cloud Run Anda tidak berisi garis bawah. Jika ada garis bawah, hapus garis bawah 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 dan oleh karena itu, monitor sintetis tidak dapat menjalankan fungsi.
Buka halaman Cloud Run Functions untuk fungsi tersebut. Untuk membuka halaman ini dari halaman Detail monitor sintetis, klik Kode, lalu klik nama fungsi.

Jika Anda melihat pesan yang mirip dengan yang berikut, 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 agar fungsi di-deploy dan dieksekusi.

Status peringatan

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

Status gagal

Halaman 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, maka 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, berarti fungsi Cloud Run mungkin kehabisan memori. Untuk mengatasi kegagalan ini, edit fungsi Cloud Run Anda, lalu tingkatkan memori menjadi minimal 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 ini:

{
  "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 membuat pemeriksa link rusak menggunakan konsol Google Cloud , dan Anda ingin mengubah elemen HTML yang diuji, atau Anda 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:

Di konsol Google Cloud , buka halaman Pemantauan sintetis:
Buka Pemantauan sintetis

Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.
Di toolbar konsol Google Cloud , pilih project Google Cloud Anda. Untuk konfigurasi Pusat Aplikasi, pilih project host atau project pengelolaan Pusat Aplikasi.
Cari monitor sintetis yang ingin Anda edit, klik Opsi lainnya, lalu pilih Edit.
Klik Edit function.
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.
Klik Simpan.

Google Cloud console melaporkan 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-langkah berikut:

Jika Anda melihat pesan InvalidStorageLocation, verifikasi keberadaan bucket Cloud Storage yang ditentukan di kolom bernama options.screenshot_options.storage_location.
Lihat 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.