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 uzvedības aspekti
Apskatīsim, kas notiek dažādos apstākļos, ja darbība ietver vairākus eskalācijas soļus.
| Situācija | Uzvedība |
|---|---|
| Attiecīgais hosts pēc sākotnējā problēmas paziņojuma nosūtīšanas nonāk uzturēšanas režīmā | Atkarībā no darbības konfigurācijā iestatījuma Pause operations for suppressed problems, visi atlikušie eskalācijas soļi tiek izpildīti vai nu ar aizkavi, ko izraisa uzturēšanas periods, vai bez aizkaves. Uzturēšanas periods neatceļ darbības. |
| Laika periods, kas definēts darbības nosacījumā Time period, beidzas pēc sākotnējā paziņojuma nosūtīšanas | Tiek izpildīti visi atlikušie eskalācijas soļi. Nosacījums Time period nevar apturēt darbības; tas ietekmē to, kad darbības tiek sāktas vai netiek sāktas, nevis pašas darbības. |
| Problēma sākas uzturēšanas laikā un turpinās (netiek atrisināta) pēc uzturēšanas beigām | Atkarībā no darbības konfigurācijā iestatījuma Pause operations for suppressed problems, visi eskalācijas soļi tiek izpildīti vai nu no brīža, kad beidzas uzturēšana, vai nekavējoties. |
| Problēma sākas bezdatu uzturēšanas laikā un turpinās (netiek atrisināta) pēc uzturēšanas beigām | Vispirms 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 īsā laikā un pārklājas | Katras jaunās eskalācijas izpilde aizstāj iepriekšējo eskalāciju, taču vismaz viens eskalācijas solis vienmēr tiek izpildīts iepriekšējā eskalācijā. Šī uzvedība ir svarīga darbībās notikumiem, kas tiek izveidoti ar trigeris EVERY problem evaluation. |
| Notiekošas eskalācijas laikā (piemēram, tiek sūtīts ziņojums), pamatojoties uz jebkura veida notikumu: - darbība ir atspējota Pamatojoties uz trigeris notikumu: - trigeris ir atspējots - hosts vai vienums ir atspējots Pamatojoties uz iekšējo notikumu par trigeriem: - trigeris ir atspējots Pamatojoties uz iekšējo notikumu par vienumiem/zemā līmeņa atklāšanas noteikumiem: - vienums ir atspējots - hosts ir atspējots |
Notiekošais ziņojums tiek nosūtīts, un pēc tam eskalācijā tiek nosūtīts vēl viens ziņojums. Turpmākā ziņojuma sākumā būs atcelšanas teksts (PIEZĪME: Eskalācija atcelta), norādot iemeslu (piemēram, PIEZĪME: Eskalācija atcelta: darbība '<Action name>' atspējota). Tādējādi saņēmējs tiek informēts, ka eskalācija ir atcelta un vairs netiks izpildīti nekādi soļi. Šis ziņojums tiek nosūtīts visiem, kas iepriekš saņēma paziņojumus. Atcelšanas iemesls tiek arī reģistrēts servera žurnālfailā (sākot no Debug Level 3=Warning). Ņemiet vērā, ka ziņojums Eskalācija atcelta tiek nosūtīts arī tad, ja darbības ir pabeigtas, bet atkopšanas darbības ir konfigurētas un vēl nav izpildītas. |
| Notiekošas eskalācijas laikā (piemēram, tiek sūtīts ziņojums) darbība tiek dzēsta | Vairāk ziņojumu netiek sūtīts. Informācija tiek reģistrēta servera žurnālfailā (sākot no Debug Level 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).