Obiekty monitorowania NetCrunch
Wszystko, co monitoruje NetCrunch, jest obiektem posiadającym stan — węzły, interfejsy, usługi, czujniki, alerty oraz statusy obliczane na ich podstawie. Wiedza o tym, na jaki obiekt patrzysz, pozwala określić, dla czego możesz skonfigurować alert, co możesz umieścić na pulpicie oraz co możesz uwzględnić w statusie usługi.
NetCrunch nie przechowuje po jednej stronie listy urządzeń, a po drugiej listy testów. Przechowuje drzewo obiektów posiadających stan. Węzły znajdują się na górze; poniżej nich są elementy monitorowane na danym węźle, a pod nimi — poszczególne mierzone wartości.
Ma to praktyczne znaczenie, ponieważ każdy obiekt w drzewie jest używany w ten sam sposób. Wszystko, co ma stan, może wygenerować alert, pojawić się na mapie lub pulpicie, zostać wskazane przez widget i zostać uwzględnione w Composite Status. Dlatego przy wystąpieniu problemu warto pytać nie „które urządzenie”, lecz który obiekt — odpowiedź decyduje o tym, skąd pochodzi alert i co powinien pokazywać pulpit.
Stan obiektu
Nazwy stanów obiektów zostały zaprojektowane tak, aby dokładnie odzwierciedlały ich bieżący status:
- Critical, Error lub Down: element nie działa albo nie odpowiada.
- Warning: problem wymaga uwagi, ale nie jest konieczne natychmiastowe działanie.
- OK, Success: element działa prawidłowo.
- Disabled: monitorowanie elementu zostało celowo wyłączone.
- Unknown: stan elementu nie został określony, ponieważ nie był on monitorowany lub nie można go monitorować.
Unknown nie oznacza rodzaju awarii. Informuje, że NetCrunch nie ma żadnego pomiaru — to coś innego niż uzyskanie pomiaru wskazującego problem. Rozróżnienie to ma największe znaczenie w przypadku Composite Status: usługa zbudowana z obiektów, których stan to jedynie Unknown, nie jest uszkodzona, lecz nieobserwowana, dlatego wymaga innej reakcji.
Węzły
Węzeł jest elementem głównym, od którego zależą wszystkie pozostałe elementy, i jest punktem końcowym usługi, a nie urządzeniem.
Starsze narzędzia monitorowania były projektowane wokół sprzętu: jedno urządzenie, jeden wpis, a monitorowanie było podłączone do tego urządzenia. Taki model już dawno przestał odzwierciedlać rzeczywistość. Pojedynczy serwer obsługuje dziesiątki maszyn wirtualnych, które mogą niezależnie ulegać awariom. Platforma SaaS, od której zależysz, nie ma urządzenia, na które można wskazać. Reverse proxy odpowiada za kilkanaście aplikacji pod jednym adresem, a awaria każdej z nich może mieć inny przebieg.
Ponieważ węzeł jest punktem końcowym, atlas nie jest inwentaryzacją sprzętu. Jedna maszyna może zgodnie z uzasadnieniem odpowiadać kilku węzłom, a węzeł może nie odpowiadać żadnej maszynie należącej do Ciebie. Modeluj to, od czego zależysz, a nie tylko to, czego możesz dotknąć — pozostała część tej strony opisuje typy obiektów, które to umożliwiają. Zobacz Czym jest węzeł w NetCrunch?.
obj-ip-node
IP Node
Najczęściej używany typ. Reprezentuje element dostępny pod danym adresem, zwykle identyfikowany przez nazwę DNS lub adres IP, i może zawierać usługi sieciowe, monitory, czujniki oraz interfejsy.
Różne nazwy oznaczają różne węzły, nawet jeśli wskazują tę samą maszynę.
Jeśli shop.example.com i api.example.com są rozpoznawane jako ten sam serwer, dodaj oba wpisy. Są to oddzielne punkty końcowe i mogą niezależnie ulegać awariom: inny host wirtualny, inny certyfikat, inna pula backendów. Działający shop nie mówi nic o api, a monitorowanie tylko wspólnego adresu nie dostarcza informacji o żadnym z nich.
To samo dotyczy sytuacji odwrotnej — urządzenie odpowiadające pod adresem zarządzania i adresem danych reprezentuje dwa punkty końcowe, a najciekawsze awarie występują wtedy, gdy przestaje działać tylko jeden z nich.
Używaj jednego węzła dla każdej nazwy, od której rzeczywiście zależysz. Zobacz Monitorowanie stron internetowych i zapytań HTTP/HTTPS, aby monitorować znajdujące się za nimi strony.
Telemetry Node
Węzeł przeznaczony dla danych, które są przesyłane do NetCrunch, a nie odpytywane przez NetCrunch. Zwykle nie ma adresu, do którego można wysłać polecenie ping — istnieje po to, aby odbierać dane.
Akceptuje dwa rodzaje danych:
- Native NetCrunch REST
- Dane JSON wysyłane do własnego endpointu węzła, zawierające liczniki, statusy i zdarzenia. Tego formatu należy używać ze skryptu, aplikacji lub dowolnego kontrolowanego przez Ciebie źródła — zobacz @data-sensor.
- OTLP (OpenTelemetry)
- Metryki i dzienniki z dowolnego klienta lub kolektora OpenTelemetry, wysyłane do bramy OTLP. Użyj tej opcji, gdy system już obsługuje OpenTelemetry i nie chcesz tworzyć eksportera.
Okres przechowywania danych jest wybierany podczas tworzenia węzła, ponieważ NetCrunch nie może wiedzieć, jak często dane będą do niego przesyłane. Zobacz Węzeł telemetryczny.
Cloud Service
Reprezentuje pojedynczą monitorowaną usługę w chmurze. NetCrunch udostępnia gotowe czujniki dla ponad 30 usług Azure, AWS, Google i innych dostawców, dlatego węzeł modeluje samą usługę, a nie znajdującą się za nią maszynę.
Cluster Node
Reprezentuje cały klaster, a nie poszczególne hosty wchodzące w jego skład.
NetCrunch tworzy taki węzeł po dodaniu klastra Proxmox VE. Węzeł zawiera czujnik Proxmox VE Cluster i monitoruje elementy należące do klastra, a nie do poszczególnych członków — kworum, współdzielone magazyny danych oraz to, czy któryś z członków odłączył się od klastra. Może także tworzyć węzły członków podczas ich wykrywania. Zobacz Monitorowanie Proxmox VE.
obj-composite-status
Composite Status
Węzeł, którego stan jest obliczany na podstawie innych obiektów, a nie mierzony na urządzeniu.
Potrzebujesz go, ponieważ żadna monitorowana przez Ciebie rzecz nie jest usługą samą w sobie. Strona składania zamówień zależy od dwóch łączy internetowych, DNS, Active Directory i serwera WWW — żaden pojedynczy węzeł w atlasie nie może powiedzieć, czy składanie zamówień działa. Composite Status może to zrobić i odpowiada na trzy pytania, na które poszczególne elementy nie potrafią odpowiedzieć:
Czy usługa rzeczywiście jest dotknięta problemem? W przypadku dwóch łączy internetowych, z których wystarczy dowolne jedno, utrata jednego łącza jest alarmem na poziomie węzła, ale usługa nadal działa. Umieść je w grupie nadmiarowej, a composite pozostanie w stanie OK do momentu awarii ostatniego łącza — to różnica między alertem wymagającym działania a szumem.
Kto ma zostać powiadomiony? Skonfiguruj alert dla composite, a jedno powiadomienie będzie opisywać usługę zamiast pięciu powiadomień opisujących jej części i pozostawiających odbiorcy konieczność samodzielnego ich podsumowania.
Co ma pojawić się na pulpicie? Jeden kafelek na usługę zamiast ściany komponentów. Composite może zawierać kolejny composite, dzięki czemu całe drzewo usług jest agregowane do jednego stanu.
Zobacz Status złożony, aby dowiedzieć się, jak definiowane są grupy, oraz Business Service Views, aby zobaczyć diagram, który NetCrunch automatycznie tworzy na jego podstawie.
Probe
Reprezentuje zdalny silnik monitorowania, a nie maszynę, na której jest uruchomiony. Jego stan informuje, czy ten silnik jest dostępny i czy zbiera dane.
Obiekt probe nie monitoruje komputera, na którym probe jest zainstalowany. Jeśli zależy Ci na monitorowaniu dysku, pamięci lub usług tej maszyny — a powinno Ci zależeć, ponieważ wszystko, co monitoruje, jest od niej zależne — dodaj ją również jako zwykły węzeł IP. Zobacz Monitorowanie rozproszone.
Monitor
Monitor jest współdzielonym połączeniem z daną technologią — SNMP, WMI, VMware, Linux over SSH — przechowującym poświadczenia i parametry używane ponownie przez wszystkie elementy tego typu na węźle. To on zapewnia NetCrunch dostęp do tysięcy metryk bez konieczności konfigurowania każdej z nich osobno.
Monitor jest celowo ogólny, dlatego jego stan nie jest wart konfigurowania alertów. Informuje, że połączenie działa, a nie że wszystko, na czym Ci zależy, jest w dobrym stanie. Konfiguruj alerty dla używających go pakietów monitorowania i czujników.
Monitoring Pack
Nazwany pakiet reguł alertów i modułów zbierających dane — określający, przed czym ostrzegać i co zapisywać w raportach — tworzony raz dla danego rodzaju elementu i stosowany wszędzie tam, gdzie ten element występuje.
Invalid Reference @def:Monitoring Pack
Jest to jednostka ponownego użycia w NetCrunch i powód, dla którego alerty rzadko konfiguruje się bezpośrednio na węźle. Pakiet można dołączyć na trzy sposoby:
- Automatycznie, za pomocą filtra
- Pakiet określa warunki, które musi spełniać węzeł — na przykład Windows Server z uruchomionym LDAP — a NetCrunch stosuje go do każdego pasującego węzła, w tym do węzłów wykrytych w przyszłym miesiącu. W ten sposób wyrażana jest polityka monitorowania, zamiast ręcznego jej utrzymywania.
- Ręcznie
- Przypisanie do jednego węzła, kilku wybranych węzłów lub całego widoku atlasu.
- Do typu czujnika
- Po ustawieniu opcji Restrictions na Sensors only pakiet zawiera reguły alertów i raportowania dla danego typu czujnika wszędzie tam, gdzie ten czujnik jest skonfigurowany, a nie dla konkretnego węzła. To samo działa w przypadku operacji IP SLA i Huawei NQA.
Opcja Restrictions spełnia dwa zadania: ogranicza zarówno zdarzenia, które może zawierać pakiet, jak i urządzenia, do których może uzyskać dostęp — Windows, Linux, macOS, BSD, Solaris, VMware ESXi, Proxmox VE, SNMP lub opcje oparte na czujnikach wymienione powyżej.
Edycja pakietu zmienia monitorowanie na każdym węźle, który go używa. Jest to jego główna zaleta, ale również ryzyko: próg złagodzony raz zostaje złagodzony wszędzie. NetCrunch zawiera ponad 270 wstępnie zdefiniowanych pakietów, a wstępnie zdefiniowane pakiety są całkowicie zastępowane przez aktualizację konfiguracji atlasu, dlatego przed dostosowaniem wstępnie zdefiniowanego pakietu należy utworzyć jego kopię. Zobacz Pakiety Monitorowania.
Network Service
Test na poziomie protokołu — około 70 testów, od HTTP i DNS po SMTP i FTP — wykonywany przez silnik monitorowania NetCrunch na serwerze lub probe. Każdy test wysyła żądanie oczekiwane przez dany protokół i sprawdza, czy odpowiedź jest prawidłowa, dlatego usługa w stanie OK oznacza, że aplikacja odpowiedziała, a nie tylko że port był otwarty.
Każda usługa rejestruje te same cztery pomiary: Round Trip Time, Check Time, % Failure Rate oraz % Packets Lost.
Network services mają większe znaczenie, niż sugerowałby ich rozmiar, ponieważ stan węzła w dużej mierze jest ich stanem. Ta zależność ma jedno zachowanie, o którym warto wiedzieć:
Gdy węzeł jest niedostępny, sprawdzana jest tylko jego wiodąca usługa.
Zamiast ponownie sprawdzać każdą usługę na urządzeniu, które nie odpowiada, NetCrunch przełącza się na jedną z nich — usługę wiodącą — i używa jej do określenia, kiedy węzeł ponownie działa. Zapobiega to generowaniu przez niedostępny węzeł serii identycznych awarii i dlatego usługa wiodąca może być sprawdzana w sekundach, a nie minutach: tylko ona jest wówczas sprawdzana.
Usługi można dostosowywać bez pisania kodu: skopiować usługę, aby działała na innym porcie (na przykład HTTP_8080 dla usługi działającej za niestandardowym portem), zdefiniować podstawowy test portu TCP, jeśli wystarczy samo połączenie, albo od podstaw utworzyć pełną definicję żądania i odpowiedzi przez TCP, UDP lub TLS/SSL. Zobacz Monitorowanie usług sieciowych.
Interfejs
Pojedynczy interfejs sieciowy na monitorowanym urządzeniu, posiadający własny stan, liczniki ruchu i błędów.
Bezpośrednie odwoływanie się do interfejsów jest przydatne, ponieważ urządzenie może być całkowicie sprawne, podczas gdy jeden z jego portów nie działa: przełącznik odpowiada na każdy test, ale łącze nadrzędne obsługujące połowę budynku jest niedostępne lub po cichu odrzuca pakiety. Obiekt interfejsu pozwala wskazać w alercie, widżecie lub statusie złożonym konkretny port zamiast całego przełącznika. Zobacz Monitorowanie interfejsów sieciowych.
Czujniki
Czujniki koncentrują się na określonych potrzebach monitorowania, takich jak monitorowanie procesu, tekstowego pliku dziennika, oczekującej aktualizacji, kamery, zapytania SQL lub strony internetowej.
Invalid Reference @def:Monitoring Sensor
Sensor Status Object
Niektóre czujniki publikują własne obiekty, które zawierają zarówno dane, jak i stan — Snapshot Image dla czujnika kamery, Web Page dla monitorowania stron internetowych oraz Process dla czujnika procesu.
Są to oddzielne obiekty, ponieważ ich stan może różnić się od stanu czujnika. Czujnik kamery może prawidłowo nawiązywać połączenie i zbierać dane, podczas gdy zwracany przez niego obraz może przestać odpowiadać obrazowi referencyjnemu; czujnik ma wtedy stan OK, a obiekt nie. Odwołuj się do obiektu, gdy interesuje Cię zmierzona wartość, a do czujnika, gdy interesuje Cię poprawność pomiaru.
Active Alert
Alert - warunek obserwowany w celu podjęcia działań w ramach reakcji na potencjalne zagrożenie lub w celu zwrócenia uwagi.
Stan alertu wynika z jego ważności. Alerty informacyjne i alerty o małej ważności są traktowane jako ok, ponieważ służą do rejestrowania informacji, a nie do podejmowania działań — dlatego węzeł zawierający kilka takich alertów nadal może być oznaczony kolorem zielonym.
SNMP Value
Dostępna po dodaniu do węzła alertu event for SNMP variable value. Sam obiekt zawsze znajduje się w stanie success i służy do przechowywania wartości; znaczący stan ma alert dołączony do tego obiektu.
IP SLA/NQA Operation
Włącz monitorowanie IP SLA lub NQA na węźle, dodaj wybrane operacje, a każda z nich stanie się obiektem, do którego można się odwoływać — test syntetyczny uruchomiony na urządzeniu będzie dostępny dla alertów i pulpitów tak samo jak wszystko, co mierzy sam NetCrunch.
Atlas View
Widok może posiadać własny status, obliczany na podstawie zawartych w nim węzłów, dlatego folder lub sieć IP można wskazywać tak samo jak każdy inny obiekt — za pomocą jednego wskaźnika pokazującego „wszystko w oddziale”, bez konieczności tworzenia dla niego composite. Zobacz Zarządzanie widokami atlasu sieci.