Bu İzleme Yazılımı ile ilgili Kanonik bir Soru .
Ayrıca İlgili: Sunucularınızı izlemek için hangi aracı kullanıyorsunuz?
Sunucularımı izlemem gerekiyor; Bir izleme çözümüne karar verirken nelere dikkat etmeliyim?
Yanıtlar:
Dışarıda birçok izleme çözümü var. Herkesin kendi tercihi vardır ve her işletmenin kendi ihtiyaçları vardır, bu nedenle doğru bir cevap yoktur. Bununla birlikte, bir izleme çözümü seçerken neyi aramak isteyebileceğinizi bulmanıza yardımcı olabilirim.
Genel olarak izleme sistemleri iki temel amaca hizmet eder. İlki, zaman içinde veri toplamak ve depolamaktır. Örneğin, CPU kullanımını toplamak ve zaman içinde grafiğini çizmek isteyebilirsiniz. İkinci amaç, işler yanıt vermediğinde veya belirli eşiklerde olmadığında uyarmaktır. Örneğin, belirli bir sunucuya ping ile erişilemiyorsa veya CPU kullanımı belirli bir yüzdeden fazlaysa uyarı isteyebilirsiniz. Splunk gibi log izleme sistemleri de var ama ben bunun için ayrı davranıyorum.
Bu iki ana rol bazen tek bir üründe gelir, diğer zamanlarda ve daha yaygın olanı her amaca yönelik bir ürüne sahip olmaktır.
Pollers :
Tüm izleme sistemlerinde veri toplamak için bir çeşit poller gerekir. Tüm veriler aynı şekilde toplanmamaktadır. Ortamınıza bakmalı ve hangi verilere ihtiyacınız olduğuna ve bunların nasıl toplanabileceğine karar vermelisiniz. Ardından, seçtiğiniz izleme sisteminin ihtiyacınız olanı desteklediğinden emin olun. Bazı yaygın yöntemler şunlardır:
Ortamınızda çoğunlukla bir işletim sistemi veya birincil işletim sistemi varsa, bazı sistemler diğerlerinden daha fazla seçeneğe sahip olabilir.
Yapılandırma :
İzleme sistemlerinde çok sayıda nesne yeniden kullanımı söz konusudur. Örneğin, bir grup sunucuda Apache veya IIS gibi belirli bir uygulamayı izlemek istiyorsunuz. Veya belirli eşiklerin sunucu gruplarına uygulanmasını istersiniz. Ayrıca, "aramada" olacak belirli insan gruplarına sahip olabilirsiniz. Bu nedenle iyi bir şablonlama sistemi, bir monitör sistemi için hayati öneme sahiptir.
Yapılandırma genellikle bir kullanıcı arayüzü veya metin dosyaları aracılığıyla yapılır. Kullanıcı arayüzü seçeneği genellikle daha kolay olacaktır, ancak metin dosyaları yeniden kullanım ve değişkenler için daha iyi olma eğilimindedir. Bu nedenle, BT personelinize bağlı olarak, güç yerine basitliği tercih edebilirsiniz.
Kullanıcı Arabirimi :
Günümüzde izleme sistemleri için en yaygın arayüz bir web arayüzüdür. Web arayüzü ile ilgili değerlendirmek için bazı şeyler şunlardır:
Uyarı Motoru : Uyarı
motoru esnek ve güvenilir olmalıdır. Aşağıdakiler dahil olmak üzere bilgilendirilmenin birçok yolu vardır:
Aranacak diğer özellikler şunlardır:
Bir şeyler ters gittiğinde uyarı alacağınıza güvenmek önemlidir. Bu iki şeye iniyor:
Veri Deposu :
Sistem veri depolar ve verileri depolarsa (örneğin, grafik içeren sistemler) veri depolar. Hem mağaza hem de grafik oluşturma için çok yaygın bir uygulama örneğin RRD'dir.
Veri deposundan aranacak bazı özellikler şunlardır:
Grafik Kütüphanesi :
Grafikler, trendleri hızlı bir şekilde tanımlamak ve geçmişine dayanarak bir şeyin mevcut durumuna bağlam vermek için yararlı olabilir. Bazıları olayları gerçekleşmeden önce tahmin etmede yardımcı olabilecek trendler de dahil (örneğin, disk alanı azalıyor). Grafiklerin size ihtiyaç duyacağınızı düşündüğünüz bilgileri net bir şekilde vereceğinden emin olun.
Erişim Kontrolleri :
Büyük bir kuruluşunuz varsa erişim kontrollerine ihtiyacınız olabilir, çünkü bazı yöneticiler yalnızca belirli şeyleri ayarlayabilmelidir. Ayrıca halka açık panoları da isteyebilirsiniz. Bu önemliyse, izleme sisteminin ihtiyacınız olan kontrollere sahip olduğundan emin olmalısınız.
Raporlama :
İyi raporlar sunan bir sistem, uzun süre boyunca neyin iyileştirilmesi gerektiğini belirlemenize yardımcı olabilir. Örneğin, "en çok hangi sistemler aşağı gidiyor?" Gibi şeylere iyi bir cevap verebilir. Yönetimi bazı şeylere para harcamak için ikna etmeye çalıştığınızda bu önemli olabilir - iş kanıtı gibidir.
Özel Özellikler :
Bazı izleme sistemleri belirli ürünleri hedef almaktadır veya diğerlerinden daha fazla desteğe sahiptir. Örneğin, izlemeniz gereken ana şey SQL sunucusuysa veya VMWare ürünlerini yoğun şekilde kullanıyorsanız, bunların ne kadar iyi desteklendiğini görmelisiniz.
Önceden Tanımlanmış İzleme Şablonları :
Çok sayıda önceden tanımlanmış şablon içeren (veya birçok şablon oluşturan bir kullanıcı tabanına sahip) bir sistem çok zaman kazandırabilir.
Keşif :
Büyük veya değişen bir ortamınız varsa. Bazı sistemler bir API üzerinden yeni sistemler ekleme veya yeni sunucular veya bileşenler bulmak için taramalar yapma olanağı sağlar.
Dağıtılmış İzleme: İzlemek
için birden fazla yeriniz varsa, WAN üzerinden çok sayıda bağımsız sistemin izlemesi yerine, her yerde izleyicilerin izlenmesi yararlı olabilir.
Dışarıda birçok izleme sistemi var. Bu eski sorunun özeti olan bir listemiz var . Hızlı başvuru için bazılarını en çok duyduğum şeyler:
Ne kullanman gerektiğini sana söyleyemememin nedeni, her organizasyonun kendine has ihtiyaçları olması. Doğru seçimi yapmak istiyorsanız yukarıdaki tüm bileşenleri göz önünde bulundurmalı ve hangi özelliklerin kuruluşunuz için önemli olduğunu bulmalısınız. Sonra ihtiyacınız olanı sağladığını iddia eden bir sistem veya sistemler bulun ve deneyin. Bunlardan bazıları biraz, çok pahalı ya da ücretsizdir. Bunları dikkate alarak seçiminizi yapabilirsiniz. Benim kullandıklarımdan, hepsi mükemmel olmaktan uzak, ama en azından uygun bir şey elde etmeye çalışabilirsin.
İzleme ve uyarı arasında ayrım yapmak faydalıdır. İzleme, veri toplama ve grafik yapma anlamına gelir. Uyarı, bir sunucu gecenin ortasında düştüğünde bana SMS gönderilmesi anlamına gelir.
Nagios uyarmak içindir. Kaktüsler ve Munin izleme için. Diğer ürünler iki işlevi birleştirir. Zenoss ve Zabbix örneklerdir.
Bazı soruları cevaplayarak başlarım:
Sunucuları, ağ cihazlarını, uygulamaları veya üçünü de izlemeniz mi gerekiyor?
İzlemek için kullanabileceğiniz yöntemlerle ilgili kısıtlamalar var mı? Sunuculara NRPE gibi izleme istemcileri kurabilir misiniz, yoksa SNMP'yi veya belki her ikisini de kullanır mısınız?
Grafikleri kim, uyarıları kim kullanacak? Sonuçların nasıl görünmesini istersiniz? Arayüzün görünüşü ve hissi önemli mi (iş adamları bunu mu kullanacak, yoksa sadece teknik personel mi?)
Zaman, beceri ve donanım bakımından kaynaklarınız nelerdir? En azından mütevazı bir komut dosyası yazma yeteneğiniz var mı? Kullanıma hazır bir çözüme mi ihtiyacınız var?
Kanımca, hem uyarı hem de izlemenin ilk kuralı Basit olmalı! Bir kuruluş, verileri nasıl uyardığı ve topladığı konusunda yaşayabilir veya ölebilir ve çoğu zaman kendi başına karmaşıklaşır. Temel bilgilerle başlayın ve oradan inşa edin.
Yazılımınızın sağladığı hizmetleri düşünün , bu hizmetler başarısız olduğunda veya bu hizmetlerin başarısız olma riski arttığında uyarılar gönderin .
İzleme stratejilerinin ardındaki teori, izlemeyi ve uyarıları bir tür hizmet seviyesi anlaşmasına bağlamaktır . Sonuçta, nji0019.myserver.com’a yapılan TCP bağlantı sayısında bir artış olması şart değil, para kaybettiğiniz konusunda uyarılmak istiyorsunuz. Size tonlarca uyarı verecek, alarmlar arasındaki bağımlılıkları tanımlayan çeşitli araçlar vardır, ancak bu kontrollerin birçoğu birisine verdiğiniz hizmetle doğrudan ilişkili değildir .
Bir web sitesine hizmet verme yeteneği ve bu web sitesini değiştirme yeteneği (örneğin, bir tür CMS) gibi sağladığınız önemli hizmetleri belirleyin. Bunlar kontrol edilmelidir (örneğin web sayfasını alabileceğinizi ve alabileceğinizi izleyerek). Bu iki Hizmetin başarısızlığı (burada büyük S harfi ile kullanılır) sizi bilgilendirmek için bir uyarı tetiklemelidir.
Sitenin makul bir süre içinde yanıt vermesi önemliyse, uyarıları da tetiklemesi gerekir. İsterseniz bir "SLA ihlali" sıralayın.
Genelde bir Hizmetin kendiliğinden başarısız olma riski vardır ve genellikle, ikinci bir sunucu veya bir ikincil veri tabanı veya ek ağ kartları gibi fazlalıklar vermeniz gerçeği nedeniyle bu riski azaltmanız yeterlidir.
Bu fazlalık kaybolduğunda, Servis hala iyidir, ancak Servisin başarısız olma riski henüz artmıştır.
Bu, uyarıları tetiklemenin ikinci ana nedenidir; fazlalıkların ortadan kalkması (örneğin, ikinci sunucunun ölmesi) ya da riskin artması tehlikesi vardır (örneğin, disk yalnızca 500Mb kaldı ya da disk eğilimi, diskin yaklaşık 5 saat içinde dolduğunu gösterir).
Fakat check_mk, ev sahibi başına 50-60 çek veriyor, bunların hepsi değersiz mi?
Hayır. Bütün bunlar, örneğin check_mk ile birlikte aldığınız otomatik çeklerin bolluğunu atmak istediğiniz anlamına gelmez, ancak bu, bir hizmetin başarısız olması durumunda hangi hizmetlerin etkilenebileceğini kontrol etmeyi denemeniz gerektiği anlamına gelir.
/ Var / bölüm doldurulursa hangi Servis etkilenir? Eth0 arayüzü kapalı olsaydı, hangi Servis etkilenir? ... giden TCP bağlantıları bazı güvenlik duvarı tarafından engellenmişse? ... eğer iplik sayısı 800'ü geçerse? ... eğer veritabanı düşerse?
2 web sunucunuz ve sahip olmadığınız bir yük dengeleyicisinin arkasındaki bir siteye hizmet veren bir veritabanı sunucunuz var (örn. ISS). Sağladığınız Hizmet iki sunucudaki 80 numaralı bağlantı noktasıdır ve örneğin, hizmet kesintisi süresinde (üçüncü sunucudaki veritabanı) hayatta kalabilecek çok büyük önbellekleri vardır.
Bu senaryoda, bir web sunucusunun tümüyle başarısız olması sitenin çökmesine neden olmaz. Olan şey, artıklığın ortadan kalkması ve böylece başarısızlık riskinin artmasıydı . Bu bir uyarı tetiklemeli.
Veritabanının tamamen başarısız olması, yerinde iyi ayarlanmış önbelleklerden dolayı siteye hizmet etme yeteneğini etkilemeyebilir; Bu daha sonra web sitesine hizmet verme hizmetini etkilemez , ancak web sitesini güncelleme veya siparişleri kabul etme gibi farklı bir Hizmeti etkileyebilir ...
Her Hizmet, hizmeti geri kazanmanın ya da kesintileri önlemenin ne kadar önemli olduğunu belirten kendi hizmet seviyesine sahip olacaktır.
Her uyarı aldığınızda, aşağıdakilerden birini yapmanız gerekir: - uyarıya neden olan sorunu gidermek için izlenen sistemi değiştirin (örn. Sürücüyü değiştirin veya logrotate'i veya başka bir şeyi yeniden yapılandırın) - uyarının olmasını önlemek için izleme sistemini değiştirin bir dahaki sefere bu durum ortaya çıktığında gönderildi. (örneğin, "disk boş" seviyelerini değiştirin, böylece disk yalnızca% 80 yerine% 90'a kadar doldurur)
Ben çoğunlukla Nagios ve ayrıntılı konfigürasyonlarına aşinayım ve o zamandan beri Check-mk multisite'sine bağlıyım. Geçenlerde check_mk'nin, bu düşünceye uygun gibi görünen (1.11'den beri) bu İş Zekası kavramına sahip olduğunu öğrendim. Nagios'taki kontrollerin daha büyük bir hizmetin parçası olduğunu ve "Hizmet" in durumunu, en kötü veya en iyi duruma göre toplanan birçok kontrol durumunun bir fonksiyonu olarak tanımlayan kurallara sahip olduğunu tanımlayabilirsiniz .
Bir izleme çözümü seçerken şirketlerin unuttukları en kritik noktalardan biri, acil operasyonel sorunların çözümü değil, yarının öngörülmemiş sorunları! Elbette acil sorunları çözmek önemlidir, ama güven bana, çoğu zaman bu kısa görüşlü strateji bir şirketin hayatta kalmasını garanti etmeyecektir.
Piyasada onlarca harika izleme çözümü var. Gereksinimlerinizi karşılayan küçük bir çözüm kümesini kısaltmak zor ve uzun bir iştir, ayrıca bütçenize uygun bir çözüm bulmak daha da zordur. İlginç olan, şu anla ve geleceğinizle uyumlu olanı bulmak . Ve bunu tespit etmek için hiçbir değerlendirme süreci yoktur, bu tecrübe meselesi + sezgisi + çok önemli bir faktördür: Güvenmek , kesmesi kolay bir şey değildir .
Kural olarak , listenizdeki bir dizi izleme çözümünün başarı öykülerini araştırın ve kazın , özellikle de sektörünüzden bir şirketi etkiliyorsa. Satıcıdan başarı öykülerini isteyin ve hatta müşterilerinden biriyle konuşma iznini bile isteyin. Bundan korkmayan şirketler, müşterileriyle gerçek ilişkilere sahip olduklarını ve bunu gizlemediklerini gösteriyor, ve bugünlerde bulmak çok nadir bir şey.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... hepsinin iniş ve çıkışları var, ama asıl mesele hangisinin geleceğinize daha iyi uyum sağladığını bulmak.
Uzaktan sistem izlemeyi düşünüyorsanız, testlerin yapıldığı gerçek konumların aranması iyi bir fikir olabilir. Bağlantı sorunları geçmişte kalmadı ve donanımınız belirli bir bölgede bir gruba hizmet veriyorsa, kaynaklarınızın o konumda bulunduğundan emin olmak isteyebilirsiniz.