1 Uz trigeriem balstīta notikumu korelācija

Pārskats

Uz trigeriem balstīta notikumu korelācija ļauj korelēt atsevišķas problēmas, par kurām ziņo viens trigeris.

Lai gan parasti OK notikums var aizvērt visus problēmu notikumus, ko izveidojis viens trigeris, ir gadījumi, kad nepieciešama detalizētāka pieeja. Piemēram, uzraugot žurnālfailus, iespējams, vēlēsieties noteikt konkrētas problēmas žurnālfailā un aizvērt tās atsevišķi, nevis visas kopā.

Tas attiecas uz trigeriem, kuriem parametram PROBLEM event generation mode ir iestatīta vērtība Multiple. Šādi trigeri parasti tiek izmantoti žurnālu uzraudzībai, slazdu apstrādei utt.

Zabbix ir iespējams saistīt problēmu notikumus, pamatojoties uz tagiem. Tagi tiek izmantoti, lai iegūtu vērtības un izveidotu problēmu notikumu identifikāciju. Izmantojot to, problēmas var arī aizvērt atsevišķi, pamatojoties uz atbilstošu tagu.

Citiem vārdiem sakot, viens un tas pats trigeris var izveidot atsevišķus notikumus, kurus identificē notikuma tags. Tādēļ problēmu notikumus var identificēt pa vienam un aizvērt atsevišķi, pamatojoties uz identifikāciju pēc notikuma taga.

Kā tas darbojas

Žurnālu uzraudzībā jūs varat sastapt rindas, kas ir līdzīgas šīm:

Line1: Pakalpojums 1 apstājās
Line2: Pakalpojums 2 apstājās
Line3: Pakalpojums 1 tika restartēts
Line4: Pakalpojums 2 tika restartēts

Notikumu korelācijas ideja ir spēt sasaistīt problēmas notikumu no Line1 ar atrisinājumu no Line3 un problēmas notikumu no Line2 ar atrisinājumu no Line4, un aizvērt šīs problēmas pa vienai:

Line1: Pakalpojums 1 apstājās
Line3: Pakalpojums 1 tika restartēts #problēma no Line 1 aizvērta

Line2: Pakalpojums 2 apstājās
Line4: Pakalpojums 2 tika restartēts #problēma no Line 2 aizvērta

Lai to izdarītu, jums šie saistītie notikumi ir jāmarķē, piemēram, kā "Service 1" un "Service 2". To var izdarīt, piemērojot regulāro izteiksmi žurnāla rindai, lai iegūtu birkas vērtību. Pēc tam, kad notikumi tiek izveidoti, tiem attiecīgi tiek piešķirtas birkas "Service 1" un "Service 2", un problēmu var sasaistīt ar atrisinājumu.

Konfigurācija

Vienums

Lai sāktu, iespējams, vēlēsieties iestatīt vienumu, kas uzrauga žurnālfailu, piemēram:

log[/var/log/syslog]

Kad vienums ir iestatīts, uzgaidiet minūti, līdz tiek uztvertas konfigurācijas izmaiņas, un pēc tam dodieties uz Jaunākie dati, lai pārliecinātos, ka vienums ir sācis vākt datus.

Trigeris

Kad vienums darbojas, jums ir jākonfigurē trigeris. Svarīgi ir izlemt, kuri žurnālfaila ieraksti ir pelnījuši uzmanību. Piemēram, šāda trigeris izteiksme meklēs virkni, piemēram, 'Stopping', lai signalizētu par iespējamām problēmām:

find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1 

Lai pārliecinātos, ka katra rinda, kurā ir virkne "Stopping", tiek uzskatīta par problēmu, trigeris konfigurācijā iestatiet arī Problem event generation mode uz 'Multiple'.

Pēc tam definējiet atjaunošanas izteiksmi. Šāda atjaunošanas izteiksme atrisinās visas problēmas, ja žurnāla rindā tiks atrasta virkne "Starting":

find(/My host/log[/var/log/syslog],,"regexp","Starting")=1 

Tā kā mēs to nevēlamies, ir svarīgi kaut kā nodrošināt, ka attiecīgās pamatproblēmas tiek aizvērtas, nevis tikai visas problēmas. Šeit var palīdzēt tagošana.

Problēmas un atrisinājumus var saskaņot, norādot tagu trigeris konfigurācijā. Jāveic šādi iestatījumi:

  • Problem event generation mode: Multiple
  • OK event closes: All problems if tag values match
  • Ievadiet taga nosaukumu notikumu saskaņošanai

  • konfigurējiet tagus, lai no žurnāla rindām iegūtu taga vērtības

Ja konfigurācija ir veiksmīga, sadaļā Monitoring > Problems varēsiet redzēt problēmu notikumus, kas ir atzīmēti pēc lietojumprogrammas un saskaņoti ar to atrisinājumiem.

Tā kā ir iespējama nepareiza konfigurācija, ja līdzīgi notikumu tagi var tikt izveidoti nesaistītām problēmām, lūdzu, pārskatiet tālāk aprakstītos gadījumus!

  • Indeksētie makrosi vienmēr attiecas uz trigeris konfigurācijas lauku Expression, nevis uz Recovery expression. Piemēram, atjaunošanas notikumā {ITEM.VALUE1} tiks atrisināts uz pirmā vienuma jaunāko vērtību problēmas izteiksmē atjaunošanas brīdī. Ja atjaunošanas izteiksme ir balstīta uz citu vienumu un problēmas izteiksmes vienuma vērtība līdz atjaunošanas brīdim mainās, notikumiem būs atšķirīgi tagi, un tie netiks korelētīti.

  • Ja divas lietojumprogrammas raksta kļūdu un atjaunošanas ziņojumus vienā un tajā pašā žurnālfailā, lietotājs var nolemt izmantot divus service tagus vienā un tajā pašā trigeris ar atšķirīgām taga vērtībām, izmantojot atsevišķas regulārās izteiksmes taga vērtībās, lai no {ITEM.VALUE} makro iegūtu, piemēram, pakalpojuma A un pakalpojuma B nosaukumus (piem., ja ziņojumu formāti atšķiras). Tomēr tas var nedarboties, kā plānots, ja regulārajām izteiksmēm nav atbilstības. Neatbilstošas regex izteiksmes radīs tukšas taga vērtības, un pietiek ar vienu tukšu taga vērtību gan problēmas, gan OK notikumos, lai tos korelētu. Tādēļ atjaunošanas ziņojums no pakalpojuma A var nejauši aizvērt kļūdas ziņojumu no pakalpojuma B.

  • Faktiskie tagi un taga vērtības kļūst redzami tikai tad, kad trigeris nostrādā. Ja izmantotā regulārā izteiksme ir nederīga, tā tiek klusi aizstāta ar UNKNOWN virkni. Ja sākotnējais problēmas notikums ar UNKNOWN taga vērtību tiek palaists garām, vēlāk var parādīties OK notikumi ar to pašu UNKNOWN taga vērtību, kas var aizvērt problēmu notikumus, kurus tiem nevajadzēja aizvērt.

  • Ja lietotājs kā taga vērtību izmanto {ITEM.VALUE} makro bez makro funkcijām, tiek piemērots 255 rakstzīmju ierobežojums. Ja žurnāla ziņojumi ir gari un pirmās 255 rakstzīmes nav specifiskas, tas var arī radīt līdzīgus notikumu tagus nesaistītām problēmām.