Menyelesaikan masalah eksekusi di Lambda - AWS Lambda

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

Menyelesaikan masalah eksekusi di Lambda

Ketika runtime Lambda menjalankan kode fungsi Anda, kejadian mungkin diproses pada instans fungsi yang sedang memproses kejadian selama beberapa saat, atau mungkin memerlukan instans baru untuk diinisialisasi. Kesalahan dapat terjadi selama inisialisasi fungsi, ketika kode handler Anda memproses kejadian, atau ketika fungsi Anda mengembalikan (atau gagal mengembalikan) respons.

Kesalahan eksekusi fungsi dapat disebabkan oleh masalah dengan kode, konfigurasi fungsi, sumber daya hilir, atau izin Anda. Jika Anda memanggil fungsi secara langsung, Anda melihat kesalahan fungsi dalam respons dari Lambda. Jika Anda memanggil fungsi Anda secara asinkron, dengan pemetaan sumber kejadian, atau melalui layanan lain, Anda mungkin menemukan kesalahan di log, antrean surat gagal, atau tujuan saat terjadi kegagalan. Opsi penanganan kesalahan dan perilaku percobaan ulang berbeda-beda tergantung pada cara Anda memanggil fungsi dan jenis kesalahan.

Saat kode fungsi atau runtime Lambda Anda memunculkan kesalahan, kode status di respons dari Lambda adalah 200 OK. Adanya kesalahan dalam respons ditunjukkan dengan header bernama X-Amz-Function-Error. Kode status seri 400 dan 500 dicadangkan untuk kesalahan invokasi.

Lambda: Eksekusi memerlukan waktu yang lama

Masalah: Eksekusi fungsi membutuhkan waktu terlalu lama.

Jika kode Anda membutuhkan waktu lebih lama untuk dijalankan di Lambda daripada di mesin lokal Anda, kode mungkin dibatasi oleh memori atau daya pemrosesan yang tersedia untuk fungsi. Konfigurasikan fungsi dengan memori tambahan untuk menambah memori danCPU.

Lambda: Payload acara tak terduga

Masalah: Kesalahan fungsi yang terkait dengan validasi data yang JSON salah atau tidak memadai.

Semua fungsi Lambda menerima payload peristiwa di parameter pertama handler. Payload acara adalah JSON struktur yang mungkin berisi array dan elemen bersarang.

Malformed JSON dapat terjadi ketika disediakan oleh layanan hulu yang tidak menggunakan proses yang kuat untuk memeriksa JSON struktur. Hal ini terjadi ketika layanan menggabungkan string teks atau menanamkan input pengguna yang belum dibersihkan. JSONjuga sering diserialisasikan untuk lewat antar layanan. Selalu mengurai JSON struktur baik sebagai produsen maupun konsumen JSON untuk memastikan bahwa struktur tersebut valid.

Demikian pula, gagal memeriksa rentang nilai dalam muatan acara dapat mengakibatkan kesalahan. Contoh ini menunjukkan fungsi yang menghitung pemotongan pajak:

exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) }

Fungsi ini menggunakan gaji dan tarif pajak dari payload acara untuk melakukan perhitungan. Namun, kode gagal untuk memeriksa apakah atribut ada. Ini juga gagal untuk memeriksa tipe data, atau memastikan batasan, seperti memastikan bahwa persentase pajak antara 0 dan 1. Akibatnya, nilai di luar batas-batas ini menghasilkan hasil yang tidak masuk akal. Jenis yang salah atau atribut yang hilang menyebabkan kesalahan runtime.

Buat pengujian untuk memastikan bahwa fungsi Anda menangani ukuran muatan yang lebih besar. Ukuran maksimum untuk muatan acara Lambda adalah 256 KB. Bergantung pada kontennya, muatan yang lebih besar dapat berarti lebih banyak item yang diteruskan ke fungsi atau lebih banyak data biner yang disematkan dalam JSON atribut. Dalam kedua kasus, ini dapat menghasilkan lebih banyak pemrosesan untuk fungsi Lambda.

Muatan yang lebih besar juga dapat menyebabkan batas waktu. Misalnya, fungsi Lambda memproses satu catatan per 100 ms dan memiliki batas waktu 3 detik. Pemrosesan berhasil untuk 0-29 item dalam muatan. Namun, setelah payload berisi lebih dari 30 item, fungsi akan habis dan menimbulkan kesalahan. Untuk menghindari hal ini, pastikan batas waktu diatur untuk menangani waktu pemrosesan tambahan untuk jumlah maksimum item yang diharapkan.

Lambda: Ukuran muatan besar yang tak terduga

Masalah: Fungsi habis waktu atau menyebabkan kesalahan karena muatan besar.

Muatan yang lebih besar dapat menyebabkan batas waktu dan kesalahan. Sebaiknya buat pengujian untuk memastikan bahwa fungsi Anda menangani muatan terbesar yang diharapkan, dan memastikan batas waktu fungsi disetel dengan benar.

Selain itu, muatan peristiwa tertentu dapat berisi petunjuk ke sumber daya lain. Misalnya, fungsi Lambda dengan memori 128 MB dapat melakukan pemrosesan gambar pada JPG file yang disimpan sebagai objek di S3. Fungsi ini berfungsi seperti yang diharapkan dengan file gambar yang lebih kecil. Namun, ketika JPG file yang lebih besar disediakan sebagai input, fungsi Lambda memunculkan kesalahan karena kehabisan memori. Untuk menghindari hal ini, kasus uji harus menyertakan contoh dari batas atas ukuran data yang diharapkan. Kode juga harus memvalidasi ukuran payload.

Lambda: kesalahan JSON pengkodean dan decoding

Masalah: NoSuchKey pengecualian saat mengurai JSON input.

Periksa untuk memastikan Anda memproses JSON atribut dengan benar. Misalnya, untuk peristiwa yang dihasilkan oleh S3, s3.object.key atribut berisi nama kunci objek yang URL dikodekan. Banyak fungsi memproses atribut ini sebagai teks untuk memuat objek S3 yang direferensikan:

const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise()

Kode ini bekerja dengan nama kunci james.jpg tetapi menimbulkan NoSuchKey kesalahan saat namanya. james beswick.jpg Karena URL pengkodean mengubah spasi dan karakter lain dalam nama kunci, Anda harus memastikan bahwa fungsi memecahkan kode kunci sebelum menggunakan data ini:

const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise()

Lambda: Log atau jejak tidak muncul

Masalah: Log tidak muncul di CloudWatch Log.

Masalah: Jejak tidak muncul di AWS X-Ray.

Fungsi Anda memerlukan izin untuk memanggil CloudWatch Log dan X-Ray. Perbarui peran eksekusi untuk memberikan izin. Tambahkan kebijakan terkelola berikut untuk mengaktifkan log dan pelacakan.

  • AWSLambdaBasicExecutionRole

  • AWSXRayDaemonWriteAccess

Saat Anda menambahkan izin ke fungsi Anda, lakukan pembaruan sepele ke kode atau konfigurasinya juga. Ini memaksa instance menjalankan fungsi Anda, yang memiliki kredensialnya yang sudah ketinggalan zaman, untuk berhenti dan diganti.

catatan

Mungkin diperlukan waktu 5 hingga 10 menit agar log muncul setelah pemanggilan fungsi.

Lambda: Tidak semua log fungsi saya muncul

Masalah: Log fungsi tidak ada di CloudWatch Log, meskipun izin saya benar

Jika Anda Akun AWS mencapai batas kuota CloudWatch Log, fungsi CloudWatch throttles logging berfungsi. Ketika ini terjadi, beberapa log yang dihasilkan oleh fungsi Anda mungkin tidak muncul di CloudWatch Log.

Jika fungsi Anda mengeluarkan log pada tingkat yang terlalu tinggi bagi Lambda untuk memprosesnya, ini juga dapat menyebabkan keluaran log tidak muncul di Log. CloudWatch Ketika Lambda tidak dapat mengirim log CloudWatch pada tingkat yang dihasilkan oleh fungsi Anda, Lambda akan menjatuhkan log untuk mencegah eksekusi fungsi Anda melambat. Berharap untuk secara konsisten mengamati log yang dijatuhkan ketika throughput log Anda melebihi 2 MB/s untuk satu aliran log.

Jika fungsi Anda dikonfigurasi untuk menggunakan log JSON yang diformat, Lambda mencoba mengirim logsDroppedperistiwa CloudWatch ke Log ketika itu menjatuhkan log. Namun, saat CloudWatch membatasi logging fungsi Anda, peristiwa ini mungkin tidak mencapai CloudWatch Log, sehingga Anda tidak akan selalu melihat catatan saat Lambda menjatuhkan log.

Untuk memeriksa apakah Anda Akun AWS telah mencapai batas kuota CloudWatch Log, lakukan hal berikut:

  1. Buka Konsol Service Quotas.

  2. Di panel navigasi, pilih Layanan AWS .

  3. Dari daftar AWS layanan, cari Amazon CloudWatch Logs.

  4. Dalam daftar kuota Layanan, pilihCreateLogGroup throttle limit in transactions per second, CreateLogStream throttle limit in transactions per second dan PutLogEvents throttle limit in transactions per second kuota untuk melihat penggunaan Anda.

Anda juga dapat mengatur CloudWatch alarm untuk mengingatkan Anda ketika penggunaan akun Anda melebihi batas yang Anda tentukan untuk kuota ini. Lihat Membuat CloudWatch alarm berdasarkan ambang batas statis untuk mempelajari lebih lanjut.

Jika batas kuota default untuk CloudWatch Log tidak cukup untuk kasus penggunaan Anda, Anda dapat meminta peningkatan kuota.

Lambda: Fungsi kembali sebelum eksekusi selesai

Masalah: (Node.js) Fungsi kembali sebelum kode menyelesaikan eksekusi

Banyak perpustakaan, termasuk, beroperasi secara AWS SDK asinkron. Ketika Anda melakukan panggilan jaringan atau melakukan operasi lain yang perlu menunggu respons, pustaka mengembalikan objek yang disebut janji, yang melacak kemajuan operasi di latar belakang.

Untuk menunggu janji selesai menjadi respons, gunakan kata kunci await. Ini menghalangi kode handler Anda beroperasi hingga janji diselesaikan menjadi objek yang berisi respons. Jika Anda tidak perlu menggunakan data dari respons dalam kode, Anda dapat mengembalikan janji secara langsung ke runtime.

Beberapa pustaka tidak mengembalikan janji, tetapi dapat dirangkum dalam kode yang mengembalikan janji. Untuk informasi selengkapnya, lihat Tentukan penangan fungsi Lambda di Node.js.

Lambda: Menjalankan versi atau alias fungsi yang tidak diinginkan

Masalah: Versi fungsi atau alias tidak dipanggil

Saat Anda mempublikasikan fungsi Lambda baru di konsol atau menggunakan AWS SAM, versi kode terbaru diwakili oleh. $LATEST Secara default, pemanggilan yang tidak menentukan versi atau alias secara otomatis menargetkan $LATEST versi kode fungsi Anda.

Jika Anda menggunakan versi fungsi atau alias tertentu, ini adalah versi fungsi yang diterbitkan yang tidak dapat diubah sebagai tambahan. $LATEST Saat memecahkan masalah fungsi ini, pertama-tama tentukan bahwa pemanggil telah memanggil versi atau alias yang dimaksud. Anda dapat melakukan ini dengan memeriksa log fungsi Anda. Versi fungsi yang dipanggil selalu ditampilkan di baris START log:

debugging ops gambar 1

Lambda: Mendeteksi loop tak terbatas

Masalah: Pola loop tak terbatas yang terkait dengan fungsi Lambda

Ada dua jenis loop tak terbatas dalam fungsi Lambda. Yang pertama ada di dalam fungsi itu sendiri, disebabkan oleh loop yang tidak pernah keluar. Pemanggilan berakhir hanya ketika fungsi habis waktu. Anda dapat mengidentifikasi ini dengan memantau batas waktu, dan kemudian memperbaiki perilaku perulangan.

Jenis loop kedua adalah antara fungsi Lambda dan sumber daya lainnya AWS . Ini terjadi ketika peristiwa dari sumber daya seperti bucket S3 memanggil fungsi Lambda, yang kemudian berinteraksi dengan sumber daya sumber yang sama untuk memicu peristiwa lain. Ini memanggil fungsi lagi, yang menciptakan interaksi lain dengan bucket S3 yang sama, dan seterusnya. Jenis loop ini dapat disebabkan oleh sejumlah sumber AWS peristiwa yang berbeda, termasuk SQS antrian Amazon dan tabel DynamoDB. Anda dapat menggunakan deteksi loop rekursif untuk mengidentifikasi pola-pola ini.

operasi debugging gambar 2

Anda dapat menghindari loop ini dengan memastikan bahwa fungsi Lambda menulis ke sumber daya yang tidak sama dengan sumber daya yang dikonsumsi. Jika Anda harus mempublikasikan data kembali ke sumber daya konsumsi, pastikan bahwa data baru tidak memicu peristiwa yang sama. Atau, gunakan pemfilteran acara. Misalnya, berikut adalah dua solusi yang diusulkan untuk loop tak terbatas dengan sumber daya S3 dan DynamoDB:

  • Jika Anda menulis kembali ke bucket S3 yang sama, gunakan awalan atau akhiran yang berbeda dari pemicu peristiwa.

  • Jika Anda menulis item ke tabel DynamoDB yang sama, sertakan atribut yang dapat difilter oleh fungsi Lambda yang memakan. Jika Lambda menemukan atribut, itu tidak akan menghasilkan pemanggilan lain.

Umum: Ketidaktersediaan layanan hilir

Masalah: Layanan hilir yang diandalkan fungsi Lambda Anda tidak tersedia

Untuk fungsi Lambda yang memanggil titik akhir pihak ketiga atau sumber daya hilir lainnya, pastikan mereka dapat menangani kesalahan layanan dan batas waktu. Sumber daya hilir ini dapat memiliki waktu respons yang bervariasi, atau menjadi tidak tersedia karena gangguan layanan. Bergantung pada implementasinya, kesalahan hilir ini dapat muncul sebagai batas waktu atau pengecualian Lambda jika respons kesalahan layanan tidak ditangani dalam kode fungsi.

Kapan saja suatu fungsi bergantung pada layanan hilir, seperti API panggilan, menerapkan penanganan kesalahan yang sesuai, dan coba lagi logika. Untuk layanan penting, fungsi Lambda harus mempublikasikan metrik atau log ke. CloudWatch Misalnya, jika pembayaran pihak ketiga tidak API tersedia, fungsi Lambda Anda dapat mencatat informasi ini. Anda kemudian dapat mengatur CloudWatch alarm untuk mengirim pemberitahuan yang terkait dengan kesalahan ini.

Karena Lambda dapat menskalakan dengan cepat, layanan hilir non-server mungkin kesulitan menangani lonjakan lalu lintas. Ada tiga pendekatan umum untuk menangani ini:

  • Caching — Pertimbangkan untuk menyimpan hasil dari nilai yang dikembalikan oleh layanan pihak ketiga jika tidak sering berubah. Anda dapat menyimpan nilai-nilai ini dalam variabel global dalam fungsi Anda, atau layanan lain. Misalnya, hasil untuk kueri daftar produk dari RDS instans Amazon dapat disimpan untuk jangka waktu tertentu dalam fungsi untuk mencegah kueri yang berlebihan.

  • Antrian - Saat menyimpan atau memperbarui data, tambahkan SQS antrian Amazon antara fungsi Lambda dan sumber daya. Antrian tahan lama mempertahankan data sementara layanan hilir memproses pesan.

  • Proxy — Di mana koneksi berumur panjang biasanya digunakan, seperti untuk RDS instans Amazon, gunakan lapisan proxy untuk mengumpulkan dan menggunakan kembali koneksi tersebut. Untuk database relasional, Amazon RDS Proxy adalah layanan yang dirancang untuk membantu meningkatkan skalabilitas dan ketahanan dalam aplikasi berbasis Lambda.

AWS SDK: Versi dan pembaruan

Masalah: Yang AWS SDK disertakan pada runtime bukanlah versi terbaru

Masalah: Yang AWS SDK disertakan pada pembaruan runtime secara otomatis

Runtime untuk bahasa scripting termasuk AWS SDK dan diperbarui secara berkala ke versi terbaru. Versi terkini untuk setiap runtime tercantum di halaman runtime. Untuk menggunakan versi yang lebih baru AWS SDK, atau untuk mengunci fungsi Anda ke versi tertentu, Anda dapat menggabungkan pustaka dengan kode fungsi Anda, atau membuat lapisan Lambda. Untuk perincian tentang pembuatan paket deployment dengan dependensi, lihat topik berikut:

Node.js

Deploy fungsi Lambda Node.js dengan arsip file .zip

Python

Bekerja dengan arsip file.zip untuk fungsi Python Lambda

Ruby

Deploy fungsi Lambda Ruby dengan arsip file .zip

Java

Deploy fungsi Java Lambda dengan arsip JAR .zip atau file

Go

Deploy fungsi Go Lambda dengan arsip file .zip

C#

Bangun dan terapkan fungsi C# Lambda dengan arsip file.zip

PowerShell

Menyebarkan fungsi PowerShell Lambda dengan arsip file.zip

Python: Pustaka memuat dengan tidak benar

Masalah: (Python) Beberapa pustaka tidak memuat dengan benar dari paket deployment

Pustaka dengan modul ekstensi yang tertulis dalam C atau C++ harus disusun dalam lingkungan dengan arsitektur prosesor yang sama dengan Lambda (Amazon Linux). Untuk informasi selengkapnya, lihat Bekerja dengan arsip file.zip untuk fungsi Python Lambda.

Java: Fungsi Anda membutuhkan waktu lebih lama untuk memproses peristiwa setelah memperbarui ke Java 17 dari Java 11

Masalah: (Java) Fungsi Anda membutuhkan waktu lebih lama untuk memproses peristiwa setelah memperbarui ke Java 17 dari Java 11

Tune compiler Anda menggunakan JAVA_TOOL_OPTIONS parameter. Runtime Lambda untuk Java 17 dan versi Java yang lebih baru mengubah opsi kompiler default. Perubahan ini meningkatkan waktu mulai dingin untuk fungsi berumur pendek, tetapi perilaku sebelumnya lebih cocok untuk fungsi komputasi yang intensif dan berjalan lebih lama. Setel JAVA_TOOL_OPTIONS -XX:-TieredCompilation untuk kembali ke perilaku Java 11. Untuk informasi tentang parameter JAVA_TOOL_OPTIONS, lihat Memahami variabel JAVA_TOOL_OPTIONS lingkungan.