LXF164: Мониторить сис­те­му

Текущая версия на 16:20, 30 октября 2018

Учебник. На­блю­дай­те за тем, что про­ис­хо­дит в Linux, с syslog-ng

[править] Жур­на­лы: Сле­дим за сис­те­мой

Есть та­кое ме­сто, где Linux пря­чет свои са­мые глу­бо­кие и тем­ные сек­ре­ты. Нейл Бот­вик бестрепетно за­гля­ды­ва­ет ту­да.

Наш эксперт. У Ней­ла Бот­ви­ка по ком­пь­ю­те­ру в ка­ж­дой ком­на­те, но он ни­по­чем не ска­жет вам, где на­хо­дит­ся цен­траль­ный сер­вер – по со­об­ра­же­ни­ям безо­пас­но­сти.

В ва­шей сис­те­ме есть ка­та­лог, ку­да вы, воз­мож­но, никогда не за­хо­ди­ли; но он жизнен­но необ­хо­дим и очень по­ле­зен, если что-то разладится. Это /var/log; в нем есть фай­лы жур­на­лов (они же – лог-фай­лы) поч­ти всех дей­ст­вий, про­ис­хо­дя­щих в сис­те­ме. Боль­шую часть опе­ра­ций журнали­ро­вания вы­пол­ня­ет сис­тем­ный лог­гер. Это фоновый де­мон, управ­ляющий за­пи­сью в лог-фай­лы – что по­зво­ля­ет не пи­сать в ка­ж­дой про­грам­ме свой код для ве­дения жур­на­лов: все они вы­зы­ва­ют одни и те же сис­тем­ные функ­ции. В Linux несколь­ко таких лог­ге­ров; они де­ла­ют поч­ти од­но и то же. Мы займемся syslog-ng, од­ним из са­мых по­пу­ляр­ных. Поч­ти все сказанное бу­дет верно для лю­бо­го из них.

За­чем ну­жен сис­тем­ный лог­гер? При­чи­ну мы уже на­зва­ли: что­б не дуб­ли­ро­вать код. Это так­же оз­на­ча­ет, что лог­гер мо­жет быть го­раз­до бо­лее гиб­ким и мощ­ным. Обыч­но он пи­шет все со­об­щения в один файл в ка­та­ло­ге /var/log (в слу­чае с syslog-ng – файл messages). Но это не един­ст­вен­ный ва­ри­ант: со­об­щения мож­но от­прав­лять в раз­ные фай­лы по раз­ным кри­те­ри­ям, и да­же пе­ре­на­прав­лять дру­го­му лог­ге­ру на дру­гой ком­пь­ю­тер.

Обыч­ная стро­ка из лог-фай­ла вы­гля­дит при­мер­но так:

Aug 16 16:54:51 hactar smartd[3191]: Device: /dev/sdc [SAT],SMART Usage Attribute: 194 Temperature_Celsius changed from 101 to 100

Ка­ж­дая запись в лог-фай­ле – это од­на стро­ка, на­чи­наю­щая­ся с да­ты и вре­мени; затем сле­ду­ют имя хоста и ко­ман­да. В дан­ном при­ме­ре это ко­ман­да smartd – де­мон, от­сле­жи­ваю­щий со­стояние же­ст­ко­го дис­ка, с иден­ти­фи­ка­то­ром про­цес­са 3191 (иден­ти­фи­ка­тор ука­зы­ва­ет­ся не для всех про­цес­сов, но для боль­шин­ст­ва). По­сле имени про­цес­са и иден­ти­фи­ка­то­ра идет двое­то­чие, а за ним – са­мо со­об­щение. Едино­го фор­ма­та со­об­щений нет: это то, что про­грам­ма от­прав­ля­ет лог­ге­ру. В этом при­ме­ре smartd со­об­ща­ет об из­менении тем­пе­ра­ту­ры од­но­го из же­ст­ких дис­ков. Зная, что де­ла­ет сис­тем­ный лог­гер, вы с его по­мо­щью смо­же­те от­сле­жи­вать про­ис­хо­дящее в ва­шей сис­те­ме. Од­на из нередких си­туа­ций – по­смот­реть, что идет не так при по­пыт­ке за­пуска про­грам­мы или ис­поль­зо­вания уст­рой­ст­ва. Ко­ман­да tail по­ка­зы­ва­ет де­сять по­следних строк фай­ла, но до­бавь­те па­ра­метр --follow, и она бу­дет по­ка­зы­вать но­вые стро­ки фай­ла; та­ким об­ра­зом, ко­ман­да

tail --follow /var/log/messages

бу­дет вы­во­дить но­вые со­об­щения по ме­ре их за­пи­си в лог-файл. Сис­тем­ный лог-файл час­то не име­ет досту­па на чтение для всех, и мо­жет по­на­до­бить­ся вы­полнить эту ко­ман­ду от имени су­пер­поль­зо­ва­те­ля-root или с пре­фик­сом sudo, ина­че ниче­го не уви­дишь. Для про­смот­ра, как это ра­бо­та­ет, за­пусти­те ко­ман­ду и вставь­те флэш­ку. Вы уви­ди­те сис­тем­ные со­об­щения о том, что об­на­ру­жен USB-диск, иден­ти­фи­ци­ро­ван как уст­рой­ст­во хранения дан­ных и про­чи­та­на его таб­ли­ца раз­де­лов. Имя про­цес­са в дан­ном слу­чае – kernel, так как го­ря­чее под­клю­чение уст­ройств об­ра­ба­ты­ва­ет­ся на­пря­мую ядром. Так как в фоне вы­пол­ня­ют­ся и дру­гие про­цес­сы, в вы­вод ко­ман­ды мо­гут по­пасть со­об­щения от лю­бо­го из них. От­фильт­ро­вать их мож­но с по­мо­щью grep. Ко­ман­да

tail --follow /var/log/messages | grep kernel:

ис­клю­чит все со­об­щения, в ко­то­рых нет сло­ва kernel: – за­вер­шаю­щее: необ­хо­ди­мо, что­бы вы­де­лить толь­ко со­об­щения от яд­ра.

[править] Соз­да­ем фильт­ры

По­ме­щать все со­об­щения в один файл – не всегда луч­ший ва­ри­ант. Не­ко­то­рые про­грам­мы генери­ру­ют мас­су со­об­щений, ко­то­рые луч­ше от­де­лить от прочих. Для это­го за­да­ют­ся пра­ви­ла фильт­ров в фай­ле /etc/syslog-ng/syslog-ng.conf. В нем ис­точники, мес­та на­зна­чения и фильт­ры пред­став­ле­ны объ­ек­та­ми, а свя­зы­ва­ют их за­пи­си в лог-фай­ле. В кон­фи­гу­ра­ции по умол­чанию стан­дарт­ный ис­точник оп­ре­де­ля­ет­ся так:

source src {

unix-stream(“/dev/log” max-connections(256));

internal();

file(“/proc/kmsg”);

};

Здесь соз­дан объ­ект ис­точника src, принимаю­щий за­пи­си жур­на­ла от раз­­ных ис­точников. За­тем оп­ре­де­лим мес­та на­зна­чения:

destination messages { file(“/var/log/messages”); };

destination console_all { file(“/dev/tty12”); };

Пер­вая стро­ка вы­во­дит за­пи­си в ука­зан­ный файл, вто­рая – в кон­соль. В этом мож­но убе­дить­ся, на­жав Ctrl + Alt + F12 или пе­рей­дя в стан­дарт­ную кон­соль вхо­да в сис­те­му 1 (Ctrl + Alt + F1 с ра­бо­че­го сто­ла) и за­тем на­жав Alt+стрел­ка вле­во. Ис­точник и ме­сто на­зна­чения готовы; те­перь оп­ре­де­лим фор­мат за­пи­сей, от­прав­ляе­мых с первого на второе. В кон­фи­гу­ра­ции по умол­чанию стан­дарт­ный ис­точник от­прав­ля­ет­ся в оба мес­та на­зна­чения.

log { source(src); destination(messages); };

log { source(src); destination(console_all); };

Здесь мож­но до­ба­вить но­вые ис­точники или мес­та на­зна­чения и фильт­ры, оп­ре­де­ляю­щие, что ку­да от­править. Вот при­мер, где вы­вод поч­то­во­го сер­ве­ра посылается в от­дель­ный файл mail.log:

destination d_mail { file(“/var/log/mail.log”); };

filter f_mail { facility(mail); };

filter f_notmail { not facility(mail); };

Стро­ки с ис­точником нет – мы все еще поль­зу­ем­ся стан­дарт­ным ис­точником. В ка­че­­ст­ве мес­та на­зна­чения за­да­ет­ся от­дель­ный лог-файл для поч­ты, а два фильт­ра с по­мо­щью функ­ции facility оп­ре­де­ля­ют, ка­кие со­об­щения при­хо­дят от поч­то­во­го сер­ве­ра. Есть несколь­ко стан­дарт­ных групп – на­при­мер, mail, auth или news (в до­ку­мен­та­ции есть пол­ный спи­сок), и при от­прав­ке со­об­щения про­цесс ука­зы­ва­ет од­ну из групп. Пре­иму­ще­ст­во та­ко­го под­хо­да в том, что не нуж­но знать имя про­цес­са: со­об­щения бу­дут от­фильт­ро­ва­ны для лю­бой поч­то­вой про­грам­мы. Вто­рой фильтр ра­бо­та­ет как от­ри­цание и вы­би­ра­ет все со­об­щения не от поч­ты. Име­на объ­ек­тов ис­точника (source), фильт­ра (filter) и мес­та на­зна­чения (destination) обыч­но пред­ва­ря­ют­ся пре­фик­са­ми s_, f_ и d_, что­бы бы­ло сра­зу по­нят­но, ка­кой объ­ект сле­ду­ет за пре­фик­сом. Те­перь за­меним пер­вые две стро­ки на сле­дую­щие:

log { source(src); filter(f_notmail); destination(messages); };

log { source(src); filter(f_mail); destination(d_mail); };

Те­перь ме­ж­ду ис­точником ме­стом на­зна­чения поя­вил­ся фильтр, и в лог-файл по­па­дут толь­ко должные со­об­щения. Не соз­дай мы фильт­ра notmail, оста­вив ис­ход­ную стро­ку, со­об­щения по­па­ли бы не толь­ко в лог-файл поч­ты, но и в лог-файл по умол­чанию. Но со­об­щения по-прежнему от­прав­ля­ют­ся в кон­соль, так как это­го мы не ме­ня­ли. При лю­бых из­менениях в кон­фи­гу­ра­ци­он­ном фай­ле нуж­но со­об­щить syslog-ng о том, что нуж­но пе­ре­чи­тать его, от­пра­вив ей сиг­нал SIGHUP та­ким об­ра­зом:

sudo killall -HUP syslog-ng

[править] Дер­жим это под кон­тро­лем

Ес­ли ваш корневой раз­дел (/) на­чал пе­ре­пол­нять­ся, про­верь­те со­дер­жи­мое /var. Вы­шед­ший из-под кон­тро­ля про­цесс мо­жет пи­сать в свой лог-файл ог­ром­ный объ­ем дан­ных, бы­ст­ро съе­дая цен­ное ме­сто на дис­ке. Это од­на из при­чин, по ко­то­рым многие пред­по­чи­та­ют раз­ме­щать /var на от­дель­ном раз­де­ле. Пере­полнение раз­де­ла / способно вызвать нехорошие по­след­ст­вия для сис­те­мы.

Со вре­менем со­дер­жи­мое ка­та­ло­га /var/log бу­дет отнимать все боль­ше мес­та на дис­ке. Что­бы ре­шить эту про­бле­му, уста­но­вим logrotate. Она за­пуска­ет cron, обыч­но раз в день, и ар­хи­ви­ру­ет лог-фай­лы в со­от­вет­ст­вии с пра­ви­ла­ми в /etc/logrotate.conf и /etc/logrotate.d. /etc/logrotate.conf – об­щий кон­фи­гу­ра­ци­он­ный файл, а в /etc/logrotate.d на­хо­дят­ся от­дель­ные на­бо­ры пра­вил, при­ме­няе­мые к кон­крет­ным па­ке­там или лог-фай­лам. В об­щем кон­фи­гу­ра­ци­он­ном фай­ле на­хо­дят­ся на­строй­ки вро­де

weekly

rotate 4

create

compress

ко­то­рые оз­на­ча­ют, что по умол­чанию лог-фай­лы ар­хи­ви­ру­ют­ся еженедель­но, хранит­ся до че­ты­рех по­следних ко­пий, при ар­хи­ви­ро­вании те­ку­ще­го соз­да­ет­ся но­вый пустой файл, и что фай­лы сжи­ма­ют­ся. На прак­ти­ке это оз­на­ча­ет, что основ­ной лог-файл messages упа­ко­вы­ва­ет­ся в messages.1.gz и соз­да­ет­ся но­вый пустой файл messages. При сле­дую­щей ар­хи­ва­ции messages.1.gz пе­ре­име­но­вы­ва­ет­ся в messages.2.gz и соз­да­ет­ся но­вый messages.1.gz. Чет­вер­тый файл уда­ля­ет­ся, что­бы рас­чис­тить до­ро­гу осталь­ным. К па­ра­мет­рам мож­но до­ба­вить dateext, и вме­сто цифр 1, 2 и 3 к име­нам фай­лов бу­дет до­бав­лять­ся да­та. Файл для syslog-ng в /etc/logrotate.d бу­дет вы­гля­деть при­мер­но так:

/var/log/messages {

postrotate

/etc/init.d/syslog-ng reload > /dev/null 2>&1 || true

endscript

}

Здесь указыва­ют­ся ар­хи­ви­руе­мый файл (его имя мо­жет за­да­вать­ся шаб­ло­ном) и пра­ви­ла. В дан­ном слу­чае един­ст­вен­ное пра­ви­ло, осо­бен­ное для это­го фай­ла – ко­ман­да postrotate, вы­пол­няе­мая по­сле за­вер­шения ар­хи­ва­ции, что­бы syslog-ng пе­ре­чи­тал кон­фи­гу­ра­ци­он­ный файл. Это так­же снима­ет бло­ки­ров­ку со ста­ро­го лог-фай­ла и от­кры­ва­ет но­вый. Здесь мож­но ука­зать лю­бые па­ра­мет­ры из гло­баль­но­го фай­ла что­бы пе­ре­за­гру­зить их. На­при­мер, мож­но хранить бо­лее длин­ную ис­то­рию для кон­крет­но­го лог-фай­ла, вклю­чив па­ра­метр:

rotate 8

Ес­ли вас бес­по­ко­ит не­по­мер­ное уве­ли­че­ние раз­ме­ра лог-фай­лов, ко­гда пошедшая вразнос про­грам­ма бу­дет пи­сать ту­да слиш­ком мно­го со­об­ще­ний, до­бавь­те па­ра­метр

maxsize 10M

для при­ну­ди­тель­ной ар­хи­ва­ции при дости­жении раз­ме­ра фай­ла в 10 МБ, да­же ес­ли вре­мя ар­хи­ва­ции еще не при­шло. Об­ра­ти­те внимание, что это про­изой­дет толь­ко при за­пуске за­дания cron, по­это­му файл мо­жет успеть стать на­мно­го боль­ше. Од­на­ко лог-фай­лы хо­ро­шо сжи­ма­ют­ся, и сжа­тие раз­бух­ше­го фай­ла высво­бо­ж­да­ет мно­го сво­бод­но­го мес­та.

Про­смат­ри­вать лог-фай­лы вруч­ную не обя­за­тель­но: есть про­грам­мы, ко­то­рые про­ана­ли­зи­ру­ют их и сфор­ми­ру­ют от­чет. Та­кие про­грам­мы как logwatch (www.logwatch.org) и logcheck (http://packages.debian.org/sid/logcheck) про­сканиру­ют сис­тем­ные лог-фай­лы и от­пра­вят вам от­чет с пре­ду­пре­ж­дения­ми о лю­бых ано­ма­ли­ях. Есть и про­грам­мы, ко­то­рые стро­ят диа­грам­мы для лог-фай­лов кон­крет­ных прило­жений – на­при­мер, диа­грам­мы тра­фи­ка че­рез Apache.

По­ка мы го­во­ри­ли толь­ко о чтении лог-фай­лов, но ко­ман­дой logger в сис­тем­ный лог мож­но за­пи­сать дан­ные и из обо­лоч­ки (или скрип­та), при­мер­но так:

logger -i -t myscript “Ваш скрипт рух­нул”

Па­ра­метр -t по­ме­ча­ет за­пись, па­ра­метр -i до­бав­ля­ет в журнал иден­ти­фи­ка­тор про­цес­са, а за ни­ми сле­ду­ет со­об­ще­ние. |