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 Pause operations for suppressed problems 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ā Time period, beidzas pēc sākotnējā paziņojuma nosūtīšanas | Visi atlikušie eskalācijas soļi tiek izpildīti. Nosacījums Time period 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 novērsta) pēc uzturēšanas beigām | Atkarībā no iestatījuma Pause operations for suppressed problems 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 novērsta) pēc uzturēšanas beigām | Tai jāgaida, līdz trigeris tiek aktivizēts, 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ā trigera problēmas novērtēšanas reizē. |
| 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 trigera notikumu: - trigeris tiek atspējots - hosts vai vienums tiek atspējots Pamatojoties uz iekšēju notikumu par trigeriem: - trigeris tiek atspējots Pamatojoties uz iekšēju notikumu par vienumiem/zemā līmeņa atklāšanas noteikumiem: - 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 (NOTE: Escalation canceled), kurā norādīts iemesls (piemēram, NOTE: Escalation canceled: action '<Action name>' disabled). 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, kuri iepriekš saņēma paziņojumus. Atcelšanas iemesls tiek ierakstīts arī servera žurnālfailā (sākot ar Debug Level 3=Warning). Ņemiet vērā, ka ziņojums Escalation canceled 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 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).