Dzi?ki eskalacjom mo?na utworzy? w?asne scenariusze wysy?ania powiadomie¨½ lub wykonywania zdalnych polece¨½.
W praktyce oznacza to, ?e:
Akcje s? eskalowane w oparciu o krok eskalacji. Ka?dy krok ma d?ugo?? trwania w czasie.
Mo?na zdefiniowa? zar¨®wno domy?ln? d?ugo?? trwania jak i w?asn? d?ugo?? trwania dla indywidualnego kroku. Minimalna d?ugo?? trwania jednego kroku eskalacji to 60 sekund.
Akcje takie jak wysy?anie wiadomo?ci czy wykonanie polece¨½, mo?na uruchamia? z dowolnego kroku. Krok pierwszy jest zarezerwowany dla akcji natychmiastowych. Je?eli chcemy op¨®?ni? akcj?, mo?emy j? przydzieli? do p¨®?niejszego kroku. Dla ka?dego kroku mo?na zdefiniowa? kilka akcji.
Ilo?? krok¨®w eskalacji nie jest ograniczona.
Eskalacje definiowane s? podczas konfigurowania operacji.
Spr¨®bujmy zobaczy? co si? stanie w r¨®?nych sytuacjach, gdy akcja posiada kilka krok¨®w eskalacji.
Sytuacja | Zachowanie |
---|---|
Pewien host przeszed? w tryb utrzymania po tym, jak zosta?o wys?ane powiadomienie o problemie | Wszystkie pozosta?e kroki eskalacji b?d? wykonywane. Utrzymanie nie mo?e zatrzyma? operacji; utrzymanie ma jedynie wp?yw na to, kiedy akcja ma by? uruchomiona lub nie, a nie na operacje. |
Okres czasu, zdefiniowany w warunku akcji Okres, zako¨½czy? si? po wys?aniu pierwszego powiadomienia | Wszystkie pozosta?e kroki eskalacji b?d? wykonywane. Warunek Okres nie mo?e zatrzyma? operacji; ma jedynie wp?yw na to, kiedy akcja ma by? uruchomiona lub nie, a nie na operacje. |
Problem wyst?pi? podczas utrzymania i trwa (nie jest rozwi?zany) po utrzymaniu | Wszystkie kroki eskalacji b?d? wykonane rozpoczynaj?c od momentu uko¨½czenia utrzymania. |
Problem wyst?pi? podczas utrzymania bez danych i trwa (nie jest rozwi?zany) po utrzymaniu | Musi zaczeka? na odpalenie wyzwalacza, wtedy zostan? uruchomione wszystkie kroki eskalacji. |
R¨®?ne eskalacje wyst?pi?y blisko siebie i nachodz? na siebie | Wykonanie ka?dej nowej eskalacji nadpisuje poprzednie eskalacje, ale przynajmniej jeden krok z poprzedniej eskalacji jest wykonywany. To zachowanie jest przydatne przy akcjach dotycz?cych zdarze¨½, kt¨®re s? tworzone przy KA?DYM wyliczeniu problemu w wyzwalaczu. |
Akcja zosta?a wy??czona podczas trwania eskalacji (np podczas wysy?ania wiadomo?ci) | Wysy?ana wiadomo?? zostanie wys?ana, a zaraz po niej wys?ana zostanie jeszcze jedna wiadomo?? eskalacji. Druga wiadomo?? b?dzie mia?a nast?puj?cy tekst na pocz?tku: NOTE: Escalation cancelled: action '<Nazwa akcji>' disabled. Dzi?ki temu odbiorca zostanie poinformowany, ?e eskalacja zosta?a anulowana i nie b?dzie wykonanych wi?cej krok¨®w. |
Wysy?anie powtarzaj?cego si? powiadomienia raz na 30 minut (og¨®?em 5 razy) do grupy 'MySQL Administrators'. ?eby skonfigurowa?:
Wiadomo?ci wys?ane zostan? w 0:00, 0:30, 1:00, 1:30, 2:00 godzinie po wyst?pieniu problemu (chyba, ?e problem zostanie rozwi?zany wcze?niej).
Je?eli problem zostanie rozwi?zany i skonfigurowano wiadomo?? odzyskania, zostanie ona wys?ana do wszystkich, kt¨®rzy odebrali przynajmniej jedn? wiadomo?? ze scenariusza eskalacji.
Je?eli wyzwalacz, kt¨®ry wygenerowa? aktywn? eskalacj? zostanie wy??czony, Áú»¢¶Ä²© wy?le wiadomo?? informuj?c? o tym do wszystkich, kt¨®rzy otrzymali ju? powiadomienia.
Wysy?anie op¨®?nionych powiadomie¨½ o d?ugo wyst?puj?cym problemie. ?eby skonfigurowa?:
Powiadomienie zostanie wys?ane jedynie w Kroku 2 scenariusza eskalacji, lub 10 godzin po wyst?pieniu problemu.
Mo?na zmieni? tekst wiadomo?ci na przyk?ad tak: 'Problem trwa od 10 godzin'.
Eskalacja problemu do Szefa.
W pierwszym przyk?adzie powy?ej skonfigurowali?my okresowe wysy?anie wiadomo?ci do administrator¨®w MySQL. W tym przypadku, administratorzy otrzymaj? cztery wiadomo?ci, a nast?pnie problem b?dzie eskalowany do menad?era baz danych. Nale?y zauwa?y?, ?e menad?er otrzyma wiadomo?? jedynie wtedy, gdy problem nie zostanie jeszcze potwierdzony, przypuszczalnie nikt nad nim nie pracuje.
Zauwa?my, ?e w wiadomo?ci u?yto makra {ESC.HISTORY}. Makro b?dzie zawiera?o informacje o wszystkich poprzednio wykonanych krokach tej eskalacji, takich jak wys?ane wiadomo?ci czy wykonane polecenia.
Bardziej skomplikowany scenariusz. Po kilku wiadomo?ciach do administrator¨®w MySQL i eskalacji do menad?era, Áú»¢¶Ä²© spr¨®buje zrestartowa? baz? danych MySQL. Nast?pi to, je?eli problem istnieje od 2:30 godzin i nie zosta? potwierdzony.
Je?eli problem nadal istnieje, po kolejnych 30 minutach Áú»¢¶Ä²© wy?le wiadomo?? do wszystkich u?ytkownik¨®w go?ci.
Je?eli to nie pomo?e, po kolejnej godzinie Áú»¢¶Ä²© zrestartuje serwer z baz? danych MySQL (drugie zdalne polecenie) u?ywaj?c polece¨½ IPMI.
Eskalacja z kilkoma operacjami przydzielonymi do jednego kroku i z w?asnymi interwa?ami. Domy?lnie czas trwania kroku to 30 minut.
Powiadomienia b?d? wysy?ane nast?puj?co: