Tworzenie i edycja reguł alertów w NetCrunch

Ten rozdział zawiera kompleksowy przewodnik dotyczący tworzenia i edycji reguł alertów w NetCrunch. Omówiono w nim kluczowe właściwości definiujące alert, takie jak Poważność, Opis i Stan Docelowy, a także zaawansowane konfiguracje, w tym dodatkowe warunki alertów i automatyczną korelację alertów. Zrozumienie tych koncepcji pozwoli administratorom sieci zoptymalizować strategie monitorowania, zmniejszyć liczbę fałszywych alarmów i zapewnić szybką i precyzyjną reakcję na incydenty.

Kluczowe właściwości

Podczas konfigurowania reguł alertów w NetCrunch kluczowe jest zrozumienie znaczenia pól definiujących alert. Napotkasz trzy pola krytyczne: „Poważność”, „Opis” i „Stan Docelowy”.

Poważność

Pole Poważność wskazuje poziom ważności alertu. Pomaga ono nadać priorytet problemom i określić pilność potrzebnej reakcji. Poziomy ważności zazwyczaj wahają się od informacyjnego do krytycznego. Oto krótki przegląd:

• Krytyczny – Poziom istotności reprezentuje poważne problemy wymagające natychmiastowej uwagi, ponieważ mogą spowodować znaczne zakłócenia, jeśli nie zostaną szybko rozwiązane.
• Ostrzeżenie – Wskazuje potencjalne problemy, które mogą eskalować, jeśli nie zostaną rozwiązane, ale nie są krytyczne.
• Informacyjne – Alerty, które dostarczają cennych informacji, ale nie wymagają natychmiastowego działania.
• Drobny – Alerty o niskim poziomie istotności wskazują problemy wymagające uwagi, ale nie stanowiące bezpośredniego zagrożenia dla funkcjonalności operacyjnej, służąc jako sygnały zapobiegawcze, pomagające utrzymać sprawność systemu.

Wybór właściwego poziomu istotności ma kluczowe znaczenie dla prawidłowego zarządzania incydentami i zapewnienia, że ​​odpowiedni członkowie zespołu skutecznie priorytetyzują swoje reakcje.

Opis

Pole Opis powinno zwięźle wyjaśniać alert i jego kontekst. Np. „Wysokie wykorzystanie procesora (> 90%)”

Stan operacyjny

Pole „Stan operacyjny” jest niezbędne do zrozumienia wpływu alertów w NetCrunchu. Rozróżnia usługę, która jedynie doświadcza problemów, od usługi, która jest całkowicie niedostępna, zapewniając w ten sposób kluczowe informacje, które wspierają skuteczne zarządzanie incydentami i szybkie rozwiązywanie problemów.

• Operacyjny — obiekt/usługa działa. Obejmuje to scenariusze, w których wydajność może ulec pogorszeniu, ale usługa pozostaje dostępna.

• Nieoperacyjny — obiekt/usługa nie działa zgodnie z oczekiwaniami, co zazwyczaj oznacza, że ​​nie odpowiada lub jest całkowicie offline.

Warunek zdarzenia

Warunek zdarzenia jest kluczowym elementem reguły alertowania w NetCrunchu, definiującym główny powód wygenerowania alertu. Ten warunek określa dokładne okoliczności, w których generowany jest alert. Na przykład, może być ustawiony tak, aby wykrywał zmianę stanu — taką jak przejście usługi z trybu reagowania na tryb niedostępności — lub monitorował próg dla określonej metryki, taki jak przekroczenie predefiniowanego limitu użycia procesora.

Alert zostanie wygenerowany tylko wtedy, gdy Warunek zdarzenia zostanie spełniony w połączeniu z dowolnymi skonfigurowanymi Dodatkowymi warunkami alertowania. To dwuwarstwowe podejście gwarantuje, że alerty są zarówno precyzyjne, jak i trafne w kontekście. Precyzyjne zdefiniowanie Warunku Zdarzenia pomaga zapewnić, że system alertów reaguje tylko na istotne zdarzenia, zmniejszając w ten sposób liczbę fałszywych alarmów i zmęczenie alertami, a jednocześnie umożliwiając szybką i skuteczną reakcję na incydenty.

Dodatkowy Warunek Alertowania

NetCrunch umożliwia zdefiniowanie dodatkowych warunków dla każdego alertu, niezależnie od tego, czy został on wywołany przez zmianę stanu węzła, alert z dziennika zdarzeń, czy pułapkę SNMP. Te dodatkowe warunki pozwalają na precyzyjne dostrojenie procesu alertowania poprzez wyzwalanie działań nawet wtedy, gdy nie wystąpiło zdarzenie główne. Na przykład, można określić warunki na podstawie określonych przedziałów czasowych lub braku zdarzenia, zapewniając aktywację alertów tylko w określonych okolicznościach. Dostępne dodatkowe warunki obejmują:

• Warunek Zdarzenia: Wyzwól alert po wystąpieniu określonego zdarzenia.
• Tylko jeśli czas pomiędzy: Wyzwól alert tylko wtedy, gdy zdarzenie wystąpi w wyznaczonym przedziale czasowym.
• Tylko jeśli czas nie jest pomiędzy: Wyzwól alert tylko poza zdefiniowanym przedziałem czasowym.
• Zdarzenie nie wystąpiło w określonym czasie: Upewnij się, że alert jest wyzwalany tylko wtedy, gdy oczekiwane zdarzenie nie wystąpi w określonym przedziale czasowym.
• Zdarzenie nie wystąpiło po określonym czasie: Aktywuj alert, jeśli określone zdarzenie nie wystąpi po określonym czasie.
• Zdarzenie oczekujące dłużej niż (określony czas): Wyzwól alert, jeśli zdarzenie pozostaje nierozwiązane dłużej niż zdefiniowany czas.

Korelacja zamknięcia alertu

Funkcja korelacji zamknięcia alertu w NetCrunchu usprawnia zarządzanie alertami poprzez automatyczne grupowanie powiązanych powiadomień. W przypadku alertów wyzwalanych wewnętrznie — generowanych przez zmiany stanu lub przekroczenia progów — NetCrunch został zaprojektowany tak, aby automatycznie je zamykać po rozwiązaniu problemu.

Jednakże, dla ext wymagana jest korelacja zamknięcia.Alerty wewnętrzne pochodzące z pułapek, syslogów lub komunikatów internetowych. W takich przypadkach alerty zewnętrzne są parowane z odpowiadającymi im zdarzeniami rozwiązania, aby zapewnić ich odpowiednie zamknięcie. Alerty można skonfigurować tak, aby zamykały się automatycznie po określonym czasie lub mogą być ręcznie kasowane przez operatora po potwierdzeniu ich rozwiązania. Takie podejście zmniejsza zmęczenie alertami i utrzymuje przejrzystość systemu, zapewniając dokładne przedstawienie rzeczywistego stanu problemów sieciowych.

Dowiedz się więcej o warunkach i korelacji

Wnioski

Tworzenie i edytowanie reguł alertów w NetCrunchu wymaga dokładnego zrozumienia pól: Ważność, Opis i Stan docelowy. Efektywne wykorzystanie tych pól, wraz z zaawansowanymi konfiguracjami, takimi jak dodatkowe warunki alertów i automatyczna korelacja zamykania alertów, może ulepszyć strategię monitorowania, usprawnić rozwiązywanie problemów i ostatecznie zapewnić niezawodność systemów.