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

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Учебник. На­блю­дай­те за тем, что про­ис­хо­дит в 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 до­бав­ля­ет в журнал иден­ти­фи­ка­тор про­цес­са, а за ни­ми сле­ду­ет со­об­ще­ние. |