Site uptime izleme ve kesinti uyarıları

Siteniz birkaç dakika erişilemez olduğunda, bunu ilk öğrenmesi gereken kişi sizsiniz, kullanıcı veya satış müdürü değil. Kesintiden haberdar olmadaki gecikme, satış, güven ve SEO kaybı anlamına gelir. Uptime İzleme (Uptime Monitoring) tam olarak bunun için oluşturulmuştur: sitenin erişilebilirliğini periyodik olarak kontrol etmek ve bir sorun oluştuğunda anında bildirim yapmak. Ancak aracı yanlış yapılandırırsanız, yardım etmek yerine bir stres kaynağına dönüşür; gece yarısı yanlış alarmlar, gereksiz bildirimler ve sonunda ekibin alarm sistemine olan güvensizliği. Bu kılavuzda uptime izlemeyi doğru şekilde nasıl kuracağınızı, en uygun kontrol aralığını nasıl seçeceğinizi ve yanlış alarmları nasıl en aza indireceğinizi öğreneceksiniz.

Uptime İzleme Neden Basit Görünür Ama Çoğunlukla Bozulur?

Ana fikir basittir: harici bir hizmet, sitenize birkaç dakikada bir HTTP isteği gönderir ve bir yanıt alamazsa size mesaj gönderir. Ancak sorun, "yanıt alamama" durumunun net bir tanımının olmamasıyla başlar. Bu, timeout mu demek? 500 hata kodu mu? Aşırı yavaşlık mı? Bunların her biri farklı bir anlama gelebilir ve tanımı netleştirmezseniz, sisteminiz ya aşırı hassas olur ya da pratikte işe yaramayacak kadar yavaş kalır.

Gerçek Downtime ile Geçici Arıza Arasındaki Fark

Gerçek bir kesinti, sitenin birkaç dakika veya daha uzun süre tamamen erişilemez olmasıdır. Ancak geçici bir arıza, 3 saniye süren bir yanıt veya CDN'den dönen ve hemen düzeltilen bir 503 hatası olabilir. Uptime izleme aracı bu ikisini ayırt edebilmelidir. Her geçici hata için alarm verirseniz, ekibiniz hızla bildirimleri görmezden gelmeyi öğrenir — ve olmaması gereken tam olarak budur.

Kontrol Aralığı Seçimi; Hız ve Maliyet Arasında Denge

Uptime izlemede en yaygın soru şudur: "Ne sıklıkla kontrol edeyim?" Kısa cevap: bütçenize ve ihtiyacınıza bağlı. Teknik cevap: genellikle 30 saniye ile 5 dakika arası.

30 Saniye ile 1 Dakika Aralığı

Bu aralık; ödeme kapıları, sıkı hizmet seviyesi anlaşmaları (SLA) olan API hizmetleri veya yüksek trafikli çevrimiçi satış platformları gibi kritik siteler için uygundur. Avantaj: kesintiyi neredeyse anında öğrenirsiniz. Dezavantaj: daha yüksek maliyet (çünkü sunucunuza daha fazla trafik girer) ve ayarlar doğru değilse daha yüksek yanlış alarm olasılığı.

2 ile 5 Dakika Aralığı

Çoğu kurumsal site, blog ve orta ölçekli mağaza için 2 ila 5 dakikalık aralık tamamen mantıklıdır. Bu sürede, site 10 dakika kesintiye uğrarsa, kesintinin başlamasından en geç 5 dakika sonra haberdar olursunuz. Bu genellikle zamanında müdahale için yeterlidir ve maliyeti ile gürültüyü düşük tutar.

5 Dakikadan Uzun Aralık

Birkaç dakikalık kesintinin kriz yaratmadığı hassas olmayan siteler için 10 veya 15 dakikalık aralığı seçebilirsiniz. Ancak unutmayın: siteniz 20 dakika kesintiye uğrarsa ve siz 15 dakika sonra öğrenirseniz, birçok kullanıcı sitenin çalışmadığını görmüştür.

Uptime İzleme Araçları; Basitten Gelişmişe

Uptime izleme için birçok araç vardır. Seçiminiz bütçenize, site sayınıza ve diğer araçlarla entegrasyon ihtiyacınıza bağlıdır.

Genel Bulut Hizmetleri

UptimeRobot, Pingdom ve StatusCake gibi hizmetler en bilinenler arasındadır. UptimeRobot, 5 dakikalık kontrol aralığı ve maksimum 50 monitör ile başlamak için harika olan ücretsiz bir sürüme sahiptir. Pingdom, hız kontrolü ve daha ayrıntılı raporlar gibi daha fazla özellik sunar ancak maliyeti daha yüksektir. Bu hizmetler, dünyanın farklı noktalarındaki farklı sunuculardan kontrol yapar; bu büyük bir avantajdır: Avrupa'daki bir veri merkezinde sorun olsa bile, Amerika'daki monitör sitenizi görmeye devam eder ve yanlış alarm göndermez.

Basit Bir Komut Dosyasıyla Özel Monitör Kurulumu

Tam kontrole sahip olmak ve ek maliyet ödemek istemiyorsanız, ayrı bir sunucuda (sitenin kendi sunucusunda değil!) basit bir komut dosyası çalıştırabilirsiniz. Aşağıdaki örnek Bash ve curl ile çalışır:

#!/bin/bash
URL="https://example.com"
EXPECTED_CODE=200
TIMEOUT=10

HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" --max-time $TIMEOUT "$URL")

if [ "$HTTP_CODE" != "$EXPECTED_CODE" ]; then
    echo "ALERT: $URL returned $HTTP_CODE at $(date)" >> /var/log/uptime-alerts.log
    # Telegram API veya e-posta ile mesaj gönder
    curl -s -X POST "https://api.telegram.org/botYOUR_TOKEN/sendMessage" \
        -d chat_id=YOUR_CHAT_ID \
        -d text="⚠️ Site kesintisi: $URL (HTTP $HTTP_CODE)"
fi

Bu komut dosyasını cron ile çalıştırın:

*/2 * * * * /usr/local/bin/check-uptime.sh

Bu yöntemin avantajı: sıfır maliyet, alarm mantığı üzerinde tam kontrol. Dezavantajı: yalnızca tek bir noktadan kontrol edersiniz, bu nedenle kendi izleme sunucunuzda bir sorun olursa yanlış alarm alırsınız.

Yanlış Alarmdan Kaçınma; Uptime İzlemenin En Önemli Kısmı

Yanlış alarm, sistemin size site kesintide olmadığı halde kesintide olduğunu söylemesidir. Bu, düşündüğünüzden daha sık olur ve ana nedeni yanlış yapılandırmadır. Bu bölümde yanlış alarmı azaltmak için üç pratik tekniği inceleyeceğiz.

1. Tek Hatada Değil, Hata Eşiği (Threshold) Kullanma

Hizmete "bir hata görürsen alarm ver" demek yerine, "arka arkaya 3 hata görürsen alarm ver" deyin. Çoğu profesyonel araç bu özelliğe sahiptir. UptimeRobot'ta bu ayar "Max Retries" veya "Attempts" adıyla bulunur. Bu sayede geçici bir hata (örneğin ağ dalgalanması nedeniyle) alarm oluşturmaz, ancak birkaç dakika süren gerçek bir kesinti kesinlikle alarm verir.

2. Birden Fazla Coğrafi Noktadan Kontrol

Hizmetiniz yalnızca tek bir noktadan kontrol ediyorsa ve o nokta (örneğin Frankfurt'taki bir veri merkezi) ağ sorunu yaşarsa, yanlış alarm alırsınız. Profesyonel araçlar, alarm verilmesi için 5 noktadan en az 2 veya 3'ünün hata görmesi gerektiğini belirlemenize olanak tanır. Bu, yanlış alarm olasılığını büyük ölçüde azaltır.

3. Akıllı Timeout Ayarı

Yanlış alarmların çoğu kısa Timeout nedeniyle oluşur. Siteniz genellikle 2 saniyede yanıt veriyorsa ancak bazen ağır bir rapor işleme nedeniyle 5 saniye sürüyorsa, Timeout'u 3 saniyeye ayarlamayın. Çoğu site için 10 ila 15 saniye mantıklıdır. Unutmayın: uptime izlemenin amacı tam kesintiyi tespit etmektir, yavaşlığı değil. Yavaşlık için Performance kontrolü gibi ayrı bir araç gerekir.

Alarm Ayarı; Kime, Hangi Yolla, Hangi İçerikle?

İyi bir alarm, doğru mesajın, doğru kişiye, doğru zamanda iletilmesidir. Alarmı herkese verirseniz, kimse sorumluluk almaz. Yalnızca bir kişiye verirseniz ve o kişi müsait değilse, tüm sistem işe yaramaz hale gelir.

Alarm Kanalları

• Telegram veya SMS: Müdahale gerektiren acil alarmlar için. Telegram ücretsizdir ve Bot API ile kolayca bağlanır. SMS maliyetlidir ancak kritik kesintiler için buna değer.
• E-posta: Periyodik raporlar ve acil olmayan alarmlar için. E-postayı gerçek kesintiler için kullanmayın çünkü saatlerce görülmeyebilir.
• Ticketing Sistemi (Slack veya Rocket.Chat gibi): Alarmı kaydetmek ve ekip takibi için. Bu kanalı ana kesinti alarm kanalı olarak düşünmeyin çünkü bildirimi kapalı olabilir.

Alarm İçeriği

İyi bir alarm şunları içermelidir:

1. Site veya hizmet adı (örneğin yalnızca example.com değil, "Ana Mağaza")
2. Alınan HTTP hata kodu (örneğin 500 veya 503)
3. Sorunun başladığı kesin zaman (yerel saatle)
4. Hatayı gören nokta (örneğin Frankfurt)
5. Anlık durumu kontrol etmek için izleme panosuna doğrudan bağlantı

İyi bir mesaj örneği:

⚠️ Hizmet kesintisi: Ana Mağaza (shop.example.com)
Hata kodu: HTTP 503
Başlangıç zamanı: 2025-06-15 14:32:10 (UTC+3:30)
Hata kaynağı: Frankfurt, Almanya
Güncel durum: Yeniden kontrol ediliyor (3 denemeden 2.)
Pano: https://status.example.com

Gerçek Sağlık Kontrolü; HTTP Yanıtının Ötesinde

Uptime izleme yalnızca sitenin 200 kodu döndürmesi anlamına gelmez. Bir site 200 kodu döndürebilir ancak ana sayfasında PHP hatası gösterebilir veya veritabanı bağlantısı kopmuş olabilir. Gerçek izleme için yanıtın içeriğini de kontrol etmelisiniz.

Anahtar Kelime Kontrolü (Keyword Checking)

Çoğu uptime izleme aracı, yanıtta belirli bir metni aramanıza olanak tanır. Örneğin, "ana sayfada 'Giriş Yap' ifadesi yoksa alarm ver" diyebilirsiniz. Bu, küçük hatalardan kaynaklanan yanlış alarmları önler ve sitenin gerçekten çalıştığından emin olmanızı sağlar; yalnızca 200 kodu döndüren beyaz bir hata sayfası değil.

# Yanıtta anahtar metnin varlığını kontrol et
if curl -s --max-time 10 "$URL" | grep -q "Giriş Yap"; then
    echo "OK"
else
    echo "ALERT: anahtar kelime bulunamadı"
fi

Farklı Katmanların İzlenmesi

Tam bir site için üç ayrı monitör bulundurmak daha iyidir:

• HTTP Monitörü: Ana sayfanın erişilebilirliğini kontrol eder (2 dakikalık aralık)
• API Monitörü: /api/health gibi kritik bir endpoint'i kontrol eder (1 dakikalık aralık)
• DNS Monitörü: Sitenin DNS kaydının doğru yanıt verip vermediğini kontrol eder (15 dakikalık aralık)

Bu ayrım, bir sorun oluştuğunda daha hızlı kök neden analizi yapmanıza yardımcı olur. DNS doğru çalışıyorsa ancak HTTP hata veriyorsa, sorun web sunucusundadır, DNS'te değil.

Özet; Uptime İzleme Kurulumu İçin Son Kontrol Listesi

Uptime izlemenizin ilk günden doğru çalışması için şu adımları sırayla uygulayın:

1. Kontrol aralığını sitenin önemine göre seçin (kritik siteler için 2 dakika, diğerleri için 5 dakika)
2. Timeout'u sitenin ortalama yanıt süresinin en az 2 katı olarak ayarlayın
3. Hata eşiğini 3 ardışık deneme olarak belirleyin
4. En az 2 coğrafi noktadan kontrolü etkinleştirin
5. Ana sayfa için bir içerik (Keyword) monitörü ekleyin
6. Ana alarm kanalı olarak Telegram veya SMS'i seçin, e-postayı değil
7. Alarmı yalnızca sorumlu kişilere verin, tüm ekibe değil
8. Site için API veya kritik yol için ayrı bir monitör oluşturun
9. İzleme komut dosyasını veya hizmetini ana siteden ayrı bir sunucuda çalıştırın
10. Ayda bir ayarları gözden geçirin ve altyapı değişikliklerinde güncelleyin

Uptime izleme, küçük bir yatırımla büyük getiri sağlar. Doğru ayarlarla, yalnızca kesintilerden daha erken haberdar olmakla kalmaz, aynı zamanda ekibinizin alarm sistemine olan güvenini de korursunuz. İzleme altyapısını yönetme ihtiyacı duymayan bir çözüm arıyorsanız, ServerNet gibi barındırma şirketleri tarafından sunulan bulut izleme hizmetleri iyi bir seçenek olabilir. Ancak her durumda, bu kılavuzda incelediğimiz ilkeler — kontrol aralığı, hata eşiği ve içerik kontrolü — hangi aracı seçerseniz seçin aynıdır.