Czy ktoś używa check_mk dla Nagios? Coś, o czym powinienem wiedzieć przed rozważeniem?


12

http://mathias-kettner.de/check_mk.html

Testowałem to na kilku maszynach programistycznych i wydaje się całkiem sprytne. Nie mogę jednak znaleźć wielu informacji na temat jego wdrożenia. Czy ktoś to aktywnie uruchamia? Czy ktoś z jakiegoś powodu wykluczył to jako opcję?


Dzięki za link! Na pewno to wypróbuję. Wydaje się świetny do kontroli lokalnych i zastępowania NRPE.
Wouter de Bie,

Nie użyłem tego, ale robi to IMO, to pasuje do tego rozmytego krajobrazu devops. W szefie kuchni / lalce używałbyś ohai / facter do robienia tego, co brzmi jak wtyczka mk, eksportowałbyś konfigurację nagios, która podaje status ohai / facter. To może wyglądać mniej ronda. Dzięki za link, na pewno się nim zajrzę!
dsummersl

Odpowiedzi:


4

Oświadczenie: Pracowałem nad tym projektem, ponieważ czułem, że jest on niezwykle potężny. (i nadal tak uważam)

Używam go od 2009 roku i poza ustawieniami starszej wersji nigdy nie zmieniłem „normalnej” (można powiedzieć, starszej) konfiguracji Nagios. To byłoby strata czasu.

Największa konfiguracja, jaką znam, to ~ 1200 serwerów monitorowania. (nie: monitorowane serwery) Ten jest również opublikowany, ale poprzednie pytanie poprzedza.

Jest teraz używany w wielu miejscach, które nie były zadowolone z prostych nagios, w przeciwieństwie do NMS na większą skalę, takich jak OpenView, i zmieniły zdanie.

Kluczową różnicą nie jest skalowalność (ponieważ 37 sygnałów wydaje się bardzo podobać) lub automatyczne wykrywanie monitorowanych rzeczy w zdalnym systemie, co sprawia, że ​​wszystko jest nobrainer, a nawet ostrzega, jeśli coś nowego zostanie dodane, ale nie będzie monitorowane.

Nie, naprawdę dużą rzeczą na dłuższą metę jest konfiguracja, która jest ściśle oparta na regułach (i zapisana jako python). Wystarczy 100 linii konfiguracji Check_MK, aby wygenerować 200 000 wierszy starej nudnej składni nagios, do której nigdy nie będziesz wracał.

  • Posiada również internetowy edytor konfiguracji. Z dziedziczeniem. I walidacja.
  • GUI jest między innymi zoptymalizowany pod kątem łączy WAN. W rzeczywistości jest to pełny framework internetowy, dlatego istnieją również pulpity nawigacyjne i silnik klasyfikacji dzienników, który może przyjmować syslog lub snmp do przetwarzania Nagios z elastycznymi zestawami reguł.
  • Wszystkie kontrole są napisane zgodnie z wysokimi standardami jakości i pokazuje czas zaoszczędzony dla użytkownika.

Ale nie ma kucyków.

  • Ludzie często są zdezorientowani interakcją między Check_MK a Nagios, co nie jest trywialne, ale właściwie ładnie rozdzielone: ​​zapisuje config, Nagios działa z tą konfiguracją i wywołuje Check_MK w celu monitorowania systemów.
  • Jeśli ktoś nie korzysta z graficznego edytora konfiguracji „WATO”, zakłada się, że jest na poziomie eksperckim w Nagios.
  • Nie ma instrukcji obsługi GUI! (ale: wbudowana pomoc, którą można włączyć w locie)
  • perfekcyjnie działające łatki wsparcia IPv6 latają od lat i nigdzie nie zniknęły.

Jest jeszcze wiele zalet i wad, ale myślę, że już dość dobrze pokazałem obu stronom. Osobiście podoba mi się wydajność konfiguracji Check_MK i jestem naprawdę zirytowany, jeśli muszę pracować z konfiguracjami oldskool Nagios. Nawet jeśli używają ładnych ram szablonów lub są dowodzone przez Puppet, nadal wydaje mi się, że jest postarzany i bezradny w porównaniu do mnie.

Oświadczenie: patrz wyżej;)


1
Tak, lubiłem check_mk, ale nie mogłem go użyć z powodu braku obsługi IPv6. Jestem w 100% środowisku z dwoma stosami.
Michael Hampton

moim pomysłem jest użycie NAT64 na polu monitorowania lub jego bramie i monitorowanie w 100% przez v6; rdzeń icinga jest na przykład bardzo gotowy do wersji v6. No cóż. niedługo tylko ludzie z v4 zaczną dostrzegać problemy, jakie przynosi im obluzowanie :)
Florian Heigl

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.