View a markdown version of this page

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: Debugging jarak jauh dengan Visual Studio Code

Masalah: Kes ulitan memecahkan masalah perilaku fungsi Lambda yang kompleks di lingkungan aktual AWS

Lambda menyediakan fitur debugging jarak jauh melalui. AWS Toolkit for Visual Studio Code Untuk pengaturan dan instruksi umum, lihatDebug fungsi Lambda dari jarak jauh dengan Visual Studio Code.

Untuk petunjuk terperinci tentang pemecahan masalah, kasus penggunaan lanjutan, dan ketersediaan wilayah, lihat Remote debugging fungsi Lambda di Panduan AWS Toolkit for Visual Studio Code Pengguna.

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, itu mungkin dibatasi oleh memori atau daya pemrosesan yang tersedia untuk fungsi tersebut. Konfigurasikan fungsi dengan memori tambahan untuk meningkatkan memori dan CPU.

Lambda: Muatan peristiwa tak terduga

Masalah: Kes alahan fungsi terkait dengan JSON yang salah format atau validasi data yang tidak memadai.

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

JSON yang salah format dapat terjadi ketika disediakan oleh layanan upstream yang tidak menggunakan proses yang kuat untuk memeriksa struktur JSON. Hal ini terjadi ketika layanan menggabungkan string teks atau menyematkan input pengguna yang belum dibersihkan. JSON juga sering diserialkan untuk melewati antar layanan. Selalu mengurai struktur JSON baik sebagai produsen maupun konsumen JSON untuk memastikan bahwa strukturnya 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 muatan acara untuk melakukan perhitungan. Namun, kode gagal 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-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 payload peristiwa Lambda adalah 1 MB. Bergantung pada konten, payload yang lebih besar mungkin berarti lebih banyak item yang diteruskan ke fungsi atau lebih banyak data biner yang disematkan dalam atribut JSON. 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 payload. Namun, setelah payload berisi lebih dari 30 item, fungsi habis waktu dan menimbulkan kesalahan. Untuk menghindari hal ini, pastikan bahwa 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 diatur dengan benar.

Selain itu, muatan acara tertentu dapat berisi pointer ke sumber daya lain. Misalnya, fungsi Lambda dengan memori 128 MB mungkin melakukan pemrosesan gambar pada file JPG yang disimpan sebagai objek di S3. Fungsi ini bekerja seperti yang diharapkan dengan file gambar yang lebih kecil.

Namun, ketika file JPG yang lebih besar disediakan sebagai input, fungsi Lambda menimbulkan 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 muatan.

Lambda: Kesalahan pengkodean dan decoding JSON

Masalah: NoSuchKey pengecualian saat mengurai input JSON.

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

contoh
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 adajames beswick.jpg. Karena pengkodean URL mengubah spasi dan karakter lain dalam nama kunci, Anda harus memastikan bahwa fungsi memecahkan kode kunci sebelum menggunakan data ini:

contoh
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 untuk kode atau konfigurasinya juga. Ini memaksa instance fungsi Anda yang sedang berjalan, yang memiliki kredenSIAL usang, untuk berhenti dan diganti.

catatan

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

Lambda: Tidak semua log fungsi saya muncul

Masalah: Log fungsi hilang di CloudWatch Log, meskipun izin saya benar

Jika Anda Akun AWS mencapai batas kuota CloudWatch Logs-nya, memper CloudWatch lambat pencatatan fungsi. Ketika ini terjadi, beberapa log keluaran oleh fungsi Anda mungkin tidak muncul di CloudWatch Log.

Jika fungsi Anda mengeluarkan log pada tingkat yang terlalu tinggi untuk Lambda memprosesnya, ini juga dapat menyebabkan output log tidak muncul di CloudWatch Log. Ketika Lambda tidak dapat mengirim log CloudWatch pada kecepatan yang dihasilkan fungsi Anda, ia akan menjatuhkan log untuk mencegah pelaksanaan fungsi Anda melambat. Berharap untuk secara konsisten mengamati log yang terputus saat throughput log Anda melebihi 2 MB/s untuk aliran log tunggal.

Jika fungsi Anda dikonfigurasi untuk menggunakan log berformat JSON, Lambda mencoba mengirim peristiwa ke logsDropped Logs saat CloudWatch menjatuhkan log. Namun, saat CloudWatch membatasi pencatatan fungsi Anda, peristiwa ini mungkin tidak mencapai CloudWatch Log, jadi Anda tidak akan selalu melihat catatan saat Lambda menjatuhkan log.

Untuk memeriksa apakah Anda Akun AWS telah mencapai batas kuota CloudWatch Logs-nya, 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 ku PutLogEvents throttle limit in transactions per second ota untuk melihat pemanfaatan 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 statis untuk mempelajari selengkapnya.

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 selesai dieksekusi

Banyak pustaka, termasuk AWS SDK, beroperasi secara 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 pengendali fungsi Lambda di Node.js.

Lambda: Menjalankan versi fungsi atau alias yang tidak diinginkan

Masalah: Versi fungsi atau alias tidak dipanggil

Saat Anda menerbitkan 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 tertentu atau alias, ini adalah versi fungsi yang dipublikasikan yang tidak dapat diubah sebagai tambahan. $LATEST Saat memecahkan masalah fungsi-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 log START:

CloudWatch log yang menunjukkan baris START dengan nomor versi fungsi yang disorot.

Lambda: Mendeteksi loop tak terbatas

Masalah: P ola loop tak terbatas 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 waktu fungsi habis. Anda dapat mengidentifikasi ini dengan memantau batas waktu, dan kemudian memperbaiki perilaku perulangan.

Jenis loop kedua adalah antara fungsi Lambda dan AWS sumber daya lainnya. 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 antrian Amazon SQS dan tabel DynamoDB. Anda dapat menggunakan deteksi loop rekursif untuk mengidentifikasi pola-pola ini.

Diagram menunjukkan loop tak terbatas antara fungsi Lambda dan bucket S3, di mana setiap pemanggilan memicu peristiwa lain.

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 yang dikonsumsi, pastikan bahwa data baru tidak memicu peristiwa yang sama. Atau, gunakan pemfilter an peristiwa. 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 menggunakan. Jika Lambda menemukan atribut, itu tidak akan menghasilkan pemanggilan lain.

Umum: Layanan hilir tidak tersedianya

Masalah: Layanan hilir yang bergantung pada fungsi Lambda Anda tidak tersedia

Untuk fungsi Lambda yang memanggil titik akhir pihak ketiga atau sumber daya hilir lainnya, pastikan bahwa 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 mungkin muncul sebagai batas waktu Lambda atau pengecualian jika respons kesalahan layanan tidak ditangani dalam kode fungsi.

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

Karena Lambda dapat berskala 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 instans Amazon RDS dapat disimpan untuk jangka waktu tertentu dalam fungsi untuk mencegah kueri berlebihan.

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

  • Proxy — Jika koneksi berumur panjang biasanya digunakan, seperti untuk instans Amazon RDS, 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. Lambda-based

AWS SDK: Versi dan pembaruan

Masalah: AWS SDK yang disertakan pada runtime bukan versi terbaru

Masalah: AWS SDK disertakan pada runtime diperbarui secara otomatis

Runtime untuk bahasa yang ditafsirkan menyertakan versi AWS SDK. Lambda secara berkala memperbarui runtime ini untuk menggunakan versi SDK terbaru. Untuk menemukan versi SDK yang disertakan dalam runtime Anda, lihat bagian berikut:

Untuk menggunakan versi AWS SDK yang lebih baru, 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

Terapkan fungsi Node.js Lambda 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 file .zip atau JAR

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

Setel kompiler 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 yang intensif secara komputasi dan berjalan lebih lama. Set JAVA_TOOL_OPTIONS el -XX:-TieredCompilation ke untuk kembali ke perilaku Java 11. Untuk informasi tentang parameter JAVA_TOOL_OPTIONS, lihat Memahami variabel lingkungan JAVA_TOOL_OPTIONS.

Kafka: Penanganan kesalahan dan masalah konfigurasi coba lagi

Masalah: Pemetaan sumber peristiwa Kafka gagal mengonfigurasi pengaturan coba ulang atau tujuan saat gagal

Konfigurasi percobaan ulang Kafka dan tujuan pada kegagalan hanya tersedia untuk pemetaan sumber peristiwa dengan mode disediakan diaktifkan. Pastikan bahwa Anda telah mengonfigur MinimumPollers asi ProvisionedPollerConfig sebelum mencoba mengatur konfigurasi coba ulang.

Kesalahan konfigurasi umum:

  • Percobaan ulang tak terbatas dengan batch bisect — Anda tidak dapat mengaktifkan BisectBatchOnFunctionError kapan MaximumRetryAttempts disetel ke -1 (tak terbatas). Tetapkan batas percobaan ulang yang terbatas atau nonaktifkan batch dua bagian.

  • Rekursi topik yang sama — Topik tujuan Kafka pada kegagalan tidak dapat sama dengan topik sumber Anda. Pilih nama topik yang berbeda untuk topik surat mati Anda.

  • Format tujuan Kafka tidak valid — Gunakan kafka://<topic-name> format saat menentukan topik Kafka sebagai tujuan saat gagal.

  • kafka: masalah WriteData izin — Pastikan peran eksekusi Anda memiliki kafka-cluster:WriteData izin untuk topik tujuan. Topik tidak ada pengecualian batas waktu atau masalah pelambatan API penulisan mungkin memerlukan peningkatan batas akun.