Documentation
Table of Contents
5 Escalaties
Overzicht
Met escalaties kunt u aangepaste scenario's maken voor het verzenden van meldingen of het uitvoeren van opdrachten op afstand.
In praktische termen betekent dit dat:
- Gebruikers direct op de hoogte kunnen worden gesteld van nieuwe problemen.
- Meldingen kunnen worden herhaald totdat het probleem is opgelost.
- Het verzenden van een melding kan worden vertraagd.
- Meldingen kunnen worden geëscaleerd naar een andere "hogere" gebruikersgroep.
- Opdrachten op afstand kunnen direct worden uitgevoerd of wanneer een probleem gedurende een lange periode niet is opgelost.
Acties worden geëscaleerd op basis van de escalatiestap. Elke stap heeft een tijdsduur.
U kunt zowel de standaard duur als een aangepaste duur van een individuele stap definiëren. De minimale duur van één escalatiestap is 60 seconden.
U kunt acties starten, zoals het verzenden van meldingen of het uitvoeren van opdrachten, vanuit elke stap. Stap één is voor onmiddellijke acties. Als u een actie wilt vertragen, kunt u deze toewijzen aan een latere stap. Voor elke stap kunnen meerdere acties worden gedefinieerd.
Het aantal escalatiestappen is niet beperkt.
Escalaties worden gedefinieerd bij het configureren van een operatie. Escalaties worden alleen ondersteund voor probleemoperaties, niet voor hersteloperaties.
Diverse aspecten van het escalatiegedrag
Laten we bekijken wat er in verschillende omstandigheden gebeurt als een actie meerdere escalatiestappen bevat.
| Situatie | Gedrag |
|---|---|
| Het betreffende host gaat in onderhoud nadat de initiële probleemmelding is verzonden | Afhankelijk van de instelling Operaties pauzeren voor onderdrukte problemen in de configuratie van de actie, worden alle resterende escalatiestappen uitgevoerd met ofwel een vertraging veroorzaakt door de onderhoudsperiode of zonder vertraging. Een onderhoudsperiode annuleert geen operaties. |
| De in de actieconditie Tijdsperiode gedefinieerde tijd eindigt nadat de initiële melding is verzonden | Alle resterende escalatiestappen worden uitgevoerd. De Tijdsperiode conditie kan geen operaties stoppen; het heeft effect met betrekking tot wanneer acties worden gestart/niet gestart, niet op operaties. |
| Een probleem begint tijdens onderhoud en gaat (niet opgelost) door na het einde van het onderhoud | Afhankelijk van de instelling Operaties pauzeren voor onderdrukte problemen in de configuratie van de actie, worden alle escalatiestappen uitgevoerd vanaf het moment dat het onderhoud eindigt of onmiddellijk. |
| Een probleem begint tijdens een geen-gegevens onderhoud en gaat (niet opgelost) door na het einde van het onderhoud | Het moet wachten tot de trigger wordt geactiveerd, voordat alle escalatiestappen worden uitgevoerd. |
| Verschillende escalaties volgen elkaar snel op en overlappen | De uitvoering van elke nieuwe escalatie vervangt de vorige escalatie, maar voor ten minste één escalatiestap die altijd wordt uitgevoerd op de vorige escalatie. Dit gedrag is relevant in acties bij gebeurtenissen die worden gecreëerd bij ELKE probleemevaluatie van de trigger. |
| Tijdens een escalatie in uitvoering (zoals een bericht dat wordt verzonden), gebaseerd op elk type gebeurtenis: - de actie wordt uitgeschakeld Gebaseerd op triggergebeurtenis: - de trigger wordt uitgeschakeld - de host of het item wordt uitgeschakeld Gebaseerd op interne gebeurtenis over triggers: - de trigger wordt uitgeschakeld Gebaseerd op interne gebeurtenis over items/low-level ontdekkingsregels: - het item wordt uitgeschakeld - de host wordt uitgeschakeld |
Het bericht dat bezig is wordt verzonden en dan wordt nog een bericht over de escalatie verzonden. Het opvolgende bericht heeft de annuleringstekst aan het begin van het bericht (bijvoorbeeld NOTE: Escalatie geannuleerd) met daarin de reden (bijvoorbeeld NOTE: Escalatie geannuleerd: actie '<Actienaam>' uitgeschakeld). Op deze manier wordt de ontvanger op de hoogte gebracht dat de escalatie is geannuleerd en dat er geen verdere stappen worden uitgevoerd. Dit bericht wordt verzonden naar iedereen die de meldingen eerder heeft ontvangen. De reden voor de annulering wordt ook vastgelegd in het serverlogbestand (beginnend vanaf Debugniveau 3=Warning). Merk op dat het Escalatie geannuleerd-bericht ook wordt verzonden als operaties zijn voltooid, maar hersteloperaties zijn geconfigureerd en nog niet zijn uitgevoerd. |
| Tijdens een escalatie in uitvoering (zoals een bericht dat wordt verzonden) wordt de actie verwijderd | Er worden geen berichten meer verzonden. De informatie wordt vastgelegd in het serverlogbestand (beginnend vanaf Debugniveau 3=Warning), bijvoorbeeld: escalation geannuleerd: actie id:334 verwijderd |
Escalatievoorbeelden
Voorbeeld 1
Het verzenden van een herhaalde melding elke 30 minuten (in totaal 5 keer) naar een groep genaamd "MySQL-beheerders". Om dit te configureren:
- Ga naar het tabblad Operaties en stel de Standaard duur van de operationele stap in op "30m" (30 minuten).
- Stel de escalatie Stappen in van "1" tot "5".
- Selecteer de groep "MySQL-beheerders" als de ontvangers van het bericht.
Meldingen worden verzonden om 0:00, 0:30, 1:00, 1:30, 2:00 uur nadat het probleem is gestart (tenzij het probleem natuurlijk eerder wordt opgelost).
Als het probleem wordt opgelost en een herstelmelding is geconfigureerd, wordt deze verzonden naar degenen die ten minste één probleemmelding hebben ontvangen binnen dit escalatiescenario.
Als de trigger die een actieve escalatie heeft gegenereerd wordt uitgeschakeld, stuurt Zabbix een informatief bericht hierover naar iedereen die al meldingen heeft ontvangen.
Voorbeeld 2
Het verzenden van een vertraagde melding over een langdurig probleem. Om dit te configureren:
- Ga naar het tabblad Operaties en stel de Standaard duur van de operationele stap in op "10h" (10 uur).
- Stel de escalatie Stappen in van "2" tot "2".
Een melding wordt alleen verzonden bij stap 2 van het escalatiescenario, dus 10 uur nadat het probleem is gestart.
U kunt de tekst van het bericht aanpassen naar iets als "Het probleem is meer dan 10 uur oud".
Voorbeeld 3
Het escaleren van het probleem naar de manager.
In het eerste voorbeeld hierboven hebben we periodieke berichtgeving geconfigureerd naar MySQL-beheerders. In dit geval zullen de beheerders vier berichten ontvangen voordat het probleem wordt geëscaleerd naar de databasemanager. Let op dat de manager alleen een bericht ontvangt als het probleem nog niet is erkend, vermoedelijk werkt niemand eraan.
Details van Operatie 2:
Let op het gebruik van de {ESC.HISTORY} macro in het aangepaste bericht. De macro bevat informatie over alle eerder uitgevoerde stappen in deze escalatie, zoals verzonden meldingen en uitgevoerde opdrachten.
Voorbeeld 4
Een complexer scenario. Na meerdere berichten naar MySQL-beheerders en escalatie naar de manager zal Zabbix proberen de MySQL-database opnieuw op te starten. Dit gebeurt als het probleem gedurende 2 uur en 30 minuten bestaat en het niet is bevestigd.
Als het probleem nog steeds bestaat, zal Zabbix na nog eens 30 minuten een bericht sturen naar alle gastgebruikers.
Als dit niet helpt, zal Zabbix na nog een uur de server opnieuw opstarten met de MySQL-database (tweede externe opdracht) met behulp van IPMI-opdrachten.
Voorbeeld 5
Een escalatie met meerdere acties toegewezen aan één stap en aangepaste intervallen gebruikt. De standaardduur van de operationele stap is 30 minuten.
Meldingen worden als volgt verzonden:
- Naar MySQL-beheerders om 0:00, 0:30, 1:00, 1:30 nadat het probleem begint.
- Naar de Databasebeheerder om 2:00 uur en 2:10 uur. (en niet om 3:00 uur; aangezien stappen 5 en 6 overlappen met de volgende operatie, overschrijft de kortere aangepaste stapduur van 10 minuten in de volgende operatie de langere stapduur van 1 uur die hier wordt geprobeerd in te stellen).
- Naar Zabbix-beheerders om 2:00, 2:10, 2:20 nadat het probleem begint (de aangepaste stapduur van 10 minuten werkt).
- Naar gastgebruikers om 4:00 uur nadat het probleem begint (de standaard stapduur van 30 minuten keert terug tussen stappen 8 en 11).