Bu konu, tam yönetilen Flink için ölçümleri açıklar.
Notlar
CloudMonitor ve Flink konsolu arasındaki veri tutarsızlıkları
Görüntülenen boyutlardaki farklılıklar: Flink konsolu, yalnızca maksimum gecikme süresini görüntülemek için PromQL sorguları kullanır. Gerçek zamanlı hesaplama senaryolarında ortalama gecikme süresi, veri eğriliği veya tek bölüm tıkanıklıkları gibi ciddi sorunları maskeleyebilir. Bu nedenle, yalnızca maksimum gecikme süresi değerli operasyonel içgörüler sağlar.
Değer tutarsızlıkları: CloudMonitor, ölçümleri hesaplamak için ön toplama mekanizması kullanır. Toplama pencereleri, örnekleme zaman damgaları veya hesaplama mantığındaki farklılıklar nedeniyle CloudMonitor'daki "maksimum" değeri, Flink konsolundaki gerçek zamanlı değerden biraz farklı olabilir. Sorun giderme amacıyla Flink konsolu verilerini doğru kaynak olarak kullanın.
Veri gecikmesi ve watermark yapılandırması
-
Gecikme hesaplama mantığı: Mevcut izleme ölçümü Emit Delay, olay zamanına dayalı olarak aşağıdaki formül kullanılarak hesaplanır:
Gecikme = Geçerli Sistem Zamanı - Veri kaydındaki mantıksal zaman alanı (örn. PriceData.time)
Bu, ölçümün sistemin işleme hızını değil veri güncelliğini yansıttığı anlamına gelir. Kaynak veriler eski olduğunda veya sistem watermark'ları hizalamak için çıktıyı duraklattığında bu ölçüm yüksek olur.
-
Öneriler
Senaryo 1: İş mantığınız doğruluk için watermark'lara dayanır ancak kaynak veriler eskidir
-
Tipik durumlar:
Yukarı akış veri teslimatı doğası gereği gecikmelidir (örn. yavaş olay raporlaması).
Önceki bir güne ait verileri işlemek için geriye dönük doldurma çalıştırıyorsunuz.
İş mantığı, sırasız gelen olayları işlemek için watermark'ların kullanılmasını gerektirir; bu nedenle watermark'lar devre dışı bırakılamaz.
Belirti: İzleme uyarıları yüksek gecikme süresi gösterir ancak Kafka tüketici grubunda gecikme yoktur (lag ≈ 0) ve CPU yükü düşüktür.
-
Öneriler:
Bu gecikme ölçümünü yok sayın: Bu durumda, verinin yaşını yansıttığı için yüksek gecikme beklenen bir durumdur. Bu durum bir sistem arızasını göstermez.
Farklı bir ölçüme geçin: Bunun yerine Kafka tüketici gecikmesini (consumer lag) izleyin. Tüketici gecikmesi sürekli artmıyorsa sistemin yeterli işleme kapasitesi vardır ve müdahale gerekmez.
Senaryo 2: Düşük gecikme süresi gerektirirsiniz ve küçük çapta sırasız gelen olaylara veya veri kaybına tolerans gösterebilirsiniz
-
Tipik durumlar:
Büyük ekran panoları veya gerçek zamanlı risk kontrolü gibi uygulamalar için watermark kaynaklı bekleme süreci çıktıyı yavaşlatır.
İş mantığı, veri kaydının içindeki zaman damgasından (olay zamanı) ziyade verinin ne zaman alındığına (işleme zamanı) daha fazla önem verir.
Belirti: Veri akışı gerçek zamanlıdır ancak watermark büyük bir tolerans penceresiyle (örn. 10 saniyelik gecikme payı) yapılandırıldığından çıktı 10 saniye gecikir.
-
Öneriler:
Watermark'ları kaldırın veya devre dışı bırakın: Hesaplamalar için işleme zamanını kullanacak şekilde geçiş yapın veya watermark bekleme eşik değerini 0 olarak ayarlayın.
Beklenen sonuç: Gecikme ölçümü önemli ölçüde azalacak ve fiili işleme zamanına yaklaşacaktır. Veriler, hizalama için beklemeden varış anında işlenir.
-
Ölçüm özellikleri
Ölçümler yalnızca bir bileşenin mevcut durumunu yansıtır ve bir sorunun kök nedenini belirlemek için yetersizdir. Kapsamlı bir teşhis için her zaman Flink UI'nın backpressure izleyicisini ve diğer araçları kullanın.
1. Operatör backpressure'ı
Belirti: Aşağı akış operatörleri veriyi yeterince hızlı işleyemediğinden kaynak yayım hızını azaltır.
Nasıl tespit edilir: Bu sorunu tespit etmek için Flink UI'nın backpressure izleyicisini kullanın.
-
Ölçüm özellikleri:
sourceIdleTimeperiyodik olarak artar.currentFetchEventTimeLagvecurrentEmitEventTimeLagsürekli olarak artar.Aşırı durum: Bir operatör tamamen takılı kalırsa
sourceIdleTimesürekli olarak artar.
2. Kaynak performans darboğazı
Belirti: Kaynak maksimum hızda okuma yapar ancak veri işleme taleplerini karşılayamaz.
Nasıl tespit edilir: İşte backpressure tespit edilmez.
-
Ölçüm özellikleri:
sourceIdleTimeçok düşük bir değerde kalır (kaynağın tam kapasitede çalıştığını gösterir).currentFetchEventTimeLagvecurrentEmitEventTimeLagbenzerdir ve yüksek kalır.
3. Veri eğriliği veya boş bölümler
Belirti: Veri dağılımı yukarı akış Kafka bölümleri arasında düzensizdir veya bazı bölümler boştur.
Nasıl tespit edilir: Farklı kaynak alt görevlerindeki ölçümleri karşılaştırın.
-
Ölçüm özellikleri:
Belirli bir kaynak alt görevinin
sourceIdleTimedeğeri diğerlerinden önemli ölçüde yüksektir; bu, söz konusu paralel örneğin boşta olduğunu gösterir.
4. Veri gecikmesi
Belirti: Genel iş gecikmesi yüksektir. Darboğazın kaynağın mı yoksa harici bir sistemin mi olduğunu belirlemeniz gerekir.
Nasıl tespit edilir: Boşta kalma süresini, gecikme ölçümleri arasındaki farkı ve birikmiş iş boyutunu birlikte analiz edin.
-
Ölçüm özellikleri:
**Yüksek
sourceIdleTime: Bu durum, kaynağın boşta olduğunu gösterir; bu genellikle Flink'in yavaş işlediği anlamına gelmez, bunun yerine harici sistemdeki** veri üretim hızının düşük olduğunu gösterir.-
Gecikme farkı analizi:
currentEmitEventTimeLagilecurrentFetchEventTimeLagarasındaki farkı karşılaştırın. Bu fark, verinin kaynak operatöründe geçirdiği süreyi temsil eder:Küçük fark (ölçüm değerleri birbirine yakın): Bu durum yetersiz getirme kapasitesini gösterir. Darboğaz genellikle ağ G/Ç bant genişliği veya yetersiz kaynak paralelliğidir.
Büyük fark: Bu durum yetersiz işleme kapasitesini gösterir. Darboğaz genellikle verimsiz veri ayrıştırma veya aşağı akış operatörlerinden gelen backpressure'dır.
**
pendingRecords(bağlayıcı tarafından destekleniyorsa): Bu ölçüm doğrudan harici birikimi** yansıtır. Daha yüksek bir değer, harici sistemde daha ciddi bir veri birikimi olduğunu gösterir.