Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah canary yang gagal

Jika canary Anda gagal, periksa hal berikut ini untuk pemecahan masalah.

Pemecahan masalah umum

Canary gagal setelah pembaruan lingkungan Lambda

CloudWatch Canary Synthetics diimplementasikan sebagai fungsi Lambda di akun Anda. Fungsi Lambda ini tunduk pada pembaruan runtime Lambda reguler yang berisi pembaruan keamanan, perbaikan bug, dan peningkatan lainnya. Lambda berusaha untuk menyediakan pembaruan runtime yang kompatibel dengan fungsi yang ada. Namun, seperti halnya patching perangkat lunak, ada kasus yang jarang terjadi di mana pembaruan runtime dapat berdampak negatif pada fungsi yang ada. Jika Anda yakin kenari Anda telah terpengaruh oleh pembaruan runtime Lambda, Anda dapat menggunakan mode manual manajemen runtime Lambda (di Wilayah yang didukung) untuk memutar kembali versi runtime Lambda sementara. Ini membuat fungsi kenari Anda tetap berfungsi dan meminimalkan gangguan, memberikan waktu untuk memperbaiki ketidakcocokan sebelum kembali ke versi runtime terbaru.

Jika kenari Anda gagal setelah pembaruan runtime Lambda, solusi terbaik adalah meningkatkan ke salah satu runtime Synthetics terbaru. Untuk informasi selengkapnya tentang runtime terbaru, lihatVersi runtime Synthetics.

Sebagai solusi alternatif, di Wilayah di mana kontrol manajemen runtime Lambda tersedia, Anda dapat mengembalikan kenari kembali ke runtime terkelola Lambda yang lebih lama, menggunakan mode manual untuk kontrol manajemen runtime. Anda dapat mengatur mode manual menggunakan AWS CLI atau dengan menggunakan konsol Lambda, menggunakan langkah-langkah di bawah ini di bagian berikut.

Prasyarat

Langkah 1: Dapatkan fungsi Lambda ARN

Jalankan perintah berikut untuk mengambil EngineArn bidang dari respons. Ini EngineArn adalah fungsi Lambda yang dikaitkan dengan kenari. ARN Anda akan menggunakan ini ARN dalam langkah-langkah berikut.

aws synthetics get-canary --name my-canary | jq '.Canary.EngineArn'

Contoh keluaran dariEngingArn:

"arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8"

Langkah 2: Dapatkan versi runtime Lambda bagus terakhir ARN

Untuk membantu memahami apakah kenari Anda terkena dampak pembaruan runtime Lambda, periksa apakah tanggal dan waktu ARN perubahan versi runtime Lambda di log Anda muncul pada tanggal dan waktu ketika Anda melihat dampak pada kenari Anda. Jika tidak cocok, itu mungkin bukan pembaruan runtime Lambda yang menyebabkan masalah Anda.

Jika kenari Anda dipengaruhi oleh pembaruan runtime Lambda, Anda harus mengidentifikasi versi runtime Lambda ARN yang berfungsi yang sebelumnya Anda gunakan. Ikuti petunjuk dalam Mengidentifikasi perubahan versi runtime untuk menemukan runtime sebelumnya. ARN Rekam versi runtimeARN, dan lanjutkan ke Langkah 3. untuk mengatur konfigurasi manajemen runtime.

Jika kenari Anda belum terpengaruh oleh pembaruan lingkungan Lambda, maka Anda dapat menemukan versi runtime Lambda ARN yang saat ini Anda gunakan. Jalankan perintah berikut untuk mengambil fungsi Lambda dari respons. RuntimeVersionArn

aws lambda get-function-configuration \
--function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8" | jq '.RuntimeVersionConfig.RuntimeVersionArn'

Contoh keluaran dariRuntimeVersionArn:

"arn:aws:lambda:us-west-2::runtime:EXAMPLE647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Langkah 3: Memperbarui konfigurasi manajemen runtime Lambda

Anda dapat menggunakan konsol Lambda AWS CLI atau Lambda untuk memperbarui konfigurasi manajemen runtime.

Untuk mengatur mode manual konfigurasi manajemen runtime Lambda menggunakan AWS CLI

Masukkan perintah berikut untuk mengubah manajemen runtime fungsi Lambda ke mode manual. Pastikan untuk mengganti function-name and qualifier dengan fungsi Lambda dan nomor versi fungsi ARN Lambda masing-masing, menggunakan nilai yang Anda temukan di Langkah 1. Juga ganti runtime-version-arn dengan versi ARN yang Anda temukan di Langkah 2.

aws lambda put-runtime-management-config \
    --function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991" \
    --qualifier 8 \
    --update-runtime-on "Manual" \
    --runtime-version-arn "arn:aws:lambda:us-west-2::runtime:a993d90ea43647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Kenari saya diblokir oleh AWS WAF

Untuk AWS WAF mencegah pemblokiran kenari Anda, siapkan kondisi kecocokan AWS WAF string yang memungkinkan stringCloudWatchSynthetics. Untuk informasi selengkapnya, lihat Bekerja dengan kondisi pencocokan string dalam AWS WAF dokumentasi.

Menunggu elemen untuk muncul

Setelah menganalisis log dan tangkapan layar Anda, jika Anda melihat bahwa skrip Anda menunggu elemen muncul di layar dan waktu habis, periksa tangkapan layar yang relevan untuk melihat apakah elemen tersebut muncul di halaman. Verifikasi xpath Anda untuk memastikan bahwa itu benar.

Untuk masalah terkait Dalang, periksa halaman Dalang atau forum internet. GitHub

Node tidak terlihat atau tidak HTMLElement untuk page.click ()

Jika simpul tidak terlihat atau bukan merupakan HTMLElement untuk page.click(), pertama verifikasi xpath yang Anda gunakan untuk mengklik elemen tersebut. Juga, jika elemen Anda ada di bagian bawah layar, sesuaikan viewport Anda. CloudWatch Synthetics secara default menggunakan viewport 1920 * 1080. Anda dapat mengatur viewport yang berbeda ketika Anda meluncurkan browser atau dengan menggunakan fungsi Puppeteer page.setViewport.

Tidak dapat mengunggah artefak ke S3, Pengecualian: Tidak dapat mengambil lokasi bucket S3: Akses Ditolak

Jika kenari Anda gagal karena kesalahan Amazon S3, CloudWatch Synthetics tidak dapat mengunggah tangkapan layar, log, atau laporan yang dibuat untuk kenari karena masalah izin. Periksa hal-hal berikut:

Jika canary melakukan pemantauan visual, silakan lihat Memperbarui lokasi artefak dan enkripsi saat menggunakan pemantauan visual untuk informasi lebih lanjut.

Kesalahan: Kesalahan protokol (Runtime. callFunctionOn): Target ditutup.

Kesalahan ini muncul jika ada beberapa permintaan jaringan setelah halaman atau browser ditutup. Anda mungkin lupa untuk menunggu operasi asynchronous. Setelah menjalankan skrip Anda, CloudWatch Synthetics menutup browser. Eksekusi setiap operasi asynchronous setelah browser ditutup dapat menyebabkan target closed error.

Canary Gagal. Kesalahan: Tidak ada datapoint - Canary Menunjukkan kesalahan batas waktu

Ini berarti bahwa canary Anda berjalan melebihi batas waktu. Eksekusi kenari berhenti sebelum CloudWatch Synthetics dapat mempublikasikan metrik CloudWatch persen keberhasilan atau memperbarui artefak HAR seperti file, log, dan tangkapan layar. Jika batas waktu Anda terlalu rendah, Anda dapat meningkatkannya.

Secara bawaan, nilai batas waktu canary sama dengan frekuensinya. Anda dapat secara manual menyesuaikan nilai batas waktu menjadi kurang dari atau sama dengan frekuensi canary. Jika frekuensi canary Anda rendah, Anda harus meningkatkan frekuensi untuk meningkatkan batas waktu. Anda dapat menyesuaikan frekuensi dan nilai batas waktu di bawah Jadwal saat Anda membuat atau memperbarui kenari dengan menggunakan konsol Synthetics CloudWatch .

Pastikan nilai batas waktu canary Anda tidak lebih singkat dari 15 detik untuk memungkinkan Lambda melakukan cold start dan waktu yang diperlukan untuk melakukan boot up instrumentasi canary.

Artefak kenari tidak tersedia untuk dilihat di konsol CloudWatch Synthetics saat kesalahan ini terjadi. Anda dapat menggunakan CloudWatch Log untuk melihat log kenari.

Coba untuk mengakses titik akhir internal

Jika Anda ingin kenari Anda mengakses titik akhir di jaringan internal Anda, kami sarankan Anda mengatur CloudWatch Synthetics untuk digunakan. VPC Untuk informasi selengkapnya, lihat Menjalankan kenari di atas VPC.

Masalah peningkatan dan penurunan versi runtime Canary

Jika Anda baru saja memutakhirkan kenari dari versi runtime syn-1.0 ke versi yang lebih baru, ini mungkin merupakan masalah cross-origin request sharing (). CORS Untuk informasi selengkapnya, lihat Masalah berbagi permintaan lintas asal (CORS).

Jika Anda baru-baru ini menurunkan versi kenari ke versi runtime yang lebih lama, periksa untuk memastikan bahwa fungsi CloudWatch Synthetics yang Anda gunakan tersedia dalam versi runtime yang lebih lama yang Anda turunkan. Misalnya, fungsi executeHttpStep tersedia untuk versi runtime syn-nodejs-2.2 dan yang lebih baru. Untuk memeriksa ketersediaan fungsi, silakan lihat Menulis skrip canary.

Masalah berbagi permintaan lintas asal (CORS)

Dalam UI canary, jika beberapa permintaan jaringan gagal dengan 403 atau net::ERR_FAILED, periksa apakah canary memiliki pelacakan aktif yang diaktifkan dan juga gunakan fungsi Puppeteer page.setExtraHTTPHeaders untuk menambahkan header. Jika demikian, permintaan jaringan yang gagal mungkin disebabkan oleh pembatasan berbagi permintaan lintas asal (CORS). Anda dapat mengonfirmasi apakah ini masalahnya dengan menonaktifkan penelusuran aktif atau menghapus header tambahan. HTTP

Mengapa hal ini terjadi?

Ketika pelacakan aktif digunakan, header tambahan ditambahkan ke semua permintaan keluar untuk melacak panggilan. Memodifikasi header permintaan dengan menambahkan header jejak atau menambahkan header tambahan menggunakan Puppeteer page.setExtraHTTPHeaders menyebabkan permintaan CORS cek untuk (). XMLHttpRequest XHR

Jika Anda tidak ingin menonaktifkan pelacakan aktif atau menghapus header tambahan, Anda dapat memperbarui aplikasi web Anda untuk mengizinkan akses lintas asal atau Anda dapat menonaktifkan keamanan web dengan menggunakan bendera disable-web-security saat Anda meluncurkan browser Chrome di skrip Anda.

Anda dapat mengganti parameter peluncuran yang digunakan oleh CloudWatch Synthetics dan meneruskan parameter flag disable-web-security tambahan dengan menggunakan fungsi peluncuran CloudWatch Synthetics. Untuk informasi selengkapnya, lihat Fungsi pustaka tersedia untuk skrip canary Node.js.

Masalah kondisi balapan kenari

Untuk pengalaman terbaik saat menggunakan CloudWatch Synthetics, pastikan bahwa kode yang ditulis untuk kenari adalah idempoten. Jika tidak, dalam kasus yang jarang terjadi, lari kenari dapat menghadapi kondisi balapan ketika kenari berinteraksi dengan sumber daya yang sama di lintasan yang berbeda.