Elastic, change point detection ile alarm gürültüsünü azaltıyor

Elastic, Significant Events özelliğinde change point detection kullanarak aynı ödeme kesintisi için tetiklenen iki ES|QL kuralını tek alarmda birleştiriyor. Bir discovery agent her kuralın kendi sorgusunu log’lara karşı yeniden çalıştırıyor ve deneme senaryosunda son bir saatte 1.156 hatalı satır sayıyor. Yazı, Knowledge Indicator (KI) çıkarımıyla başlayan üç bölümlük serinin son parçası.

Kısaca Change point detection nedir

Change point detection, bir zaman serisinin istatistiksel davranışının değiştiği noktaları bulan analiz yöntemidir. Ani sıçrama, düşüş, seviye kayması veya trend değişimini sabit bir eşiğe ihtiyaç duymadan yakalar. Observability (gözlemlenebilirlik) araçlarında metrik ve log tabanlı alarmları sabit eşik yerine serinin kendi geçmişiyle karşılaştırmak için kullanılır.

ES|QL nedir?

ES|QL, Elasticsearch’ün pipe karakteriyle zincirlenen adımlardan oluşan sorgu dilidir. Veriyi filtreleme, dönüştürme ve aggregation adımlarını tek bir sorguda sırayla yazmaya imkân verir. Kibana’da log analizi, görselleştirme ve alarm kuralları için kullanılır; klasik Query DSL’e göre daha okunabilir bir sözdizimi hedefler.

Change point detection eşik yerine geçmişe bakıyor

Alarm gürültüsü çoğu ortamda aynı yerden doğuyor. Tek bir kesinti, birbirine yakın birkaç kural ve her biri için ayrı bildirim. Elastic’in change point detection yaklaşımı bunu iki katmanda kesiyor. Önce kuralın eşleşip eşleşmediğine değil, davranışının değişip değişmediğine bakıyor. Ardından aynı olayı anlatan kuralları tek alarmda topluyor.

Sabit eşik yazmak için her kuralın normal seviyesini önceden bilmeniz gerekir. Gün boyu aynı tolere edilen hatayı basan bir servis bu hesabı bozar. Elasticsearch’ün change_point aggregation’ı her kuralın sonuç serisini kendi yakın geçmişiyle karşılaştırıyor. Spike, dip, step veya trend değişimini bir anlamlılık değeriyle raporluyor.

Örnekte iki ödeme kuralı aynı 676 dokümanla birlikte sıçradı. P-value 0.0000127 çıktı, kabaca 80.000’de bir.

Sabit oranda tetiklenen bir kural seri durağan kaldığı için hiç detection üretmiyor. Değişmiş durumda kalan kural da kesinti boyunca yalnızca bir detection veriyor.

Model kanıt topluyor, kararı kod veriyor

Yazının en taşınabilir kısmı iş bölümü. Hangi kuralın değiştiğine, hangi detection’ın agent’a gideceğine ve alarmın durumuna kod karar veriyor. Model ise log’ların kuralı doğrulayıp doğrulamadığına, hangi kuralların birlikte gruplanacağına ve olayın ciddiyetine bakıyor.

Model sorguyu düzenleyemiyor. WHERE koşuluna, alan adlarına ve FROM kısmına dokunamıyor. Doğrulama sorgusu, KI’da saklanan sorgunun önüne zaman filtresi eklenmiş hâli. Böylece model kendi hipotezine uyan bir sorgu yazıp onu kanıt diye sunamıyor.

LLM’i alarm hattına sokmayı düşünüyorsanız bu sınırı aynen kopyalayın. Modele yalnızca önceden doğrulanmış sorguları çalıştırma yetkisi verin. Alarmda geçen her sayı, onu üreten sorguyla birlikte saklansın ki operatör kanıtı kendisi açabilsin.

Kuyruk mantığı da kendi sisteminize taşınabilir. Detection ancak agent işi bitirdiğini bildirince kapanıyor. Alarm yazımı dahil herhangi bir adım hata verirse kural bir sonraki çalışmada kuyruğa dönüyor. Sıralama ciddiyete ve bekleme süresine göre yapılıyor.

Gece 3’te sorulan üç soru

Agent hatayı doğruladıktan sonra üç aggregation sorgusu daha çalıştırıyor: son bir saatteki yayılım, son 24 saatteki trend (en fazla 50 bucket) ve 14 güne kadar geriye giden ilk ve son görülme zamanı. Hepsi aggregation olduğu için kaynak ne kadar büyük olursa olsun birkaç satır dönüyor.

Son sorgu Elastic dışında da işe yarar. Son görülme bir dakika önceyse kesinti sürüyor; bir saat önceyse bitmiş, sayı ne gösterirse göstersin.

FROM logs.otel
| WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend
| WHERE <scope>
| WHERE <failure>
| STATS earliest = MIN(@timestamp), latest = MAX(@timestamp)

<scope> operasyonun başarılı veya hatalı bütün satırlarını seçiyor, <failure> hatalı olanları işaretliyor. Ödeme kurallarında scope yoktu, çünkü sorgu yalnızca hata metnine bakıyordu. Agent bu yüzden 1.156 satırlık sayım verdi ama hata oranını ölçemedi.

Kural sorgularınızı yazarken işlemin tamamını seçen bir scope koşulu tanımlayın. Oran olmadan tek bir gürültülü servisi, bütün çağıranları vuran bir arızadan ayırmak zorlaşıyor.

Promote edilmeyen sorgu alarm üretmiyor

Change point detection zinciri yalnızca kurala dönüşmüş sorgular için çalışıyor. Serinin ikinci bölümündeki en isabetli sorgu olan checkout startup sorgusu 25 puan aldı, kurala dönüşmedi ve hiç tetiklenmedi. Otomatik promote eşiği burada bir false negative (yanlış negatif) kaynağına dönüşüyor.

Bu yapıyı kullanacaksanız düşük puanlı ama isabetli KI’ları elle gözden geçirin ve gerekenleri elle promote edin. Puan izleme sıklığını da belirliyor. Critical kurallar kısa pencerede ince bucket’larla izleniyor. Geri kalanlar uzun pencerede kaba bucket’larla izleniyor ve bu, tepki süresini uzatıp false positive (yanlış pozitif) alarmları azaltıyor. Düşük puan almış bir kural kısa süreli bir kesintiyi bu yüzden kaçırabilir.

Blast radius hesabında agent yalnızca doğrulanmış satırların desteklediği varlıkları adlandırıyor. Örnekteki sorgu üç feature ID’ye bağlıydı, fakat bütün satırlar frontend’den geldiği için alarma yalnızca frontend-payment-grpc girdi. Checkout kenarı sorguya bağlı olduğu hâlde, o yoldan satır gelmediği için alarmda yer almadı.