Realtime Compute for Apache Flink:Konfigurasi pemantauan yang direkomendasikan

Scenario

Combined metric/Event name

Rule configuration

Level

Action

Job failure alert

Job status event

= FAILED (event alerting)

P0

1. Periksa apakah kebijakan restart salah dikonfigurasi. Kami merekomendasikan penggunaan konfigurasi default.

2. Tentukan apakah penyebabnya adalah kebijakan restart atau JobManager atau TaskManager yang tidak normal.

3. Pulihkan pekerjaan dari snapshot terbaru atau checkpoint yang berhasil.

Failover surge

Overview/Number of error recoveries per minute for the job

≥ 1 for 1 consecutive period

P0

1. Identifikasi masalahnya.

• Analisis log failover, JobManager, dan TaskManager untuk menemukan akar penyebabnya.

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

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

2. Pulihkan pekerjaan dari snapshot terbaru atau checkpoint yang berhasil.

Consecutive checkpoint failures

Number of successful checkpoints (5 min cumulative)

≤ 0 for 1 consecutive period

P0

1. Untuk informasi selengkapnya, lihat System checkpoints untuk memecahkan akar penyebab kegagalan.

2. Identifikasi masalahnya.

• Masalah parameter (seperti timeout): Sesuaikan konfigurasi checkpoint.

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

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

High business latency (with data)

Overview/Business latency && Records in from source per second

Maximum latency ≥ 180000

Input records ≥ 0

for 3 consecutive periods

P1

1. Untuk informasi selengkapnya, lihat Metric description untuk menyelidiki penyebab latensi.

• Data plane: Apakah waktu kejadian tidak berurutan?

• Traffic level: Menunjukkan apakah terjadi lonjakan trafik hulu atau backpressure hilir.

2. Ambil tindakan berdasarkan penyebabnya.

• Internal: Sesuaikan parameter WITH konektor dan scale out operator yang menjadi bottleneck.

• External: Optimalkan konfigurasi layanan eksternal, seperti menyesuaikan kebijakan throttling atau menambah jumlah koneksi.

Upstream data stream interruption detection

Overview/Records in from source per second &&

Source Raw Data Timestamp

Input records ≤ 0 (business-dependent)

Maximum idle time ≥ 60000

for 5 consecutive periods

P1

1. Periksa taskmanager.log, flame graphs, dan metrik layanan hulu untuk memastikan apakah masalahnya disebabkan oleh tidak adanya data hulu, throttling, error, atau stack thread yang macet.

2. Ambil tindakan berdasarkan penyebabnya.

• Connector issue: Optimalkan parameter konektor seperti timeout atau konkurensi, atau tambahkan lebih banyak sumber daya TaskManager.

• Upstream/downstream service issue: Beri tahu pemilik bisnis hulu untuk menangani masalah tersebut.

• Flink internal bottleneck (seperti backpressure atau sistem freeze): Pertama, selesaikan akar penyebab bottleneck, misalnya masalah hilir. Kemudian, restart pekerjaan dari checkpoint terbaru.

No downstream data output detection

Overview/Records out to sink per second

≤ 0 for 5 consecutive periods

P1

1. Pastikan apakah data mencapai operator sink.

• Business logic filtering: Gunakan log atau metrik untuk memastikan apakah semua data masukan difilter karena tidak memenuhi kondisi.

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

2. Pastikan apakah sink dapat menulis ke sistem eksternal.

• Connection layer: Apakah kolam koneksi sink penuh? Apakah konektivitas jaringan normal?

• Target system layer: Apakah database atau layanan hilir memiliki tabel terkunci, ruang disk space tidak mencukupi, write throttling, atau error lainnya?

3. Sebagai langkah sementara, aktifkan dual-write ke sistem backup storage.

CPU performance bottlenecks

CPU/ CPU utilization of a single TM

≥ 85 % for 10 consecutive periods

P2

1. Gunakan flame graphs atau UI Flink untuk menemukan operator hot spot.

• Business logic: Periksa apakah terdapat perhitungan kompleks, parsing JSON, atau user-defined function (UDF) yang tidak efisien.

• Data skew: Periksa apakah kunci hot spot menyebabkan satu tugas kelebihan beban karena volume data yang berlebihan.

• Insufficient resources: Apakah tingkat paralelisme dan sumber daya TM saat ini mampu menangani trafik data? Apakah terjadi backpressure parah?

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

2. Tingkatkan tingkat paralelisme untuk operator bottleneck, atau alokasikan lebih banyak core CPU ke TaskManager.

Memory performance bottlenecks

TM heap memory used

≥ 90 % for 10 consecutive periods

P2

1. Periksa log GC untuk mengidentifikasi masalahnya.

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

• Insufficient capacity: Penggunaan memori heap secara konsisten tinggi, sering memicu Full GC dan menurunkan kinerja.

• Sudden OOM: Memori langsung penuh saat memproses catatan atau batch data tertentu, langsung menyebabkan OutOfMemoryError.

2. Ambil tindakan berdasarkan penyebabnya: Tambah ukuran heap atau tingkatkan tingkat paralelisme untuk mengurangi volume data per slot.