Udostępnij za pośrednictwem

  • Artykuł

Alerty

 

Dotyczy: System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

W programie Operations Manager alerty mogą być generowane przez monitory lub zasady. W konsoli Operacje te typy nie są rozróżnione, lecz istnieją między nimi pewne różnice, które należy poznać w celu definiowania monitorów i zasad. Poniższe sekcje zawierają właściwości alertów, które należy zdefiniować podczas konfigurowania monitora generującego alert lub tworzenia zasady generowania alertu.

Alerty z monitorów

Alert będzie generowany tylko przez monitor, gdy są spełnione wszystkie następujące warunki:

  • Monitor jest skonfigurowany do generowania alertu.

  • Kondycja monitora zmieniła się ze stanu Dobra kondycja na stan Ostrzeżenie lub Błąd w zależności od możliwych stanów monitora.

  • Nie istnieje już otwarty alert dla tego samego obiektu utworzonego przez ten sam monitor.

Monitor generuje alerty tylko w przypadku, gdy jego kondycja zmieni się ze stanu Dobra kondycja. Kryteria stanu błędu mogą wystąpić wiele razy, lecz nie spowoduje to generowania wielu alertów po zmianie kondycji monitora na stan Ostrzeżenie lub Krytyczny. Nowy alert zostanie wygenerowany tylko w przypadku, gdy kondycja monitora powróci do stanu Dobra kondycja i ponownie wystąpi błąd.

Przykładem może być monitor zdarzeń systemu Windows skonfigurowany w taki sposób, aby ustawiał stan krytyczny po wykryciu zdarzenia o numerze 101 i resetował monitor w przypadku wykrycia zdarzenia o numerze 100. Po utworzeniu pierwszego zdarzenia o numerze 101 monitor zmieni stan na krytyczny i zostanie wygenerowany alert. Alert można zamknąć, lecz w przypadku wykrycia dodatkowego zdarzenia o numerze 101 nie zostanie utworzony nowy alert, ponieważ monitor nie zmienił stanu. Alert zostanie wygenerowany tylko po zresetowaniu monitora ręcznie lub wskutek wykrycia zdarzenia o numerze 100 i po wykryciu zdarzenia o numerze 101.

Nazwa alertu

Nazwa alertu składa się z jednego wiersza tekstu statycznego i nie może zawierać żadnych zmiennych.

Priorytet i ważność

Występują następujące rodzaje ważności alertu: Informacje, Ostrzeżenie lub Krytyczny. Ta ważność nie musi odpowiadać ważności kondycji wyzwalającej alert. Ważność alertu określa ikona w konsoli Operacje i jest ona używana w widokach oraz subskrypcjach powiadomień. Priorytet alertu nie jest dostępny z poziomu konsoli Operacje, lecz jest używany głównie w subskrypcjach powiadomień.

Opis alertu

Opis alertu może składać się z kilku wierszy tekstu, zawierających tekst statyczny oraz zmienne. W opisie alertu najczęściej będą występowały zmienne $Data, aby uwzględnić w nim różne informacje ze źródła danych monitora. Dostępne właściwości różnią się w zależności od używanego źródła danych.

Poniższa tabela zawiera składnie i przykłady zmiennych w alertach tworzonych przez monitory.

Źródło danych

Składnia

Przykłady

Zdarzenie systemu Windows

 
        $Data/Context/<Property Name>$
      
        $Data/Context/EventDescription$
      
        $Data/Context/Params/Param[#]$
      
        $Data/Context/Params/Param[2]$

Dziennik tekstowy

 
        $Data/Context/<Property Name>$
      
        $Data/Context/LogFileName$
      
        $Data/Context/Params/Param[1]$
      
        $Data/Context/Params/Param[1]$

Rozdzielany dziennik tekstowy

 
        $Data/Context/<Property Name>$
      
        $Data/Context/LogFileName$
      
        $Data/Context/Params/Param[#]$
      
        $Data/Context/Params/Param[2]$

Zdarzenie WMI

 
        $Data/Context/Collection[@Name='<TargetInstance|PreviousInstance>']/Property[@Name='<PropertyName>']$
      
        $Data/Context/Collection[@Name=’TargetInstance’]/Property[@Name='Name']$

Wydajność systemu Windows

 
        $Data/Context/<PropertyName>]$
      
        $Data/Context/Value$

Wydajność WMI

 
        $Data/Context/<PropertyName>]$
      
        $Data/Context/Value$

Skrypt monitorowania

 
        $Data/Context/Property[@Name='<PropertyName>']$
      
        $Data/Context/Property[@Name='Result'>']$

Automatyczne rozwiązywanie alertów

Monitory tworzące alerty można skonfigurować, aby automatycznie rozwiązywały alerty po przywróceniu stanu dobrej kondycji. Dzięki temu wszystkie nierozwiązane alerty monitora wskazują problem, który nadal istnieje. Jedynym sposobem konfiguracji tego wymagania jest potwierdzenie opcji automatycznego rozwiązywania.

Uwaga

Automatyczne rozwiązywanie alertów nie może odbywać się przy użyciu zasad, ponieważ nie wykrywają one, czy problem został usunięty.

Alerty z zasad

Alert będzie generowany przez zasadę tylko w następujących warunkach:

  • Zasada jest skonfigurowana do generowania alertu.

  • Spełniono kryteria zdefiniowane w zasadzie.

  • Nie istnieje jeszcze otwarty alert odpowiadający konfiguracji pomijania alertu.

W poniższej tabeli omówiono możliwości generowania alertów przez poszczególne typy zasad.

Typ zasady

Możliwości generowania alertów

Zasady zdarzeń

Zasady alertów można tworzyć dla każdego źródła danych zdarzenia. Kryteria służące do określenia momentu tworzeniu alertu są takie same jak kryteria zmiany stanu w monitorach zdarzeń.

Zasady wydajności

Nie można utworzyć zasady alertu na podstawie licznika wydajności. Zamiast tego należy użyć monitora, ponieważ stan powodzenia jest zazwyczaj wykrywany z licznika wydajności i odnosi się do kondycji klasy docelowej.

Zasady wykonywania skryptów

Nie można utworzyć zasady alertu na podstawie skryptu. Zamiast tego należy użyć monitora, ponieważ skrypt zwykle zwraca wartość dotyczącą zarówno błędu, jak i dobrej kondycji, umożliwiając wykrycie stanu powodzenia odnoszącego się do kondycji klasy docelowej.

Nazwa alertu

Nazwa alertu składa się z jednego wiersza tekstu statycznego i nie może zawierać żadnych zmiennych.

Priorytet i ważność

Występują następujące rodzaje ważności alertu: Informacje, Ostrzeżenie lub Krytyczny. Ta ważność nie musi odpowiadać ważności kondycji wyzwalającej alert. Ważność alertu określa ikona w konsoli Operacje i jest ona używana w widokach oraz subskrypcjach powiadomień. Priorytet alertu nie jest dostępny z poziomu konsoli Operacje, lecz jest używany głównie w subskrypcjach powiadomień.

Opis alertu

Opis alertu może składać się z kilku wierszy tekstu, zawierających tekst statyczny lub zmienne. W opisie alertu najczęściej będą występowały zmienne $Data, aby uwzględnić w nim różne informacje ze źródła danych zasady. Dostępne właściwości różnią się w zależności od używanego źródła danych. Każda sekcja tematu Źródła danych zawiera listę właściwości dostępnych dla różnych źródeł danych.

Poniższa tabela zawiera składnie i przykłady zmiennych w alertach tworzonych przez zasady:

Źródło danych

Składnia

Przykłady

Zdarzenie systemu Windows

 
        $Data/<Property Name>$
      
        $Data/EventDescription$
      
        $Data/Params/Param[#]$
      
        $Data/Params/Param[2]$

Dziennik tekstowy

 
        $Data/EventData/DataItem/<PropertyName>$
      
        $Data/EventData/DataItem/LogFileName$
      
        $Data/EventData/DataItem/Params/Param[1]$
      
        $Data/EventData/DataItem/Params/Param[1]$

Rozdzielany dziennik tekstowy

 
        $Data/EventData/DataItem/<PropertyName>$
      
        $Data/EventData/DataItem/LogFileName$
      
        $Data/EventData/DataItem/Params/Param[#]$
      
        $Data/EventData/DataItem/Params/Param[2]$

Zdarzenie WMI

 
        $Data/EventData/DataItem/Collection[@Name='<TargetInstance | PreviousInstance>']/Property[@Name='<PropertyName>']$
      
        $Data/EventData/DataItem/Collection[@Name='TargetInstance']/Property[@Name='Name']$

Zdarzenie dziennika systemu

 
        $Data/EventData/DataItem/<PropertyName>$
      
        $Data/EventData/DataItem/Facility$

Pomijanie alertów

Pomijanie alertów odnosi się do logiki zdefiniowanej w zasadach alertów w celu pomijania zadania tworzenia alertu, gdy nadal jest otwarty odpowiedni alert. Zapobiega to „burzom alertów” polegających na tworzeniu wielu alertów dotyczących tego samego problemu. Problem został już wskazany przez otwarty alert, dlatego utworzenie dodatkowego alertu powoduje powstanie niepotrzebnego szumu o minimalnej wartości. Gdy spełniono warunek zasady alertu, ale istniejący alert jest nadal otwarty, funkcja pomijania alertów zwiększy liczbę powtórzeń istniejącego alertu, zapobiegając utworzeniu dodatkowego.

Aby zdefiniować pomijanie w zasadzie alertu, w polach należy określić rozpoznawanie odpowiadającego alertu. Przed utworzeniem nowego alertu zasada sprawdzi, czy istnieje otwarty alert z wartościami w polach zdefiniowanych w ramach funkcji pomijania, które odpowiadają wartościom w tych samych polach nowego alertu. Jeżeli istnieje otwarty alert z takimi samymi wartościami w każdym z tych pól, nowy alert nie zostanie utworzony.

W funkcji pomijania alertów należy określić minimalną liczbę pól, które jednoznacznie identyfikują alert. Oprócz pól używanych w kryteriach zasady zazwyczaj będzie to nazwa komputera. Pomijanie w zasadach zdarzeń można na przykład często uzyskać przy użyciu następujących pól:

  • Komputer logowania

  • Źródło zdarzenia

  • Numer zdarzenia

Jeżeli jednak klasą docelową zasady jest klasa z wieloma wystąpieniami w agencie, do jednoznacznego zidentyfikowania zdarzenia w kryteriach zasady może być wymagany parametr. W takim przypadku należy określić taki sam parametr w funkcji pomijania alertów.

Uwaga

Pomijanie alertów nie jest potrzebne w przypadku monitorów i tym samym jest niedostępne. Monitory generują alerty tylko, gdy ich stan zmieni się z dobrej kondycji na stan ostrzeżenia lub krytyczny. Alert nie jest generowany nawet w przypadku ponownego wystąpienia problemu, gdy monitor jest już w stanie negatywnym — jego stan nie zmienił się. Nowy alert jest generowany tylko w przypadku, gdy monitor powróci do stanu dobrej kondycji przed wystąpieniem problemu.