İş Sunucusu İzleme Kontrol Listesi: 12 Kontrol
2 Ağustos 2026 tarihinde yayımlandı
Bir sunucu ping isteklerine yanıt verebilir ve yine de çok uzun bir öğleden sonra yaşatacak bir yeniden başlatmadan yalnızca bir adım uzakta olabilir. Bu iş sunucusu izleme kontrol listesi, önce müşterileri, personeli ve geliri etkileyen sinyallere odaklanır: kullanılabilirlik, uygulama davranışı, kapasite, güvenlik ve kurtarılabilirlik. Amaç, her küçük hareket için uyarı üretmek değildir. Amaç, gerçek bir hizmet sorunu oluşurken bunu erken fark etmektir.
İşe Gerçekte Kullandığı Şeylerle Başlayın
İzleme yalnızca müşteri yolculuğunu takip ettiğinde faydalıdır. Bir CPU grafiği, ödeme sürecinin çalışıp çalışmadığını, bir müşteri portalının e-posta gönderip göndermediğini veya bir API'nin geçerli yanıtlar döndürüp döndürmediğini söylemez. Kullanılabilir kalması gereken hizmetleri listeleyerek başlayın: web siteleri, veritabanları, posta hizmetleri, VPN'ler, arka plan çalışanları, dosya depolama, zamanlanmış işler ve üçüncü taraf entegrasyonları.
Her hizmet için bir sorumlu belirleyin, kabul edilebilir bir yanıt süresi tanımlayın ve neyin kesinti sayılacağına karar verin. Bir pazarlama sitesi birkaç saniyelik ek yükü tolere edebilir. Bir ödeme uç noktası veya üretim API'si ise genellikle bunu tolere edemez. Küçük ekiplerin avantaj kazandığı nokta burasıdır: liste kısa, net ve gerçek iş etkisine bağlı olabilir.
İş Sunucusu İzleme Kontrol Listesi: 12 Temel Kontrol
1. Harici uptime ve yanıt süresi
En önemli genel URL'lerinizi ve hizmet portlarınızı sunucunun dışından kontrol edin. Dahili izleme her şeyin yolunda olduğunu söyleyebilirken bir DNS sorunu, güvenlik duvarı kuralı, süresi dolmuş sertifika veya upstream yönlendirme hatası gerçek ziyaretçileri engelleyebilir.
HTTP durum kodlarını, sayfa veya API yanıt süresini ve mümkün olduğunda anlamlı bir içerik kontrolünü izleyin. Bir çevrimiçi mağaza için ana sayfanın 200 döndürdüğünü doğrulamak faydalıdır. Bir ürün araması veya sepet uç noktasının çalıştığını doğrulamak daha iyidir.
2. CPU kullanımı, load average ve steal time
Sürekli CPU doygunluğu veritabanlarını, web çalışanlarını, cron işlerini ve uzaktan yönetimi yavaşlatır. Ortalama CPU kullanımını izleyin, ancak load average değerini kullanılabilir CPU çekirdeği sayısıyla da karşılaştırın. Yüksek bir load average, CPU baskısını, disk I/O bekleyen süreçleri veya engellenmiş görevleri gösterebilir.
Bir sanal özel sunucuda CPU steal time dikkatle izlenmelidir. Yüksek steal time, hypervisor'un sizin iş yükünüze sıra gelmeden önce diğer iş yüklerine çok fazla zaman ayırdığı anlamına gelir. Bu her zaman bir uygulama sorunu değildir ve PHP ayarlamak gürültülü komşu durumunu düzeltmez.
3. Bellek kullanılabilirliği ve swap etkinliği
Yalnızca düşük boş bellek mutlaka kötü değildir. Linux kullanılmayan belleği önbellek için kullanır; bu normal bir davranıştır. Uyarı işaretleri; artan swap kullanımı, sık page fault'lar, out-of-memory olayları veya bir sürecin kernel tarafından sonlandırılmasıdır.
Yalnızca boş belleği değil, kullanılabilir belleği izleyin. Normal trafik sırasında swap sürekli büyüyorsa, bir sonraki trafik zirvesi gelmeden önce uygulamayı, veritabanı tamponlarını, çalışan sınırlarını veya sunucu boyutunu inceleyin.
4. Disk kapasitesi, inode kullanımı ve büyüme hızı
Dolu bir disk veritabanlarını durdurabilir, logların yazılmasını engelleyebilir, yedekleri bozabilir ve başka türlü sağlıklı olan bir web sitesinin şaşırtıcı şekillerde başarısız olmasına neden olabilir. Yalnızca ana dosya sistemini değil, ilgili her bağlama noktasını izleyin. Uygulama birimlerini, veritabanı depolamasını, yedek hazırlama alanlarını ve geçici dizinleri dahil edin.
Ayrıca inode tüketimini de izleyin. Milyonlarca küçük dosya, çok fazla disk alanı kalsa bile inode'ları tüketebilir. Büyüme hızını da izleyin. %70 dolulukta bir dosya sistemi sakin olabilir; günde %10 büyüyen bir sistem ise sorunun oldukça net bir habercisidir.
5. Disk I/O gecikmesi ve dosya sistemi hataları
Disk kullanımı kapasitedir. Disk gecikmesi performanstır. Yüksek okuma veya yazma bekleme süreleri, CPU kullanımı düşük olsa bile bir sunucunun donmuş gibi hissettirmesine neden olabilir. Veritabanı ağırlıklı hizmetler yavaş depolamaya özellikle duyarlıdır.
Olağandışı I/O wait, uzun süreli disk gecikmesi, dosya sistemi hataları ve tekrarlayan bağlama sorunları için uyarılar ayarlayın. Bir veritabanı sorgusu aniden genel olarak yavaşlarsa, veritabanının daha büyük bir önbelleğe ihtiyaç duyduğunu varsaymadan önce depolama davranışı kontrol edilmelidir.
6. Ağ trafiği, paket kaybı ve bağlantı hataları
Gelen ve giden throughput'u sunucu port kapasitesine göre izleyin, ancak burada durmayın. Paket kaybı, yeniden iletimler, arayüz hataları, düşen paketler ve beklenmedik derecede yüksek bağlantı sayıları genellikle yavaş veya güvenilmez hizmeti açıklar.
Bir trafik artışı iyi haber olabilir; örneğin başarılı bir kampanya gibi. Ya da bot trafiği, bir scraping çalıştırması, yanlış saatte planlanmış bir yedek aktarımı veya bir saldırı olabilir. İzleme, çok renkli bir grafikten tahmin yürütmek yerine bu kararı vermeniz için size kanıt sağlar.
7. Web sunucusu ve uygulama sağlığı
Web sunucunuz, yalnızca sürecinin çalışıp çalışmadığının ötesinde kontrol edilmelidir. Etkin bağlantıları, istek oranını, yanıt kodlarını, çalışan kullanılabilirliğini, kuyruk derinliğini ve uygulama hata oranlarını izleyin. Bir süreç canlı kalabilirken her istek 500 hatası döndürebilir.
PHP, Node.js, Java, Python veya benzer uygulama yığınları için çalışan yeniden başlatmalarını, bellek büyümesini, yakalanmamış istisnaları ve uç nokta bazında istek gecikmesini izleyin. En iyi uyarı çoğu zaman “süreç durdu” değildir. “Ödeme uç noktası normalden beş kat daha yavaş” uyarısıdır.
8. Veritabanı performansı ve replikasyon durumu
Veritabanları web sunucularından farklı şekilde başarısız oldukları için kendi izleme planlarını hak eder. Bağlantı kullanımını, yavaş sorguları, sorgu gecikmesini, kilitleri, tampon veya önbellek verimliliğini, depolama büyümesini ve hata loglarını izleyin.
Replikasyon kullanıyorsanız, replikasyon gecikmesini ve replika sağlığını izleyin. Saatlerce geriden gelen bir replika hâlâ çevrimiçi görünebilir, ancak raporlama, failover veya kurtarma için hazır değildir. Yönetilen veritabanı iş yüklerinde, yavaş sorgu kalıplarını kimin ve ne sıklıkla inceleyeceğine karar verin. Bunu uygulama gözle görülür şekilde yavaşlayana kadar ertelemek pahalı bir zamanlamadır.
9. Yedekleme tamamlanması ve geri yükleme hazırlığı
Başlayan bir yedekleme işi, sizi kurtarabilecek bir yedek olduğu anlamına otomatik olarak gelmez. İşlerin tamamlanıp tamamlanmadığını, ne kadar sürdüklerini, yedeğin boyutunu, hedef depolamanın kullanılabilirliğini, kullanılıyorsa şifreleme durumunu ve yedekleme aracından gelen tüm uyarıları izleyin.
En önemlisi, geri yükleme testleri planlayın. Bir dosya geri yüklemesini, bir veritabanı geri yüklemesini ve pratik olduğu durumlarda ayrı bir ortama tam hizmet kurtarmasını test edin. Loglar, ancak bir geri yükleme test edildikten sonra artık aynı hikâyeyi anlatıyor olur. Geri yükleme kanıtı olmayan bir yedek hâlâ umutla kurulmuş bir düzendir.
10. Güvenlik olayları ve yama durumu
Başarısız oturum açma kalıplarını, ayrıcalık değişikliklerini, yeni kullanıcı hesaplarını, SSH erişimini, güvenlik duvarı engellemelerini, kötü amaçlı yazılım uyarılarını, sertifika süresinin dolmasını ve olağandışı giden bağlantıları izleyin. Her başarısız oturum açma gece yarısı araması gerektirmez, ancak bir yönetici hesabına karşı ani bir patlama daha yakından incelenmeyi hak eder.
Yama izleme, hem mevcut güncellemeleri hem de gecikmiş kritik düzeltmeleri raporlamalıdır. Güncellemeleri, hizmete uygun bir bakım planıyla uygulayın. Bir geliştirme VPS'i hızlı bir yeniden başlatmaya izin verebilir. Müşteriye dönük bir üretim sunucusu test, yedek kontrolü ve planlı bir değişiklik penceresi gerektirebilir.
11. SSL, DNS ve alan adı bağımlılıkları
Sertifika süresinin dolması, çalışan bir web sitesini anında bir güven sorununa dönüştürebilir. Sertifikaların süresi dolmadan çok önce uyarı verin ve otomatik yenileme sonuçlarını izleyin. Sertifikanın amaçlanan ana bilgisayar adıyla eşleştiğini ve tam zincirin doğru şekilde sunulduğunu kontrol edin.
DNS de benzer özeni hak eder. Temel DNS kayıtlarını, ad sunucusu kullanılabilirliğini ve beklenmeyen kayıt değişikliklerini izleyin. DNS ters gittiğinde en güzel durum değildir, ancak bilinen bir temeliniz ve müşteriler bildirmeden önce bir uyarınız varsa kontrol altındadır.
12. Loglar, zamanlanmış işler ve uyarı teslimatı
Mümkün olduğunda yararlı logları merkezileştirin ve tekrarlayan hataları, kimlik doğrulama başarısızlıklarını, uygulama istisnalarını ve hizmet yeniden başlatmalarını izleyin. Log hacmi de bir sinyaldir. Ani bir sel depolamayı doldurabilir; ani bir sessizlik ise log aracısının başarısız olduğu anlamına gelebilir.
Cron işlerini, kuyrukları, zamanlanmış içe aktarmaları, rapor oluşturmayı ve yenileme görevlerini izleyin. Bu işler genellikle sessizce başarısız olur çünkü web sitesinin kendisi çevrimiçi kalır. Son olarak, uyarı teslimatını test edin. Saat 3'te kimsenin kontrol etmediği bir gelen kutusuna ulaşan bir uyarı. operasyonel kontrolden çok bir günlük kaydı gibidir.
Gürültü Değil, Eylem Yaratan Eşikler Belirleyin
Herkese uyan tek tip eşiklerden kaçının. %90 CPU uyarısı, normalde %15 düzeyinde çalışan küçük bir VPS'te acil olabilir; ancak her gece bir saat boyunca yüksek yükte çalışmak üzere tasarlanmış bir toplu işleme sunucusu için zararsız olabilir. Normal trafik sırasında bir temel oluşturun, sonra kalıcı sapma ve iş etkisine göre uyarı verin.
Net eylemlerle önem dereceleri kullanın. Bir uyarı seviyesi, nöbetçi kişinin büyüyen bir diski mesai saatleri içinde incelemesini isteyebilir. Kritik bir uyarı, müşteriye dönük bir hizmetin kapalı olması, veri korumanın risk altında bulunması veya kapasitenin yakında tükenecek olması nedeniyle birinin hemen harekete geçmesi gerektiği anlamına gelmelidir.
Her önemli uyarı üç soruya yanıt vermelidir: ne başarısız oldu, ne etkilendi ve önce ne kontrol edilmeli. Uyarı mesajına sunucu adını, hizmeti, zaman damgasını, ilgili metriği ve kısa bir runbook referansını ekleyin. Bunu alan kişi yorgun olabilir, ortama yeni olabilir veya her ikisi birden olabilir. Onlara adil bir başlangıç verin.
Baskı Oluşmadan Önce Bir Eskalasyon Yolu Oluşturun
Bir izleme yığını operasyonel sahipliğin yerini tutmaz. Uyarıları kimin aldığını, yeniden başlatma veya rollback onayını kimin verebileceğini, kimlik bilgilerinin güvenli şekilde nerede saklandığını ve doğrulanmış bir olay sırasında müşterilerin nasıl bilgilendirileceğini belgeleyin. Ajanslar için bu özellikle değerlidir çünkü tek bir altyapı olayı aynı anda birkaç müşteri hesabını etkileyebilir.
Yönetilen izleme burada yükü azaltabilir. FASTCARE monitoring gibi hizmetler, özellikle mesai saatleri dışında ekibinizin sunucu sinyalleri üzerinde insan gözüne ihtiyaç duyduğu durumlarda faydalıdır, ancak yine de eskalasyon irtibat kişileri ve izin verilen eylemler üzerinde anlaşmanız gerekir. Disk %100'e ulaşırken kimsenin bir telefon numarası aramak zorunda kalmadığı durumlarda hızlı müdahale en iyi sonucu verir.
Kontrol listesini aylık olarak ve her olaydan sonra gözden geçirin. Gürültü yaratan uyarıları kaldırın, tespitten kaçan arızalar için kontroller ekleyin ve iş yükü büyüdükçe eşikleri güncelleyin. Sakin altyapı sessiz altyapı değildir. Doğru kişilerin doğru sinyali hizmeti yeniden sakinleştirecek kadar erken aldığı bir ortamdır.
Andres Saar Müşteri Hizmetleri Mühendisi