Geograficznie rozmieszczone, odporne na uszkodzenia i „inteligentne” systemy monitorowania aplikacji / hosta


12

Pozdrowienia,

Chciałbym zapytać kolektywne o opinię i pogląd na temat rozproszonych systemów monitorowania, z czego korzystasz i co wiesz, które mogą zaznaczyć moje pola?

Wymagania są dość złożone;

  • Brak pojedynczego punktu awarii. Naprawdę. Jestem śmiertelnie poważny! Musi być w stanie tolerować awarie pojedynczego / wielu węzłów, zarówno „głównego”, jak i „roboczego”, i można założyć, że żadna lokalizacja monitorowania („witryna”) nie ma wielu węzłów lub jest w tej samej sieci. Dlatego prawdopodobnie wyklucza to tradycyjne techniki HA, takie jak DRBD lub Keepalive.

  • Logika rozproszona. Chciałbym wdrażać ponad 5 węzłów w wielu sieciach, w wielu centrach danych i na wielu kontynentach. Chcę widok „Birds Eye” mojej sieci i aplikacji z perspektywy moich klientów, punkty bonusowe za logikę monitorowania nie ulegną zapadnięciu, gdy masz ponad 50 węzłów, a nawet ponad 500 węzłów.

  • Musi być w stanie obsłużyć dość uzasadnioną liczbę kontroli hosta / usługi, a la Nagios, dla danych liczbowych na boisku zakłada 1500-2500 hostów i 30 usług na hosta. Byłoby naprawdę miło, gdyby dodanie większej liczby węzłów monitorowania pozwoliło na skalowanie względnie liniowe, być może za 5 lat będę chciał monitorować 5000 hostów i 40 usług na host! Dodając do mojej powyższej uwagi na temat „logiki rozproszonej”, dobrze byłoby powiedzieć:

    • W normalnych okolicznościach kontrole te muszą być uruchamiane na $ n lub n% węzłów monitorowania.
    • Jeśli zostanie wykryta awaria, uruchom sprawdzanie kolejnych $ n lub n% węzłów, skoreluj wyniki, a następnie użyj ich do podjęcia decyzji, czy spełnione są kryteria, aby wysłać alert.
  • Wykresy i funkcje przyjazne dla zarządzania. Musimy śledzić nasze umowy SLA i wiedzieć, czy nasze „wysoce dostępne” aplikacje działają 24x7, jest nieco przydatne. Idealnie byłoby, gdyby proponowane rozwiązanie generowało raportowanie „od razu po wyjęciu z pudełka” przy minimalnym nakładzie pracy.

  • Musi mieć solidny interfejs API lub system wtyczek do opracowywania niestandardowych kontroli.

  • Musi być rozsądny, jeśli chodzi o alerty. Nie chcę koniecznie wiedzieć (przez SMS, o 3 nad ranem!), Że jeden węzeł monitorujący uważa, że ​​mój główny router jest wyłączony. I nie chcę wiedzieć, czy określony procent z nich zgadza się , że coś się dzieje Funky;) Zasadniczo, co mówię tutaj o „quorum” logika, lub stosowanie zdrowego rozsądku do rozproszonego szaleństwa!

Jestem gotów rozważyć zarówno opcje komercyjne, jak i open source, chociaż wolałbym omijać oprogramowanie kosztujące miliony funtów :-) Jestem również skłonny zaakceptować fakt, że może nie być nic, co mogłoby zaznaczyć wszystkie te pola, ale chciałem zapytać kolektyw o to.

Myśląc o monitorowaniu węzłów i ich rozmieszczeniu, należy pamiętać, że większość z nich będzie serwerami dedykowanymi w losowych sieciach dostawców usług internetowych, a zatem w dużej mierze poza moją kontrolą. Rozwiązania oparte na kanałach BGP i innych złożonych wygłupach sieciowych prawdopodobnie nie będą pasować.

Powinienem również zauważyć, że albo oceniłem, wdrożyłem lub intensywnie używałem / dostosowywałem większość smaków open source w przeszłości, w tym Nagios, Zabbix i przyjaciół - to naprawdę nie są złe narzędzia, ale nie pasują do całości ” aspekt „rozproszony”, szczególnie w odniesieniu do logiki omówionej w moim pytaniu i „inteligentnych” alertów.

Chętnie wyjaśni wszelkie wymagane punkty. Na zdrowie chłopaki i dziewczęta :-)


2
To naprawdę dziwne, miałem właśnie zadać podobne pytanie. W tym tygodniu mieliśmy skargi klientów na awarie witryn, ale tylko z niektórych lokalizacji. Nasze systemy alarmowe nie wykryły tych problemów. Skontaktowaliśmy się z naszym dostawcą, który potwierdził, że niektórzy mieli problemy z kręgosłupem. Więc jestem również zainteresowany rozwiązaniem. Dzięki!
splattne

A jakie było ostateczne rozwiązanie?
ewwhite

Odpowiedzi:


4

nie jest to odpowiedź, ale niektóre wskazówki:

  • zdecydowanie spójrz na prezentację o nagios @ goldman sachs . napotkali problemy, o których wspomniałeś - nadmiarowość, skalowalność: tysiące hostów, a także automatyczne generowanie konfiguracji.

  • miałem nadmiarową konfigurację nagios, ale na znacznie mniejszą skalę - 80 serwerów, łącznie ~ 1 000 usług. jeden dedykowany serwer główny, jeden serwer podrzędny pobiera konfigurację z serwera głównego w regularnych odstępach czasu kilka razy dziennie. oba serwery obejmowały monitorowanie tych samych komputerów, między sobą sprawdzono ich kondycję. używałem nagios głównie jako ramy do wywoływania niestandardowych kontroli specyficznych dla produktu [kilka zadań cron wykonujących skrypty wykonujące „sztuczną kontrolę przepływu”, wyniki logowane do sql, wtyczki nrpe ware sprawdzające pomyślne / nieudane wykonanie tych w ostatnich x minutach]. wszystko działało bardzo ładnie.

  • twoja logika kworum brzmi dobrze - trochę podobnie do moich „sztucznych przepływów” - w zasadzie kontynuuj, ipmplementuj siebie ;-]. i niech nrpe po prostu sprawdzi jakiś rodzaj flagi [lub sql db ze znacznikiem czasu], jak się rzeczy mają.

  • prawdopodobnie będziesz chciał zbudować hierarchię do skalowania - będziesz mieć kilka węzłów, które zbierają przegląd innych węzłów, spójrz na prezentację od pierwszego punktu. domyślnym rozwidleniem nagios dla każdego pojedynczego czeku jest przesada przy większej liczbie monitorowanych usług.

odpowiedzieć na kilka pytań:

  • w moim przypadku monitorowanym środowiskiem była typowa konfiguracja master-slave [podstawowy sql lub serwer aplikacji + hot standby], brak master-master.
  • moja konfiguracja obejmowała „ludzki czynnik filtrujący” - grupę resolverów, która była „kopią zapasową” powiadomień SMS. była już opłacana grupa techników, którzy z innych powodów mieli 24/5 zmian, dostali „sprawdzanie maili nagios” jako dodatkowe zadanie, nie obciążające ich zbytnio. i oni dbają o to, aby db-admins / it-ops / app-admins ware rzeczywiście wstawał i naprawiał problemy; -]
  • Słyszałem wiele dobrych rzeczy o zabbix - do ostrzegania i kreślenia trendów, ale nigdy ich nie używałem. dla mnie munin załatwi sprawę , zhakowałem prostą wtyczkę nagios , sprawdzając, czy na liście serwerów munin jest „jakikolwiek czerwony” [krytyczny] kolor - to tylko dodatkowe sprawdzenie. możesz również odczytywać wartości z plików munin rrd, aby zmniejszyć liczbę zapytań wysyłanych do monitorowanego komputera.

1
@astinus - dobrze dla rozsądnych alertów użyłem niestandardowego skryptu powiadomień. zamiast polegać na nagios powiadomić pocztą / pageriem, zapisałem wiadomość do fifo que i miałem konsumenta, który wysłał wiadomość w oparciu o niestandardową logikę [na podstawie dość elastycznego harmonogramu dyżurów itp.], dodatkowo był pewien limit wysyłanych wiadomości na godzinę, więc jeden w krótkim czasie nie otrzymuje 50 smsów. widzę podobne podejścia w większych skalach - nagios to tylko szkielet, a ludzie piszą wokół niego i faktycznie używają coraz mniej jego funkcji.
pQd

1
Jeśli chodzi o hierarchię, w tej chwili mam całkowicie „modułową” konfigurację Nagios, w której katalog etc / zawiera konfigurację „core”, która jest współdzielona (i identyczna) na wszystkich hostach, a następnie etc / modules / $ NAME (tj. : Poczta, sieć, sieć, DNS), który jest w 100% przenośny między serwerami. Dołącz z cfg_dir =) Do tego katalogu wstawiasz wszelkie specyficzne dla modułu polecenia, wtyczki i wszystko . Uruchomienie> 1 serwera uruchamia te kontrole jest dość łatwe, ponieważ wystarczy skopiować moduł do tylu skrzynek Nagios, ile potrzeba, jednak logika alertów powoduje problemy :-)
nixgeek

1
@ astinus # 2. w moim przypadku replikacja konfiguracji master-> slave odbywa się co 6 godzin. jeśli master po prostu umrze [przerwa w dostawie prądu itp.] - slave ostrzeże wszystkich o śmierci mistrza [kontrola między serwerami]. można sobie wyobrazić inny scenariusz - kiedy mistrz umiera z powodu błędnej konfiguracji. jeśli zdarzy się to do 5 minut przed synchronizacją konfiguracji z urządzeniem slave - pojawi się powiadomienie. jeśli jest to tuż przed synchronizacją konfiguracji - niestety nie mamy systemu monitorowania. „kto będzie obserwował stróża”? no może jeszcze jedno bardzo proste nagio.
pQd

1
@pQd - ciekawe, zgadzam się, że wdrożenie logiki w niestandardowych skryptach powiadomień jest prawdopodobnie dobrym rozwiązaniem. Jednak dość trudne jest unikanie podwójnych powiadomień od 2+ hostów, kiedy powiesz 50 hostów monitorujących, a ja jeszcze nie widziałem, aby ktokolwiek (publicznie) wprowadził wspólną logikę do odpowiedniego systemu przekazywania wiadomości, takiego jak Rabbit lub Amazon SQS.
nixgeek

1
@ astinus # 3 w moim przypadku było to rozwiązanie „Poziomu 8” [modelu iso osi]: główne nagios wysyłały SMS-y do ludzi na telefon + e-maile do „grupy tłumaczącej” 24/5, podczas gdy drugie nagios wysyłało tylko wiadomości „ grupa tłumacząca ”. do tej grupy należało filtrowanie duplikatów przed eskalacją;
pQd

1

To, o co prosisz, brzmi bardzo podobnie do tego, co Shinken zrobił dla Nagios.

Shinken to przepisanie Nagios.

  • Język nowoczesny (Python)
  • Nowoczesne rozproszone ramy programistyczne (Pyro)
  • Monitoring Realms (multi-tenancy), HA, części zamienne
  • Livestatus API
  • Kompatybilny z wtyczką Nagios
  • Natywne wykonanie NRPE
  • Krytyczność biznesowa obiektów
  • Reguły biznesowe można zastosować do stanu obiektów (zarządzanie dostępnością klastra lub puli)
  • Wykresy mogą korzystać z PNP4nagios opartych na graficie lub RRDtool
  • Stabilny i wdrażany w dużych środowiskach
  • Duże wdrożenia mogą rozważyć powiązanie go ze Splunk do raportowania lub zajrzeć do Graphite, gdzie RRDtool nie jest dobrym rozwiązaniem.

To powinno być przemyśleniem.

Twoje zdrowie

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.