5 Eskalācijas
Pārskats
Ar eskalācijām varat izveidot pielāgotus scenārijus paziņojumu sūtīšanai vai attālinātu komandu izpildei.
Praksē tas nozīmē, ka:
- Lietotājus var nekavējoties informēt par jaunām problēmām.
- Paziņojumus var atkārtot, līdz problēma ir novērsta.
- Paziņojuma nosūtīšanu var aizkavēt.
- Paziņojumus var eskalēt uz citu, "augstāku" lietotāju grupu.
- Attālinātās komandas var izpildīt nekavējoties vai tad, ja problēma ilgstoši netiek novērsta.
Darbības tiek eskalētas, pamatojoties uz eskalācijas soli. Katram solim ir noteikts ilgums.
Varat definēt gan noklusējuma ilgumu, gan arī atsevišķa soļa pielāgotu ilgumu. Viena eskalācijas soļa minimālais ilgums ir 60 sekundes.
Varat sākt darbības, piemēram, paziņojumu sūtīšanu vai komandu izpildi, no jebkura soļa. Pirmais solis ir paredzēts tūlītējām darbībām. Ja vēlaties aizkavēt darbību, varat to piešķirt vēlākam solim. Katram solim var definēt vairākas darbības.
Eskalācijas soļu skaits nav ierobežots.
Eskalācijas tiek definētas, konfigurējot operāciju. Eskalācijas tiek atbalstītas tikai problēmu operācijām, nevis atkopšanai.
Dažādi eskalācijas darbības aspekti
Apskatīsim, kas notiek dažādos apstākļos, ja darbība satur vairākus eskalācijas soļus.
| Situācija | Darbība |
|---|---|
| Attiecīgais hosts pāriet uzturēšanas režīmā pēc sākotnējā problēmas paziņojuma nosūtīšanas | Atkarībā no iestatījuma Apturēt operācijas apspiestām problēmām darbības konfigurācijā visi atlikušie eskalācijas soļi tiek izpildīti vai nu ar uzturēšanas perioda izraisītu aizkavi, vai bez aizkaves. Uzturēšanas periods neatceļ operācijas. |
| Laika periods, kas definēts darbības nosacījumā Laika periods, beidzas pēc sākotnējā paziņojuma nosūtīšanas | Visi atlikušie eskalācijas soļi tiek izpildīti. Nosacījums Laika periods nevar apturēt operācijas; tas ietekmē to, kad darbības tiek sāktas vai netiek sāktas, nevis operācijas. |
| Problēma sākas uzturēšanas laikā un turpinās (netiek atrisināta) pēc uzturēšanas beigām | Atkarībā no iestatījuma Apturēt operācijas apspiestām problēmām darbības konfigurācijā visi eskalācijas soļi tiek izpildīti vai nu no uzturēšanas beigšanās brīža, vai nekavējoties. |
| Problēma sākas uzturēšanas laikā bez datiem un turpinās (netiek atrisināta) pēc uzturēšanas beigām | Tai jāgaida, līdz trigeris nostrādā, un tikai pēc tam tiek izpildīti visi eskalācijas soļi. |
| Dažādas eskalācijas seko cita citai ar nelielu intervālu un pārklājas | Katras jaunas eskalācijas izpilde aizstāj iepriekšējo eskalāciju, taču iepriekšējā eskalācijā vienmēr tiek izpildīts vismaz viens eskalācijas solis. Šāda darbība ir būtiska darbībām saistībā ar notikumiem, kas tiek izveidoti katrā trigerim veicot problēmas novērtējumu. |
| Notiekošas eskalācijas laikā (piemēram, kamēr tiek nosūtīts ziņojums), pamatojoties uz jebkāda veida notikumu: - darbība tiek atspējota Pamatojoties uz trigeru notikumu: - trigeris tiek atspējots - hosts vai vienums tiek atspējots Pamatojoties uz iekšēju trigeru notikumu: - trigeris tiek atspējots Pamatojoties uz iekšēju vienumu/zemas līmeņa atklāšanas noteikumu notikumu: - vienums tiek atspējots - hosts tiek atspējots |
Notiekošais ziņojums tiek nosūtīts, un pēc tam eskalācijas ietvaros tiek nosūtīts vēl viens ziņojums. Turpmākā ziņojuma pamattekstā sākumā būs atcelšanas teksts (PIEZĪME: Eskalācija atcelta), kurā norādīts iemesls (piemēram, PIEZĪME: Eskalācija atcelta: darbība '<Action name>' ir atspējota). Tādējādi adresāts tiek informēts, ka eskalācija ir atcelta un turpmākie soļi netiks izpildīti. Šis ziņojums tiek nosūtīts visiem, kas iepriekš saņēma paziņojumus. Atcelšanas iemesls tiek ierakstīts arī servera žurnālfailā (sākot ar atkļūdošanas līmeni 3=Warning). Ņemiet vērā, ka ziņojums Eskalācija atcelta tiek nosūtīts arī tad, ja operācijas ir pabeigtas, bet ir konfigurētas atkopšanas operācijas un tās vēl nav izpildītas. |
| Notiekošas eskalācijas laikā (piemēram, kamēr tiek nosūtīts ziņojums) darbība tiek dzēsta | Vairāk ziņojumu netiek nosūtīts. Informācija tiek ierakstīta servera žurnālfailā (sākot ar atkļūdošanas līmeni 3=Warning), piemēram: escalation canceled: action id:334 deleted |
Eskalācijas piemēri
Piemērs 1
Atkārtota paziņojuma sūtīšana reizi 30 minūtēs (kopā 5 reizes) grupai "MySQL Administrators". Lai to konfigurētu:
- Cilnē Operations iestatiet Default operation step duration uz "30m" (30 minūtes).
- Iestatiet eskalācijas Steps no "1" līdz "5".
- Atlasiet grupu "MySQL Administrators" kā ziņojuma saņēmējus.
Paziņojumi tiks nosūtīti pēc 0:00, 0:30, 1:00, 1:30 un 2:00 stundām kopš problēmas sākuma (ja vien, protams, problēma netiek atrisināta agrāk).
Ja problēma tiek atrisināta un ir konfigurēts atkopšanas ziņojums, tas tiks nosūtīts tiem, kuri šajā eskalācijas scenārijā saņēma vismaz vienu problēmas ziņojumu.
Ja trigeris, kas izveidoja aktīvu eskalāciju, tiek atspējots, Zabbix nosūta informatīvu ziņojumu visiem tiem, kuri jau ir saņēmuši paziņojumus.
Piemērs 2
Aizkavēta paziņojuma nosūtīšana par ilgstošu problēmu. Lai to konfigurētu:
- Cilnē Operations iestatiet Default operation step duration uz "10h" (10 stundas).
- Iestatiet eskalācijas Steps no "2" līdz "2".
Paziņojums tiks nosūtīts tikai eskalācijas scenārija 2. solī, jeb 10 stundas pēc problēmas sākuma.
Varat pielāgot ziņojuma tekstu, piemēram: "Problēma ilgst jau vairāk nekā 10 stundas".
Piemērs 3
Problēmas eskalēšana vadītājam.
Pirmajā iepriekš minētajā piemērā mēs konfigurējām periodisku ziņojumu sūtīšanu MySQL administratoriem. Šajā gadījumā administratori saņems četrus ziņojumus, pirms problēma tiks eskalēta datubāzes pārvaldniekam. Ņemiet vērā, ka pārvaldnieks saņems ziņojumu tikai tad, ja problēma vēl nebūs apstiprināta, t. i., visticamāk, neviens ar to vēl nestrādā.
- darbības informācija:
Ņemiet vērā pielāgotajā ziņojumā izmantoto makrosu {ESC.HISTORY}. Šis makross saturēs informāciju par visām iepriekš izpildītajām šīs eskalācijas darbībām, piemēram, nosūtītajiem paziņojumiem un izpildītajām komandām.
Piemērs 4
Sarežģītāks scenārijs. Pēc vairākiem ziņojumiem MySQL administratoriem un eskalācijas vadītājam, Zabbix mēģinās restartēt MySQL datu bāzi. Tas notiks, ja problēma pastāvēs 2:30 stundas un tā nebūs apstiprināta.
Ja problēma joprojām pastāvēs, pēc vēl 30 minūtēm Zabbix nosūtīs ziņojumu visiem vieslietotājiem.
Ja tas nepalīdzēs, pēc vēl vienas stundas Zabbix pārstartēs serveri ar MySQL datu bāzi (otrā attālā komanda), izmantojot IPMI komandas.
Piemērs 5
Eskalācija ar vairākām operācijām, kurām pārklājas soļu diapazoni un ir pielāgoti intervāli. Noklusējuma operācijas soļa ilgums ir 30 minūtes.
Paziņojumi tiks nosūtīti šādi:
- MySQL administratoriem 0:00, 0:30, 1:00 un 1:30 pēc problēmas sākuma.
- Database manager 2:00 un 2:10 (īsākais turpmākajā operācijā definētais pielāgotais soļa ilgums — 10 minūtes — aizstāj šeit konfigurēto garāko soļa ilgumu — 1 stundu, kā aprakstīts sadaļā Operation details parametram Step duration, ja soļi pārklājas).
- Zabbix administratoriem 2:00, 2:10 un 2:20 pēc problēmas sākuma (tiek piemērots pielāgotais soļa ilgums — 10 minūtes).
- vieslietotājiem 4:00 pēc problēmas sākuma (starp 8. un 11. soli stājas spēkā noklusējuma soļa ilgums — 30 minūtes).