Prometheus'ta Öngörücü Alarmlarda Yanlış Pozitifleri Çözmek
Prometheus tabanlı öngörücü alarm modellerinde offline başarıyla üretim gürültüsü arasındaki farkın nedeni ve query_range hizalama, rate() ve şema kontrolü ile çözümü.
Bir anomali tespit modeli offline testte %94 hassasiyet gösterse de, canlı Prometheus query_range verisiyle beslenince pod restartlarında ve scrape boşluklarında yanlış alarm üretmeye başlıyor. Kaynak, bu sorunun kök nedeninin eşik değeri ayarı değil, eğitim ve çıkarım (inference) sırasında kullanılan sorguların birbirinden farklı davranması olduğunu gösteriyor: farklı step/çözünürlük değerleri, ham counter metriklerinin rate() dönüşümü yapılmadan doğrudan modele verilmesi, staleness sonrası oluşan NaN değerlerinin ele alınmaması ve rolling deploy sırasında pod_name gibi açık etiketlerin sebep olduğu kardinalite patlaması.
Çözüm iki ana adımda toplanıyor. Birincisi, canlı sorgunun eğitim sorgusuyla matematiksel olarak eşdeğer olmasını garanti etmek: step değerini sabit bir sabit olarak tanımlamak, ham counter'ları PromQL seviyesinde rate() ile dönüştürmek, kısa veri boşluklarını sınırlı ffill ile doldurup uzun boşluklarda skorlamayı tamamen durdurmak. İkincisi ise özellik (feature) sözleşmesini dondurmak: level:metric:operation adlandırma kuralıyla recording rule'lar üzerinden stabil metrikler üretmek, özellik adları listesinin hash'ini eğitim anında hesaplayıp her çıkarımda doğrulamak ve model dosyasını hem özellik hash'i hem sklearn sürümüyle versiyonlamak.
Bu yaklaşım, mühendislere modeli değil veri hattını (pipeline) güvenilir kılmanın önemini gösteriyor; çünkü offline doğruluk metrikleri, üretimdeki sorgu semantiği ve şema kaymalarını yakalayamıyor. Prometheus ve scikit-learn ile MLOps çalışan ekipler için, recording rule tabanlı özellik sabitleme ve hash tabanlı şema doğrulaması, sessiz veri bozulmalarını erken tespit etmenin pratik bir yolu olarak sunuluyor.