Zabbix се може користити за централизовано надгледање и анализу датотека евиденције са/без подршке за ротацију дневника.
Обавештења се могу користити за упозорење корисника када датотека евиденције садржи одређене низове или обрасце низова.
Да бисте надгледали датотеку евиденције морате имати:
Ограничење величине праћене датотеке евиденције зависи од подршка за велике датотеке.
Уверите се да у конфигурациони фајл агента:
Конфигуришите праћење дневника ставка.
Сва обавезна поља за унос су означена црвеном звездицом.
Конкретно за ставке праћења дневника које уносите:
. | . |
---|---|
* Type* | Изаберите Zabbix агент (активан) овде. |
* Key* | Користите један од следећих кључева ставке: ** log[]** или ** logrt[]: Ова два кључа ставке омогућавају праћење евиденција и филтрирање уноса дневника према редовном изразу садржаја, ако постоји. На пример : log[/var/log/syslog,error] . Уверите се да датотека има дозволе за читање за 'zabbix' корисника, иначе ће статус ставке бити подешен на 'неподржано'.log.count[]** или logrt.count[] : Ова два кључа ставке омогућавају да се врати само број одговарајућих линија. Погледајте подржану Zabbix агентску ставку одељак кључева за детаље о коришћењу ових кључева ставки и њихових параметара. |
Type of information | Унапред попуњено:<бр>За ставке дневника[] или logrt[] - Евиденција ;За log.count[] или logrt.count[] ставке – Нумерички (непотписани) .Ако опционо користите параметар излаз , можете ручно да изаберете одговарајући тип информација осим Евиденција .Имајте на уму да одабиром non-Log тип информација ће довести до губитка локалне временске ознаке. |
Update interval (in sec) | Параметар дефинише колико ће често Zabbix агент проверавати било какве промене у датотеци евиденције. Подешавање на 1 секунду ће осигурати да добијете нове записе што је пре могуће. |
Log time format | У овом пољу можете опционо да наведете образац за рашчлањивање временске ознаке линије дневника. Подржани чувари места: * y: Година (1970-2038) * М: Месец (01-12) * **d* : Дан (01-31) * h: Сат (00-23) * м: Минут (00-59) * s: Секунда (00-59)* Ако се остави празно, временска ознака ће бити постављена на 0 у Unix времену, што представља 1. јануар 1970. На пример, узмите у обзир следећи ред из датотеке евиденције Zabbix агента: " 23480:20100328:154718.045 Zabbix агент је покренут Zabbix 1.8.2 (ревизија 11211)." Почиње са шест позиција знакова за PID, праћено датумом, временом и остатком поруке. Формат времена дневника за ову линију. бити "pppppp:yyyyMMdd:hhmmss". Имајте на уму да су знакови "p" и ":" чувари места и могу бити било који знак осим "yMdhms". |
logrt[]
и Zabbix агент прати најновију од њих и ова најновија датотека евиденције је избрисана, порука упозорења"нема датотека које одговарају "<regexp mask>" у "<directory>"
је евидентиран Zabbix агент игнорише датотеке дневника са безвременским изменама од последњег времена модификације које је агент видео за logrt[]
ставку која се проверава.log[]
или logrt[]
има интервал ажурирања од 1 секунде, агент ће подразумевано анализирати не више од 200 записа датотеке дневника и неће послати више од 20 подударних записа у Zabbix сервер у једној провери. Повећањем MaxLinesPerSecond у конфигурационој датотеци агента или постављањем параметра ** maxlines** у кључу ставке, ограничење се може повећати до 10000 анализираних записа евиденције и 1000 одговарајућих записа послатих Zabbix серверу у једној провери. Ако је интервал ажурирања постављен на 2 секунде, ограничења за једну проверу би била постављена 2 пута већа него са интервалом ажурирања од 1 секунде.logrt
су подржани само у називу датотеке, подударање регуларних израза директоријума није подржано.logrt[]
постаје НЕПОДРЖАНОМ ако директоријум у којем је дневник датотеке за које се очекује да ће бити пронађене не постоје.logrt[]
не чини је ПОДРЖАНОМ. Грешке при читању датотека евиденције за ставку logrt[]
се евидентирају као упозорења у датотеку евиденције Zabbix агента, али не чине ставку НЕПОДРЖАНОМ.log[]
или logrt[]
ставка је постала НИЈЕ ПОДРЖАНА. Zabbix може да надгледа свој фајл дневника агента, осим када је на DebugLevel=4 or DebugLevel=5.\?
може довести до лажних позитивних резултата ако текстуална датотека садржи NUL симболе, јер су они замењени са "?" од стране Zabbix-а да настави обраду линије до знака за нови ред.Понекад ћемо можда желети да издвојимо само интересантну вредност из циљне датотеке уместо да враћамо цео ред када се пронађе подударање регуларног израза.
Ставке дневника имају могућност да издвоје жељене вредности из подударних линија. Ово се постиже додатним параметром излаз у ставкама log
и logrt
.
Коришћење параметра 'излаз' омогућава да назначимо "групу за снимање" подударања за које бисмо могли бити заинтересовани.
Дакле, на пример
log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]
треба да дозволи враћање уноса рачунај као што је пронађено у садржају:
Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) велика додела бафера резултата - /Дужина: 437136/Уноси: 5948/Верзија клијента: >=10/RPCI D: 555 : AUser/Form: CFG:ServiceLevelAgreement
Само број ће бити враћен јер се \1 односи на прву и једину групу за снимање: ([0-9]+). И, са могућношћу издвајања и враћања броја , вредност се може користити за дефинисање покретача.
Параметар 'maxdelay' у ставкама евиденције омогућава игнорисање неких старијих редова из датотека евиденције како би се најновији редови анализирали у року од 'maxdelay' секунди.
Одређивање 'maxdelay' > 0 може довести до занемаривања важних записа у фајлу евиденције и пропуштена упозорења. Користите га пажљиво на сопствени ризик само када је потребно.
Подразумевано ставке за праћење дневника прате све нове редове који се појављују у датотекама евиденције. Међутим, постоје апликације које у неким ситуацијама почну да пишу огроман број порука у своје датотеке евиденције. На пример, ако база података или DNS сервер нису доступни, такве апликације преплављују датотеке евиденције са хиљадама скоро идентичних порука о грешци док се нормалан рад не врати. Подразумевано, све те поруке ће бити пажљиво анализиране и одговарајуће линије ће бити послате серверу како је конфигурисано у ставкама log
и logrt
.
Уграђена заштита од преоптерећења се састоји од конфигурабилног параметра 'maxlines'' (штити сервер од превише долазних одговарајућих линија дневника ) и ограничење од 10*'maxlines'' (штити централну процесорску јединицу домаћина и И/О од преоптерећења од стране агента у једној провери). Ипак, постоје 2 проблема са уграђеном заштитом. Прво, велики број потенцијално не тако информативних порука се пријављује серверу и заузима простор у бази података. Друго, због ограниченог броја анализираних линија у секунди, агент може сатима заостајати за најновијим записима дневника. Сасвим је вероватно да бисте више волели да будете раније обавештени о тренутној ситуацији у датотекама евиденције уместо да сатима листате старе записе.
Решење за оба проблема је коришћење параметра 'maxdelay'. Ако је 'maxdelay' > 0, током сваке провере се мери број обрађених бајтова, број преосталих бајтова и време обраде. Из ових бројева агент израчунава процењено кашњење – колико секунди би било потребно да се анализирају сви преостали записи у датотеци евиденције.
Ако кашњење не прелази 'maxdelay' онда агент наставља са анализом датотеке евиденције као и обично.
Ако је кашњење веће него 'maxdelay', онда агент игнорише део датотеке евиденције тако што "скаче" преко њега на нову процењену позицију тако да преостали линије се могу анализирати у року од 'maxdelay' секунди.
Имајте на уму да агент чак ни не чита игнорисане линије у бафер, већ израчунава приближну позицију на коју ће скочити у датотеци.
Чињеница прескакања редова датотеке евиденције се евидентира у датотеци дневника агента овако:
14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0- 9].log",ERROR,,1000,,,120.0]"logfile:"/home/zabbix32/test1.log" skipping 679858 bytes(from byte 75653115 to byte 76332973) да би се испунило максимално кашњење
Број "до бајта" је приближно јер након "скока" агент прилагођава позицију у датотеци на почетак реда дневника који може бити даље у датотеци или раније.
У зависности од тога како се брзина раста упоређује са брзином анализе датотеке евиденције, можда ћете видети не " скокови", ретки или често "скокови", велики или мали "скокови", или чак мали "скок" у свакој провери. Флуктуације у оптерећењу система и кашњењу мреже такође утиче на израчунавање кашњења, а самим тим и на „скакање“ унапред да би се одржао корак са параметром "maxdelay".
Постављање "maxdelay" < 'интервал ажурирања' се не препоручује (може резултирати честим малим "скоковима").
logrt
са опцијом copytruncate
претпоставља да различите датотеке дневника имају различите записе (барем су њихове временске ознаке различите), стога ће MD5 суми почетних блокова (до првих 512 бајтова) бити различити. Две датотеке са истим MD5 збиром почетних блокова значе да је један од њих оригинал, а други - копија.
logrt
са опцијом copytruncate
чини напор да исправно обради копије датотека дневника без пријављивања дупликата. Међутим, ствари као што су прављење више копија датотека евиденције са истом временском ознаком, ротирање датотеке евиденције чешће од интервала ажурирања logrt[] ставке, често поновно покретање агента се не препоручују. Агент покушава да се носи са свим овим ситуацијама разумно добро, али добри резултати се не могу гарантовати у свим околностима.
Када се Zabbix агент покрене, прима листу активних провера са Zabbix сервера или проксија. За метрику дневника*[] прима обрађену величину дневника и време модификације за проналажење одакле да почне надгледање датотеке евиденције. У зависности од стварног дневника величина датотеке и време модификације које извештава систем датотека агент одлучује или да настави надгледање датотеке евиденције од обрађене величине дневника или да поново анализира датотеку евиденције од почетка.
Агент који ради одржава већи скуп атрибута за праћење свих праћених датотека дневника између провера. Ово стање у-меморији се губи када је агент заустављен.
Нови опциони параметар persistent_dir специфицира директоријум за складиштење овог стања евиденције[], log.count[], logrt[] или logrt.count[] у датотеци. Стање ставке дневника се враћа из трајне датотеке након што се Zabbix агент поново покрене.
Примарна употреба-случај је надгледање датотеке евиденције која се налази на пресликаном систему датотека. До неког тренутка, датотека евиденције се уписује у оба огледала. Затим се огледала деле. На активној копији датотека евиденције и даље расте, добијајући нове записе. Zabbix агент га анализира и шаље обрађену величину дневника и време модификације серверу. На пасивној копији датотека евиденције остаје иста, далеко иза активне копије. Касније се оперативни систем и Zabbix агент поново покрећу из пасивне копије. Величина обрађеног дневника и време модификације које Zabbix агент прима од сервера можда неће бити валидни за ситуацију на пасивној копији. Да би се наставило праћење датотеке евиденције са места где је агент престао у тренутку раздвајања огледала система датотека, агент враћа своје стање из трајне датотеке.
Приликом покретања Zabbix агент не зна ништа о трајним датотекама. Тек након што прими листу активних провера са Zabbix сервера (прокси), агент види да неке логичке ставке треба да буду подржане трајним датотекама у одређеним директоријумима.
Током рада агента, сталне датотеке се отварају за писање (fopen(filename, "w")) и замењен најновијим подацима. Шанса да изгубите трајне податке о датотеци ако се преписивање и огледало система датотека поделе у исто време је велика мала, без посебног руковања за то. Уписивање у трајну датотеку НЕ прати принудна синхронизација са медијумом за складиштење (fsync() се не позива).
Замена са најновијим подацима се врши након успешног извештавања о одговарајућем запису датотеке дневника или метаподацима ( обрађена величина дневника и време модификације) на Zabbix сервер. То се може десити онолико често колико свака ставка проверава да ли се датотека евиденције мења.
Нема посебних радњи током гашења агента.
Након што прими листу активних провера, агент означава застареле трајне датотеке за уклањање. Трајна датотека постаје застарела ако: 1) одговарајућа ставка дневника се више не надгледа, 2) ставка дневника је поново конфигурисана са другомpersistent_dir локацијом него пре.
Уклањање се врши са закашњењем од 24 сата јер датотеке евиденције у стању НЕПОДРЖАНЕ нису укључене у листу активних провера, али могу постати ПОДРЖАНЕ касније и њихове трајне датотеке ће бити корисне.
Ако је агент заустављен пре истека 24 сата, застареле датотеке неће бити избрисан јер Zabbix агент више не добија информације о својој локацији са Zabbix сервера.
Реконфигурисање дневника persistent_dir ставке назад на старуpersistent_dir локацију док је агент заустављен, без брисања старе трајне датотеке од стране корисника - узроковаће враћање стања агента из старе персистентне датотеке, што ће резултирати пропуштеним порукама или лажним упозорења.
Zabbix агент разликује активне провере по њиховим кључевима. На пример, logrt[/home/zabbix/test.log] и logrt[/home/zabbix/test.log,] су различите ставке. Измена ставке logrt[/хоме/заббик/тест.лог,, ,10] испред логрт[/home/zabbix/test.log,,,20] ће довести до брисања ставке логрт[/хоме/заббик/тест.лог,,,10] са агентове листе активних провера и креирање logrt[/home/zabbix/test.log,,,20] ставке (неки атрибути се преносе кроз модификације у корисничком интерфјесу /сервер, није у агенту).
Име датотеке се састоји од MD5 суме кључа ставке са додатком дужине кључа ставке да би се смањила могућност колизија. На пример, стање logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] ставка ће се чувати у трајној датотеци c963ade4008054813bbc0a650bb8e09266.
Више ставки дневника може да користи исту вредност persistent_dir.
persistent_dir се одређује узимајући у обзир специфичне распореде система датотека, тачке монтирања и опције монтирања и конфигурацију пресликавања складишта - трајна датотека треба да буде укључена исти пресликани систем датотека као и мониторедлог фајл.
Ако persistent_dir директоријум не може да се креира или не постоји, или права приступа Zabbix агенту не дозвољавају креирање/писање/читање/брисање датотека ставка дневника постаје НИЈЕ ПОДРЖАНА.
Ако се права приступа трајним датотекама складиштења уклоне током рада агента или се појаве друге грешке (нпр. диск је пун), онда се грешке пријављују у датотеку дневника агента, али ставка дневника не постаје НИЈЕ ПОДРЖАНА.
Трајна датотека ставке се ажурира након успешног слања сваке серије података (која садржи податке ставке) на сервер. На пример, подразумевана 'BufferSize' је 100. Ако је ставка дневника пронашла 70 одговарајућих записа, тада ће првих 50 записа бити послато у једном групна, упорна датотека ће бити ажурирана, а затим ће преосталих 20 записа бити послато (можда са неким закашњењем када више података се акумулира) у 2. групи, а трајна датотека ће бити поново ажурирана.
Свака одговарајућа линија из ставке log[]
и logrt[]
и резултат сваке провере ставке log.count[]`` и
logrt.count[]` захтева слободан слот у одређеној области од 50% у агенту послати бафер. Елементи бафера се редовно шаљу серверу (или проксију) и слотови бафера су поново слободни.
Док постоје слободни слотови у назначеној области дневника у баферу за слање агента и комуникација не успе између агента и сервера (или проксија), резултати праћења дневника се акумулирају у бафер за слање. Ово помаже у ублажавању кратких кварова у комуникацији.
Током дужих неуспеха комуникације, сви слотови дневника се заузму и предузимају се следеће радње:
log[]
и logrt[]
провере ставки се заустављају. Када је комуникација обновљена и слободни слотови у баферу су доступни, провере се настављају са претходне позиције. Ниједна линија која се подудара није изгубљена, само се пријављује касније.log.count[]
and logrt.count[]
провере се заустављају ако јеmaxdelay = 0
(подразумевано). Понашање је слично ставкама log[]
и logrt[]
као што је горе описано. Имајте на уму да ово може утицати на резултате log.count[]
и logrt.count[]
: на пример, једна провера броји 100 одговарајућих линија у датотеци евиденције, али пошто у баферу нема слободних места, провера је заустављена. Када се комуникација успостави, агент броји истих 100 одговарајућих линија и такође 70 нових одговарајућих линија. Агент сада шаље count = 170 као да су пронађени у једној провери.log.count[]
и logrt.count[]
провере са maxdelay > 0
: ако није било "скока" током провере, онда понашање је слично горе описаном. Ако је дошло до "скока" преко редова датотеке евиденције, позиција после "скока" се задржава и резултат изброја се одбацује. Дакле, агент покушава да одржи корак са растућом датотеком евиденције чак и у случају неуспеха комуникације.Ако регуларни израз који се користи у log[]
, logrt[]
, log.count[]
или logrt.count[]
не може да компајлира PCRE или PCRE2 библиотека, онда ставка прелази у стање НИЈЕ ПОДРЖАН са порука о грешци. Да бисте наставили са надгледањем ставке дневника, регуларни израз треба да буде поправљен.
Ако се регуларни израз успешно компајлира, али не успе у току извршавања (на неким или на свим записима дневника), онда ставка дневника остаје подржана и надгледање се наставља. Грешка у току извођења се евидентира у датотеци евиденције Zabbix агента (без записа датотеке евиденције).
Стопа евидентирања је ограничена на једну грешку током извршавања по провери да би се омогућило Zabbix агенту да надгледа сопствену датотеку евиденције.
На пример, ако се анализира 10 записа, а 3 записа не успеју са грешком у извршавању редовног израза, један запис се производи у дневнику агента.
Изузетак: ако је MaxLinesPerSecond=1 и интервал ажурирања=1 (само 1 запис је дозвољен за анализу по провери), онда се грешке извођења редовног израза не евидентирају.
zabbix_agentd евидентира кључ ставке у случају грешке током извршавања, zabbix_agent2 евидентира ID ставке да би помогао у идентификацији која ставка дневника има грешке током извођења. Препоручује се редизајн регуларног израза у случају грешака у току извршавања.