Coğrafi olarak dağıtılmış, hataya dayanıklı ve “akıllı” uygulama / ana bilgisayar izleme sistemleri


12

Selamlar,

Dağıtılmış izleme sistemleri hakkında kolektif görüş ve görüş sormak istiyorum, ne kullanıyorsunuz ve hangilerinin kutularımı işaretleyebileceğinin farkında mısınız?

Gereksinimler oldukça karmaşıktır;

  • Tek bir hata noktası yok. Gerçekten mi. Çok ciddiyim! Hem 'ana' hem de 'çalışan' olmak üzere tek / çoklu düğüm hatasını tolere edebilmeniz gerekir ve hiçbir izleme konumunun ("site") içinde birden fazla düğümün olmadığını veya aynı ağda olduğunu varsayabilirsiniz. Bu nedenle, bu muhtemelen DRBD veya Keepalive gibi geleneksel HA tekniklerini geçersiz kılar.

  • Dağıtılmış mantık, birden fazla ağda, birden fazla veri merkezinde ve birden fazla kıtada 5+ düğümü dağıtmak istiyorum. Müşterilerimin bakış açısından ağımın ve uygulamaların "Kuş Gözü" görünümünü, 50+ düğümünüz veya 500+ düğümünüz olduğunda izleme mantığının öne çıkmasını istemiyorum.

  • Ballpark rakamları için oldukça makul sayıda ev sahibi / hizmet kontrolünü, la Nagios'u idare edebilmek için 1500-2500 ev sahibi ve ev sahibi başına 30 hizmet varsayılmaktadır. Daha fazla izleme düğümü eklemek nispeten doğrusal olarak ölçeklendirmenize izin verseydi gerçekten güzel olurdu, belki 5 yıl içinde 5000 ana bilgisayar ve ana bilgisayar başına 40 hizmeti izlemek isteyebilirim! Yukarıdaki notumdan 'dağıtılmış mantık' üzerine ekleyerek şunu söylemek güzel olurdu:

    • Normal koşullarda, bu kontroller izleme düğümlerinin $ n veya% n üzerinde çalışmalıdır.
    • Bir hata tespit edilirse, düğümlerin başka bir n $ n veya n% 'sinde kontroller yapın, sonuçları ilişkilendirin ve ardından uyarı vermek için kriterlerin karşılanıp karşılanmadığına karar vermek için bunları kullanın.
  • Grafikler ve yönetim dostu özellikler. SLA'larımızı takip etmeliyiz ve 'yüksek oranda kullanılabilir' uygulamalarımızın 7 gün 24 saat kadar yüksek olup olmadığını bilmek biraz faydalıdır. İdeal olarak önerilen çözümünüz en az faff ile "kullanıma hazır" raporlama yapmalıdır.

  • Ismarlama kontrollerin geliştirilmesi için sağlam bir API veya eklenti sistemine sahip olmalıdır.

  • Uyarılar hakkında duyarlı olmak gerekir. Mutlaka bilmek istiyorum (SMS ile, 3 am!) Bir izleme düğümü çekirdek yönlendiricimin aşağı olduğunu düşünüyor. Ben do bunların tanımlanmış bir yüzdesinin bilmek istiyorum katılıyorum şey korkak oluyor ki;) Esasen ne hakkında burada konuşuyorum "çekirdek" mantığı veya dağıtılmış akıldan deliliğe uygulanmasıdır!

Milyonlarca pounda mal olan yazılımdan uzak durmayı tercih etsem de, hem ticari hem de açık kaynak seçeneklerini göz önünde bulundurmaya hazırım :-) Ayrıca, tüm bu kutuları işaretleyen hiçbir şey olmadığını kabul etmeye istekliyim, ama Kolektife bunu sormak istedim.

İzleme düğümleri ve yerleşimleri hakkında düşünürken, bunların çoğunun rastgele ISS ağlarındaki adanmış sunucular olacağını ve dolayısıyla büyük ölçüde kontrol alanımdan çıkacağını unutmayın. BGP yayınlarına ve diğer karmaşık ağ oluşturma özelliklerine dayanan çözümler muhtemelen uygun değildir.

Ayrıca geçmişte Nagios, Zabbix ve arkadaşları da dahil olmak üzere açık kaynaklı lezzetlerin çoğunu değerlendirdiğim, kullandığımı veya yoğun bir şekilde kullandığımı / özelleştirdiğimi belirtmeliyim - gerçekten kötü araçlar değiller ama genel olarak düz düşüyorlar " Özellikle benim sorum ve 'akıllı' uyarılarda tartışılan mantık açısından dağıtıldı.

Gerekli noktaları netleştirmek için mutluyuz. Şerefe çocuklar ve kızlar :-)


2
Bu gerçekten garip, benzer bir soru sormak üzereydim. Bu hafta site kesintileri hakkında, ancak yalnızca belirli konumlardan bazı müşteri şikayetleri vardı. Uyarı sistemlerimiz bu sorunları tespit etmedi. Sağlayıcımızla iletişime geçtik ve bazılarının omurga problemleri olduğunu doğruladılar. Ben de bir çözümle ilgileniyorum. Teşekkürler!
splattne

Son çözüm neydi?
ewwhite

Yanıtlar:


4

gerçekten bir cevap değil, bazı işaretçiler:

  • nagios @ goldman sachs hakkındaki sunuma kesinlikle bir göz atın . bahsettiğiniz sorunlarla karşı karşıya kaldılar - yedeklilik, ölçeklenebilirlik: binlerce ana bilgisayar, ayrıca otomatik yapılandırma oluşturma.

  • i gereksiz nagios kurulum vardı ama çok daha küçük ölçekte - 80 sunucular, toplam ~ 1k hizmetleri. adanmış bir ana sunucu, bir bağımlı sunucu, yapılandırmayı günde birkaç kez düzenli aralıklarla master'dan çeker. her iki sunucu da aynı makinelerin izlenmesini kapsadı, aralarında sağlık çapraz kontrolü vardı. nagios'u çoğunlukla özel ürüne özgü kontrolleri çağırmak için çerçeve olarak kullanmıştır ['yapay akış kontrolleri' yapan komut dosyaları yürüten cron işleri, son x dakikadaki başarılı / başarısız uygulamalar için nrpe eklentileri tesisat kontrolü]. hepsi çok güzel çalıştı.

  • Çekirdek mantığınız kulağa hoş geliyor - benim 'yapay akışlarıma' biraz benziyor - temelde devam edin, kendinizi geliştirin; -]. ve nrpe sadece bir tür bayrağı [veya zaman damgası durumu ile sql db] nasıl şeyler kontrol edin.

  • muhtemelen ölçeklemek için bazı hiyerarşi oluşturmak isteyeceksiniz - diğer düğümlere genel bakış sunan bazı düğümlere sahip olacaksınız, sunuma ilk noktadan bakacaksınız. her bir kontrole yönelik varsayılan nagios, daha fazla sayıda izlenen hizmette aşırı doludur.

bazı soruları cevaplamak için:

  • benim durumumda izlenen ortam tipik master-slave kurulum [birincil sql veya uygulama sunucusu + sıcak bekleme], hiçbir master-master oldu.
  • kurulumumda 'insan filtreleme faktörü' - sms bildirimi için 'yedek' olan çözümleyici grup vardı. başka nedenlerle 24/5 vardiyaya sahip ücretli bir grup teknisyen vardı, onlara fazla yük yüklemeyen ek görev olarak 'nagios postalarını kontrol ettiler'. ve onlar db-yöneticileri / it-ops / app-yöneticileri aslında kalkmak ve sorunları çözme emin olmak için sorumlu eşya; -]
  • Trendleri uyarmak ve çizmek için zabbix hakkında çok iyi şeyler duydum , ama hiç kullanmadım. benim için munin hile yapar, ben basit bir nagios eklentisi, sunucuların munin listesinde 'herhangi bir kırmızı' [kritik] renk olup olmadığını kontrol ettik - sadece ek bir kontrol. izlenen makineye gönderdiğiniz sorgu sayısını azaltmak için munin rrd dosyalarındaki değerleri de okuyabilirsiniz.

1
@astinus - mantıklı uyarılar için iyi özel bildirim komut dosyası kullandım. nagios güvenmek yerine posta / çağrı cihazı ile bildirmek için mesajı fifo que'e depoladım ve özel mantığa dayalı mesaj gönderen tüketici vardı (oldukça esnek çağrı programına vb. dayalı), ayrıca saatte gönderilen msj sınırlaması vardı. kısa süre içinde 50 smses almaz. daha büyük ölçeklerde benzer yaklaşımlar görüyorum - nagios sadece iskelet ve insanlar onun etrafında senaryo ve aslında daha az ve daha az özellik kullanır.
pQd

1
Hiyerarşi ile ilgili olarak, şu anda sahip olduğum tamamen "modüler" Nagios kurulumudur, burada etc / dizininiz tüm ana bilgisayarlarda paylaşılan (ve özdeş) ve daha sonra etc / modülleri / $ NAME (yani : Mail, Web, Network, DNS). Cfg_dir = ile ekle) Modüle özgü komutları, eklentileri ve her dizini o dizine koyarsınız . > 1 sunucunun bu kontrolleri yürütmesi, modülü gerektiği kadar Nagios kutusuna kopyaladığınız için oldukça kolaydır, ancak bir kez daha uyarı mantığı sorunlara neden olur :-)
nixgeek

1
@ astinus 2.. benim durumumda yapılandırma çoğaltma master-> slave her 6 saatte bir gerçekleşir. eğer master sadece ölürse [elektrik kesintisi vb.] - köle, master'ın ölü olduğu konusunda herkesi uyaracaktır [sunucular arasında çapraz kontrol]. biri diğer senaryoları hayal edebilir - master yanlış konfigürasyon nedeniyle öldüğünde. Bu, config slave ile senkronize edilmeden önce 5 dakikaya kadar devam ederse - bildirim olacaktır. yapılandırma senkronizasyonundan hemen önce - maalesef izleme sistemine sahip değiliz. 'bekçiyi kim izleyecek?' belki başka bir çok basit nagios.
pQd

1
@pQd - ilginç, mantığı özel bildirim komut dosyalarında uygulamanın muhtemelen gidilecek yol olduğunu kabul ediyorum. Ancak, 50 izleme ana bilgisayarı dediğinizde, 2+ ana bilgisayardan yinelenen bildirimlerden kaçınmak oldukça zor olur ve henüz kimsenin (genel olarak) paylaşılan mantığını Tavşan veya Amazon gibi uygun bir 'mesaj' geçiş sistemine koyduğunu görmedim SQS.
nixgeek

1
@ astinus # 3 benim durumumda 'iso osi modelinin' Seviye 8 'çözümü idi: birincil nagios, 24/5' çözümleyici grubuna 'çağrı + posta gönderen kişilere sms'es gönderirken, 2nature nagios sadece posta gönderiyor' çözümleyici grubu '. tırmanmadan önce kopyaları filtrelemek o gruba kalmıştı;
pQd

1

Sorduğunuz şey, Shinken'in Nagios için yaptıklarına çok benziyor.

Shinken bir Nagios yeniden yazımıdır.

  • Modern dil (Python)
  • Modern dağıtılmış programlama çerçevesi (Pyro)
  • İzleme Alanları (çoklu kiracılık), HA, yedek parçalar
  • Livestatus API'sı
  • Nagios eklentisi uyumlu
  • Yerel NRPE yürütme
  • Nesnelerin ticari önemi
  • İş kuralları nesnelerin durumuna uygulanabilir (küme veya havuz kullanılabilirliğini yönetme)
  • Grafik, Graphite veya RRDtool tabanlı PNP4nagios kullanabilir
  • İstikrarlı ve geniş ortamlara dağıtılıyor
  • Büyük dağıtımlar, raporlama için Splunk ile eşleştirmeyi veya RRDtool'un uygun olmadığı Grafite bakmayı düşünebilir.

Bu düşünce için yiyecek olmalı.

Şerefe

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.