Pemantauan dalam Layanan Terkelola untuk Apache Flink - Layanan Terkelola untuk Apache Flink

Amazon Managed Service untuk Apache Flink sebelumnya dikenal sebagai Amazon Kinesis Data Analytics untuk Apache Flink.

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

Pemantauan dalam Layanan Terkelola untuk Apache Flink

Saat menjalankan aplikasi streaming dalam produksi, Anda mulai menjalankan aplikasi secara terus menerus dan tanpa batas waktu. Sangat penting untuk menerapkan pemantauan dan pengkhawatiran yang tepat dari semua komponen tidak hanya aplikasi Flink. Jika tidak, Anda berisiko melewatkan masalah yang muncul sejak dini dan hanya menyadari peristiwa operasional setelah sepenuhnya terurai dan jauh lebih sulit untuk dikurangi. Hal-hal umum yang harus dipantau meliputi:

  • Apakah sumbernya menelan data?

  • Apakah data dibaca dari sumber (dari perspektif sumber)?

  • Apakah aplikasi Flink menerima data?

  • Apakah aplikasi Flink dapat mengikuti atau tertinggal?

  • Apakah aplikasi Flink menyimpan data ke wastafel (dari perspektif aplikasi)?

  • Apakah wastafel menerima data?

Metrik yang lebih spesifik kemudian harus dipertimbangkan untuk aplikasi Flink. CloudWatch Dasbor ini memberikan titik awal yang baik. Untuk informasi selengkapnya tentang metrik apa yang harus dipantau untuk aplikasi produksi, lihatGunakan CloudWatch Alarm dengan Amazon Managed Service untuk Apache Flink. Metrik ini meliputi:

  • records_lag_max dan millisbehindLatest— Jika aplikasi menggunakan Kinesis atau Kafka, metrik ini menunjukkan apakah aplikasi tertinggal dan perlu diskalakan untuk mengikuti beban saat ini. Ini adalah metrik generik yang baik yang mudah dilacak untuk semua jenis aplikasi. Tetapi itu hanya dapat digunakan untuk penskalaan reaktif, yaitu, ketika aplikasi sudah tertinggal.

  • cpuUtilizationdan heapMemoryUtilization— Metrik ini memberikan indikasi yang baik tentang pemanfaatan sumber daya aplikasi secara keseluruhan dan dapat digunakan untuk penskalaan proaktif kecuali aplikasi terikat I/O.

  • downtime — Downtime yang lebih besar dari nol menunjukkan bahwa aplikasi telah gagal. Jika nilainya lebih besar dari 0, aplikasi tidak memproses data apa pun.

  • lastCheckpointSizedan lastCheckpointDuration— Metrik ini memantau berapa banyak data yang disimpan dalam keadaan dan berapa lama waktu yang dibutuhkan untuk mengambil pos pemeriksaan. Jika pos pemeriksaan bertambah atau memakan waktu lama, aplikasi terus menghabiskan waktu untuk pos pemeriksaan dan memiliki lebih sedikit siklus untuk pemrosesan yang sebenarnya. Di beberapa titik, pos pemeriksaan mungkin tumbuh terlalu besar atau memakan waktu lama sehingga gagal. Selain memantau nilai absolut, pelanggan juga harus mempertimbangkan untuk memantau tingkat perubahan dengan RATE(lastCheckpointSize) danRATE(lastCheckpointDuration).

  • numberOfFailedCheckpoints — Metrik ini menghitung jumlah pos pemeriksaan yang gagal sejak aplikasi dimulai. Tergantung pada aplikasinya, itu bisa ditoleransi jika pos pemeriksaan gagal sesekali. Tetapi jika pos pemeriksaan secara teratur gagal, aplikasi tersebut kemungkinan tidak sehat dan perlu perhatian lebih lanjut. Kami merekomendasikan pemantauan RATE(numberOfFailedCheckpoints) untuk alarm pada gradien dan bukan pada nilai absolut.