Atlassian, otomatik olay oluşturma sistemini besleyen olay keşif platformunu Apache Kafka, Kubernetes üzerinde Apache Flink ve OpenTelemetry kullanarak yeniden inşa etti. 18 aylık çalışmanın ardından yayımlanan ölçümlere göre, olayın metriğe ulaşma süresi 40 saniyenin üzerinden 10 saniyenin altına inerken sürdürülebilir kapasite, %50 örnekleme kullanıldığında günde yaklaşık 500 milyon olaydan günde 1 milyardan fazla olaya yükseldi.
Proje kendisini tamamlanmış bir başarı öyküsü olarak sunmuyor. İzleme kapsamındaki olayların geri çağırma oranı yaklaşık %60'tan Haziran 2026'da %86'lık zirveye yükseldi, ardından Ağustos'ta %64'e geriledi. Doğruluk da hedeflenen seviyenin altında kaldı. Bu durum, ekibi dedektörün kendi kalitesi ile ölçümle donatılmış ürün ve deneylerin kapsama alanı arasında ayrım yapmaya yöneltti.
Olay akışı etrafında inşa edilen platform
Atlassian, milyonlarca kiracı için ondan fazla bulut ürünü işletiyor ve bu ürünler kullanıcı etkileşimlerinden her gün milyarlarca olay üretiyor. Olaylar görev başlangıcını ve sonucunu; kiracı, kullanıcı, deney ve HTTP kodu hakkındaki verilerle birlikte içeriyor. Platform bu verileri üç soruyu hızla yanıtlamak için kullanıyor: Bir sorun var mı? Etkisinin boyutu ne? Hangi ekip, hangi önem derecesiyle uyarılmalı?
Yeni tasarımda olaylar, akışın tamamının uygulama içinde tüketilmesi yerine Apache Kafka veri yolu düzeyinde filtreleniyor. Yaklaşık 770 satırlık YAML'den oluşan abonelik filtresi, yazılım yapılandırmasının bir parçası olarak tutuluyor. Ardından tek bir Apache Flink 1.20 uygulaması, Kubernetes üzerinde olayları işliyor; olayları kiracı verileriyle zenginleştiriyor, metrikleri OpenTelemetry üzerinden gönderiyor ve olay etkisini 60 saniyelik pencerelerde topluyor.
Ekip, toplanan verilerin depolanmasında Apache Parquet ve anahtar değerler için çok bölgeli bir depo kullandı. Impact API ise etkilenen kullanıcı ve kiracıların sayısı hakkında yanıtlar sağlıyor. AutoHOT motoru uyarıları olaylara dönüştürüyor, önem derecesi matrisi uyguluyor, geçici uyarıları engelliyor ve etkiyi her dakika yeniden değerlendiriyor.
Performans ve maliyet kazanımları
- Sanal makine sayısı, kuyruk ve önbellekleme katmanlarına ek olarak yaklaşık 90 makineden dört Kubernetes konteynerına düşürüldü.
- Aylık işletim maliyeti yaklaşık 20.000 dolardan yaklaşık 650 dolara geriledi; bu, yaklaşık %97'lik bir düşüş anlamına geliyor.
- Veri kaybı olmadan Kafka olaylarının yaklaşık 20 dakika içinde yeniden oynatılması sayesinde işlem kesintisinden kurtarma mümkün hale geldi.
- Etki panosunun sorgu süresi yaklaşık 10 saniyeden yaklaşık bir saniyeye indi.
- İki hafta süren paralel çalışma sırasında eski hatla eşleşme oranı %99,9'a ulaştı.
Tasarım, etkilenen benzersiz kullanıcıları hesaplamak için kullanıcı kimliklerini saklamak yerine yaklaşık %1,5 hata payıyla HyperLogLog'a dayandı. Kafka'nın yeniden oynatılmasını satırların iki kez eklenmesi olmadan kurtarılabilir hale getirmek için idempotent depolama anahtarları da kullanıldı. Ekip, eski metrik adlarını StatsD hattı üzerinden korudu. Böylece mevcut SLO panoları ve dedektörler geçiş sırasında değişiklik yapılmadan çalışmaya devam edebildi.
Performans rakamları neden yeterli değil?
Olay sonuçları, veri hattını hızlandırmanın mutlaka daha iyi kapsama anlamına gelmediğini gösteriyor. Dokuz ay içinde 263 büyük olay meydana geldi, ancak yalnızca 117 olay, yani %44,5'i, izlemeyle donatılmış deneyleri etkiledi. Bu olayların 80'i keşfedildi; bu da sistemin o dönemdeki toplam büyük olayların yalnızca %30,4'ünü yakaladığı anlamına geliyor.
Doğruluk da uyarı türüne göre değişti. Sistem tarafından otomatik olarak oluşturulan Sev2 olaylarının doğruluğu mali yıl boyunca yaklaşık %85 olurken, daha düşük önem derecesine sahip erken uyarıların doğruluğu %70 ile %79 arasında değişti. Dalgalanmaların bastırılması, reddedilen geçici uyarı biletlerini yaklaşık %80 oranında azalttı. Buna karşılık, metrik sistemindeki gecikme veri düşüşünü sıfır olarak değerlendirdi ve bu da yanlış uyarı dalgası oluşturdu. Sorun, düşük hacim dedektörlerine en az 120 saniyelik bir gecikme eklenerek giderildi.
Açık kalan sınırlamalar
En büyük mantıksal sorun, sessizliğin sağlık durumu gibi görünebilmesi. Bir veritabanının tamamen durması sayfanın yüklenmesini engelleyebilir ve bu nedenle hiçbir hata olayı üretmeyebilir. Olay hattının kendisinin durması da dedektörü kör bırakabilir. Bu nedenle ekip veri hacmi düşüşü dedektörleri ve metrik güncelliği kontrolleri ekledi; 5xx kenar hataları ve sentetik problar gibi bağımsız sinyalleri dahil etmeyi planlıyor.
Ekip ayrıca olayın keşfedilmesi ile etkisinin ölçülmesinin birbirinden ayrı iki sorun olduğunu gördü. Olaylardan birinde kayıt erken oluşturuldu, ancak sistem etkiyi yaklaşık 2.000 kullanıcı olarak tahmin etti; gerçek sayı ise 80.000'i aşıyordu. Ayrıca Impact API, okuma sırasında ön toplama veya önbellekleme yapmadan HyperLogLog şemalarını birleştirdiği için yaklaşık 100 eşzamanlı kullanıcının baskısı altında çöktü.
En önemli zayıflık noktası ise olay geçidi, Kafka aboneliği ve Flink işlevinin tek bir bölgede çalışması; buna karşın karar motorunun iki bölgede aktif-aktif modda çalışmasıdır. Bu, bölgesel bir arızanın hesaplamayı işler durumda bırakırken keşif kaynağının kendisini devre dışı bırakabileceği anlamına geliyor.
certi.news'un editoryal değerlendirmesi
Atlassian deneyinin temel değeri, Flink veya Kafka'nın tek başına seçilmesinde değil; mimari kararların gözden geçirilebilir operasyonel metriklerle ilişkilendirilmesinde yatıyor: veri yolunda filtreleme, idempotent anahtarlar, platformun kendi OpenTelemetry araçlarıyla izlenmesi ve recall ile coverage arasındaki ayrım. Sonuçlar, verimliliğin iyileştirilmesinin maliyeti ve süreyi açıkça azaltabileceğini, ancak ölçüm boşluklarını veya kullanıcı sinyali üretmeyen olayları otomatik olarak ele almadığını gösteriyor.
Atlassian, dedektörleri OpenTelemetry üzerinden beslenen zaman serisi deposuna taşımayı, Flink hattını bölgeler arasında aktif-aktif moda genişletmeyi ve Impact API önünde günlük toplama ile önbellekleme eklemeyi planlıyor. Ayrıca izleme ile donatılmış kapsam içinde recall ve doğruluk oranlarının her birini %90'ın üzerine çıkarmayı ve Sev3 olaylarının keşfi için P90 süresini 90 dakikanın altında tutmayı hedefliyor. Yayımlanan makaleye göre bunlar henüz gerçekleşmiş sonuçlar değil, geleceğe yönelik hedeflerdir.