Sunucu izleme yazılımı: CPU, RAM, disk ve SNMP kontrolleri

Çoğu sunucu izleme ürünü, bir aracı kurmanızı ister: makinenizde kalıcı olarak çalışan ve veri akıtan, sistem düzeyinde erişime sahip bir arka plan işlemi. HostTracker kasıtlı olarak bunu yapmaz. O harici bir izleme hizmetidir ve bir sunucu yük kontrolü tam tersi yönde çalışır - sunucunuz tek bir sayı bildiren, küçük ve salt okunur bir uç nokta sunar ve HostTracker onu sizin belirlediğiniz zamanlamada ister.

Bu tersine çevirme tüm tasarımın özüdür. Canlı tutulacak bir arka plan hizmeti, üretimde çalışan sizin yazmadığınız ayrıcalıklı bir yazılım, üçüncü bir tarafa devredilen kimlik bilgileri veya gelen bir yönetim portu yoktur. Açığa çıkardığınız şey, hiçbir komut kabul etmeyen, hiçbir şeyi değiştirmeyen ve tek bir değer döndüren bir URL'dir.

Her monitör tek bir değeri izler; bu yüzden tipik bir sunucuda genellikle üç veya dört tanesi bulunur - ve her biri kendi eşiğine, kendi geçmişine ve kendi uyarısına sahiptir. Değer türleri şunlardır:

İhtiyacınız olan şey, sunucunun bağlantı süresi değil de arkasındaki veritabanıysa, bu farklı ve daha derin bir kontroldür: bir veritabanı sorgu monitörü bağlanır, kimlik doğrular, sizin yazdığınız bir sorguyu çalıştırır ve döndürdüğü değeri bir eşikle karşılaştırır.

Sözleşme kasıtlı olarak çok basittir, çünkü amaç, onu tek oturuşta okuyabilmeniz ve ekibinizin zaten kullandığı herhangi bir dilde uygulayabilmenizdir. HostTracker URL'nizi ister; uç noktanız değeri taşıyan bir JSON nesnesiyle yanıt verir:

{ "v": 42.7 }

Gereken tek şey bu kadardır. İki isteğe bağlı üye, sonucu daha kullanışlı hale getirir: e, değer bu sefer okunamadığında bir hata dizesi taşır - yanıltıcı bir sıfır raporlamaktan çok daha iyi bir sonuçtur - ve vs kendi sürüm dizenizi taşır; bu, sonuçta görünür, böylece toplayıcının hangi yapısının yanıt verdiğini anlayabilirsiniz.

{ "v": 91.4, "e": "", "vs": "collector-2.1" }

Okuyucuyu siz yazdığınız için, genel bir aracının toplamayı bildiği şeylerle sınırlı değilsinizdir. Kuyruk derinliği, önbellek isabet oranı, bekleyen iş sayısı, işlenmemiş en eski kaydın yaşı, boş inode'lar, asla büyümemesi gereken bir dizinin boyutu - sayı olarak ifade edebileceğiniz her şey, kendisine eşikler, geçmiş ve uyarı eklenmiş izlenen bir değere dönüşür.

Ham bir sayı veridir; onu izlemeye dönüştüren şey bir eşiktir. Her monitör bir koşul ve bir veya iki sınır taşır; böylece yalnızca bir tavan değil, "yanlış"ın şeklini ifade edebilirsiniz:

• bir sınırdan büyük veya küçük - günlük kullanılan biçim. CPU 90'ın üzerinde. Boş disk 10'un altında.
• bir sınıra eşit veya eşit değil - gerçekte bir durum olan bir değer için: 4'te kalması gereken bir işçi sayısı, 0'da kalması gereken bir bayrak.
• iki sınırla bir aralığın içinde veya bir aralığın dışında - sağlıklı bir maksimumdan çok sağlıklı bir bant içeren her şey için doğru biçim. Normalde 10 ile 500 arasında olan bir kuyruk, 0 okuduğunda size bir şey, 5.000 okuduğunda başka bir şey söylüyordur.
• hiç koşul olmadan - kontrolü asla başarısız kılmadan değeri toplayın ve grafikleyin. "Kötü"nün neye benzediğini bilmeden önce geçmişini istediğiniz bir metrik için kullanışlıdır.

Sıçrama önleyici (debounce), gürültüyü durduran ayardır

Eşiğin yanında, sıfırdan yirmiye kadar ayarlanabilen, monitörün kesintiye düşmeden önceki ardışık aşırı yüklenmiş kontrol sayısı yer alır. Bu, sayfadaki tek en değerli ayardır ve en sık dokunulmadan bırakılanıdır. Gecelik bir yedekleme sırasında bir örnekte %95 CPU'da olan bir sunucu bir olay değildir. Art arda beş kontrolde %95'te olan bir sunucu ise öyledir. Sayacı, iş yükünüzün ne kadar süre meşgul olmasına meşru olarak izin verildiğine göre ayarlayın; eşiğiniz daha az sıkı hale gelmeden, sabahın 3'ündeki sahte alarmların tüm bir kategorisi ortadan kalkar.

Bu, bir web kontrolüne göre burada daha da önemlidir, çünkü bir sunucu metriği, bir erişilebilirlik kontrolünün yaptığı gibi birkaç bağımsız kontrol noktası genelinde doğrulanmak yerine, tek bir yetkili kaynaktan - kendi toplayıcınızdan - okunur. Anlık bir sıçramayı ortalamaya alacak ikinci bir görüş yoktur; bu yüzden o rolü oynayan şey sıçrama önleyici (debounce) sayacıdır.

Üç temel metrik gerçekten farklı şekillerde başarısız olur ve hangisine baktığınızı bilmek, ne kadar zamanınız olduğunu size söyler.

Disk, klasik önlenebilir kesinti olarak ününü hak ediyor. Bir eşiğe ve bir haftalık geçmişe sahip bir monitörün her zaman ilk yakalayacağı arıza budur ve sonradan açıklaması en can sıkıcı olanıdır.

Her okuma saklanır; bu yüzden her sunucu monitörünün, baktığınız pencere için ortalama, minimum ve maksimumla birlikte kendi değerinin zaman içindeki bir grafiği vardır. Yüzdeler yüzde olarak, bağlantı süreleri ise milisaniye olarak grafiklenir; böylece bir CPU monitörü ve bir veritabanı gecikme monitörü her biri beklediğiniz şekilde okunur.

Uyarı size bir şeyin bir çizgiyi aştığını söyler; grafik ise size sonrasında gerçekten ihtiyacınız olan iki şeyi söyler. Bu yeni mi? - tek başına alarm verici görünen bir sıçrama, genellikle bir yıldır her Salı saat 02:00'de yaşanan aynı sıçramadır. Ve nereye gidiyor? - yeniden başlatmalar arasında sürekli yükselen bir bellek rakamı, mevcut değeri ne olursa olsun bir sızıntıdır ve haftada yüzde iki yükselen bir disk, üzerinde bir tarih taşır.

Bu ikinci soru, sunucu izlemenin kapasite planlama kullanımıdır ve üzerine hangi eşiği koyacağınızı bilmeden önce bir metriği toplamaya başlamanın nedenidir. Geçmiş size normalin neye benzediğini söyledikten sonra, eşiği bir ay içinde ekleyebilirsiniz. Toplamadığınız geçmiş, geri alamayacağınız geçmiştir.

Bunlar birbirinin alternatifi değil, tamamlayıcısıdır ve ayrım açıkça belirtmeye değecek kadar nettir.

Yalnızca birini çalıştırmak, her iki yönde de gerçek bir boşluk bırakır. Çoğu hesabın karar kıldığı eşleştirme, birden fazla konumdan bir dakikalık bir erişilebilirlik kontrolü artı CPU, bellek ve dolması en olası birim üzerinde birkaç sunucu monitörüdür.

Yönlendiriciler, anahtarlar, güvenlik duvarları, UPS üniteleri ve yazıcılar bir betik barındıramaz, ama neredeyse hepsi zaten SNMP konuşur. Ayrı bir SNMP kontrolü, sayısal bir değeri doğrudan cihazdan OID ile okur - arayüz sayaçları, sıcaklık, yük, çalışma süresi, pil şarjı - SNMP v1, v2c veya v3 üzerinden; kimlik bilgilerinin açık metin olarak gönderilmemesi için kimlik doğrulama ve gizlilik içeren v3 dahil.

Bunun bugün nerede durduğu konusunda size dürüst olalım: bir SNMP kontrolü, cihazın raporladığı değeri okur ve kaydeder. Bir SNMP değeri üzerinde eşik tabanlı uyarı henüz mevcut değildir - bir sayının gerçekten bir olay tetiklemesine ihtiyacınız olduğunda, yukarıda açıklanan tam koşul ve sıçrama önleyici modeline sahip bir toplayıcıya karşı bir sunucu yük monitörü kullanın.

1. Neyi açığa çıkaracağınıza karar verin. Sunucunuz zaten PHP veya IIS çalıştırıyorsa, eşleşen hazır toplayıcı en hızlı yoldur; aksi hâlde uç noktayı kendiniz yazın - tek bir sayı döndürür.
2. Onu izlemek istediğiniz sunucuya dağıtın ve kendinizin de isteyebildiğini doğrulayın. Tahmin edilemez bir yola koyun. Makine yeniyse, daha ileri gitmeden önce dışarıdan erişilebilir olduğunu doğrulamanın hızlı bir yolu ücretsiz TCP port kontrolü ve ücretsiz ping testidir - giriş gerekmez.
3. CPU, RAM, HDD izle türünde bir monitör ekleyin, hangi değeri okuyacağını seçin ve ona toplayıcının URL'sini verin. Bir disk monitörü için yolu veya sürücüyü belirtin; bir veritabanı bağlantı süresi monitörü için toplayıcının araması gereken bağlantı ayrıntılarını verin.
4. Koşulu ve sınırları ayarlayın - ve kesintiye düşmeden önceki aşırı yüklenme sayısını varsayılanda bırakmak yerine bilinçli olarak ayarlayın. Monitörün kullanışlı mı yoksa göz ardı mı edileceğine karar veren ayar budur.
5. Bir dakikadan 24 saate kadar herhangi bir yerden bir aralık seçin. Bir dakika, iş açısından kritik bir şey çalıştıran bir makineye uyar; disk kullanımı gibi bir eğilim için 5 veya 10 dakika fazlasıyla yeterlidir.
6. O ana bilgisayarda önemli olan her değer için tekrarlayın - CPU, bellek ve dolması en olası birim, makul bir başlangıç kümesidir - ardından bundan haberdar olması gereken kişileri ekleyin.
7. Herhangi bir şeyi ince ayar yapmadan önce bir hafta bekletin. Geçmişin ilk haftası, eşiğinizin doğru olup olmadığını size söyleyen şeydir ve ilk gün yapılan bir tahminden çok daha iyi bir kanıttır.

• Toplayıcının erişilebilir olması gerekir. Hiç gelen erişimi olmayan bir ana bilgisayar sorgulanamaz. Açığa çıkarılması gereken şey bir yönetim portu değil, salt okunur tek bir URL'dir - ama yine de açığa çıkarılması gerekir.
• Bir monitör tek bir değeri izler. CPU, bellek ve disk, her biri kendi eşiğine ve kendi geçmişine sahip üç monitördür. Uyarıyı hassas kılan şey budur ve bu, meşgul bir sunucunun birkaç monitör slotu kullandığı anlamına gelir.
• Windows performans sayaçları ASP.NET toplayıcısını gerektirir. Kategori / ad / örnek üçlüsü, o toplayıcı tarafından yerel olarak okunur; bir PHP ana bilgisayarı bunun yerine CPU, bellek, disk ve bağlantı sürelerini raporlar.
• Çok konumlu bir doğrulama yoktur. Bir erişilebilirlik kontrolünün aksine, bir sunucu metriği tek bir yetkili kaynaktan gelir; bu yüzden tek bir anormal okuma gerçek bir okumadır. Bunun için araç ardışık aşırı yüklenme sayısıdır ve ayarlamaya değer.
• Toplayıcının raporladığını raporlar. Özel uç noktanızda bir hata varsa, monitör sadakatle yanlış sayı üzerinden uyarı verir - yanıttaki isteğe bağlı hata üyesinin önemli olmasının nedeni budur: sıfır yerine bir hata raporlayın.
• Ağ verim (throughput) sayacı yoktur. Kullanılabilir değerler CPU, bellek, disk kullanımı, bağlantı süreleri ve Windows performans sayaçlarıdır; bant genişliği bunların arasında değildir. Verimi SNMP üzerinden raporlayan bir cihaz için bir SNMP kontrolü o sayacı okuyup grafikleyebilir.