Sunucum Çöktü ve Bunu Beş Saat Sonra Tesadüfen Öğrendim

Bildirim bir izleme hizmetinden gelmedi. Otomatik bir uyarıdan veya Slack'e ateşlenen bir webhook'dan gelmedi. En ilkel izleme sisteminden geldi: tarayıcı açmak, URL'yi yazmak ve boş bir sayfa görmek. Salı öğleden sonrasıydı. Site, sabah dokuz civarında çevrimdışı olmuş ve şimdi öğleden sonra ikiye yakın bir saatti. Normalde günde binlerce istek sunan bir web uygulamasından tam beş saatlik sessizlik. Her ziyaretçi bir hata sayfası gördüğü, her API çağrısı hiçbir şey döndürmediği ve her zamanlanmış görev arka planda sessizce başarısız olduğu beş saat. Sunucu dramatik bir şekilde çökmemişti. Çekirdek panik yoktu, disk arızası yoktu, adli kanıtlar bırakan hiçbir saldırı vektörü yoktu. Contabo VPS, geçerli bir IP adresi ve ağ katmanında bir sinyal bulunmasına rağmen, HTTP isteklerine yanıt vermeyi reddetmişti.

Keşif tamamen ilgisiz bir görev nedeniyle oldu. Bir tasarım değişikliği için belirli bir sayfa düzenini kontrol etmeye ihtiyaç vardı, bu yüzden tarayıcı URL'ye gitti ve hiçbir şey döndürmedi. İlk düşünce yerel ağı suçlamaktı. Sayfayı yenile. Hala hiçbir şey. Farklı bir tarayıcı denedi. Hala hiçbir şey. Terminal açtı ve sunucuyu ping attı. Paketler normal şekilde döndü. SSH bağlantısı? Çalışıyor. Apache durumu? Ölü. Web sunucusu işlemi, bu tam arızayı ele almak için hiçbir işlem denetçisi yapılandırılmadığından, erken saatlerde bir noktada çökmüş ve hiçbir zaman yeniden başlatılmamıştı. Düzeltme otuz saniye sürdü. Bunun tekrar olabileceği ve muhtemelen kimse fark etmeden daha önce olmuş olduğu farkındalığı, sindirilmesi çok daha uzun sürdü.

VPS'de üretim hizmetleri çalıştıran her geliştirici bu hikayenin bir versiyonuna sahiptir. Belki beş saat değildi. Belki iki, sekiz ya da tam bir hafta sonuydu. Detaylar değişse de desen aynıdır. Sunucu çöktü, kimse fark etmedi ve keşif tesadüfi oldu. Kök problem sunucu güvenilirliği değildir. Sunucular başarısız olur, işlemler çöker, diskler dolur, bellek sızıntıları birikir. Bu, yazılımı fiziksel donanımda çalıştırmanın doğasıdır. Kök problem izlemenin olmaması ve daha spesifik olarak, sunucunun çevrimiçi olduğunu bilmek ile uygulamanın aslında çalıştığını bilmek arasındaki boşluktur.

Çalışma Zamanı İzlemesi ile Sitenizin Gerçekten Çalışıp Çalışmadığını Bilmek Arasındaki Fark

Geleneksel çalışma zamanı monitörleri bir şeyi iyi yapar. Düzenli aralıklarla bir URL'ye HTTP isteği gönderir ve yanıt kodunun 200 olup olmadığını kontrol eder. Kod başka bir şey ise veya istek zaman aşımına uğrarsa, bir uyarı çalışır. Bu en yıkıcı arızaları yakalar: sunucu tamamen erişilemez, alan adı süresi dolmuş, SSL sertifikası geçersiz. Ancak muhtemelen daha yaygın ve daha zarar verici olan muazzam bir sorun kategorisini kaçırır.

Sunucunun 200 durum kodu döndürdüğü bir senaryoyu düşünün, ancak sayfa bozuk. Veritabanı bağlantısı başarısız oldu, bu nedenle içerik alanı beklenen ürün listesi yerine bir hata mesajı gösterir. CSS dosyası yüklenemedi, bu nedenle sayfa stil uygulanmamış HTML olarak işlenir. Bir JavaScript hatası ana uygulamanın başlatılmasını engeller ve kullanıcı hiçbir zaman çözülmeyecek bir yükleme dönemine bakar. Bir üçüncü taraf widget, tüm sayfa içeriğini kaplayan bir yer paylaşımı enjekte eder. Bu durumların tümünde, çalışma zamanı monitörü 200 yanıt aldığı için her şeyi sağlıklı olarak bildiriyor. Sunucu çalışıyor. Site bozuk. Kimse bilmiyor.

"sunucu yanıt veriyor" ile "site çalışıyor" arasındaki bu boşluk, ekran görüntüsü izlemesinin gerekli hale geldiği yerdir. Zamanlanmış bir ekran görüntüsü, sayfanın düzenli aralıklarla aslında nasıl göründüğünü yakalar. Sayfa aniden bir hata mesajı, kırılmış bir düzen veya boş beyaz bir ekran gösterirse, ekran görüntüsü bunu hemen görünür kılar. Zamanlanmış ekran görüntüleri piksel diff karşılaştırması ile birleştirin ve sistem otomatik olarak bir sayfa beklenmeyen şekillerde değiştiğinde algılayabilir. İçerik güncellemesi nedeniyle birkaç pikselin kaydırılması normaldir. Tüm sayfanın beyaz olması veya bir hata stack izlemesi görüntülemesi değildir ve diff algoritması, yapılandırılabilir duyarlılık eşikleri ile ikisi arasında ayrım yapabilir.

Beş saatlik kesintinden sonra, ilk ayarlanan şey her kritik hizmet için bir çalışma zamanı monitörüydü. Ancak daha ilginç eklenti, her on beş dakikada bir anahtar sayfaların gerçek görsel durumunu yakalan zamanlanmış ekran görüntüsü izlemesiydi. Çalışma zamanı monitörü, bariz çöküşleri yakalar. Ekran görüntüsü monitörü her şeyi yakalar: 200 durum kodu döndürürken kırılmış bir sayfa gösteren, beklenmeyen içerik enjekte eden üçüncü taraf betikleri, yalnızca belirli koşullar altında ortaya çıkan veritabanı hatalarını.

İlk Günden Beri Var Olması Gereken Uyarı Boru Hattını İnşa Etmek

Uygun bir izleme sisteminin mimarisi teoride karmaşık değildir. Bir zamanlayıcı, tanımlanmış aralıklarda bir kontrolü tetikler. Kontrol, hedefin mevcut durumunu yakalar. Durum beklenen temel çizgi ile karşılaştırılır. Karşılaştırma bir eşiği aşarsa, bir uyarı çalışır. Zorluk mimaride değil, her bir bileşenin güvenilirliğinde yatıyor. Kendisi çöken bir izleme sistemi, hiç izleme sisteminden daha kötüdür, çünkü yanlış bir güvenlik hissi yaratır.

Ekran görüntüsü izleme boru hattı aşamalarda çalışır. Zamanlayıcı, kritiklik düzeyine bağlı olarak tipik olarak her beş, on veya on beş dakikada bir yapılandırılmış aralıkta bir yakalama işini gönderir. Yakalama işi, sayfa yükleyen, işlemeyi tamamlamasını bekleyen ve ortaya çıkan ekran görüntüsünü kaydeden headless bir Chromium örneğini çalıştırır. Yeni ekran görüntüsü daha sonra, değiştirilmiş bölgeleri tanımlayan ve toplam değişim yüzdesini hesaplayan piksel diff algoritması kullanılarak önceki yakalama ile karşılaştırılır. Değişim yapılandırılmış eşiği aşarsa, yapılandırılmış kanallar aracılığıyla bir bildirim gönderilir: e-posta, webhook, Slack veya herhangi bir özel uç nokta.

Diff karşılaştırması, teknik açıdan gerçekten ilginç hale geldiği yerdir. Naif bir piksel karşılaştırması, zaman damgaları, reklamlar veya animasyonlu öğeler gibi dinamik içerik nedeniyle her ekran görüntüsünü değiştirilmiş olarak işaretlerdi. Diff motoru, bunu karşılaştırmadan önce maskeli olan sayfanın dikdörtgen bölgeleri olan dışlama bölgelerini destekleyerek hesaba katıyor. Başlıktaki zaman damgası, dönen banner reklamı, köşedeki canlı sohbet widget'ı: bunların tümü dışlanabilir, böylece yalnızca anlamlı değişiklikler uyarıları tetikler. Dışlama sonrası kalan şey, istikrarlı içerik alanı ve orada yapılan herhangi bir değişiklik neredeyse kesinlikle araştırma değerdir.

Beş saatlik kesinti, bu sistem altında dakikalar içinde yakalanırdı. Sunucu çöktükten sonraki ilk zamanlanmış ekran görüntüsü, boş bir görüntü veya bir hata sayfası döndürürdü, ikisi de temeliden çarpıcı şekilde farklı olurdu. Diff yüzde neredeyse %100'e yakın olurdu, makul bir eşiğin çok üstünde ve uyarı hemen çalışırdı. Beş saat kesinti, beş dakika olurdu ve bu beş dakika, bir insanın tesadüfen sorunu keşfetmesine olan zaman değil, izleme aralığının kendisi olurdu.

Beş Saatlik Görünmez Kesintinin Gerçekten Maliyeti Nedir

Beş saatlik kesintinin acil maliyeti, sayılar mevcut olduğunda hesaplaması kolaydır. Binlerce günlük istek gerçekleştiren bir site için, beş saat günlük trafiğin önemli bir dilimini temsil eder. Hata döndüren her istek, gelmek istediği şeyi almayan bir kullanıcıydı. Bu kullanıcılardan bazıları hiçbir zaman geri dönmeyecek yeni ziyaretçilerdi. Bazıları az miktarda güven kaybedecek mevcut kullanıcılardı. Bazıları, bağımlılık nedeniyle kendi uygulamaları başarısız olan API tüketicileriydi. Doğrudan gelir etkisi sitenin yapısına bağlıdır, ancak küçük bir SaaS uygulaması için dahi, çalışma saatlerinde beş saat kesinti, yüzlerce dolarlık kayıp dönüştürmeleri temsil edebilir.

Gizli maliyet, niceliksel olarak daha zordur, ancak muhtemelen daha büyüktür. Site'yi bu beş saat içinde taramasını yapan arama motorları hata yanıtları aldı ve kısa bir kesinti genellikle Google'ın tarama altyapısı tarafından tolere edilse de, uzun süreli kesinti, etkilenen sayfaların geçici deindeksatlanmasına neden olabilir. Kesinti sırasında çalışan e-posta kampanyaları ölü bir uç noktaya trafik yönlendirdi ve tüm kampanya harcamasını boşa harcadı. Web uygulamasına bağlı zamanlanmış görevler, webhook denemeleri, rapor oluşturma ve toplu işleme gibi şeyler tümü sessizce başarısız oldu ve sunucu geri yüklenirken manuel olarak tanımlanması ve yeniden çalıştırılması gerekti.

En sinsi maliyet itibarı olanıdır. Çöken bir site ile karşılaşan kullanıcılar tipik olarak "siteniz çökmüş" diyen bir e-posta göndermezler. Basitçe ayrılırlar ve geri döndüğü de olmayabilir. Kesinti için geri bildirim mekanizması yoktur çünkü geri bildirim mekanizmasının kendisi çökmüştür. Beş saatlik pencere, bazı kullanıcıların site denediğini, bozuk bulduğunu ve tek bir veri noktası oluşturmadan rakibe taşındığından emin olmak için yeterince uzundu, bu da ne olduğunu gösterecekti. Basitçe gidiyorlar ve kaç kişinin olduğunu veya kimin olduğunu bilmenin hiçbir yolu yoktur.

Reaktiften Proaktife ve Tesadüfen Birinciye Asla Geri Dönmeme

O Salı öğleden sonrasından dersi, sunucuların çökmesi değildi. Bu zaten bilindi. Ders şu ki, bir arıza ile keşfi arasındaki her dakika, bileşik hasarın bir dakikasıdır ve bu pencereyi en aza indirmenin tek yolu otomasyonu algılamaktır. İnsan izlemesi ölçeklemez. Bir siteni günde bir kez manuel olarak kontrol etmek, bir kesinti için ortalama algılama süresinin on iki saat olduğu anlamına gelir. Saatte bir kez kontrol etmek bunu otuz dakikaya düşürür, ancak hiçbir insan gerçekçi olarak gün boyunca her uygulama sayfasını saat saatinde kontrol edemez.

Çalışma zamanı izlemesi ve görsel ekran görüntüsü izlemesinin kombinasyonu sorunun her iki katmanını kapsar. Çalışma zamanı monitörü, sunucunun tamamen çevrimdışı gitmesini yakalar. Ekran görüntüsü monitörü, sunucu çevrimiçi kalırken uygulamanın kırılmasını yakalar. Birlikte, algılama penceresini "birisi tesadüfen fark ettiği zaman" dan izleme aralığının kendisine indirger, bu kritik hizmetler için bir dakika kadar kısa olabilir. Uyarı ateşlenir, bildirim gelir ve düzeltme, saatler yerine dakikalar içinde başlar.

Sunucu o orijinal hadiseden iki kez daha çöktü. Her iki durumda da, uyarı üç dakika içinde geldi. Her iki durumda da, herhangi bir önemli trafik kaybedilmeden önce düzeltme uygulandı. İzleme altyapısı, yakalayacağı ilk hadisede kendisine ödedisi ve sonra gelen her şey saf artı tarafıdır. Tesadüfen kesintiler hakkında öğrenmenin çağı bitti ve geriye bakıldığında, tek gerçek soru, bir beş saatlik kesintinin yatırımı ne zaman açık hale getirdiğidir.

Sıkça Sorulan Sorular

Çalışma zamanı izlemesi ile ekran görüntüsü izlemesi arasındaki fark nedir?

Çalışma zamanı izlemesi, bir sunucunun geçerli bir HTTP yanıt kodu döndürüp döndürmediğini kontrol eder, genellikle 200. Ekran görüntüsü izlemesi, sayfanın gerçek görsel görünümünü yakalar ve temeliye karşı karşılaştırır. Bir sunucu, 200 durum kodu döndürürken kırılmış bir sayfa gösterebilir, bu çalışma zamanı izlemesi kaçırır ancak ekran görüntüsü izlemesi yakalamaz.

İzleme amaçları için ekran görüntüleri ne sıklıkta alınmalıdır?

Aralık, sayfanın kritiklik düzeyine bağlıdır. Ödeme akışları ve oturum açma ekranları gibi misyon kritik sayfalar, bir ila beş dakikalık aralıklardan yararlanır. İçerik sayfaları ve pazarlama siteleri genellikle on beş ila otuz dakikalık aralıkları kullanabilir. Değişim, algılama hızı ile sık yakalama hesaplama maliyeti arasındadır.

Ekran görüntüsü izlemesi tam kesintiler olmayan sorunları algılayabilir mi?

Evet. Ekran görüntüsü izlemesi, kırılmış düzenler, eksik resimler, başka türlü işlevsel bir sayfa içinde görüntülenen hata mesajları, üçüncü taraf betik enjeksiyonları ve CSS yükleme başarısızlıklarını içeren sayfaya yapılan herhangi bir görsel değişikliği algılar. Bu kısmi arızalar genellikle geleneksel çalışma zamanı monitörleri için görünmez.

Piksel diff karşılaştırması nedir ve nasıl çalışır?

Piksel diff, değiştirilmiş bölgeleri tanımlamak için iki ekran görüntüsünü piksel düzeyinde karşılaştırır. Algoritma, değiştirilen piksellerin toplam yüzdesini hesaplar ve farklılıkların bulunduğu belirli alanları vurgulayabilir. Yapılandırılabilir duyarlılık eşikleri ve dışlama bölgeleri, reklamlar veya zaman damgaları gibi dinamik içerikten yanlış uyarıları önler.

İzleme sistemi birinin yanlış gittiğinde ne kadar hızlı uyarı verebilir?

Uyarı hızı izleme aralığına bağlıdır. Bir dakikalık bir aralıkla, maksimum algılama süresi bir dakika artı ekran görüntüsünü yakalama ve karşılaştırma zamanıdır, bu tipik olarak iki ila beş saniye ekler. Bildirimler, algılamadan sonra saniyeler içinde e-posta, Slack webhook'ları veya özel HTTP uç noktaları aracılığıyla gönderilebilir.

Ekran görüntüsü izlemesi, ağır bir şekilde JavaScript'e güvenen tek sayfa uygulamaları için çalışır mı?

Evet. Ekran görüntüleri, tam JavaScript'i çalıştıran, dinamik içeriği işleyen ve yakalamadan önce sayfanın istikrarlı bir duruma ulaşmasını bekleyen gerçek bir Chromium tarayıcı motoru kullanılarak yakalanır. Bu, React, Vue, Angular veya benzer çerçeveler ile oluşturulan tek sayfa uygulamalarının doğru bir şekilde yakalandığı anlamına gelir.