5 Eskalācijas
Overview
With escalations you can create custom scenarios for sending notifications or executing remote commands.
In practical terms it means that:
- Users can be informed about new problems immediately
- Notifications can be repeated until the problem is resolved
- Sending a notification can be delayed
- Notifications can be escalated to another "higher" user group
- Remote commands can be executed immediately or when a problem is not resolved for a lengthy period
Actions are escalated based on the escalation step. Each step has a duration in time.
You can define both the default duration and a custom duration of an individual step. The minimum duration of one escalation step is 60 seconds.
You can start actions, such as sending notifications or executing commands, from any step. Step one is for immediate actions. If you want to delay an action, you can assign it to a later step. For each step, several actions can be defined.
The number of escalation steps is not limited.
Escalations are defined when configuring an operation. Escalations are supported for problem operations only, not recovery.
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 tiek ievietots uzturēšanā 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. |
| Darbības nosacījumā Time period definētais 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 Time period nevar apturēt operācijas; tas ietekmē tikai 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 Pause operations for suppressed problems darbības konfigurācijā, visi eskalācijas soļi tiek izpildīti vai nu no brīža, kad uzturēšana beidzas, vai nekavējoties. |
| Problēma sākas no-data uzturēšanas laikā un turpinās (netiek atrisināta) pēc uzturēšanas beigām | Jāgaida, līdz nostrādā trigeris, pirms tiek izpildīti visi eskalācijas soļi. |
| Dažādas eskalācijas seko cita citai īsā laikā un pārklājas | Katras jaunas eskalācijas izpilde aizstāj iepriekšējo eskalāciju, taču iepriekšējai eskalācijai vienmēr tiek izpildīts vismaz viens eskalācijas solis. Šī darbība ir būtiska darbībām uz notikumiem, kas tiek izveidoti ar KATRU trigeris problēmas novērtējumu. |
| Notiekošas eskalācijas laikā (piemēram, tiek sūtīts ziņojums), pamatojoties uz jebkura veida notikumu: - darbība tiek atspējota Pamatojoties uz trigeris 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/zema līmeņa atklāšanas kārtulām: - 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. Sekojošā ziņojuma pamatteksta sākumā būs atcelšanas teksts (NOTE: Escalation canceled), norādot iemeslu (piemēram, NOTE: Escalation canceled: action '<Action name>' disabled). Tādējādi saņēmējs tiek informēts, ka eskalācija ir atcelta un turpmāki soļi netiks izpildīti. Šis ziņojums tiek nosūtīts visiem, kuri iepriekš saņēma paziņojumus. Atcelšanas iemesls tiek arī reģistrēts serveris žurnālfailā (sākot no Debug Level 3=Warning). Ņemiet vērā, ka ziņojums Escalation canceled tiek nosūtīts arī tad, ja operācijas ir pabeigtas, bet atkopšanas operācijas 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 serveris ž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).