Documentation
Table of Contents
5 Escalades
Vista general
Amb les escalades, podeu crear escenaris personalitzats per enviar notificacions o executar comandes de forma remota.
Concretament això vol dir que:
- Els usuaris poden ésser notificats immediatament de nous problemes
- Les notificacions es poden repetir fins que es resolgui el problema
- L'enviament d'una notificació es pot endarrerir
- Les notificacions es poden reenviar a un altre grup d'usuaris "superior".
- Les comandes remotes es poden executar immediatament o quan un problema no es resol durant molt de temps
Les accions s'escalen en funció de l'etapa d'escalada. Cada etapa té una durada en el temps.
Podeu establir tant la durada predeterminada com la durada personalitzada d'una passa individual. La durada mínima d'una passa d'escalada és de 60 segons.
Podeu iniciar accions, com ara enviar notificacions o executar comandes, des de qualsevol etapa. La primera passa es refereix a les accions immediates. Si voleu endarrerir una acció, podeu assignar-la a una passa posterior. Per a cada passa, es poden definir diverses accions.
El nombre de graons de pujada no és limitat.
Les escalades es defineixen quan es configura una operació. Les escalades només s'admeten per a operacions problemàtiques, no per a la recuperació.
Aspectes diversos del comportament de l'escalada
Considerem què passa en diferents circumstàncies si una acció conté diverses passes d'escalada.
| Estat | Comportament |
|---|---|
| L'equip en qüestió entra en manteniment després que s'enviï la notificació inicial del problema | Segons la configuració Aturar operacions per problemes esborrats a configuració de l'acció, totes les passes d'escalada restants s'executen amb un endarreriment causat pel període de manteniment o sense demora. Un període de manteniment no cancel·la les operacions. |
| El període de temps definit a la condició d'acció Període de temps acaba després d'enviar la notificació inicial | S'executen totes les passes d'escalada restants. La condició Període no pot aturar les operacions; té un efecte sobre quan s'inicien/no s'inicien les accions, no sobre les operacions. |
| Un problema comença durant el manteniment i continua (no es resol) després d'acabar el manteniment | Segons la configuració Pausa les operacions per a problemes esborrats a configuració de l'acció, totes les passes d'escalada s'executen tan aviat com acaba el manteniment o immediatament. |
| Un problema s'inicia durant un manteniment sense dades i continua (no es resol) després d'acabar el manteniment | Ha d'esperar que el trigger s'activi, abans d'executar qualsevol pas d'escalada. |
| Es segueixen i es superposen diferents escalades | L'execució de cada escalada nova substitueix l'escalada anterior, però almenys per a una passa d'escalada que encara s'executa a l'escalada anterior. Aquest comportament és rellevant en accions sobre esdeveniments que es creen amb l'avaluació de CADA problema del trigger. |
| Durant una escalada en curs (com l'enviament d'un missatge), depenent de qualsevol tipus d'esdeveniment: - l'acció és desactivada Depenent de l'esdeveniment trigger:< br>- l'activador és desactivat - equip o element és desactivat Segons un esdeveniment intern relacionat amb els triggers: - el trigger és desactivat Segons un esdeveniment intern relacionat amb els elements/regles de descoberta de baix nivell: - l'element és desactivat<br >- l'equip és desactivat |
S'envia el missatge actual i després s'envia un altre missatge sobre l'escalada. El missatge de seguiment contindrà el text de cancel·lació al principi del cos del missatge (NOTA: Escalada cancel·lada) indicant el motiu (p. ex. **NOTA: Escalada cancel·lada: acció '<Nom de l'acció>' desactivada). D'aquesta manera, s'avisa al destinatari que l'escalada s'ha cancel·lat i no es faran més passes. Aquest missatge s'envia a tothom que hagi rebut les notificacions abans. El motiu de la recuperació també es registra al fitxer de registre del servidor (des del nivell de depuració 3=Avís). Tingueu en compte que el missatge Escalada cancel·lada* també és enviat si les operacions s'han completat, però les operacions de recuperació són configurades i encara no s'executen. |
| Durant una escalada en curs (com ara enviar un missatge) l'acció s'esborra | No s'envien més missatges. La informació es registra al fitxer de registre del servidor (des del nivell de depuració 3=Avís), per exemple: escalada cancel·lada: acció id:334 esborrada |
Exemples d'escalada
Exemple 1
Enviament d'una notificació repetida cada 30 minuts (5 vegades en total) a un grup "Administradors de MySQL". Per configurar-lo:
- A la pestanya Operacions, establiu la durada predeterminada de la passa de l'operació a '30 m' (30 minuts)
- Estableix les passes d'escalada a De '1' A '5'
- Seleccioneu el grup "Administradors de MySQL" com a destinataris del missatge
Les notificacions s'enviaran a les 0:00, 0:30, 1:00, 1:30, 2:00 hores després de l'inici del problema (tret que, per descomptat, el problema es resolgui abans).
Si el problema es resol i es configura un missatge de recuperació, s'enviarà a aquells que hagin rebut almenys un missatge de problema en aquest escenari d'escalada.
Si el trigger que va generar una escalada activa és desactivat, Zabbix envia un missatge informatiu al respecte a tothom que ja hagi rebut notificacions.
Exemple 2
Enviament d'una notificació amb endarreriment sobre un problema de llarga data. Configura:
- A la pestanya Operacions, establiu la durada predeterminada de la passa de l'operació a "10 h" (10 hores)
- Estableix les passes d'escalada a De '2' A '2'
No s'enviarà una notificació fins a l'etapa 2 de l'escenari d'escalada o 10 hores després de l'inici del problema.
Podeu personalitzar el text del missatge amb alguna cosa com "El problema té més de 10 hores".
Exemple 3
Escala el problema al cap.
En el primer exemple anterior, hem configurat l'enviament de missatges programats als administradors de MySQL. En aquest cas, els administradors rebran quatre missatges abans que el problema s'escali al gestor de bases de dades. Tingueu en compte que el gestor només rebrà un missatge si encara no s'ha reconegut el problema, és a dir, ningú hi treballa.
Detalls de l'operació 2:
Tingueu en compte l'ús de la macro {ESC.HISTORY} al missatge personalitzat. La macro contindrà informació sobre totes les passes executades prèviament en aquesta escalada, com ara les notificacions enviades i les ordres executades.
Exemple 4
Un escenari més complex. Després de diversos missatges als administradors de MySQL i una escalada al responsable, Zabbix intentarà reiniciar la base de dades MySQL. Això passarà si el problema ha existit durant les 2:30 i no s'ha reconegut.
Si el problema persisteix, després de 30 minuts més, Zabbix enviarà un missatge a tots els usuaris convidats.
Si això no resol el problema, després d'una hora més Zabbix reiniciarà el servidor amb la base de dades MySQL (segona ordre remota) mitjançant ordres IPMI.
Exemple 5
Una escalada amb múltiples operacions assignades a una passa i intervals personalitzats emprats. La durada predeterminada de la passa d'operació és de 30 minuts.
Les notificacions s'enviaran de la següent manera:
- als administradors de MySQL 0:00, 0:30, 1:00, 1:30 després de l'inici del problema
- al gestor de bases de dades a les 2:00 i a les 2:10 després de l'inici del problema (no a les 3:00; com que les passes 5 i 6 es superposen amb la següent operació, la durada de la passa personalitzada més curta de 10 minuts a l'operació següent anul·la la més llarga. La durada de la passa d'1 hora s'ha intentat establir aquí)
- als administradors de Zabbix 2:00, 2:10, 2:20 després de l'inici del problema (la durada de la passa personalitzada de 10 minuts de feina)
- als usuaris convidats 4:00 hores després de l'inici de l'emissió (la durada de l'etapa predeterminada de 30 minuts es revertirà entre les etapes 8 i 11)