Realtime Compute for Apache Flink:Konfigurasi dan templat peringatan

Scenario

Metric/event name

Rule configuration

Severity

Actions

Job failure

Job run status event

= FAILED (Event-based alert)

P0

1. Periksa apakah kebijakan restart salah dikonfigurasi. Disarankan menggunakan konfigurasi default.

2. Tentukan apakah kegagalan disebabkan oleh kebijakan restart atau oleh exception pada JobManager/TaskManager.

3. Pulihkan job dari savepoint terbaru atau checkpoint yang berhasil.

Spike in failovers

Overview / NumOfRestart

≥ 1 selama 1 periode berturut-turut

P0

1. Identifikasi akar penyebabnya.

• Analisis log failover, JobManager, dan TaskManager untuk detail error.

• Abaikan: Kegagalan mesin yang jarang terjadi dan dapat pulih otomatis.

• Perbaiki: Bug kode, bottleneck sumber daya, atau kesalahan konfigurasi.

2. Pulihkan job dari savepoint terbaru atau checkpoint yang berhasil.

Consecutive checkpoint failures

NumOfCheckpoints (agregat 5 menit)

≤ 0 selama 1 periode berturut-turut

P0

1. Lihat System checkpoints untuk mendiagnosis akar penyebab kegagalan checkpoint.

2. Identifikasi dan selesaikan masalah tersebut.

• Masalah parameter (misalnya, timeout): Sesuaikan konfigurasi terkait checkpoint.

• Skalabilitas sumber daya (misalnya, backpressure): Gunakan dynamic scaling untuk menambahkan sumber daya ke operator yang mengalami backpressure.

3. Perbarui konfigurasi secara dinamis atau pulihkan job dari checkpoint terakhir yang berhasil.

High latency (with data ingress)

Overview / CurrentEmitEventTimeLag && NumOfRecordsInFromSourcePerSecond

Latensi maksimum ≥ 180.000 ms

Input records > 0

selama 3 periode berturut-turut

P1

1. Lihat Monitor metrics untuk mengidentifikasi penyebab latensi.

• Data: Apakah waktu event tidak berurutan?

• Traffic: Apakah terjadi lonjakan traffic upstream atau backpressure dari sistem downstream?

• Internal: Sesuaikan opsi WITH konektor atau tingkatkan skala operator yang menjadi bottleneck.

• Eksternal: Optimalkan konfigurasi layanan eksternal, seperti menyesuaikan kebijakan rate-limiting atau menambah jumlah koneksi.

Upstream data flow interruption

Overview / NumOfRecordsInFromSourcePerSecond &&

SourceIdleTime

Input records ≤ 0 (tergantung logika bisnis Anda)

Waktu idle maksimum ≥ 60.000 ms

selama 5 periode berturut-turut

P1

1. Periksa taskmanager.log, flame graph, dan metrik layanan upstream untuk memastikan apakah masalahnya disebabkan oleh tidak adanya data upstream, rate limiting, atau exception, atau stack thread yang macet.

• Masalah konektor: Optimalkan parameter konektor (misalnya, timeout, concurrency), atau tambahkan lebih banyak sumber daya TaskManager.

• Masalah layanan upstream: Beri tahu pemilik layanan upstream untuk menyelesaikan masalah tersebut.

• Bottleneck internal Flink (misalnya, backpressure atau sistem membeku): Selesaikan akar penyebab bottleneck (seperti masalah downstream), lalu restart job dari checkpoint terbaru.

No data output

Overview / NumOfRecordsOutToSinkPerSecond

≤ 0 selama 5 periode berturut-turut

P1

1. Verifikasi apakah data mencapai operator sink.

• Filtering logika bisnis: Gunakan log atau metrik untuk memastikan apakah semua data input difilter karena tidak memenuhi kondisi tertentu.

• Data terlambat dibuang: Periksa konfigurasi watermark dan window untuk memastikan apakah data dibuang karena terlambat.

2. Verifikasi apakah sink dapat menulis ke sistem eksternal.

• Tingkat koneksi: Apakah kolam koneksi sink telah habis? Apakah koneksi jaringan stabil?

• Tingkat sistem tujuan: Periksa database atau layanan downstream untuk lock tabel, disk space tidak mencukupi, write throttling, atau error lainnya.

3. Sebagai fallback sementara, terapkan dual-write ke sistem backup storage.

CPU performance bottleneck

CPU / TMCPUUsage

≥ 85% selama 10 periode berturut-turut

P2

1. Gunakan flame graph atau UI Flink untuk mengidentifikasi operator hotspot.

• Logika bisnis: Komputasi kompleks, parsing JSON, atau user-defined function (UDF) yang tidak efisien.

• Data skew: Kunci panas menyebabkan satu task kelebihan beban karena volume data besar.

• Sumber daya tidak mencukupi: Apakah parallelism dan sumber daya TaskManager saat ini sesuai dengan traffic data? Apakah terjadi backpressure parah?

• GC sering: Gunakan log atau metrik JVM untuk memeriksa apakah tekanan memori menyebabkan Full GC sering, yang mengonsumsi CPU signifikan.

2. Tingkatkan parallelism operator bottleneck atau alokasikan lebih banyak core CPU ke TaskManager.

Memory performance bottleneck

TMHeapMemoryUsed

≥ 90% selama 10 periode berturut-turut

P2

1. Analisis log GC untuk mengidentifikasi masalahnya.

• Memory leak: Gunakan UI Flink atau dasbor pemantauan untuk mengamati apakah memori heap gagal kembali ke garis dasar setelah GC dan garis dasar terus meningkat.

• Kapasitas tidak mencukupi: Jika penggunaan memori heap konsisten tinggi, hal ini dapat memicu Full GC sering dan menurunkan kinerja.

• OOM mendadak: Periksa apakah pemrosesan record atau batch data tertentu menyebabkan memori langsung habis, sehingga langsung memicu OutOfMemoryError.

2. Tingkatkan ukuran heap atau parallelism untuk mengurangi volume data per slot.