Monitorowanie aplikacji C ++

Wdrażamy nowe scentralizowane rozwiązanie do monitorowania (Zenoss). Włączanie serwerów, sieci i programów Java jest proste dzięki SNMP i JMX.

Pytanie brzmi jednak: jakie są najlepsze praktyki monitorowania niestandardowych aplikacji C ++ i zarządzania nimi w dużych, heterogenicznych środowiskach (Solaris x86, RHEL Linux, Windows)?

Możliwości, które widzę to:

1. Net SNMP

• Zalety

1. pojedynczy, centralny demon na każdym serwerze
2. dobrze znany standard
3. łatwa integracja z rozwiązaniami monitorującymi
4. uruchamiamy już demony Net SNMP na naszych serwerach

Niedogodności:

1. kompleksowa implementacja (MIB, biblioteka Net SNMP)
2. nowa technologia do wprowadzenia dla programistów C ++

rsyslog

• Zalety

1. pojedynczy, centralny demon na każdym serwerze
2. dobrze znany standard
3. nieznana integracja z rozwiązaniami monitorującymi (wiem, że potrafią robić alerty na podstawie tekstu, ale jak dobrze by to działało w przypadku wysyłania danych telemetrycznych, takich jak użycie pamięci, głębokości kolejek, pojemność wątków itp.)
4. prosta implementacja

Niedogodności:

1. możliwe problemy z integracją
2. nieco nowa technologia dla programistów C ++
3. możliwe problemy z portowaniem, jeśli zmienimy dostawców monitorujących
4. prawdopodobnie wiąże się z opracowaniem protokołu komunikacyjnego ad hoc (lub wykorzystaniem danych strukturalnych RFC5424; nie wiem, czy Zenoss obsługuje to bez niestandardowego kodowania Zenpack)

Osadzony JMX (osadzenie JVM i użycie JNI)

• Zalety

1. spójny interfejs zarządzania dla Java i C ++
2. dobrze znany standard
3. łatwa integracja z rozwiązaniami monitorującymi
4. nieco prosta implementacja (robimy to już dzisiaj do innych celów)

Niedogodności:

1. złożoność (JNI, thunking layer między native C ++ i Java, w zasadzie dwukrotne pisanie kodu zarządzania)
2. możliwe problemy ze stabilnością
3. wymaga JVM w każdym procesie, zużywając znacznie więcej pamięci
4. JMX to nowa technologia dla programistów C ++
5. każdy proces ma swój własny port JMX (uruchamiamy wiele procesów na każdym komputerze)

Lokalny demon JMX, procesy się z nim łączą

• Zalety

1. pojedynczy, centralny demon na każdym serwerze
2. spójny interfejs zarządzania dla Java i C ++
3. dobrze znany standard
4. łatwa integracja z rozwiązaniami monitorującymi

Niedogodności:

1. złożoność (w zasadzie dwukrotne pisanie kodu zarządzania)
2. trzeba znaleźć lub napisać takiego demona
3. potrzebujesz protokołu między demonem JMX a procesem C ++
4. JMX to nowa technologia dla programistów C ++

Jon CodeMesh JunC ++

• Zalety

1. spójny interfejs zarządzania dla Java i C ++
2. dobrze znany standard
3. łatwa integracja z rozwiązaniami monitorującymi
4. pojedynczy, centralny demon na każdym serwerze, gdy działa we współdzielonym trybie JVM
5. nieco prosta implementacja (wymaga wygenerowania kodu)

Niedogodności:

1. złożoność (generowanie kodu, wymaga GUI i kilku rund ulepszeń w celu wytworzenia kodu proxy)
2. możliwe problemy ze stabilnością JNI
3. wymaga JVM w każdym procesie, zużywając znacznie więcej pamięci (w trybie osadzonym)
4. Nie obsługuje Solaris x86 (przerywnik transakcji)
5. Nawet jeśli obsługuje system Solaris x86, możliwe są problemy ze zgodnością kompilatora (używamy nieparzystej kombinacji STLPort i Forte w systemie Solaris
6. każdy proces ma własny port JMX, gdy jest uruchomiony w trybie osadzonym (uruchamiamy wiele procesów na każdym komputerze)
7. prawdopodobnie wyklucza współużytkowany serwer JMX dla procesów innych niż C ++ (?)

Czy brakuje jakiegoś rozsądnie ustandaryzowanego, prostego rozwiązania?

Biorąc pod uwagę inne rozsądne rozwiązania, które z tych rozwiązań jest zwykle używane w niestandardowych programach C ++?

Mam wrażenie, że Net SNMP to sposób, w jaki ludzie to robią, ale chciałbym, aby inni wnieśli wkład i doświadczenie, zanim podejmę decyzję.

Nie jestem bardzo obeznany z Zenoss ale gdy kiedyś używane Nagios dla tego typu rzeczy chcielibyśmy zrobić c / c ++ proces słuchać na gnieździe i napisać zwyczaj nagios plugin który przekazaniu informacji diagnostycznych i stanu.

Pierwszym krokiem jest wybranie biblioteki, której chcesz użyć, aby proces nasłuchiwał. Coś takiego jak C ++ Socket Library zrobi to za to. Nic skomplikowanego… po prostu spraw, aby proces nasłuchiwał.

Następnie musisz zdefiniować odpowiedź, którą Twój proces wyśle, biorąc pod uwagę określony bodziec. To naprawdę oznaczało (przynajmniej w nagios) zdefiniowanie „usługi”, a następnie wysłanie do procesu sygnału odpowiadającego tej usłudze. Najprostszą rzeczą, jaką możesz zrobić, to utworzyć „ping procesu”, aby zobaczyć, czy możesz pomyślnie połączyć się z uruchomionym procesem. Jeśli to zrobisz, niestandardowa wtyczka nagios wie, że przynajmniej proces nadal trwa.

Istnieje wiele bardziej wyrafinowanych rzeczy, które możesz zrobić, ale pomysł jest dość prosty. Możesz napisać swoją własną bibliotekę procesową kodu nasłuchującego zamkniętego w obiektach i przeciągnąć go do swoich niestandardowych plików c ++ w standardowy sposób za każdym razem, gdy budujesz jeden (lub wszystkie) pliki wykonywalne

Moje rozumienie jest Zenoss można to zrobić też .

Prawdopodobnie ponieważ Zenoss jest pythonem, napiszesz do niego swoją niestandardową wtyczkę, używając czegoś takiego jak Twisted do połączenia ze słuchającym plikiem wykonywalnym c ++.

nie znam tych produktów, które znasz, ale w systemie Windows monitoruję zużycie pamięci za pomocą perfmon, istnieją pewne specjalne liczniki, takie jak błędy puli niestronicowanej, które pokazują, że jeśli twój program zawiera wycieki pamięci, mogą być małe, a zatem zajmują dużo czasu czas na monitorowanie, ale moim zdaniem jest to prosta metoda sprawdzania.

W systemie Windows możesz wiele zrobić za pomocą perfmon, nawet zdalnie. Możesz też skorzystać z WMI, aby podłączyć się do tych samych liczników i wykonać na nim automatyzację (w wmi), aby wykonać działania.

Podchodzę do tego, ponieważ niedawno przeszliśmy przez ten sam proces jak Ty: Szukaliśmy lekkiego, nieblokującego rozwiązania typu open source, które umożliwia ujawnianie i późniejsze zdalne monitorowanie metryk z poziomu usług C / C ++ ( mamy około ~ 3000).

SNMP był najbliżej, ale integracja ze źródłem i systemem monitorowania jest uciążliwa i nie nadaje się do naszych procesów w czasie rzeczywistym.

Ostatecznie postanowiliśmy opracować nowe rozwiązanie o nazwie CMX, które wykorzystuje technologię pamięci współdzielonej i uczyniło ją otwartym oprogramowaniem. Możesz to sprawdzić tutaj: www.cern.ch/cmx .

Nie jestem bardzo obeznany z C ++ stronie rzeczy, ale w Javie my intensywnie wykorzystywać CodaHale metryki w połączeniu z grafitu . CodaHale przechowuje metryki dla poszczególnych instancji w lokalnej pamięci instancji, a następnie używa wątku w tle do opróżniania metryk na serwerze grafitowym co minutę (konfigurowalne). W graficie możemy agregować między instancjami, a także identyfikować wadliwe instancje. Jeśli nie chcesz, aby złożoność obsługi klastra grafitowego była możliwa , możesz użyć HostedGraphite .

Ta konfiguracja oznacza brak pojedynczego punktu awarii dla agregacji metryk lub raportowania, ponieważ (agregacja oparta na czasie zachodzi na samych węzłach, a agregacja raportowania na całej powierzchni występuje w rozproszonym klastrze grafitowym (lub graficie hostowanym).

Na koniec możesz użyć Seyren, aby wyświetlać alerty na podstawie danych monitorowania.

Jeśli korzystasz z systemu Windows, zwykle piszesz do dziennika zdarzeń, a następnie używasz WMI lub podobnego procesu do odczytu zdarzeń. Jeśli chcesz monitorować, dodajesz do aplikacji liczniki monitorów wydajności i pozwalasz perfmonowi je odczytać. Oba są usługami systemowymi w systemie Windows.

W Linuksie jest to oczywiście bardziej elastyczne, ale zawsze widziałem zaimplementowane monitory w stylu nagios, z niestandardowym gniazdem wysyłającym dane do serwera w stylu nagios.

To powiedziawszy, widziałem kilka miejsc, w których używa się SMNP , i szczerze mówiąc, nie widzę powodu, dla którego byś go nie używał - zwłaszcza jeśli prowadzisz całkowicie heterogeniczne środowisko.