Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan masalah runtime
Bagian ini berisi informasi tentang mendiagnosis dan memperbaiki masalah runtime dengan aplikasi Managed Service for Apache Flink Anda.
**Topics**
+ [Alat pemecahan masalah](#troubleshooting-tools)
+ [Masalah aplikasi](troubleshooting-symptoms.md)
+ [Aplikasi dimulai ulang](troubleshooting-rt-restarts.md)
+ [Throughput terlalu lambat](troubleshooting-rt-throughput.md)
+ [Pertumbuhan negara tak terbatas](troubleshooting-rt-stateleaks.md)
+ [Operator terikat I/O](troubleshooting-io-bound-operators.md)
+ [Pelambatan hulu atau sumber dari aliran data Kinesis](troubleshooting-source-throttling.md)
+ [Titik pemeriksaan](troubleshooting-checkpoints.md)
+ [Waktu titik checkpointing](troubleshooting-chk-timeout.md)
+ [Kegagalan pos pemeriksaan untuk aplikasi Apache Beam](troubleshooting-chk-failure-beam.md)
+ [Tekanan balik](troubleshooting-backpressure.md)
+ [Kemiringan data](troubleshooting-data-skew.md)
+ [Kemiringan negara](troubleshooting-state-skew.md)
+ [Integrasikan dengan sumber daya di berbagai Wilayah](troubleshooting-resources-in-different-regions.md)
## Alat pemecahan masalah
Alat utama untuk mendeteksi masalah aplikasi adalah CloudWatch alarm. Dengan menggunakan CloudWatch alarm, Anda dapat mengatur ambang batas untuk CloudWatch metrik yang menunjukkan kondisi kesalahan atau kemacetan dalam aplikasi Anda. Untuk informasi tentang CloudWatch alarm yang direkomendasikan, lihat[Gunakan CloudWatch Alarm dengan Amazon Managed Service untuk Apache Flink](monitoring-metrics-alarms.md).
# Masalah aplikasi
Bagian ini berisi solusi untuk kondisi kesalahan yang mungkin Anda temui dengan Layanan Terkelola untuk aplikasi Apache Flink Anda.
**Topics**
+ [Aplikasi macet dalam status sementara](#troubleshooting-rt-stuck)
+ [Pembuatan snapshot gagal](#troubleshooting-rt-snapshots)
+ [Tidak dapat mengakses sumber daya dalam VPC](#troubleshooting-rt-vpc)
+ [Data hilang saat menulis ke bucket Amazon S3](#troubleshooting-rt-s3)
+ [Aplikasi dalam status RUNNING tetapi tidak memproses data](#troubleshooting-rt-processing)
+ [Snapshot, pembaruan aplikasi, atau kesalahan penghentian aplikasi: InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception)
+ [java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf)
## Aplikasi macet dalam status sementara
Jika aplikasi Anda tetap dalam status transien (`STARTING`,, `UPDATING``STOPPING`, atau`AUTOSCALING`), Anda dapat menghentikan aplikasi Anda dengan menggunakan [StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html)tindakan dengan `Force` parameter yang disetel ke. `true` Anda tidak dapat menghentikan paksa aplikasi di status `DELETING`. Atau, jika aplikasi dalam status `UPDATING` atau `AUTOSCALING`, Anda dapat mengembalikannya ke versi berjalan sebelumnya. Ketika Anda mengembalikan aplikasi, data status dari snapshot terakhir yang berhasil akan dimuat. Jika aplikasi tidak memiliki snapshot, Managed Service for Apache Flink menolak permintaan rollback. Untuk informasi selengkapnya tentang memutar kembali aplikasi, lihat [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html)tindakan.
**catatan**
Menghentikan paksa aplikasi Anda dapat menyebabkan kehilangan data atau duplikasi. Untuk mencegah kehilangan data atau menduplikasi pemrosesan data selama aplikasi dimulai ulang, sebaiknya ambil snapshot yang sering dari aplikasi Anda.
Penyebab aplikasi terhenti mencakup berikut ini:
+ **Status aplikasi terlalu besar:** Memiliki status aplikasi yang terlalu besar atau terlalu persisten dapat menyebabkan aplikasi terhenti selama operasi titik pemeriksaan atau snapshot. Periksa metrik `lastCheckpointDuration` dan `lastCheckpointSize` aplikasi Anda untuk nilai yang terus meningkat atau nilai tinggi yang tidak normal.
+ **Kode aplikasi terlalu besar:** Pastikan file JAR aplikasi Anda lebih kecil dari 512 MB. File JAR yang lebih besar dari 512 MB tidak didukung.
+ **Pembuatan snapshot aplikasi gagal:** Layanan Terkelola untuk Apache Flink mengambil snapshot aplikasi selama permintaan atau permintaan. [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html) Layanan selanjutnya menggunakan status snapshot ini dan mengembalikan aplikasi menggunakan konfigurasi aplikasi yang diperbarui untuk memberikan semantik pemrosesan *exactly-once*. Jika pembuatan snapshot otomatis gagal, lihat [Pembuatan snapshot gagal](#troubleshooting-rt-snapshots) di bawah ini.
+ **Memulihkan dari snapshot gagal:** Jika Anda menghapus atau mengubah operator dalam pembaruan aplikasi dan mencoba memulihkan dari snapshot, pemulihan akan gagal secara default jika snapshot berisi data status untuk operator yang hilang. Selain itu, aplikasi akan terhenti di status `STOPPED` atau `UPDATING`. Untuk mengubah perilaku ini dan memungkinkan pemulihan berhasil, ubah *AllowNonRestoredState*parameter aplikasi [FlinkRunConfiguration](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html)menjadi`true`. Ini akan memungkinkan operasi lanjutkan melewati data status yang tidak dapat dipetakan ke program baru.
+ **Inisialisasi aplikasi memakan waktu lebih lama:** Layanan Terkelola untuk Apache Flink menggunakan batas waktu internal 5 menit (pengaturan lunak) sambil menunggu pekerjaan Flink dimulai. Jika pekerjaan Anda gagal untuk memulai dalam batas waktu ini, Anda akan melihat CloudWatch log sebagai berikut:
```
Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s
```
Jika Anda mengalami kesalahan di atas, itu berarti operasi Anda yang ditentukan di bawah `main` metode pekerjaan Flink memakan waktu lebih dari 5 menit, menyebabkan pembuatan pekerjaan Flink habis pada Layanan Terkelola untuk Apache Flink berakhir. Kami sarankan Anda memeriksa **JobManager**log Flink serta kode aplikasi Anda untuk melihat apakah penundaan dalam `main` metode ini diharapkan. Jika tidak, Anda perlu mengambil langkah-langkah untuk mengatasi masalah ini sehingga selesai dalam waktu kurang dari 5 menit.
Anda dapat memeriksa status aplikasi Anda menggunakan tindakan [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) atau [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html).
## Pembuatan snapshot gagal
Layanan Terkelola untuk layanan Apache Flink tidak dapat mengambil snapshot dalam keadaan berikut:
+ Aplikasi melebihi batas snapshot. Batas untuk snapshot adalah 1.000. Untuk informasi selengkapnya, lihat [Kelola cadangan aplikasi menggunakan snapshot](how-snapshots.md).
+ Aplikasi tidak memiliki izin untuk mengakses sumber atau sink.
+ Kode aplikasi tidak berfungsi dengan benar.
+ Aplikasi mengalami masalah konfigurasi lainnya.
Jika Anda mendapatkan pengecualian saat mengambil snapshot selama pembaruan aplikasi atau saat menghentikan aplikasi, atur properti `SnapshotsEnabled` dari [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html) aplikasi Anda ke `false` dan coba lagi permintaan.
Snapshot dapat gagal jika operator aplikasi Anda tidak disediakan dengan benar. Untuk informasi tentang penyetelan performa operator, lihat [Penskalaan operator](performance-improving.md#performance-improving-scaling-op).
Setelah aplikasi kembali ke status sehat, sebaiknya atur properti `SnapshotsEnabled` aplikasi ke `true`.
## Tidak dapat mengakses sumber daya dalam VPC
Jika aplikasi Anda menggunakan VPC yang berjalan di Amazon VPC, lakukan hal berikut untuk memastikan aplikasi Anda memiliki akses ke sumber dayanya:
+ Periksa CloudWatch log Anda untuk kesalahan berikut. Kesalahan ini menunjukkan aplikasi Anda tidak dapat mengakses sumber daya di VPC Anda:
```
org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.
```
Jika Anda melihat kesalahan ini, pastikan tabel rute Anda diatur dengan benar, dan konektor Anda memiliki pengaturan koneksi yang benar.
Untuk informasi tentang menyiapkan dan menganalisis CloudWatch log, lihat[Pencatatan dan pemantauan di Amazon Managed Service untuk Apache Flink](monitoring-overview.md).
## Data hilang saat menulis ke bucket Amazon S3
Beberapa kehilangan data mungkin terjadi ketika menulis output ke bucket Amazon S3 menggunakan Apache Flink versi 1.6.2. Sebaiknya gunakan versi Apache Flink terbaru yang didukung ketika menggunakan Amazon S3 untuk output langsung. Untuk menulis ke bucket Amazon S3 menggunakan Apache Flink 1.6.2, sebaiknya gunakan Firehose. Untuk informasi selengkapnya tentang penggunaan Firehose dengan Managed Service for Apache Flink, lihat. [Wastafel Firehose](earlier.md#get-started-exercise-fh)
## Aplikasi dalam status RUNNING tetapi tidak memproses data
Anda dapat memeriksa status aplikasi Anda menggunakan tindakan [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) atau [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html). Jika aplikasi Anda memasukkan `RUNNING` status tetapi tidak menulis data ke wastafel Anda, Anda dapat memecahkan masalah dengan menambahkan aliran CloudWatch log Amazon ke aplikasi Anda. Untuk informasi selengkapnya, lihat [Bekerja dengan opsi CloudWatch pencatatan aplikasi](cloudwatch-logs.md#adding_cloudwatch). Aliran log berisi pesan yang dapat Anda gunakan untuk memecahkan masalah aplikasi.
## Snapshot, pembaruan aplikasi, atau kesalahan penghentian aplikasi: InvalidApplicationConfigurationException
Kesalahan yang mirip dengan berikut ini mungkin terjadi selama operasi snapshot, atau selama operasi yang membuat snapshot, seperti memperbarui atau menghentikan aplikasi:
```
An error occurred (InvalidApplicationConfigurationException) when calling the UpdateApplication operation:
Failed to take snapshot for the application xxxx at this moment. The application is currently experiencing downtime.
Please check the application's CloudWatch metrics or CloudWatch logs for any possible errors and retry the request.
You can also retry the request after disabling the snapshots in the Managed Service for Apache Flink console or by updating
the ApplicationSnapshotConfiguration through the AWS SDK
```
Kesalahan ini terjadi ketika aplikasi tidak dapat membuat snapshot.
Jika Anda mengalami kesalahan ini selama operasi snapshot atau operasi yang membuat snapshot, lakukan hal berikut:
+ Nonaktifkan snapshot untuk aplikasi Anda. Anda dapat melakukan ini baik di Managed Service for Apache Flink console, atau dengan menggunakan `SnapshotsEnabledUpdate` parameter tindakan. [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)
+ Selidiki alasan snapshot tidak dapat dibuat. Untuk informasi selengkapnya, lihat [Aplikasi macet dalam status sementara](#troubleshooting-rt-stuck).
+ Aktifkan kembali snapshot ketika aplikasi kembali ke status sehat.
## java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts
Lokasi truststore SSL diperbarui di deployment sebelumnya. Sebagai gantinya, gunakan nilai berikut untuk parameter `ssl.truststore.location`:
```
/usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts
```
# Aplikasi dimulai ulang
Jika aplikasi Anda tidak sehat, tugas Apache Flink terus gagal dan dimulai ulang. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Kondisi ini dapat memiliki gejala berikut:
+ Metrik `FullRestarts` tidak nol. Metrik ini menunjukkan berapa kali tugas aplikasi dimulai ulang sejak Anda memulai aplikasi.
+ Metrik `Downtime` tidak nol. Metrik ini menunjukkan jumlah milidetik ketika aplikasi berada di status `FAILING` atau `RESTARTING`.
+ Log aplikasi berisi perubahan status ke `RESTARTING` atau `FAILED`. Anda dapat menanyakan log aplikasi untuk perubahan status ini menggunakan kueri Wawasan CloudWatch Log berikut:[Menganalisis kesalahan: Kegagalan terkait tugas aplikasi](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
## Penyebab dan solusi
Kondisi berikut dapat menyebabkan aplikasi Anda menjadi tidak stabil dan dimulai ulang berulang kali:
+ **Operator melempar pengecualian:** Jika ada pengecualian dalam operator dalam aplikasi Anda tidak tertangani, aplikasi gagal selesai (dengan menafsirkan bahwa kegagalan tidak dapat ditangani oleh operator). Aplikasi dimulai ulang dari titik pemeriksaan terbaru untuk mempertahankan semantik pemrosesan "exactly-once". Akibatnya, `Downtime` tidak nol selama periode mulai ulang ini. Agar hal ini tidak terjadi, sebaiknya tangani pengecualian yang dapat dicoba lagi dalam kode aplikasi.
Anda dapat menyelidiki penyebab kondisi ini dengan mengkueri log aplikasi Anda untuk perubahan dari status aplikasi Anda dari `RUNNING` ke `FAILED`. Untuk informasi selengkapnya, lihat [Menganalisis kesalahan: Kegagalan terkait tugas aplikasi](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
+ **Aliran data Kinesis tidak disediakan dengan benar:** Jika sumber atau sink untuk aplikasi Anda adalah aliran data Kinesis, periksa [metrik](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) untuk aliran atau kesalahan. `ReadProvisionedThroughputExceeded` `WriteProvisionedThroughputExceeded`
Jika Anda melihat kesalahan ini, Anda dapat meningkatkan throughput yang tersedia untuk aliran Kinesis dengan meningkatkan jumlah serpihan aliran. Untuk informasi selengkapnya, lihat [ Bagaimana cara mengubah jumlah serpihan terbuka di Kinesis Data Streams?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/).
+ **Sumber atau sink lainnya tidak diberikan atau tersedia dengan benar:** Pastikan aplikasi Anda menyediakan sumber dan sink dengan benar. Periksa apakah sumber atau sink apa pun yang digunakan dalam aplikasi (seperti AWS layanan lain, atau sumber atau tujuan eksternal) disediakan dengan baik, tidak mengalami pelambatan baca atau tulis, atau secara berkala tidak tersedia.
Jika Anda mengalami masalah terkait throughput pada layanan dependen Anda, baik meningkatkan sumber daya yang tersedia untuk layanan tersebut, maupun menyelidiki penyebab kesalahan atau ketidaktersediaan apa pun.
+ **Operator tidak disediakan dengan benar:** Jika beban kerja pada utas untuk salah satu operator dalam aplikasi Anda tidak didistribusikan dengan benar, operator dapat kelebihan beban dan aplikasi dapat crash. Untuk informasi tentang penyetelan paralelisme operator, lihat [Kelola penskalaan operator dengan benar](performance-improving.md#performance-improving-scaling-op).
+ **Aplikasi gagal dengan DaemonException:** Kesalahan ini muncul di log aplikasi Anda jika Anda menggunakan versi Apache Flink sebelum 1.11. Anda mungkin perlu meng-upgrade ke versi Apache Flink yang lebih baru sehingga versi KPL 0,14 atau yang lebih baru digunakan.
+ **Aplikasi gagal dengan TimeoutException, FlinkException, atau RemoteTransportException:** Kesalahan ini mungkin muncul di log aplikasi Anda jika pengelola tugas Anda mogok. Jika aplikasi Anda kelebihan beban, manajer tugas Anda dapat mengalami tekanan sumber daya CPU atau memori, menyebabkannya gagal.
Kesalahan ini mungkin terlihat seperti berikut:
+ `java.util.concurrent.TimeoutException: The heartbeat of JobManager with id xxx timed out`
+ `org.apache.flink.util.FlinkException: The assigned slot xxx was removed`
+ `org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Connection unexpectedly closed by remote task manager`
Untuk memecahkan masalah kondisi ini, periksa hal berikut:
+ Periksa CloudWatch metrik Anda untuk lonjakan yang tidak biasa dalam penggunaan CPU atau memori.
+ Periksa aplikasi Anda untuk masalah throughput. Untuk informasi selengkapnya, lihat [Memecahkan masalah kinerja](performance-troubleshooting.md).
+ Periksa log aplikasi Anda untuk pengecualian yang tidak tertangani yang ditimbulkan oleh kode aplikasi Anda.
+ **Aplikasi gagal dengan kesalahan JaxbAnnotationModule Tidak Ditemukan: Kesalahan** ini terjadi jika aplikasi Anda menggunakan Apache Beam, tetapi tidak memiliki dependensi atau versi dependensi yang benar. Managed Service untuk aplikasi Apache Flink yang menggunakan Apache Beam harus menggunakan versi dependensi berikut:
```
2.10.2
...
com.fasterxml.jackson.module
jackson-module-jaxb-annotations
2.10.2
```
Jika Anda tidak menyediakan versi `jackson-module-jaxb-annotations` yang benar sebagai dependensi eksplisit, aplikasi Anda memuatnya dari dependensi lingkungan, dan karena versi tidak cocok, aplikasi mengalami crash saat runtime.
Untuk informasi selengkapnya tentang penggunaan Apache Beam dengan Managed Service for Apache Flink, lihat. [Gunakan CloudFormationMembuat aplikasi menggunakan Apache Beam](examples-beam.md)
+ **Aplikasi gagal dengan java.io. IOException: Jumlah buffer jaringan tidak mencukupi**
Ini terjadi ketika aplikasi tidak memiliki cukup memori yang dialokasikan untuk buffer jaringan. Buffer jaringan memfasilitasi komunikasi antar subtugas. Mereka digunakan untuk menyimpan catatan sebelum transmisi melalui jaringan, dan untuk menyimpan data yang masuk sebelum membedahnya menjadi catatan dan menyerahkannya ke subtugas. Jumlah buffer jaringan diperlukan skala langsung dengan paralelisme dan kompleksitas grafik pekerjaan Anda. Ada sejumlah pendekatan untuk mengurangi masalah ini:
+ Anda dapat mengkonfigurasi yang lebih rendah `parallelismPerKpu` sehingga ada lebih banyak memori yang dialokasikan per subtask dan buffer jaringan. Perhatikan bahwa penurunan `parallelismPerKpu` akan meningkatkan KPU dan karenanya biaya. Untuk menghindari hal ini, Anda dapat menjaga jumlah KPU yang sama dengan menurunkan paralelisme dengan faktor yang sama.
+ Anda dapat menyederhanakan grafik pekerjaan Anda dengan mengurangi jumlah operator atau merantainya sehingga lebih sedikit buffer yang dibutuhkan.
+ Jika tidak, Anda dapat menghubungi https://aws.amazon.com/premiumsupport/ konfigurasi buffer jaringan khusus.
# Throughput terlalu lambat
Jika aplikasi Anda tidak memproses data streaming yang masuk dengan cukup cepat, aplikasi akan berperforma buruk dan menjadi tidak stabil. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Kondisi ini dapat memiliki gejala berikut:
+ Jika sumber data untuk aplikasi Anda adalah aliran Kinesis, metrik `millisbehindLatest` aliran terus meningkat.
+ Jika sumber data untuk aplikasi Anda adalah klaster Amazon MSK, metrik lag konsumen klaster terus meningkat. Untuk informasi selengkapnya, lihat [Pemantauan Lag Konsumen](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html) di [ Panduan Developer Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html).
+ Jika sumber data untuk aplikasi Anda adalah layanan atau sumber yang berbeda, periksa metrik atau data lag konsumen yang tersedia.
## Penyebab dan solusi
Ada banyak penyebab untuk throughput aplikasi yang lambat. Jika aplikasi Anda tidak mengikuti input, periksa hal berikut:
+ Jika lag throughput melonjak, lalu menurun, periksa apakah aplikasi dimulai ulang. Aplikasi Anda akan berhenti memproses input saat dimulai ulang, menyebabkan lonjakan lag. Untuk informasi selengkapnya tentang kegagalan aplikasi, lihat [Aplikasi dimulai ulang](troubleshooting-rt-restarts.md).
+ Jika lag throughput konsisten, periksa untuk melihat apakah performa aplikasi Anda dioptimalkan. Untuk informasi tentang mengoptimalkan performa aplikasi, lihat [Memecahkan masalah kinerja](performance-troubleshooting.md).
+ Jika lag throughput tidak melonjak, tetapi terus meningkat, dan performa aplikasi Anda dioptimalkan, Anda harus meningkatkan sumber daya aplikasi Anda. Untuk informasi tentang peningkatan sumber daya aplikasi, lihat [Menerapkan penskalaan aplikasi](how-scaling.md).
+ Jika aplikasi Anda membaca dari cluster Kafka di Wilayah yang berbeda dan `FlinkKafkaConsumer` atau `KafkaSource` sebagian besar menganggur (tinggi `idleTimeMsPerSecond` atau rendah`CPUUtilization`) meskipun kelambatan konsumen tinggi, Anda dapat meningkatkan nilainya`receive.buffer.byte`, seperti 2097152. Untuk informasi selengkapnya, lihat bagian lingkungan latensi tinggi di konfigurasi [MSK Kustom](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html).
Untuk langkah-langkah pemecahan masalah untuk throughput lambat atau lag konsumen yang meningkat di sumber aplikasi, lihat [Memecahkan masalah kinerja](performance-troubleshooting.md).
# Pertumbuhan negara tak terbatas
Jika aplikasi Anda tidak membuang informasi status yang tidak berlaku dengan benar, informasi akan terus diakumulasi dan menyebabkan masalah performa atau stabilitas aplikasi. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Kondisi ini dapat memiliki gejala berikut:
+ Metrik `lastCheckpointDuration` meningkat atau melonjak secara bertahap.
+ Metrik `lastCheckpointSize` meningkat atau melonjak secara bertahap.
## Penyebab dan solusi
Kondisi berikut dapat menyebabkan aplikasi Anda mengakumulasi data status:
+ Aplikasi Anda menyimpan data status lebih lama dari yang dibutuhkan.
+ Aplikasi Anda menggunakan kueri jendela dengan durasi yang terlalu lama.
+ Anda tidak menetapkan TTL untuk data status Anda. Untuk informasi selengkapnya, lihat [Status Time-To-Live (TTL) di Dokumentasi](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) Apache Flink.
+ Anda menjalankan aplikasi yang bergantung pada Apache Beam versi 2.25.0 atau yang lebih baru. Anda dapat memilih keluar dari versi baru transformasi baca dengan [memperluas eksperimen dan nilai `use_deprecated_read` utama Anda BeamApplicationProperties](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure). Untuk informasi selengkapnya, lihat [Dokumentasi Apache Beam](https://beam.apache.org/blog/beam-2.25.0/#highlights).
Terkadang aplikasi menghadapi pertumbuhan ukuran negara yang terus berkembang, yang tidak berkelanjutan dalam jangka panjang (bagaimanapun juga aplikasi Flink berjalan tanpa batas waktu). Terkadang, ini dapat ditelusuri kembali ke aplikasi yang menyimpan data dalam keadaan dan tidak menua informasi lama dengan benar. Tapi terkadang hanya ada harapan yang tidak masuk akal tentang apa yang bisa diberikan Flink. Aplikasi dapat menggunakan agregasi selama jendela waktu besar yang mencakup hari atau bahkan berminggu-minggu. Kecuali [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)digunakan, yang memungkinkan agregasi inkremental, Flink perlu menjaga peristiwa seluruh jendela dalam keadaan.
Selain itu, ketika menggunakan fungsi proses untuk mengimplementasikan operator kustom, aplikasi perlu menghapus data dari status yang tidak lagi diperlukan untuk logika bisnis. Dalam hal ini, [status time-to-live](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) dapat digunakan untuk secara otomatis menua data berdasarkan waktu pemrosesan. [Layanan Terkelola untuk Apache Flink menggunakan pos pemeriksaan tambahan dan dengan demikian status ttl didasarkan pada pemadatan RocksDB.](https://github.com/facebook/rocksdb/wiki/Compaction) Anda hanya dapat mengamati pengurangan aktual dalam ukuran status (ditunjukkan oleh ukuran pos pemeriksaan) setelah operasi pemadatan terjadi. Khususnya untuk ukuran pos pemeriksaan di bawah 200 MB, kecil kemungkinan Anda mengamati pengurangan ukuran pos pemeriksaan sebagai akibat dari keadaan kedaluwarsa. Namun, savepoints didasarkan pada salinan bersih dari status yang tidak berisi data lama, sehingga Anda dapat memicu snapshot di Managed Service for Apache Flink untuk memaksa penghapusan status usang.
Untuk tujuan debugging, masuk akal untuk menonaktifkan pos pemeriksaan tambahan untuk memverifikasi lebih cepat bahwa ukuran pos pemeriksaan benar-benar berkurang atau stabil (dan menghindari efek pemadatan di RocksBS). Namun, ini membutuhkan tiket ke tim layanan.
# Operator terikat I/O
Yang terbaik adalah menghindari dependensi ke sistem eksternal pada jalur data. Seringkali jauh lebih berkinerja untuk menjaga kumpulan data referensi dalam keadaan daripada menanyakan sistem eksternal untuk memperkaya peristiwa individu. Namun, terkadang ada dependensi yang tidak dapat dengan mudah dipindahkan ke status, misalnya, jika Anda ingin memperkaya peristiwa dengan model pembelajaran mesin yang di-host di Amazon Sagemaker.
Operator yang berinteraksi dengan sistem eksternal melalui jaringan dapat menjadi hambatan dan menyebabkan tekanan balik. Sangat disarankan untuk menggunakan [Asyncio](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) untuk mengimplementasikan fungsionalitas, untuk mengurangi waktu tunggu untuk panggilan individual dan menghindari seluruh aplikasi melambat.
Selain itu, untuk aplikasi dengan operator I/O terikat juga masuk akal untuk meningkatkan pengaturan [ParallelismPerKPU](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) dari Managed Service untuk aplikasi Apache Flink. Konfigurasi ini menjelaskan jumlah subtugas paralel yang dapat dilakukan aplikasi per Kinesis Processing Unit (KPU). Dengan meningkatkan nilai dari default 1 menjadi, katakanlah, 4, aplikasi memanfaatkan sumber daya yang sama (dan memiliki biaya yang sama) tetapi dapat menskalakan hingga 4 kali paralelisme. Ini berfungsi dengan baik untuk aplikasi I/O terikat, tetapi menyebabkan overhead tambahan untuk aplikasi yang tidak I/O terikat.
# Pelambatan hulu atau sumber dari aliran data Kinesis
**Gejala**: Aplikasi ini bertemu `LimitExceededExceptions` dari aliran data Kinesis sumber hulu mereka.
**Penyebab Potensi**: Pengaturan default untuk konektor Kinesis pustaka Apache Flink diatur untuk dibaca dari sumber aliran data Kinesis dengan pengaturan default yang sangat agresif untuk jumlah maksimum catatan yang diambil per panggilan. `GetRecords` Apache Flink dikonfigurasi secara default untuk mengambil 10.000 catatan per `GetRecords` panggilan (panggilan ini dibuat secara default setiap 200 ms), meskipun batas per pecahan hanya 1.000 catatan.
Perilaku default ini dapat menyebabkan pelambatan saat mencoba mengkonsumsi dari aliran data Kinesis, yang akan memengaruhi kinerja dan stabilitas aplikasi.
Anda dapat mengonfirmasi ini dengan memeriksa CloudWatch `ReadProvisionedThroughputExceeded` metrik dan melihat periode yang berkepanjangan atau berkelanjutan di mana metrik ini lebih besar dari nol.
Anda juga dapat melihat ini di CloudWatch log untuk Amazon Managed Service untuk aplikasi Apache Flink Anda dengan mengamati kesalahan lanjutan`LimitExceededException`.
**Resolusi**: Anda dapat melakukan salah satu dari dua hal untuk menyelesaikan skenario ini:
+ Turunkan batas default untuk jumlah rekaman yang diambil per panggilan `GetRecords`
+ Aktifkan Bacaan Adaptif di Amazon Managed Service untuk aplikasi Apache Flink Anda. [Untuk informasi selengkapnya tentang fitur Bacaan Adaptif, lihat SHARD\$1USE\$1ADAPTIVE\$1READS](https://nightlies.apache.org/flink/flink-docs-release-1.10/api/java/org/apache/flink/streaming/connectors/kinesis/config/ConsumerConfigConstants.html#SHARD_USE_ADAPTIVE_READS)
# Titik pemeriksaan
Pos pemeriksaan adalah mekanisme Flink untuk memastikan bahwa status aplikasi toleran terhadap kesalahan. Mekanisme ini memungkinkan Flink untuk memulihkan status operator jika pekerjaan gagal dan memberikan aplikasi semantik yang sama dengan eksekusi bebas kegagalan. Dengan Managed Service for Apache Flink, status aplikasi disimpan di RocksDB, key/value toko tertanam yang menjaga status kerjanya pada disk. Ketika pos pemeriksaan diambil, status juga diunggah ke Amazon S3 sehingga meskipun disk hilang maka pos pemeriksaan dapat digunakan untuk memulihkan status aplikasi.
Untuk informasi selengkapnya, lihat [Bagaimana Cara Kerja Snapshotting Status](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work)? .
## Tahapan pemeriksaan
Untuk subtugas operator checkpointing di Flink ada 5 tahap utama:
+ Waiting [**Start Delay**] - Flink menggunakan penghalang pos pemeriksaan yang dimasukkan ke dalam aliran sehingga waktu dalam tahap ini adalah waktu operator menunggu penghalang pos pemeriksaan untuk mencapainya.
+ Alignment [**Alignment Duration**] - Pada tahap ini subtugas telah mencapai satu penghalang tetapi menunggu hambatan dari aliran input lainnya.
+ Sinkronkan pos pemeriksaan [**Durasi Sinkronisasi**] — Tahap ini adalah saat subtugas benar-benar memotret status operator dan memblokir semua aktivitas lain pada subtugas.
+ Async checkpointing [**Async Duration**] — Sebagian besar tahap ini adalah subtugas yang mengunggah status ke Amazon S3. Selama tahap ini, subtugas tidak lagi diblokir dan dapat memproses catatan.
+ Mengakui — Ini biasanya merupakan tahap pendek dan hanyalah subtugas yang mengirimkan pengakuan ke JobManager dan juga melakukan pesan komit apa pun (misalnya dengan sink Kafka).
Masing-masing tahapan ini (selain dari Mengakui) memetakan ke metrik durasi untuk pos pemeriksaan yang tersedia dari WebUI Flink, yang dapat membantu mengisolasi penyebab pos pemeriksaan yang panjang.
Untuk melihat definisi yang tepat dari setiap metrik yang tersedia di pos pemeriksaan, buka Tab [Riwayat](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab).
## Menyelidiki
Saat menyelidiki durasi pos pemeriksaan yang panjang, hal terpenting yang harus ditentukan adalah kemacetan untuk pos pemeriksaan, yaitu operator dan subtugas apa yang paling lama menuju pos pemeriksaan dan tahap mana dari subtugas itu yang membutuhkan waktu yang lama. Ini dapat ditentukan menggunakan WebUI Flink di bawah tugas pos pemeriksaan pekerjaan. Antarmuka Web Flink menyediakan data dan informasi yang membantu menyelidiki masalah pos pemeriksaan. Untuk rincian lengkap, lihat [Memantau Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/).
Hal pertama yang harus dilihat adalah **Durasi Akhir ke Akhir** setiap operator dalam grafik Job untuk menentukan operator mana yang membutuhkan waktu lama untuk melakukan pemeriksaan dan memerlukan penyelidikan lebih lanjut. Per dokumentasi Flink, definisi durasinya adalah:
*Durasi dari stempel waktu pemicu hingga pengakuan terbaru (atau n/a jika belum ada pengakuan yang diterima). Durasi ujung ke akhir untuk pos pemeriksaan lengkap ditentukan oleh subtugas terakhir yang mengakui pos pemeriksaan. Waktu ini biasanya lebih besar dari subtugas tunggal yang perlu benar-benar memeriksa status.*
Durasi lain untuk pos pemeriksaan juga memberikan informasi yang lebih halus tentang di mana waktu dihabiskan.
Jika **Durasi Sinkronisasi** tinggi maka ini menunjukkan sesuatu sedang terjadi selama snapshotting. Selama tahap ini `snapshotState()` dipanggil untuk kelas yang mengimplementasikan antarmuka SnapshotState; ini bisa menjadi kode pengguna sehingga thread-dump dapat berguna untuk menyelidiki ini.
**Durasi Async** yang panjang akan menyarankan bahwa banyak waktu dihabiskan untuk mengunggah status ke Amazon S3. Ini dapat terjadi jika statusnya besar atau jika ada banyak file status yang sedang diunggah. Jika ini masalahnya, perlu diselidiki bagaimana status digunakan oleh aplikasi dan memastikan bahwa struktur data asli Flink digunakan jika memungkinkan ([Menggunakan Status Keyed](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state)). Layanan Terkelola untuk Apache Flink mengonfigurasi Flink sedemikian rupa untuk meminimalkan jumlah panggilan Amazon S3 untuk memastikan ini tidak terlalu lama. Berikut ini adalah contoh statistik checkpointing operator. Ini menunjukkan bahwa **Durasi Async** relatif panjang dibandingkan dengan statistik checkpointing operator sebelumnya.
![\[Menyelidiki pos pemeriksaan\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint.png)
**Start Delay** yang tinggi akan menunjukkan bahwa sebagian besar waktu dihabiskan untuk menunggu penghalang pos pemeriksaan mencapai operator. Ini menunjukkan bahwa aplikasi membutuhkan waktu untuk memproses catatan, yang berarti penghalang mengalir melalui grafik pekerjaan secara perlahan. Ini biasanya terjadi jika Job mengalami backpressure atau jika operator terus-menerus sibuk. Berikut ini adalah contoh JobGraph di mana KeyedProcess operator kedua sibuk.
![\[Menyelidiki pos pemeriksaan\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint2.png)
Anda dapat menyelidiki apa yang memakan waktu lama dengan menggunakan Flink Flame Graphs atau TaskManager thread dump. Setelah leher botol diidentifikasi, dapat diselidiki lebih lanjut menggunakan Flame-graphs atau thread-dumps.
## Pembuangan benang
Thread dump adalah alat debugging lain yang berada pada tingkat yang sedikit lebih rendah dari grafik api. Thread dump menampilkan status eksekusi semua thread pada satu titik waktu. Flink mengambil dump thread JVM, yang merupakan status eksekusi dari semua thread dalam proses Flink. Keadaan utas disajikan oleh jejak tumpukan utas serta beberapa informasi tambahan. Grafik api sebenarnya dibuat menggunakan beberapa jejak tumpukan yang diambil secara berurutan. Grafik adalah visualisasi yang dibuat dari jejak ini yang membuatnya mudah untuk mengidentifikasi jalur kode umum.
```
"KeyedProcess (1/3)#0" prio=5 Id=1423 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:154)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(>19)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
Di atas adalah cuplikan dump utas yang diambil dari UI Flink untuk satu utas. Baris pertama berisi beberapa informasi umum tentang utas ini termasuk:
+ Nama thread *KeyedProcess (1/3) \$10*
+ Prioritas thread *prio=5*
+ Utas unik Id *Id=1423*
+ Status utas *RUNNABLE*
Nama utas biasanya memberikan informasi tentang tujuan umum utas. Utas operator dapat diidentifikasi dengan namanya karena utas operator memiliki nama yang sama dengan operator, serta indikasi subtugas mana yang terkait dengannya, misalnya, utas *KeyedProcess (1/3) \$10* berasal dari *KeyedProcess*operator dan berasal dari subtugas pertama (dari 3).
Thread dapat berada di salah satu dari beberapa negara bagian:
+ BARU - Thread telah dibuat tetapi belum diproses
+ RUNNABLE — Thread adalah eksekusi pada CPU
+ DIBLOKIR - Utas sedang menunggu utas lain untuk melepaskan kuncinya
+ WAITING — Thread sedang menunggu dengan menggunakan`wait()`,`join()`, atau `park()` metode
+ TIMED\$1WAITING — Thread sedang menunggu dengan menggunakan metode sleep, wait, join atau park, tetapi dengan waktu tunggu maksimum.
**catatan**
Di Flink 1.13, kedalaman maksimum satu stacktrace di thread dump dibatasi hingga 8.
**catatan**
Thread dump harus menjadi pilihan terakhir untuk men-debug masalah kinerja dalam aplikasi Flink karena dapat menantang untuk dibaca, memerlukan beberapa sampel untuk diambil dan dianalisis secara manual. Jika memungkinkan, lebih baik menggunakan grafik nyala api.
### Pembuangan utas di Flink
**Di Flink, dump thread dapat diambil dengan memilih opsi **Task Manager** di bilah navigasi kiri UI Flink, memilih pengelola tugas tertentu, dan kemudian menavigasi ke tab Thread Dump.** Thread dump dapat diunduh, disalin ke editor teks favorit Anda (atau thread dump analyzer), atau dianalisis langsung di dalam tampilan teks di UI Web Flink (namun, opsi terakhir ini bisa sedikit kikuk.
Untuk menentukan Task Manager mana yang akan mengambil thread dump dari **TaskManagers**tab dapat digunakan ketika operator tertentu dipilih. Ini menunjukkan bahwa operator berjalan pada subtugas yang berbeda dari operator dan dapat berjalan pada Manajer Tugas yang berbeda.
![\[Menggunakan Thread Dump\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint4.png)
Dump akan terdiri dari beberapa jejak tumpukan. Namun ketika menyelidiki dump yang terkait dengan operator adalah yang paling penting. Ini dapat dengan mudah ditemukan karena utas operator memiliki nama yang sama dengan operator, serta indikasi subtugas mana yang terkait dengannya. Misalnya jejak tumpukan berikut berasal dari *KeyedProcess*operator dan merupakan subtugas pertama.
```
"KeyedProcess (1/3)#0" prio=5 Id=595 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:155)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:19)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
Ini bisa menjadi membingungkan jika ada beberapa operator dengan nama yang sama tetapi kita dapat memberi nama operator untuk menyiasatinya. Contoh:
```
....
.process(new ExpensiveFunction).name("Expensive function")
```
## [Grafik api](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/)
Grafik api adalah alat debugging yang berguna yang memvisualisasikan jejak tumpukan kode yang ditargetkan, yang memungkinkan jalur kode yang paling sering diidentifikasi. Mereka dibuat dengan pengambilan sampel jejak tumpukan beberapa kali. Sumbu x dari grafik nyala menunjukkan profil tumpukan yang berbeda, sedangkan sumbu y menunjukkan kedalaman tumpukan, dan panggilan dalam jejak tumpukan. Sebuah persegi panjang tunggal dalam grafik nyala mewakili pada bingkai tumpukan, dan lebar bingkai menunjukkan seberapa sering muncul di tumpukan. Untuk detail selengkapnya tentang grafik api dan cara menggunakannya, lihat [Grafik Api](https://www.brendangregg.com/flamegraphs.html).
Di Flink, grafik api untuk operator dapat diakses melalui UI Web dengan memilih operator dan kemudian memilih **FlameGraph**tab. Setelah sampel yang cukup dikumpulkan, flamegraph akan ditampilkan. Berikut ini adalah FlameGraph untuk ProcessFunction yang mengambil banyak waktu untuk pos pemeriksaan.
![\[Menggunakan grafik Flame\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint3.png)
Ini adalah grafik api yang sangat sederhana dan menunjukkan bahwa semua waktu CPU dihabiskan dalam tampilan foreach di `processElement` dalam ExpensiveFunction operator. Anda juga mendapatkan nomor baris untuk membantu menentukan di mana eksekusi kode berlangsung.
# Waktu titik checkpointing
Jika aplikasi Anda tidak dioptimalkan atau disediakan dengan benar, titik pemeriksaan bisa gagal. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Jika titik pemeriksaan gagal untuk aplikasi Anda, `numberOfFailedCheckpoints` akan lebih besar dari nol.
Titik pemeriksaan bisa gagal karena kegagalan langsung, seperti kesalahan aplikasi, atau karena kegagalan sementara, seperti kehabisan sumber daya aplikasi. Periksa log dan metrik aplikasi Anda untuk gejala berikut:
+ Kesalahan dalam kode Anda.
+ Kesalahan mengakses layanan dependen aplikasi Anda.
+ Kesalahan serialisasi data. Jika serializer default tidak dapat membuat serialisasi data aplikasi Anda, aplikasi akan gagal. Untuk informasi tentang menggunakan serializer kustom dalam aplikasi Anda, lihat [Jenis Data dan Serialisasi](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) di Dokumentasi Apache Flink.
+ Kesalahan Kehabisan Memori.
+ Lonjakan atau peningkatan stabil dalam metrik berikut:
+ `heapMemoryUtilization`
+ `oldGenerationGCTime`
+ `oldGenerationGCCount`
+ `lastCheckpointSize`
+ `lastCheckpointDuration`
Untuk informasi selengkapnya tentang pemantauan pos pemeriksaan, lihat [Memantau Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/) di Dokumentasi Apache Flink.
## Penyebab dan solusi
Pesan kesalahan log aplikasi Anda menunjukkan penyebab kegagalan langsung. Kegagalan sementara dapat disebabkan hal berikut:
+ Persediaan KPU aplikasi Anda tidak cukup. Untuk informasi tentang meningkatkan persediaan aplikasi Anda, lihat [Menerapkan penskalaan aplikasi](how-scaling.md).
+ Ukuran status aplikasi Anda terlalu besar. Anda dapat memantau ukuran status aplikasi Anda menggunakan metrik `lastCheckpointSize`.
+ Data status aplikasi Anda tidak didistribusikan secara merata di antara kunci. Jika aplikasi Anda menggunakan operator `KeyBy`, pastikan data yang masuk dibagi rata di antara kunci. Jika sebagian besar data ditetapkan ke satu kunci, ini membuat hambatan yang menyebabkan kegagalan.
+ Aplikasi Anda mengalami tekanan balik memori atau pengumpulan sampah. Pantau `heapMemoryUtilization`, `oldGenerationGCTime`, dan `oldGenerationGCCount` aplikasi Anda untuk lonjakan atau nilai yang terus meningkat.
# Kegagalan pos pemeriksaan untuk aplikasi Apache Beam
Jika aplikasi Beam Anda dikonfigurasi dengan [shutdownSourcesAfterIdleMs](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs)disetel ke 0ms, pos pemeriksaan dapat gagal dipicu karena tugas dalam status “SELESAI”. Bagian ini menjelaskan gejala dan resolusi untuk kondisi ini.
## Gejala
Buka Layanan Terkelola untuk CloudWatch log aplikasi Apache Flink Anda dan periksa apakah pesan log berikut telah dicatat. Pesan log berikut menunjukkan bahwa pos pemeriksaan gagal dipicu karena beberapa tugas telah selesai.
```
{
"locationInformation": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator.onTriggerFailure(CheckpointCoordinator.java:888)",
"logger": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator",
"message": "Failed to trigger checkpoint for job your job ID since some tasks of job your job ID has been finished, abort the checkpoint Failure reason: Not all required tasks are currently running.",
"threadName": "Checkpoint Timer",
"applicationARN": your application ARN,
"applicationVersionId": "5",
"messageSchemaVersion": "1",
"messageType": "INFO"
}
```
Ini juga dapat ditemukan di dasbor Flink di mana beberapa tugas telah memasuki status “SELESAI”, dan pos pemeriksaan tidak dimungkinkan lagi.
![\[Tugas dalam keadaan “SELESAI”\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/beam_checkpoint_failure.png)
## Penyebab
shutdownSourcesAfterIdleMs adalah variabel konfigurasi Beam yang mematikan sumber yang telah menganggur selama waktu milidetik yang dikonfigurasi. Setelah sumber dimatikan, pos pemeriksaan tidak dimungkinkan lagi. Hal ini dapat menyebabkan [kegagalan pos pemeriksaan](https://issues.apache.org/jira/browse/FLINK-2491).
Salah satu penyebab tugas memasuki status “SELESAI” shutdownSourcesAfter IdleMs adalah ketika diatur ke 0ms, yang berarti bahwa tugas yang menganggur akan segera dimatikan.
## Solusi
Untuk mencegah tugas memasuki status “SELESAI” segera, setel shutdownSourcesAfter IdleMs ke long.max\$1value. Ini dapat dilakukan dengan dua cara:
+ Opsi 1: Jika konfigurasi balok Anda diatur di halaman konfigurasi aplikasi Managed Service for Apache Flink, maka Anda dapat menambahkan pasangan nilai kunci baru untuk mengatur shutdpwnSourcesAfteridle Ms sebagai berikut:
![\[Setel shutdownSourcesAfter IdleMs ke Long.MAX_Value\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png)
+ Opsi 2: Jika konfigurasi balok Anda diatur dalam file JAR Anda, maka Anda dapat mengatur shutdownSourcesAfter IdleMs sebagai berikut:
```
FlinkPipelineOptions options = PipelineOptionsFactory.create().as(FlinkPipelineOptions.class); // Initialize Beam Options object
options.setShutdownSourcesAfterIdleMs(Long.MAX_VALUE); // set shutdownSourcesAfterIdleMs to Long.MAX_VALUE
options.setRunner(FlinkRunner.class);
Pipeline p = Pipeline.create(options); // attach specified options to Beam pipeline
```
# Tekanan balik
Flink menggunakan tekanan balik untuk menyesuaikan kecepatan pemrosesan masing-masing operator.
Operator dapat berjuang untuk terus memproses volume pesan yang diterimanya karena berbagai alasan. Operasi mungkin memerlukan lebih banyak sumber daya CPU daripada yang tersedia operator, Operator mungkin menunggu I/O operasi selesai. Jika operator tidak dapat memproses peristiwa dengan cukup cepat, itu membangun tekanan balik di operator hulu yang masuk ke operator lambat. Hal ini menyebabkan operator hulu melambat, yang selanjutnya dapat menyebarkan tekanan balik ke sumber dan menyebabkan sumber beradaptasi dengan keseluruhan throughput aplikasi dengan memperlambat juga. Anda dapat menemukan deskripsi tekanan balik yang lebih dalam dan cara kerjanya di [Bagaimana Apache Flink™](https://www.ververica.com/blog/how-flink-handles-backpressure) menangani tekanan balik.
Mengetahui operator mana dalam aplikasi yang lambat memberi Anda informasi penting untuk memahami akar penyebab masalah kinerja dalam aplikasi. Informasi tekanan balik [diekspos melalui Dasbor Flink](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). Untuk mengidentifikasi operator lambat, cari operator dengan nilai tekanan balik tinggi yang paling dekat dengan wastafel (operator B pada contoh berikut). Operator yang menyebabkan kelambatan kemudian menjadi salah satu operator hilir (operator C dalam contoh). B dapat memproses peristiwa lebih cepat, tetapi ditekan kembali karena tidak dapat meneruskan output ke operator lambat yang sebenarnya C.
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
Setelah Anda mengidentifikasi operator yang lambat, cobalah untuk memahami mengapa itu lambat. Mungkin ada banyak alasan dan terkadang tidak jelas apa yang salah dan dapat memerlukan berhari-hari debugging dan pembuatan profil untuk menyelesaikannya. Berikut adalah beberapa alasan yang jelas dan lebih umum, beberapa di antaranya dijelaskan lebih lanjut di bawah ini:
+ Operator melakukan I/O lambat, misalnya, panggilan jaringan (pertimbangkan untuk menggunakan AsynciO sebagai gantinya).
+ Ada kemiringan dalam data dan satu operator menerima lebih banyak peristiwa daripada yang lain (verifikasi dengan melihat jumlah pesan dari subtugas individu (yaitu, contoh in/out dari operator yang sama) di dasbor Flink.
+ Ini adalah operasi intensif sumber daya (jika tidak ada kemiringan data, pertimbangkan penskalaan untuk pekerjaan CPU/memory terikat atau meningkat `ParallelismPerKPU` untuk I/O pekerjaan terikat)
+ Logging ekstensif di operator (kurangi logging seminimal mungkin untuk aplikasi produksi atau pertimbangkan untuk mengirim output debug ke aliran data sebagai gantinya).
## Menguji throughput dengan Discarding Sink
[Discarding Sink](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html) mengabaikan semua peristiwa yang diterimanya saat masih menjalankan aplikasi (aplikasi tanpa sink gagal dijalankan). Ini sangat berguna untuk pengujian throughput, pembuatan profil, dan untuk memverifikasi apakah aplikasi melakukan penskalaan dengan benar. Ini juga merupakan pemeriksaan kewarasan yang sangat pragmatis untuk memverifikasi apakah sink menyebabkan tekanan balik atau aplikasi (tetapi hanya memeriksa metrik tekanan balik seringkali lebih mudah dan lebih mudah).
Dengan mengganti semua sink aplikasi dengan wastafel pembuangan dan membuat sumber tiruan yang menghasilkan data yang r misalnya data produksi, Anda dapat mengukur throughput maksimum aplikasi untuk pengaturan paralelisme tertentu. Anda kemudian juga dapat meningkatkan paralelisme untuk memverifikasi bahwa aplikasi menskalakan dengan benar dan tidak memiliki hambatan yang hanya muncul pada throughput yang lebih tinggi (misalnya, karena kemiringan data).
# Kemiringan data
Aplikasi Flink dijalankan pada cluster dengan cara terdistribusi. Untuk skala ke beberapa node, Flink menggunakan konsep aliran yang dikunci, yang pada dasarnya berarti bahwa peristiwa aliran dipartisi sesuai dengan kunci tertentu, misalnya, id pelanggan, dan Flink kemudian dapat memproses partisi yang berbeda pada node yang berbeda. [Banyak operator Flink kemudian dievaluasi berdasarkan partisi ini, misalnya, [Keyed Windows, [Process Functions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/process_function/)](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/) dan Async I/O.](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/)
Memilih kunci partisi sering tergantung pada logika bisnis. Pada saat yang sama, banyak praktik terbaik untuk, misalnya, [DynamoDB](https://aws.amazon.com/dynamodb/) dan Spark, sama-sama berlaku untuk Flink, termasuk:
+ memastikan kardinalitas kunci partisi yang tinggi
+ menghindari kemiringan dalam volume acara antar partisi
Anda dapat mengidentifikasi kemiringan di partisi dengan membandingkan catatan subtugas (yaitu, contoh received/sent dari operator yang sama) di dasbor Flink. Selain itu, Layanan Terkelola untuk pemantauan Apache Flink dapat dikonfigurasi untuk mengekspos metrik untuk `numRecordsIn/Out` dan `numRecordsInPerSecond/OutPerSecond` pada tingkat subtugas juga.
# Kemiringan negara
Untuk operator stateful, yaitu, operator yang mempertahankan status untuk logika bisnis mereka seperti windows, kemiringan data selalu mengarah ke kemiringan status. Beberapa subtugas menerima lebih banyak peristiwa daripada yang lain karena kemiringan data dan karenanya juga mempertahankan lebih banyak data dalam keadaan. Namun, bahkan untuk aplikasi yang memiliki partisi seimbang secara merata, mungkin ada kemiringan dalam berapa banyak data yang disimpan dalam keadaan. Misalnya, untuk jendela sesi, beberapa pengguna dan sesi masing-masing mungkin jauh lebih lama daripada yang lain. Jika sesi yang lebih panjang kebetulan menjadi bagian dari partisi yang sama, itu dapat menyebabkan ketidakseimbangan ukuran status yang disimpan oleh subtugas yang berbeda dari operator yang sama.
Kemiringan status tidak hanya meningkatkan lebih banyak memori dan sumber daya disk yang dibutuhkan oleh subtugas individu, tetapi juga dapat menurunkan kinerja aplikasi secara keseluruhan. Saat aplikasi mengambil pos pemeriksaan atau savepoint, status operator dipertahankan ke Amazon S3, untuk melindungi status terhadap kegagalan node atau cluster. Selama proses ini (terutama dengan semantik sekali yang diaktifkan secara default pada Managed Service for Apache Flink), pemrosesan berhenti dari perspektif eksternal hingga selesai. checkpoint/savepoint Jika ada kemiringan data, waktu untuk menyelesaikan operasi dapat diikat oleh satu subtugas yang telah mengumpulkan jumlah status yang sangat tinggi. Dalam kasus ekstrim, pengambilan checkpoints/savepoints dapat gagal karena satu subtugas tidak dapat bertahan.
Jadi mirip dengan kemiringan data, kemiringan status secara substansional dapat memperlambat aplikasi.
Untuk mengidentifikasi kemiringan status, Anda dapat memanfaatkan dasbor Flink. Temukan pos pemeriksaan atau savepoint terbaru dan bandingkan jumlah data yang telah disimpan untuk subtugas individual dalam detailnya.
# Integrasikan dengan sumber daya di berbagai Wilayah
Anda dapat mengaktifkan penggunaan `StreamingFileSink` untuk menulis ke bucket Amazon S3 di Wilayah yang berbeda dari aplikasi Layanan Terkelola untuk Apache Flink melalui pengaturan yang diperlukan untuk replikasi lintas Wilayah dalam konfigurasi Flink. Untuk melakukan ini, ajukan tiket dukungan di [AWS Dukungan Center](https://console.aws.amazon.com/support/home#/).