İşe Yarayan Sunucu İzleme Kurulum Rehberi
15 Haziran 2026 tarihinde yayımlandı
Sunucu izleme kurulum rehberiniz tek ve katı bir kuralla başlamalıdır: bir uyarı sizi uykudan uyandırıyorsa, gerçekten uyanmaya değmelidir. İzleme sorunlarının çoğu eksik araçlardan kaynaklanmaz. Bunlar gürültülü eşiklerden, belirsiz kontrollerden ve yoğun görünen ama hiçbir soruya yanıt vermeyen panolardan kaynaklanır. Çözüm kulağa geldiğinden daha basittir. Doğru katmanları kontrol edin, yalnızca eylem gerektiren durumlarda uyarı verin ve birinin ne olduğunu iki dakikadan kısa sürede anlayabildiğinden emin olun.
Pratik temel çizgi budur. İstemci siteleri için bir VPS, bir dedicated server üzerinde bir SaaS uygulaması ya da ödeme trafiği olan bir e-ticaret yığını çalıştırıyorsanız, izlemenizin tek görevi vardır - sorunları, hâlâ seçenekleriniz varken yeterince erken göstermesi. Kesinti sayfasından sonra değil, müşteri e-postasından sonra değil ve kesinlikle veritabanı kendi kendini küçük bir trajediye dönüştürecek kadar swap kullanmaya başladıktan sonra hiç değil.
Bir sunucu izleme kurulum rehberi neleri kapsamalı
Kullanışlı bir sunucu izleme kurulum rehberi yalnızca CPU ve bellek grafiklerinden ibaret değildir. Ana makine sağlığını, hizmet sağlığını, uygulama davranışını, depolama baskısını, ağ kalitesini ve kullanıcıların gerçekten izlediği yolu kapsamalıdır. Bunlardan biri eksikse, sunucunun "çalışıyor" göründüğü ama işin fiilen durmuş olduğu klasik durum ortaya çıkar.
Altyapı katmanından başlayın. CPU doygunluğunu, bellek kullanımını, swap etkinliğini, disk alanını, disk G/Ç beklemesini, yük ortalamalarını ve ağ aktarım hızını izleyin. Bunlar, kutunun kendisinin baskı altında olduğunun işaretleridir. Sanal sunucularda yalnızca zirvelere değil, patlama örüntülerine ve sürekli baskıya da dikkat edin. Beş saniyelik bir sıçrama çoğu zaman zararsızdır. Otuz dakikalık disk beklemesi ise başka bir hikâyedir.
Sonra hizmetlere geçin. Nginx veya Apache'nin yanıt verip vermediğini, PHP-FPM çalışanlarının takılıp takılmadığını, MySQL veya PostgreSQL'in bağlantı kabul edip etmediğini, Redis'in yeterince hızlı yanıt verip vermediğini ve cron işlerinin zamanında tamamlanıp tamamlanmadığını kontrol edin. Posta etkin sistemlerde SMTP kuyruk derinliğini ve teslimat hatalarını da izlemek istersiniz. Kapsayıcılaştırılmış iş yüklerinde yeniden başlatmaları, başarısız probları ve düğüm baskısını izleyin.
Son olarak, dışarıdan izleyin. Başka bir konumdan yapılan sentetik kontroller, kullanıcıların ne gördüğünü size söyler. Ana sayfa yüklemeleri, API sağlık uç noktaları, oturum açma yolları, SSL geçerliliği, DNS çözümlemesi ve yanıt süresi eğilimleri önemlidir; çünkü bunlar sunucu sağlığını gerçek hizmet davranışına bağlar. Bir güvenlik duvarı değişikliği veya süresi dolmuş sertifika erişimi çoktan bozmuşken iç metrikler sakin görünebilir.
Kurulumu tek bir yığın halinde değil, katmanlar halinde oluşturun
En temiz izleme kurulumları üç katman kullanır.
İlk katman kaynak izlemedir. Bu, birkaç saniye veya dakikada bir toplanan klasik sistem telemetrisidir. Makinenin kısıt altında olup olmadığını, bellek sızdırıp sızdırmadığını veya tam dolu bir diske yaklaşıp yaklaşmadığını yanıtlar. Buradaki iyi metrikler arasında moda göre CPU kullanımı, boş bellek, swap giriş ve çıkışı, bağlama noktasına göre dosya sistemi kullanımı, inode kullanımı, G/Ç gecikmesi ve ağ hataları yer alır.
İkinci katman hizmet izlemedir. Bu, önemli süreçlerin yalnızca çalıştığını değil, normal davrandığını da doğrular. Bir web sunucusu sürecinin bellekte bulunması, isteklerin çalıştığını kanıtlamaz. Bir veritabanı bağlantı noktasının açık olması, sorguların tamamlandığını kanıtlamaz. Bu katman yanıt süresi, hata oranları, kuyruk derinliği ve başarısız yeniden başlatmaları içermelidir.
Üçüncü katman bağlamlı uyarılamadır. Pek çok ekip burada yorulur. Her uyarı ana makine adı, metrik değeri, son eğilim ve temel düzeltme notları olmadan gelirse, insanlar yalnızca mesajı çözmek için zaman kaybeder. İyi bir uyarı, neyin başarısız olduğunu, nerede olduğunu, ne kadar kötü olduğunu ve neyin değiştiğini söyler. Günlükler şu anda aynı hikâyeyi anlatıyor - uyarınız da öyle yapmalıdır.
Gerçeği yansıtan eşikler seçin
Sabit eşikler başlangıç noktası olarak iyidir, ancak ayarlanmaları gerekir. CPU'nun bir dakika boyunca %90'ın üzerinde olması, yedeklemeler veya dağıtımlar sırasında normal olabilir. Disk kullanımının %80 olması, log yoğun bir veritabanı ana makinesinde riskli olabilir ancak çoğunlukla statik bir web düğümünde kabul edilebilir olabilir. Bellek alarmları özellikle zordur çünkü Linux, tasarım gereği kullanılabilir RAM'i agresif şekilde kullanır.
Daha iyi bir yaklaşım, eşik ile süreyi birleştirmektir. CPU bir kez %85'in üzerine çıktığında uyarı vermek yerine, 10 dakika boyunca %85'in üzerinde kalırsa ve yanıt süresi de artıyorsa uyarı verin. Yalnızca disk alanı için uyarı vermek yerine, kalan kapasite düştüğünde ve tüketim hızı hızlı olduğunda uyarı verin. Bir dosya sisteminde %15 alan kalmış olsa bile saatte 10 GB hızla doluyorsa, bu ham yüzde değerinin düşündürdüğünden daha erken dikkat gerektirir.
Bu, her sunucu izleme kurulum rehberindeki temel ödünleşimlerden biridir. Eşikleri fazla hassas tutarsanız ekip alarmları görmezden gelmeye başlar. Onları fazla gevşek yaparsanız sorunu müşterilerden öğrenirsiniz. İkisi de pek zarif değildir.
Metrikler faydalıdır, ancak günlükler ve yedekler de resmin parçasıdır
İzleme tek başına yaşamamalıdır. Bir uyarı tetiklendiğinde, sonraki adım genellikle günlüklerdir. Sistem günlükleri, web sunucusu günlükleri, veritabanı günlükleri ve uygulama günlükleri; sorunun yük, hatalı dağıtım, saldırı trafiği, sertifika sorunu veya arızalı depolama olup olmadığını doğrulamaya yardımcı olur. İzleme platformunuz en azından sizi bu kanıtlara yönlendiremiyorsa, yanıt süresi gerekenden daha uzun uzar.
Yedekler de burada önemlidir, teknik olarak izleme olmasalar bile. Uyarılar bozulma, başarısız yükseltmeler veya ani veri kaybı gösteriyorsa, güveniniz doğrudan yedek görünürlüğüne bağlıdır. backup job success, yedek yaşı, depo erişilebilirliği ve geri yükleme testi sonuçlarını izleyin. Hiçbir geri yüklemeyi atlatmamış yeşil bir yedek rozeti, operasyonlardan çok iyimserliktir.
Çoğu ekibin gerçekten ihtiyaç duyduğu minimum kontroller
Pratik bir başlangıç noktası istiyorsanız, egzotik herhangi bir şeyden önce şunları izleyin: sunucu erişilebilirliği, CPU, bellek, swap, disk kapasitesi, disk G/Ç beklemesi, web sunucusu yanıtı, veritabanı bağlantıları, SSL expiration, yedek iş durumu ve basit bir harici çalışma süresi kontrolü. Bir e-ticaret sitesi için ödeme adımı yolu izlemesini ve ödeme webhook hatalarını ekleyin. SaaS için API gecikmesini, çalı şan kuyruk derinliğini ve ilgiliyse veritabanı replikasyon gecikmesini ekleyin.
Bu, kurulumu bir hobi projesine dönüştürmeden birçok kör noktayı önlemek için yeterlidir. Uygulama metriklerini her zaman daha sonra ekleyebilirsiniz. Önce geliri, erişimi veya kurtarmayı bozan şeylerle başlayın.
Uyarı yorgunluğu yaratmadan uyarılar nasıl ayarlanır
Uyarı yönlendirmesi neredeyse kontrollerin kendileri kadar önemlidir. Kritik olaylar hemen nöbetçi yola gitmelidir. Daha düşük önem düzeyindeki uyarılar, mesai saatlerinde inceleme için paylaşılan bir kanala gidebilir. Her disk uyarısı, sertifika hatırlatması ve kısa yük sıçraması aynı yere ve aynı aciliyetle düşerse, önemli olaylar karmaşanın içinde kaybolur.
Açık anlamlı önem düzeyleri kullanın. Kritik, anında eylem anlamına gelir. Uyarı, yakında araştır anlamına gelir. Bilgi, izle veya gözden geçir anlamına gelir. İfadeyi sakin ve net tutun. "app-db-02 üzerinde 12 dakikadır veritabanı gecikmesi yüksek, yazmalar yavaşlıyor" ifadesi, "Performans sorunu algılandı." ifadesinden çok daha kullanışlıdır.
Ortamınız büyüdükçe eskalasyon kuralları yardımcı olur. Kritik bir uyarı birkaç dakika içinde onaylanmazsa, bunu ikincil bir kişiye yönlendirin. Aynı uyarı birden fazla ana makinede tekrarlanıyorsa, bunu tek bir olay hâlinde gruplayın. Yinelenen bildirimlerden oluşan bir fırtına kimseye yardımcı olmaz ve daha da az kişiyi etkiler.
Araçlar, kapsama ve disiplinden daha az önemlidir
Bunun için birçok iyi yığın vardır. Bazı ekipler metrikler ve görselleştirme için Prometheus ve Grafana'yı tercih eder. Diğerleri daha az bakım istedikleri için entegre barındırma izlemesi veya yönetilen gözlemlenebilirlik platformları kullanır. Seçim, ekibin becerisine, bütçeye ve ne kadar özelleştirme gerektiğine bağlıdır.
Şirket içinde güçlü operasyon becerileriniz varsa, esnek bir metrik yığını iyi bir uyum sağlayabilir. Daha az hareketli parça ve daha hızlı değer elde etme süresi istiyorsanız, yönetilen izleme çoğu zaman daha mantıklıdır. Küçük ve orta ölçekli işletmeler, gözlemlenebilirliğin ürünün kendisinin bir parçası olduğu durumlar dışında genellikle ikinci seçenekten fayda görür. Hiç kimse, sabah 2:13'te alertmanager ayarı yapma hayaliyle dükkân açmaz.
Operasyonel destek sunan bir sağlayıcının riski azaltabildiği yer burasıdır. kodu.cloud'da değer, yalnızca kontrollerin mevcut olması değildir. Değer; birinin altyapı bağlamıyla izliyor olması, yedeklerin daha geniş güvenlik ağının bir parçası olması ve kontrol yüzeyinin yalnızca tam zamanlı sistem yöneticileri için tasarlanmamış olmasıdır.
Büyüyen ortamlar için bir sunucu izleme kurulum rehberi
Altyapınız büyüdükçe, izlemeyi role göre ayırın. Web düğümleri, veritabanı düğümleri, önbellek düğümleri ve çalışan düğümleri aynı kontrolleri paylaşmamalıdır. Arıza örüntüleri farklıdır. Veritabanları G/Ç gecikmesi, replikasyon, kilitler ve disk büyümesine son derece duyarlıdır. Web düğümleri daha çok istek oranı, hata yanıtları, süreç sağlığı ve sertifika durumuna önem verir. Arka plan çalışanları kuyruk zamanlamasına, başarısız işlere ve harici bağımlılık kontrollerine ihtiyaç duyar.
Ayrıca her anlamlı olaydan sonra izlemenizi gözden geçirmelisiniz. Üç şeyi sorun: ilk olarak hangi işaret ortaya çıktı, doğru şekilde uyarı verip vermedi ve tanıyı neyin kısaltacağı. İzlemenin daha iyi hâle geldiği yer bu incelemedir. Yirmi yeni grafik ekleyerek değil, belirsizliği kaldırarak.
Sakin bir izleme kurulumu, hasardan önce uyarı veren, sistem sağlıklıyken sessiz kalan ve bir şeyler yolunda değilse sonraki eylemi açık hâle getiren kurulumdur. Bunu hedefleyerek kurun; böylece hizmet çoğu zaman yeniden sakin olur.
Andres Saar Müşteri Hizmetleri Mühendisi