Site kesintilerini nasıl kök nedenine kadar izleriz?

Siteniz birkaç saatte bir, iki ila beş dakika boyunca erişilemez hale geliyor. Sonra kendi kendine geri dönüyor. Hosting izleme her şeyin yeşil olduğunu söylüyor, müşteri beyaz sayfa gördüğünü söylüyor ve siz "belki sorun onun kendi internetindeydi" ile "kesinlikle bir yerde bir sorun var" arasında sıkışıp kalıyorsunuz. Bu, en can sıkıcı site kesintisi türüdür, çünkü asla sizinle aynı anda gerçekleşmez.

Yapmanız gereken ilk şey, kesintiyi "his"ten "sayı"ya dönüştürmektir. Elinizde yalnızca sözlü bir anlatım olduğu sürece, sunucudaki her değişiklik bir kumar oynamaktır.

Hosting panelinin izlemesi site kesintisini neden görmüyor

Hosting panelleri genellikle her 5 dakikada bir ana sayfaya bir ICMP ping veya bir HTTP isteği gönderir. Burada iki yapısal sorun var. Birincisi, 5 dakikalık aralık 90 saniyelik kesintileri tamamen atlar; eğer kesinti iki kontrol arasına düşer ve bir sonraki kontrole kadar sona ererse, hiçbir zaman kaydedilmez. İkincisi, ICMP ping yalnızca sunucunun ağ kartının yanıt verdiğini söyler, PHP'nin veya MySQL'in ya da web sunucusunun upstream'inin sağlıklı olduğunu değil.

30 veya 60 saniyelik aralıklarla harici bir izleme servisi kurun ve bunu statik bir dosya üzerinde değil, veritabanına ve uygulama koduna bağlı gerçek bir endpoint üzerinde ayarlayın. Örneğin, veritabanına hafif bir sorgu atan ve 200 kodu döndüren /healthz gibi bir sağlık yolu. Yalnızca ana sayfayı kontrol ederseniz, sayfa önbelleği yanıt verebilir ve siz veritabanı kesintisini göremezsiniz.

Daha az söylenen bir nokta: tek bir noktadan izleme yeterli değildir. Eğer monitör İran içindeki bir veri merkezinden kontrol ediyorsa ve kullanıcınız yurt dışından bağlanıyorsa, sorun sunucunuzda değil uluslararası ağ yolunda olabilir. Farklı ISP'lere sahip en az iki izleme noktası koyun. Yolu ve alan adı kayıtlarını incelemek için de DNS ve ağ inceleme aracını kullanarak kesinti anında alan adı çözümlemesinin doğru yapılıp yapılmadığını görebilirsiniz.

Zaman korelasyonu: site kesintisini neyle karşılaştırmalıyız

Bir kesinti aralığı kaydedildiğinde, doğru soru "neden kesildi?" değil, "o aralıkta sunucuda tam olarak ne çalışıyordu?" olmalıdır. Üç kaynağı yan yana koymanız gerekir:

• Web sunucusu logu (örneğin /var/log/nginx/error.log ve access log) tam zaman damgasıyla
• Sistem logu ve cron: journalctl -u cron --since "2025-01-14 03:00" --until "2025-01-14 04:00"
• Sunucu kaynak grafiği (CPU, RAM, disk I/O) saatlik ortalama değil, bir dakikalık çözünürlükte

Kendi gördüğüm çoğu durumda desen şunlardan biridir: gerçek trafikle aynı zamana denk gelen ağır bir cron job (yedekleme, içe aktarma, tablo temizleme); ya da birkaç saatte bir OOM killer'ı tetikleyen bellek sızıntısı olan bir betik; ya da yüksek hızda ağır sayfaları döven crawler botu gibi harici bir süreç.

Kesinti anında hangi sürecin en fazla baskı yaptığını görmek için, atop kuruluysa atop -r /var/log/atop/atop_20250114 -b 03:00 kullanın. Yoksa, bugün kurun; geçmiş veri olmadan düzensiz kesintileri sorun gidermek neredeyse şansa bağlıdır.

Cron'u birinci şüpheli yapmayın, ama önce onu kontrol edin

Yaygın bir hata: site yöneticisi yedekleme cron'unu devre dışı bırakır, iki gün kesinti olmaz ve sorunun çözüldüğü sonucuna varır. Sonra üç hafta sonra kesinti geri döner. Bunun nedeni, cron'un yalnızca eşzamanlayıcı olması, neden olmamasıdır. Eğer yedeklemeniz 40 dakika disk I/O'sunu meşgul ediyorsa ve site aynı diskte sunuluyorsa, gerçek sorun yedekleme ile trafiğin ortak bir kaynağa düşmesidir. Doğru çözüm, yedekleme zamanını kaydırmak veya ionice -c2 -n7 ile I/O hızını sınırlamaktır, yedeklemeyi silmek değil.

Burada hata yapıyorlar

En çok duyduğum cümle: "Şu an site ayakta, demek ki sorun sunucuda değil." Bu argüman yanlıştır ve tam da sorun gidermeyi haftalarca geciktiren şeydir. Kısa kesintiler genellikle anlık doygunluk türündendir: bir kuyruk dolar, bir timeout alınır, bir servis yeniden başlatılır ve her şey birkaç saniye içinde normale döner. Siz SSH ile bağlanıp her şeyi sağlıklı gördüğünüz anda, o pencere kapanmıştır.

İşareti de şudur: kullanıcı "502 aldım" der, siz web sunucusu logunda upstream timed out (110: Connection timed out) while reading response header from upstream satırını görürsünüz, ama aynı isteği elle attığınızda 200 milisaniyede yanıt alırsınız. Bu çelişki, sunucunun masumiyetine kanıt değil, kendisi bir kanıttır.

Kesintiyi öngörülebilir kılmak için neyi ölçmeliyiz

Her zaman elinizde olması gereken üç sayı var. Birincisi, ortalama değil, 95. ve 99. yüzdelik dilimde yanıt süresi. 200 milisaniye ortalama ile 8 saniye 99. yüzdelik, kullanıcılarınızın bir kısmının siteyi pratikte açamadığı anlamına gelir. İkincisi, ayarlanan üst sınıra karşı aktif bağlantı sayısı; eğer worker_connections 1024 ise ve yoğun saatlerde 900'e ulaşıyorsa, kesintiyle aranızda az mesafe var demektir. Üçüncüsü, PHP-FPM veya uygulama süreçlerinin bellek tüketimi, her pool için ayrı ayrı.

Siteniz paylaşımlı bir sunucuda veya küçük bir VPS'te çalışıyorsa ve agent kurmak için gerekli kontrole sahip değilseniz, harici HTTP izleme ile uygulamanın kendi loglarının kombinasyonu yeterlidir. Ancak trafik arttığında ve kesintilerin gerçek maliyeti olduğunda, özel sunucu çekirdeği, ağ parametrelerini ve cron zamanlamasını kendinizin kontrol etmesine olanak tanır; paylaşımlı ortamda bu mümkün değildir.

Yedekleme, kurtarma ve kesinti anındaki farkları

Kriz anında ortaya çıkan bir nokta: yedeklemeye sahip olmak ile hızlı kurtarmaya sahip olmak aynı şey değildir. Yedeklemeniz 20 gigabayt ise ve aynı sunucuda saklanıyorsa, disk kesintisinde bu ikisinden hiçbirine sahip değilsiniz. Yedeklemeyi ayrı bir hedefe koyun ve ayda en az bir kez gerçek kurtarma süresini ölçün. Elde edilen sayı (örneğin tam geri yükleme için 45 dakika), paydaşlara söylemeniz gereken şeydir, "yedeklememiz var" değil.

Yönetilen hosting üzerinde çalışan siteler için, standart dosya ve veritabanı yönetim araçlarına sahip Linux hosting, kurtarma ve log inceleme işini kolaylaştırır; ancak yine de hangi tablonun ne kadar büyük olduğunu ve kurtarmasının ne kadar süreceğini kendiniz bilmelisiniz.

Bu gece için pratik kontrol listesi

1. Veritabanına bağlı bir sağlık endpoint'i oluşturun ve bunu 30 saniyelik aralıklarla iki noktadan izleyin.
2. Web sunucusu ve cron loglarını aynı zaman damgasıyla merkezi bir hedefe gönderin ki korelasyon mümkün olsun.
3. Kaynak grafiğini saatlik ortalama değil, bir dakikalık çözünürlükte saklayın.
4. Ağır cron'ların zamanlamasını yoğun trafik saatleriyle karşılaştırın ve çakışma varsa kaydırın veya sınırlayın.
5. Yedekten kurtarmayı bir kez deneyin ve gerçek süresini not edin.

Herhangi bir altyapı değişikliğinden önce sitenin mevcut durumu hakkında daha net bir görüntü almak istiyorsanız, hız ve yanıt verme durumunu incelemek için ücretsiz webmaster araçlarını kullanın. Ve bu adımlardan sonra hâlâ bir desen bulamadıysanız, sorun muhtemelen ölçmediğiniz bir katmandadır; genellikle DNS veya ağ yolu. ServerNet blogunda bu tür sorun gidermenin gerçek örnekleri belgelenmiştir.

Sıkça sorulan sorular

Sitem neden yalnızca bazı kullanıcılar için kesiliyor?

Genellikle bu, sorunun sunucuda değil, sunucuya giden yolda olduğu anlamına gelir. DNS resolver farkı, uluslararası yol veya kullanıcının yerel DNS önbelleği bile birinin siteyi görmesine, diğerinin görmemesine neden olabilir. Teşhis için farklı coğrafi noktalardan test edin ve alan adı çözümleme sonucunu karşılaştırın.

Birkaç saniyelik kesintiler gerçekten önemli mi?

Evet, eğer kullanıcının işlem yaptığı endpoint'lerde meydana gelirse. Ödeme ortasında 10 saniyelik bir kesinti, siparişi yarım bırakır ve tutarsız veri oluşturabilir. Ayrıca crawler'lar da bu hataları görür ve sayfa sıralamasını etkiler.

İzleme için uygun aralık nedir?

Ticari siteler için 30 ila 60 saniye makul bir başlangıç noktasıdır. 30 saniyeden kısa aralıklar genellikle yeni bir şey göstermeden maliyeti ve uyarı gürültüsünü artırır, tabii SLA'nız gerçekten çok katı değilse.

Kesintinin veritabanından mı yoksa web sunucusundan mı olduğunu nasıl anlarım?

Veritabanı için yalnızca basit bir sorgu atan ayrı bir sağlık endpoint'i oluşturun. Eğer o endpoint kesinti aralığında hata verdi ama statik sayfa sağlıklıysa, sorun veritabanındadır. Eğer her ikisi de hata verdiyse, sorun muhtemelen web sunucusu veya ağ katmanındadır.