Sunucu Çalışma Süresi Nasıl Doğru Şekilde İzlenir
26 Mayıs 2026 tarihinde yayımlandı
Tahmine dayanmadan sunucu çalışma süresini nasıl izleyeceğinizi öğrenmek istiyorsanız, yalnızca sunucunun içinden değil, sunucunun dışından yapılan kontrollerle başlayın. Bir hizmet, kullanıcılar zaman aşımı sayfasına bakıp dururken yerel günlüklerde sağlıklı görünebilir. İlk iş basittir - sunucunun bağımsız bir konumdan yanıt verip vermediğini, doğru portun açık olup olmadığını ve gerçek hizmetin geçerli bir yanıt döndürüp döndürmediğini doğrulayın. Zaman kazandıran kısım işte tam da gece 3:14’te olan budur. kimsenin felsefe istemediği zaman.
Kör noktalar olmadan sunucu çalışma süresi nasıl izlenir
Çalışma süresi izlemesi tek bir kontrolden ibaret değildir. Farklı soruları yanıtlayan küçük bir kontrol zinciridir. Ana makine ağa üzerinden erişilebilir mi? Web sunucusu 80 veya 443 portunda yanıt veriyor mu? Uygulama, 500 hatası yerine sağlıklı bir sayfa mı döndürüyor? Veritabanı hâlâ bağlantıları kabul ediyor mu? Yalnızca bir katmanı izlerseniz, gayet gerçek bir kesintiyi gözden kaçırabilirsiniz.
Temel bir ICMP ping, sunucuya erişilip erişilemediğini söyleyebilir, ancak web sitesinin veya API'nin çalıştığını kanıtlamaz. Bir TCP port kontrolü daha iyidir çünkü belirli bir hizmetin dinlemede olduğunu doğrular. Bir HTTP veya HTTPS kontrolü daha da ileri gider ve durum kodunu, yanıt içeriğini, sertifika geçerliliğini ve yanıt süresini doğrular. Çoğu iş yükü için HTTP kontrolleri asıl doğruluk merkezi sayılır çünkü müşterilerin kullandığı şey budur.
Birçok kurulumun biraz fazla iyimser hâle geldiği yer burasıdır. Yeşil bir ping sonucu, arkasındaki uygulama hiç de sakin değilken herkese güven verebilir.
Doğru uptime kontrolleriyle başlayın
Bir web sitesi için genel URL'yi HTTPS üzerinden izleyin, beklenen yanıt kodunu doğrulayın ve yanıt gövdesinde bilinen bir anahtar sözcüğü kontrol edin. Bu, sayfanın beklendiği gibi yüklendiğini gösterir; yalnızca yanlışlıkla 200 durumu döndüren bir hata şablonu getirdiğini değil.
Bir API için, varsa health endpoint'ini kontrol edin, ancak yüzeysel health kontrollerine karşı dikkatli olun. Endpoint yalnızca sürecin canlı olduğunu söylüyorsa, bozuk veritabanı bağlantılarını, başarısız cache backend'lerini veya depolama sorunlarını gizliyor olabilir. Daha kullanışlı bir health endpoint'i, uygulama için gerçekten önemli olan bağımlılıkları test eder.
Posta sunucuları için SMTP, IMAP veya POP3 portlarını doğrudan izleyin. Veritabanları için, genel kontrolleri açığa çıkarmak yerine iç izlemeyi kullanın. Amaç her hizmeti herkese açık hâle getirmek değildir. Amaç, hizmeti doğru yerden doğru yöntemle doğrulamaktır.
Pratik bir izleme yığını genellikle harici uptime kontrollerini, dahili hizmet kontrollerini ve sistem metriklerini içerir. Harici kontroller, kullanıcıların ne deneyimlediğini gösterir. Dahili kontroller, bir şeyin neden başarısız olduğunu gösterir. Metrikler, sorunları kesinti olmadan önce yakalamanıza yardımcı olur.
Neyle ilgili uyarı verilmeli, neyle ilgili verilmemeli
Her küçük sıçrama bir uyarı oluşturursa, ekibiniz uyarılara güvenmeyi bırakır. Gerçek olayların göz ardı edilmesi de böyle olur. İyi uptime izleme gürültücü değildir. Doğrudur.
İlk küçük aksaklıklar için değil, doğrulanmış arızalar için uyarı ayarlayın. Yaygın bir yaklaşım, yalnızca birden fazla konumdan arka arkaya iki veya üç başarısız kontrolden sonra uyarı vermektir. Bu, geçici paket kaybını veya tek bir izleme düğümünün kötü bir sabah geçirmesini ayıklamaya yardımcı olur. Aynı zamanda, uyarıları müşteriler önce fark edecek kadar da geciktirmeyin. Denge hizmete bağlıdır. Ödeme saatlerindeki bir çevrimiçi mağaza, özel bir dahili araçtan daha sıkı eşiklere ihtiyaç duyar.
Yanıt süresinin de eşikleri olmalıdır, ancak dikkatle. Yavaş olmak, kapalı olmakla aynı şey değildir. Bir ana sayfa normalde 300 ms içinde yükleniyor ve birden on dakika boyunca 4 saniye sürüyorsa, uptime izleme hâlâ yeşil gösterse bile bu dikkat gerektirir. Performans düşüşü çoğu zaman gerçek arızadan önce gelir.
Sertifika süresi dolma uyarıları da aynı konuşmanın parçasıdır. Teknik olarak, süresi dolmuş SSL sunucu kesintisi değildir, ancak müşteriler yine de bozuk bir hizmet görecektir. Operasyonel açıdan sonuç yeterince benzerdir.
Dahili metrikler uptime izlemeyi kullanışlı hâle getirir
Yalnızca çalışıyor-mu-çalışmıyor-mu kontrolleri toplarsanız, bir şeyin bozulduğunu bilirsiniz ama nedenini bilemezsiniz. Sistem metrikleri ve hizmet metrikleri ekleyin ki olay ilk dakikadan itibaren bağlama sahip olsun.
CPU kullanımı, bellek baskısı, disk alanı, disk G/Ç beklemesi, yük ortalaması, inode kullanımı ve ağ aktarım hızı olağan başlangıç noktalarıdır. Modern uygulama sunucularında bellek ve depolama sorunları, önlenebilir kesintilerin sık nedenleridir. Dolu bir disk, tek ve oldukça kaba bir hamleyle loglamayı, veritabanı yazmalarını, cache davranışını, yedeklemeleri ve paket güncellemelerini bozabilir.
Uygulama katmanında web sunucusu bağlantılarını, istek oranlarını, hata oranlarını, veritabanı gecikmesini, kuyruk uzunluğunu ve süreç yeniden başlatmalarını izleyin. Container kullanıyorsanız, container çıkışlarını ve kaynak sınırlarını izleyin. Bir SaaS platformu işletiyorsanız bağımlılıkları da izleyin - veritabanı replikasyon gecikmesi, Redis bellek kullanımı, nesne depolama kullanılabilirliği ve harici API zaman aşımları, müşteri bakış açısından uptime'ı etkileyebilir.
Metrikleri Prometheus'a aktaran ve bunları Grafana'da görselleştiren araçlar, ayrıntı ve esneklik isteyen ekipler için iyi çalışır. Daha basit barındırılan izleme araçları, tam bir observability platformu kurmadan güvenilir uyarılara ihtiyaç duyan daha küçük ekipler için çoğu zaman yeterlidir. Bu, ne kadar kontrole ihtiyaç duyduğunuza ve izlemenin kendisini sürdürmek için ne kadar zaman harcamak istediğinize bağlıdır.
Farklı ortamlar için sunucu uptime'ı nasıl izlenir
Tek bir iş web sitesini barındıran tek bir VPS, yalın bir kurulum gerektirir. Harici bir HTTPS kontrolü, temel sistem metrikleri, disk uyarıları, SSL süre dolumu izleme ve yedek doğrulaması riskin büyük bölümünü kapsar. Basit bir yığın için çok görkemli bir izleme imparatorluğuna ihtiyacınız yok.
Yönetilen bir VPS veya çok siteli ajans sunucusu daha fazla ayrım gerektirir. Yalnızca sunucuyu değil, her siteyi ayrı ayrı izleyin. Makinenin geri kalanı teknik olarak iyi durumda olsa bile, tek bir müşteri sitesi bozuk bir PHP süreci veya veritabanı sorunu nedeniyle başarısız olabilir. Yalnızca sunucu düzeyindeki uptime'ı izlerseniz, müşteriyle yüz yüze olan olayları kaçırırsınız.
Dedicated server'lar ve kümelenmiş uygulamalar düğüm düzeyinde ve hizmet düzeyinde izleme gerektirir. Bir düğüm başarısız olur ama trafik yine de doğru yönlendirilirse, hizmet kullanılabilir kalabilir. Bu uptime için iyidir, ancak yine de başarısız düğümün hemen görünür olmasını istersiniz ki yedeklilik sessizce ortadan kaybolmasın.
E-ticaret ve SaaS için işlem kontrolleri çabaya değer. Yalnızca ana sayfayı kontrol etmek yerine, oturum açma, arama yapma veya sepete ürün ekleme gibi temel bir eylemi simüle edin. Bu, sitenin çevrimiçi olduğu ama gelirin olmadığı o garip durumları yakalar.
Uyarı teslimi insanların kabul ettiğinden daha önemlidir
İzleme ancak doğru kişi, harekete geçebilecek kadar hızlı biçimde uyarıyı alırsa faydalıdır. Yalnızca e-posta, gerçek olaylar için fazla yavaştır. SMS, telefonla eskalasyon veya push tabanlı bir olay uygulaması gibi en az bir anlık kanal kullanın. Uyarıları önem derecesine ve günün saatine göre yönlendirin. Başarısız bir yedekleme raporu gece birini uyandırmamalıdır. Ölü bir production veritabanı muhtemelen uyandırmalıdır.
Ayrıca uyarıların yeterli bağlam içerdiğinden emin olun. "Server down" diyen bir mesaj teknik olarak dürüst, operasyonel olarak ise tembeldir. Daha iyi bir uyarı, hangi kontrolün başarısız olduğunu, hangi bölgelerden olduğunu, ne kadar sürdüğünü, yakın zamanda neyin değiştiğini ve hangi ilgili metriklerin şüpheli göründüğünü belirtir. Bu, ilk inceleme adımını kısaltır; dakikaların kaybolduğu yer de burasıdır.
Sağlayıcınız aktif izleme ve insan müdahalesi sunuyorsa, bu operasyonel sürtünmenin büyük bölümünü azaltabilir. Yönetilen altyapının karşılığını verdiği yerlerden biri budur. Örneğin kodu.cloud'da, izleme ve destek; tespit ile eylem arasındaki süreyi azaltacak şekilde tasarlanmıştır; bu da bir kesinti sırasında gösterişli panolardan daha önemlidir.
Uptime verilerini yanıltıcı hâle getiren yaygın hatalar
Hatalardan biri, sunucunun genel giriş noktası yerine özel IP'sini izlemektir. Bu, kutunun canlı olduğunu kanıtlar, ancak kullanıcıların ona DNS, yük dengeleyiciler, güvenlik duvarları veya TLS üzerinden erişebildiğini kanıtlamaz.
Bir diğeri yalnızca tek bir izleme konumu kullanmaktır. Bölgesel yönlendirme sorunları olur. Bir hizmet New York'tan bakıldığında sağlıklı olabilir, ancak bir sağlayıcı yol sorunu nedeniyle Dallas'tan erişilemez olabilir. Birden fazla kontrol bölgesi, yerel gürültüyü gerçek olaylardan ayırmaya yardımcı olur.
Üçüncü bir hata, bakım pencerelerini ve planlı değişiklikleri görmezden gelmektir. Her dağıtım yanlış kesinti uyarılarını tetiklerse ekipler duyarsızlaşır. Mümkün olduğunda bakım zamanlaması ve bağımlılık farkındalığı olan uyarı bastırma kullanın.
Bir de yedek doğrulaması olmadan yedeğe güvenme meselesi var. Bir sunucu, kurtarma gerekene kadar mükemmel uptime'a sahip olabilir. Yedekleme tamamlanmasını, saklama süresini, depolama sağlığını ve test geri yüklemelerini izleyin. Katı anlamda bu uptime izleme değildir. Gerçek dünyada, aynı güvenlik sisteminin parçasıdır.
Yalnızca bir pano değil, bir izleme rutini oluşturun
En güçlü kurulum iyi anlamda sıkıcıdır. Kontroller her bir veya iki dakikada bir çalışır. Uyarılar test edilir. Eşikler gerçek olaylardan sonra ayarlanır. Panolar mevcut sağlığı gösterir, ancak raporlar haftalar ve aylar boyunca eğilimleri de gösterir. Kesintinin kod değişikliklerinden mi, tükenmiş kaynaklardan mı, gürültülü komşulardan mı, süresi dolmuş sertifikalardan mı yoksa eski usul insan hatasından mı kaynaklandığını öğrenirsiniz.
Bunu sıfırdan kuruyorsanız, bir harici HTTPS kontrolü, bir dahili metrik toplayıcısı ve birinin gerçekten yanıt verdiği bir uyarı rotasıyla başlayın. Ardından, yığının başarısız olduğunda en çok acı veren kısımları için hizmete özgü kontroller ekleyin. İzleme egoyla değil, iş riskiyle birlikte büyümelidir.
Doğru yapıldığında uptime izleme size iki şey verir: daha hızlı olay müdahalesi ve daha az sürpriz. İnsanların başta çok etkileyici görünen pek çok çizgiye sahip bir pano istemiş olsalar bile, genellikle baştan beri istedikleri şey buydu.
Andres Saar Müşteri Hizmetleri Mühendisi