Topik ini menjelaskan metrik yang didukung oleh Flink yang sepenuhnya dikelola.
Catatan
Ketidaksesuaian data antara Cloud Monitor dan konsol Flink
Perbedaan dalam dimensi tampilan
Konsol Flink menggunakan kueri Prometheus Query Language (PromQL) untuk menampilkan hanya latensi maksimum. Dalam skenario komputasi real-time, latensi rata-rata dapat dengan mudah menyembunyikan masalah kritis seperti kesenjangan data atau pemblokiran pada partisi tunggal. Oleh karena itu, hanya latensi maksimum yang memberikan informasi bernilai untuk operasi dan pemeliharaan (O&M).Deviasi nilai
Cloud Monitor menggunakan mekanisme pra-agregasi untuk menghitung metrik. Karena perbedaan dalam jendela agregasi, waktu pengambilan sampel, atau logika perhitungan, nilai maksimum yang ditampilkan di Cloud Monitor mungkin sedikit berbeda dari nilai real-time yang ditampilkan di konsol Flink. Saat troubleshooting, gunakan data dari konsol Flink sebagai acuan.
Latensi data dan konfigurasi Watermark
Logika perhitungan latensi
Metrik pemantauan saat ini, Emit Delay, dihitung berdasarkan event time. Rumusnya adalah sebagai berikut:Delay = Waktu sistem saat ini - Bidang waktu logis dalam muatan data (misalnya, PriceData.time)
Artinya, metrik ini mencerminkan kesegaran data, bukan kecepatan pemrosesan sistem. Nilai metrik akan tinggi jika datanya sendiri sudah lama atau jika sistem menghentikan sementara output untuk menunggu penyelarasan watermark.
Penyesuaian yang direkomendasikan
Skenario 1: Logika bisnis sangat bergantung pada watermark untuk keakuratan, tetapi sumber data bersifat lama
Situasi khas:
Transmisi data hulu memiliki latensi bawaan, seperti pelaporan instrumen yang lambat.
Data historis sedang diisi ulang, memproses data dari hari sebelumnya.
Logika bisnis harus bergantung pada watermark untuk menangani event yang tidak berurutan dan tidak dapat dinonaktifkan.
Gejala: Peringatan pemantauan menunjukkan latensi tinggi, tetapi kelompok konsumen Kafka tidak memiliki akumulasi pesan (Lag ≈ 0) dan beban CPU rendah.
Rekomendasi:
Abaikan metrik latensi ini: Delay tinggi dalam kasus ini merupakan perilaku bisnis normal karena mencerminkan bahwa datanya memang lama. Ini bukan indikasi kesalahan sistem.
Ubah metrik pemantauan: Insinyur O&M sebaiknya memantau Kafka Consumer Lag (akumulasi pesan) sebagai gantinya. Selama akumulasi tidak terus meningkat, kemampuan pemrosesan sistem normal dan tidak diperlukan intervensi.
Skenario 2: Kinerja real-time diprioritaskan, dan event yang tidak berurutan atau kehilangan data dalam jumlah kecil dapat ditoleransi
Situasi khas:
Untuk dasbor atau kontrol risiko real-time, output menjadi lambat karena data menunggu watermark.
Bisnis lebih peduli pada 'kapan data diterima' daripada 'timestamp dalam data'.
Gejala: Aliran data bersifat real-time, tetapi karena watermark dikonfigurasi dengan jendela toleransi besar—misalnya, memungkinkan delay 10 detik—output data tertunda selama 10 detik.
Rekomendasi:
Hapus atau nonaktifkan watermark: Anda dapat beralih ke processing time untuk perhitungan atau mengatur ambang batas tunggu watermark menjadi 0.
Hasil yang diharapkan: Metrik latensi akan turun secara instan, mendekati waktu pemrosesan fisik, dan data akan diproses serta dioutput sesaat setelah tiba tanpa menunggu penyelarasan.
Karakteristik metrik dalam skenario khas
Metrik hanya mencerminkan status komponen saat ini dan tidak cukup untuk menentukan akar penyebab masalah. Anda harus selalu menggunakan fitur deteksi tekanan balik di UI Flink dan alat pendukung lainnya untuk diagnosis menyeluruh.
1. Tekanan balik Operator
Gejala: Kapasitas pemrosesan hilir yang tidak mencukupi menyebabkan laju pengiriman sumber menurun.
Metode deteksi: Gunakan panel pemantauan tekanan balik di UI Flink.
Karakteristik metrik:
sourceIdleTime meningkat secara periodik.
currentFetchEventTimeLag dan currentEmitEventTimeLag terus meningkat.
Kasus ekstrem: Jika suatu operator benar-benar macet, sourceIdleTime akan terus meningkat.
2. Bottleneck performa sumber
Gejala: Kecepatan baca sumber telah mencapai batasnya tetapi masih belum memenuhi permintaan pemrosesan data.
Metode deteksi: Tidak ada tekanan balik yang terdeteksi dalam pekerjaan.
Karakteristik metrik:
sourceIdleTime tetap pada nilai yang sangat rendah, yang mengindikasikan bahwa sumber beroperasi pada kapasitas penuh.
currentFetchEventTimeLag dan currentEmitEventTimeLag memiliki nilai yang mirip dan tinggi.
3. Kesenjangan data atau partisi kosong
Gejala: Data tersebar tidak merata di seluruh partisi Kafka hulu, atau terdapat partisi kosong.
Metode deteksi: Amati perbedaan metrik antara berbagai sumber.
Karakteristik metrik:
sourceIdleTime dari sumber tertentu jauh lebih tinggi dibandingkan yang lain, yang mengindikasikan bahwa tingkat paralelismenya idle.
4. Analisis latensi data
Gejala: Latensi pekerjaan secara keseluruhan tinggi, dan Anda perlu menentukan apakah bottleneck berada di sumber atau di sistem eksternal.
Metode deteksi: Analisis kombinasi waktu idle, selisih lag, dan akumulasi pesan.
Karakteristik metrik:
sourceIdleTime tinggi:
Ini mengindikasikan bahwa sumber sedang idle. Biasanya berarti bahwa laju output data dari sistem eksternal rendah, bukan karena pemrosesan Flink yang lambat.Analisis selisih lag:
Bandingkan selisih antara currentEmitEventTimeLag dan currentFetchEventTimeLag, yaitu waktu data berada di dalam operator sumber:Selisih kecil (kedua metrik saling berdekatan): Kemampuan tarik tidak mencukupi. Bottleneck berada pada bandwidth I/O jaringan atau tingkat paralelisme sumber yang tidak mencukupi.
Selisih besar: Kemampuan pemrosesan tidak mencukupi. Bottleneck disebabkan oleh penguraian data yang tidak efisien atau keterbatasan akibat tekanan balik dari hilir.
pendingRecords (jika didukung oleh konektor):
Metrik ini secara langsung mencerminkan jumlah data yang tertahan secara eksternal. Nilai yang lebih tinggi mengindikasikan akumulasi data yang lebih parah di sistem eksternal.