Автоматичне очищення логів IIS за допомогою PowerShell

Веб сервер IIS (Internet Information Services) у процесі роботи генерує досить багато логів, які пишуться у файли журналів. Основна проблема в тому, що за промовчанням журнали IIS розташовані на системному диску, і згодом файли логів можуть забити все доступне місце на диску і роботу сервера буде паралізовано. Наприклад, у моєму випадку на Exchange Server 2013 з майже 1000 ящиків, IIS генерує за день лог-файл близько 200 Мб. Таким чином, за рік файли логів IIS займатимуть 70 Гб дискового простору. Чи можна якось керувати цим процесом?

У IIS відсутня вбудована процедура ротації логів IIS, тому адміністраторам доводиться вигадувати власні схеми для автоматичної ротації або видалення журналів IIS на веб серверах.

Насамперед адміністратор повинен у принципі вирішити, чи потрібні взагалі логи, які генерує IIS. Якщо питання негативне – ведення журналів ліг можна відключити в налаштуваннях сайту в консолі Internet Information Services (IIS) Manager у розділі Logging. У деяких випадках також застосовується перенесення файлів журналів із системного диска на диск із даними/виділений диск. Для цього в тому самому розділі достатньо змінити шлях до каталогу LogFiles.

За промовчанням, у Windows Server 2003 логи IIS зберігаються в папці %windir%\system32\LogFiles\ та у Windows Server 2008 / 2012 /R2 у папці %SystemDrive%\inetpub\logs\LogFiles\.

У разі вичерпання вільного місця на системному диску, адміністратор судорожно намагається знайти чим забитий диск, і благополучно не звертає увагу на каталог inetpub, т.к. здавалося б його розмір незначний.Проблема в тому, що за замовчуванням у адміністратора немає прав на перегляд стандартних каталогів усередині папки inetpub, і таким чином провідник Windows не показує реального розміру вкладених папок.

Якщо спробувати відкрити каталог %SystemDrive%\inetpub\logs\LogFiles, підтверджуючи призначення необхідних дозволів (або запустити провідник з правами адміністратора), можна побачити, що розмір папки з логами насправді досить великий.

Як правило, можна безпечно видалити всі файли логів старше 3-7 днів. Це можна зробити вручну (не найкращий варіант), або автоматично за допомогою скрипт PowerShell який видалятиме старі лог файли за розкладом.

Простий PowerShell скрипт, який рекурсивно видаляти файли з розширенням *.log з каталогу C:\inetpub\logs може бути таким:

gci 'C:\inetpub\logs -Include '*.log' -Recurse | ? LastWriteTime -LT (Get-Date).AddDays(-7) | Remove-Item

Для автоматичного запуску скрипта можна створити таке завдання у планувальнику (Task Scheduler):

Порада. Ще один спосіб "швидко" зменшити розмір балок, коли видаляти їх з якихось причин не можна - включити NTFS стиск на каталозі з балками. Т.к. логи являють собою прості текстові файли, тиснуться вони досить сильно (в 4-5 разів). Щоб увімкнути компресію NTFS, відкрийте властивості папки з логами і натисніть кнопку Advanced. Позначте галку Compress contents to save disk space та двічі натисніть OK.

Як вимкнути логування ubuntu

Вчасно налаштоване журналування дозволяє уникнути несподіваних проблем з веб-сервером. Інформація, що зберігається в логах (або журналах) сервера, допомагає швидко оцінити ситуацію та усунути помилки.

Цей посібник знайомить з можливостями журналу Nginx і призначеними для цього інструментами.

Примітка: цей посібник призначений для Ubuntu 12.04, але будь-який сучасний дистрибутив буде працювати аналогічним чином.

Директива error_log

Для керування логами веб-сервер Nginx використовує декілька спеціальних директив. Одна з основних директив – error_log.

Синтаксис error_log

Директива error_log має наступний синтаксис:

error_log log_file [log_level]

У прикладі log_file вказує файл, до якого записуватимуться дані, а log_level задає найнижчий рівень логування.

Рівні логування

Директиву error_log можна налаштувати для логування певної кількості інформації. Існують такі рівні логування:

• emerg: критична ситуація, аварійний збій, система перебуває у неробочому стані.
• alert: складна передаварійна ситуація, необхідно терміново вжити заходів.
• crit: критичні проблеми, які потрібно вирішити.
• error: сталася помилка.
• warn: попередження; у системі щось сталося, але причин для занепокоєння немає.
• notice: система гаразд, але варто звернути увагу до її стан.
• info: важлива інформація, яку слід прийняти до відома.
• Debug: інформація для налагодження, яка допоможе визначити проблему.

Чим вищий рівень знаходиться в цьому списку, тим вищий його пріоритет. Логи фіксують зазначений рівень логування, а також усі рівні з вищим пріоритетом. Наприклад, якщо вибрати рівень error, логи фіксуватимуть рівні error, crit, alert та emerg.

Щоб дізнатися, як ця директива використовується, відкрийте головний конфігураційний файл.

sudo nano /etc/nginx/nginx.conf
. . .
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
. . .

Щоб директива error_log не фіксувала жодних даних, надішліть її висновок /dev/null.

error_log /dev/null crit;

У цей модуль також включено кілька інших директив, що допомагають налаштовувати логістики.

Директива log_format

Директива log_format визначає формат запису лога за допомогою простого тексту та змінних.

Формат, який використовує Nginx, називається комбінованим.Цей загальний формат використовується багатьма серверами. Він має такий вигляд:

log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

Визначення цієї директиви охоплює кілька рядків і закінчується крапкою з комою (;).

Фрагменти, які починаються із символу $, задають змінні; символи тире та квадратних дужок ([ і ]) сприймаються буквально.

Загальний синтаксис команди:

log_format format_name string_describing_formatting;

Директива access_log

Синтаксис директиви access_log схожий на синтаксис error_log, але він гнучкіший. Ця директива використовується для налаштування логів користувача.

access_log /path/to/log/location [ format_of_log buffer_size ];

Стандартним форматом директиви access_log є combined (як і log_format). Можна використовувати будь-який формат, визначений у log_format.

Фрагмент команди buffer_size визначає максимальний обсяг даних, які зберігає сервер Nginx, перш ніж внести їх у лог. Щоб налаштувати стиснення лог-файлу, потрібно додати директиву gzip:

access_log location format gzip;

На відміну від error_log, директиву access_log можна просто вимкнути:

Її висновок не обов'язково перекладати /dev/null.

Ротація логів

Щоб уникнути заповнення дискового простору, необхідно використовувати механізми логування в міру зростання лог-файлів. Ротація логів – це процес, що передбачає відключення застарілих чи надто об'ємних лог-файлів та його архівування (на встановлений період).

Сервер Nginx не надає інструментів керування лог-файлами, але дозволяє використовувати механізми, що спрощують ротацію логів.

Ротація логів вручну

Щоб запустити ротацію логів вручну (або створити скрипт для запуску ротації), виконайте команди:

mv /path/to/access.log /path/to/access.log.0
kill -USR1 `cat /var/run/nginx.pid`
sleep 1
[ post-rotation processing of old log file ]

Тобто спочатку потрібно перемістити поточний лог у новий файл для зберігання. В імені нового лог-файлу прийнято використовувати суфікс 0, в імені старішого - суфікс 1, і т.д.

Команда, яка виконує ротацію логів:

kill -USR1 /var/run/nginx.pid

Насправді вона не зупиняє процес Nginx, а надсилає йому сигнал, що перезавантажує лог-файли. Отже, нові запити потраплять до оновленого лог-файлу.

У файлі /var/run/nginx.pid веб-сервер зберігає pid головного процесу. Цей файл вказується в конфігураційному файлі у рядку, який починається з pid:

sudo nano /etc/nginx/nginx.conf
. . .
pid /path/to/pid/file;
. . .

Після виконання ротації потрібно запустити команду:

Ця команда дозволяє процесу завершити перехід. Після цього можна заархівувати старий лог-файл.

Утиліта logrotate

logrotate – це звичайна програмка для ротації логів. Її можна знайти у репозиторії Ubuntu. Крім того, Nginx поставляється в Ubuntu з користувальницьким скриптом logrotate.

Щоб переглянути сценарій, введіть:

sudo nano /etc/logrotate.d/nginx

Перший рядок у файлі визначає точку системи, до якої будуть застосовуватись усі наступні рядки. Майте на увазі, якщо вирішите змінити розташування логів у конфігураційних файлах Nginx.

Інші рядки файлу виконуватимуть щоденну ротацію заданого файлу, а також зберігатимуть 52 застарілі його копії. На жаль, цей посібник не охоплює загальні налаштування logrotate.

Як бачите, розділ postrotate містить команду, яка схожа на ту, що була використана при ручній ротації логів:

postrotate
[! -f /var/run/nginx.pid] || kill -USR1 `cat /var/run/nginx.pid`
endscript

Цей розділ перезавантажує лог-файли Nginx після ротації.

Висновок

Звісно, ​​це керівництво охоплює лише основи логування.

Також дуже важливо стежити за логами сервера, щоб випадково не наразити на небезпеку конфіденційну інформацію.

Веб-сервер Apache може надавати адміністратору багато корисної інформації про свою роботу, а також проблеми та помилки, які потрібно усунути.

Вчасно налаштоване журналування дозволяє уникнути несподіваних проблем з веб-сервером. Інформація, що зберігається в логах (або журналах) сервера, допомагає швидко оцінити ситуацію та усунути помилки. Apache надає дуже гнучкий механізм журналування.

Даний посібник знайомить з можливостями журналування Apache та призначеними для цього інструментами.

У цьому посібнику використовується Apache2 на сервері Ubuntu 12.04, але інструкції підійдуть і для інших дистрибутивів.

Рівні логування

Існують такі рівні логування:

• emerg: критична ситуація, аварійний збій, система перебуває у неробочому стані.
• alert: складна передаварійна ситуація, необхідно терміново вжити заходів.
• crit: критичні проблеми, які потрібно вирішити.
• error: сталася помилка.
• warn: попередження; у системі щось сталося, але причин для занепокоєння немає.
• notice: система гаразд, але варто звернути увагу до її стан.
• info: важлива інформація, яку слід прийняти до відома.
• Debug: інформація для налагодження, яка допоможе визначити проблему.
• trace7: Трасування інформації різних рівнів деталізації.

При налаштуванні логування задається менш важливий рівень, який необхідно вносити в балку. Що це означає? Логи фіксують зазначений рівень логування, а також усі рівні з вищим пріоритетом. Наприклад, якщо вибрати рівень error, логи фіксуватимуть рівні error, crit, alert та emerg.

Для встановлення рівня логування існує директива LogLevel. За замовчуванням рівень логування заданий у стандартному конфігураційному файлі:

sudo nano /etc/apache2/apache2.conf
. . .
LogLevel warn
. . .

Де є логі Apache?

Apache може розмістити свої логи за допомогою загальносерверних налаштувань ведення логів. Також можна налаштувати індивідуальне логування кожного окремого віртуального хоста.

Загальносерверні налаштування логування

Щоб дізнатися, де є стандартні логи сервера, відкрийте конфігураційний файл. У Ubuntu це /etc/apache2/apache2.conf:

sudo nano /etc/apache2/apache2.conf

Знайдіть у файлі рядок:

Щоб дізнатися про змінну APACHE_LOG_DIR, відкрийте файл envvars:

sudo nano /etc/apache2/envvars
. . .
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
. . .

Згідно з цим файлом, змінна APACHE_LOG_DIR налаштована на каталог /var/log/apache2. Це означає, що Apache з'єднає це значення з директивою в конфігураційному файлі apache2.conf і вноситиме дані в лог /var/log/apache2/error.log.

sudo ls /var/log/apache2
access.log error.log other_vhosts_access.log

Як бачите, тут знаходиться лог помилок error.log і кілька інших логів.

Логування віртуальних хостів

Файл access.log, згаданий наприкінці попереднього розділу, не налаштовується у файлі apache2.conf. Натомість розробники помістили відповідну директиву у файл віртуального хоста.

Відкрийте та перегляньте стандартний віртуальний хост:

sudo nano /etc/apache2/sites-available/default

Перейдіть до файлу та знайдіть наступні три значення, пов'язані з логуванням:

Місцезнаходження ErrorLog збігається з визначенням у стандартному конфігураційному файлі. Цей рядок не обов'язково повинен перебувати у двох окремих файлах; при зміні місцезнаходження цього лога в одному файлі помилки не виникне.

Користувальницькі логи

У попередньому розділі рядок, який описує access.log, використовує не таку директиву, як попередні рядки для налаштування логів. Вона використовує CustomLog:

CustomLog $/access.log combined

Ця директива має такий синтаксис:

CustomLog log_location log_format

У разі log_format (формат логів) є комбінованим (combined). Ця специфікація не є внутрішньою специфікацією Apache; вона задає формат користувача, який визначений у конфігураційному файлі за замовчуванням.

Знову відкрийте конфігураційний файл за замовчуванням та знайдіть рядок, який визначає формат combined:

sudo nano /etc/apache2/apache2.conf
. . .
LogFormat %h %l %u %t %r %>s %O \"i\" \"%i\" combined
. . .

Команда LogFormat визначає формат користувача логів, що викликаються директивою CustomLog.

Цей формат називається комбінованим (combined).

Примітка: Докладніше про доступні формати можна дізнатися тут.

Існує ще кілька поширених форматів, які можна використовувати для визначення віртуальних хостів. Можна також створювати власні формати.

Ротація логів Apache

Ротація логів – це процес, що передбачає відключення застарілих чи надто об'ємних лог-файлів та його архівування (на встановлений період). Apache може вносити в лог досить великі обсяги даних, отже, щоб уникнути заповнення дискового простору, необхідно налаштувати ротацію логів.

Ротація ліг може бути дуже простою (як, наприклад, відключення занадто великих ліг), а може мати і більш складну конфігурацію (тобто, функціонувати як система архівування та зберігання старих ліг).

Розглянемо методи настроювання ротації логів Apache.

Ротація логів вручну

Не можна переміщати логи під час роботи Apache. Тобто, щоб перемістити в архів застарілі або заповнені логи та замінити їх на нові, потрібно перезапустити сервер.

Це можна зробити вручну. Для цього потрібно перемістити застарілі файли, а потім, перезапустивши Apache, оновити налаштування веб-сервера та змусити його використовувати нові логи.

Нижче наведено приклад із документації Apache. Можливо, доведеться додати на початок цих команд sudo.

mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
[post-processing of log files]

Ці команди перемістять файли, перезапустять сервер і скажуть йому зачекати 600 секунд. Таким чином, Apache зможе використовувати старі лог-файли, щоб завершити реєстрацію старих запитів. Протягом цього часу нові запити будуть записані до нових лог-файлів.

Майте на увазі: ротація логів вручну дуже ненадійна у великих серверних середовищах.

Утиліта logrotate

За замовчуванням система Ubuntu налаштовує ротацію логів за допомогою logrotate утиліти.

Ця програма може виконувати ротацію логів за дотримання певних критеріїв. Переглянути події, які включають Logrotate для ротації логів, можна у файлі /etc/logrotate.d/apache2:

sudo nano /etc/logrotate.d/apache2

У ньому є кілька параметрів logrotate. Зверніть увагу на перший рядок:

Це означає, що logrotate буде виконувати ротацію лише тих логів, які знаходяться у /var/log/apache2. Майте на увазі, якщо ви вибрали інший каталог для зберігання в конфігурації Apache.

Як бачите, логи ротуються щотижня. Також тут є розділ коду, що перезапускає Apache після ротації:

postrotate
/etc/init.d/apache2 reload > /dev/null
endscript

Ці рядки автоматично перезапускають веб-сервер Apache після завершення ротації.

Примітка: На жаль, налаштування файлу не охоплені в цьому посібнику.

Ротація логів каналами

Використання каналів замість файлів – простий спосіб передати обробку виведення програмі логування. Це також вирішує проблему ротації балок, оскільки ротація може виконуватися за допомогою програми на серверній стороні (а не самим сервером Apache).

Щоб логи оброблялися програмою логування, яка приймає стандартний висновок, замініть наступний рядок таким чином:

CustomLog "|logging_program logging_program_parameters"

Apache запустить програму логування під час завантаження та перезапустить її у разі помилки або збою.

Для ротації ліг можна використовувати різні програми, але за замовчуванням Apache поставляється з rotatelogs. Щоб налаштувати цю програму, використовуйте:

CustomLog "| /path/to/rotatelog /path/of/log/to/rotate number_of_seconds_between_rotations" log_level

Аналогічну конфігурацію можна створити й інших програм.

Висновок

Звичайно, цей посібник охоплює тільки основи логування Apache.

Також дуже важливо стежити за логами сервера, щоб випадково не наразити на небезпеку конфіденційну інформацію.

Адміністраторам Linux часто потрібно заглядати в лог-файл для усунення несправностей. По суті, це дія першої необхідності будь-якого адміну.

Цей посібник розглядає різні частини механізму журналування Linux.

Примітка: Команди цього посібника були протестовані на простих установках CentOS 6.4, Ubuntu 12 та Debian 7.

Стандартні логи

За промовчанням журнали Linux зберігаються в /var/log.

Щоб переглянути список журналів у цьому каталозі, використовуйте ls -l /var/log.

У системі CentOS це виглядає так:

Перегляд логів

У каталозі /var/log є кілька загальних журналів:

• wtmp
• utmp
• dmesg
• messages
• maillog або mail.log
• spooler
• auth.log або secure

Файли wtmp і utmp відслідковують користувачів, що увійшли та залишили систему. Вміст даних журналів не можна читати за допомогою простої команди cat, для цього є спеціальні команди, з якими тепер потрібно ознайомитися.

Щоб дізнатися, хто зараз знаходиться на сервері Linux, потрібно використовувати команду «who». Вона отримує інформацію з /var/run/utmp (CentOS і Debian) або /run/utmp (Ubuntu).

Це приклад її роботи у CentOS:

Команда "sysadmin" виводить історію входу користувачів:

У цьому прикладі потрібно було одержати історію входу користувача sysadmin. Як можна бачити, було кілька випадків, коли він приводив до збою системи.

Щоб дізнатися час останнього перезавантаження системи, використовуйте наступну команду:

Результат має приблизно такий вигляд:

reboot system boot 2.6.32-358.el6.x Mon Dec 9 10:27 - 10:47 (00:19)
reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:37 - 10:47 (2+18:10)
reboot system boot 2.6.32-358.el6.x Fri Dec 6 16:28 - 16:36 (00:08) reboot system boot 2.6.32-358.el6.x Fri Dec 6 11:06 - 16:36 ( 05:29)
reboot system boot 2.6.32-358.el6.x Mon Dec 2 17:00 - 16:36 (3+23:36)
reboot system boot 2.6.32-358.el6.x Fri Nov 29 16:01 - 16:36 (7+00:34)
reboot system boot 2.6.32-358.el6.x Fri Nov 29 15:43 - 16:36 (7+00:53)
.
.
wtmp begins Fri Nov 15 16:11:54 2013

Щоб дізнатися про час останнього входу в систему, використовуйте lastlog:

Результат на CentOS виглядає приблизно так:

Username Port From Latest
root tty1 Mon Dec 9 10:44:30 +1100 2013
bin **Never logged in**
daemon **Never logged in**
adm **Never logged in**
lp **Never logged in**
sync **Never logged in**
shutdown **Never logged in**
halt **Never logged in**
mail **Never logged in**
uucp **Never logged in**
operator **Never logged in**
games **Never logged in**
gopher **Never logged in**
ftp **Never logged in**
nobody **Never logged in**
vcsa **Never logged in**
saslauth **Never logged in**
postfix **Never logged in**
sshd **Never logged in**
sysadmin pts/1 10.0.2.2 Mon Dec 9 10:31:50 +1100 2013
dbus **Never logged in**
joeblog pts/2 10.0.2.2 Mon Dec 9 10:39:24 +1100 2013

Для перегляду текстових журналів можна використовувати команди «cat», «head» або «tail».

У цьому прикладі наведено останні 10 рядків журналу /var/log/messages на Debian:

$ sudo tail /var/log/messages

Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Dec 16 01:21:08 debian kernel: [ 9.584074] Bluetooth: BNEP filters: protocol multicast
Dec 16 01:21:08 debian kernel: [ 9.648220] Bridge firewalling registered
Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO (Voice Link) ver 0.6
Dec 16 01:21:08 debian kernel: [ 9.696728] Bluetooth: SCO socket layer initialized
Dec 16 01:21:08 debian kernel: [ 9.832215] lp: driver loaded but no devices found
Dec 16 01:21:08 debian kernel: [ 9.868897] ppdev: user-space parallel port driver
Dec 16 01:21:11 debian kernel: [ 12.748833] [drm] Initialized drm 1.1.0 20060810
Dec 16 01:21:11 debian kernel: [ 12.754412] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11
Dec 16 01:21:11 debian kernel: [ 12.754412] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0

Демон rsyslog

Конфігураційний файл rsyslog

Демон rsyslog отримує конфігурації з файлу rsyslog.conf, який знаходиться в каталозі /etc.

Цей файл можна знайти в rsyslog.d/50-default.conf в Ubuntu.

Під двома частинами рядків маються на увазі селектор і дія (selector та action). Вони поділяються символом пробілу.

Ось уривок із файлу rsyslog.conf на CentOS:

Щоб зрозуміти, що це означає, потрібно розглянути типи об'єктів, які розпізнає Linux:

Нижче наведено список пріоритетів за зростанням:

Вивчіть наступний рядок із файлу:

Об'єкти та пріоритети можуть бути пов'язані кількома способами.

Декілька об'єктів в одному рядку потрібно розділити комою.

Декілька селекторів в одному рядку також поділяються комою.

Зазначена зірочкою дія поєднує всіх користувачів.

Наприклад, про це говорить запис у файлі rsyslog.conf на CentOS:

По можливості перевірте, що каже rsyslog.conf на інших системах Linux. Ось уривок з Debian:

Конфігурації для rsyslog можуть виходити також від інших файлів користувача. Ці файли конфігурацій користувача, як правило, розташовані в різних каталогах в /etc/rsyslog.d. Файл rsyslog.conf включає ці каталоги, використовуючи директиву $IncludeConfig.

Так це виглядає в Ubuntu:

Для цього потрібно буде зробити таке:

• Задати специфікацію у файлі /etc/rsyslog.conf;
• Перезапустити демон rsyslog;
• Перевірити конфігурацію за допомогою утиліти "logger".

У наступному прикладі внесено два рядки у файл rsyslog.conf на CentOS. Як бачите, обидві вони походять від об'єкта local4 і мають різні пріоритети.

Потім потрібно перезапустити сервіс, щоб оновити дані файлу:

.
.
-rw------- 1 root root 0 Dec 9 11:21 local4crit.log
-rw------- 1 root root 72 Dec 9 11:22 local4info.log

Ротація лог-файлів

Згодом журнали стають більшими, оскільки в них з'являється нова інформація. Це створює потенційну проблему продуктивності. Крім того, керування файлами стає скрутним.

Linux використовує поняття «ротації» журналів замість їхнього очищення чи видалення. При ротації створюється новий каталог, а старий перейменується і за необхідності стискається. Таким чином журнали мають кілька старих версій. Ці файли будуть повертатися протягом певного періоду у вигляді про backlog-ов. Як тільки буде отримано певну кількість backlog-ів, нова ротація видалить найстаріший журнал.

Ротація виконується за допомогою утиліти "logrotate".

Конфігураційний файл logrotate

Як і rsyslog, logrotate залежить від конфігураційного файлу на ім'я logrotate.conf, який знаходиться в / etc.

Ось що знаходиться в цьому файлі на Debian:

За замовчуванням журнали ротуються щотижня, залишаючи 4 backlog-а. При запуску програми створюється новий порожній журнал, а старі за потреби будуть стиснуті.

Файли wtmp та btmp є винятками. wtmp відстежує вхід до системи, а btmp містить інформацію про невдалі спроби входу. Ці журнальні файли ротуються кожен місяць, і помилки не повертаються, якщо можна знайти один із попередніх файлів wtmp або btmp.

Конфігурації користувача ротації журналів містяться в каталозі «etc/logrotate.d». також вони включені до logrotate.conf за допомогою директиви include. Наприклад, Debian показує такий зміст даного каталогу:

$ls -l /etc/logrotate.d
total 44
-rw-r--r-- 1 root root 173 Apr 15 2011 apt
-rw-r--r-- 1 root root 79 Aug 12 2011 aptitude
-rw-r--r-- 1 root root 135 Feb 24 2010 consolekit
-rw-r--r-- 1 root root 248 Nov 28 2011 cups
-rw-r--r-- 1 root root 232 Sep 19 2012 dpkg
-rw-r--r-- 1 root root 146 May 12 2011 exim4-base
-rw-r--r-- 1 root root 126 May 12 2011 exim4-paniclog
-rw-r--r-- 1 root root 157 Nov 16 2010 pm-utils
-rw-r--r-- 1 root root 94 Aug 8 2010 ppp
-rw-r--r-- 1 root root 515 Nov 30 2010 rsyslog
-rw-r--r-- 1 root root 114 Nov 26 2008 unattended-upgrades

Зміст rsyslog показує, як повернути логи у вихідний стан:

$cat /etc/logrotate.d/rsyslog
/var/log/syslog
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
>
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
>

Як бачите, файл "syslog" буде повторно ініціалізований щодня. Інші журнальні файли ротуються щотижня.

Також варто згадати директиви postrotate. Вона вказує на дію, яка відбувається після завершення ротації журналів.

Тестування ротації

Logrotate можна запустити вручну для ротації одного чи кількох файлів.Щоб це зробити, потрібно просто вказати відповідний конфігураційний файл як аргумент.

Щоб продемонструвати, як це працює, наведено нижче неповний список журнальних файлів у каталозі /var/log на CentOS:

Неповний вміст файлу logrotate.conf має такий вигляд:

Потім запустіть команду logrotate:

Висновок

Сподіваємося, цей посібник дав вам деяке уявлення про журналування Linux. Спробуйте заглянути у власні розробки чи перевірки систем, щоб мати повніше поняття. Отримавши глибокі знання розташування журнальних файлів, і навіть ознайомившись із їхніми параметрами конфігурацій, можна використовувати для підтримки продуктивності системи.

Управління типом та подробицею журналованої інформації

Конфігураційний файл syslog.conf

Джерело (він же категорія) може бути наступним:

Задається повним шляхом, починаючи зі слєшу (/). Поставте перед ним дефіс (-), щоб скасувати синхронізацію файлу після кожного запису. Це може призвести до втрати інформації, але збільшити продуктивність.

Термінал та консоль

Термінал, такий як /dev/console.

Приклад простого syslog.conf:

Як і в багатьох конфігураційних файлах синтаксис наступний:

У синтаксисі конфігураційного файлу можна поставити перед пріоритетом знак !, щоб показати, що дія не повинна застосовуватися, починаючи з цього рівня та вище. Подібним чином, перед пріоритетом можна поставити знак = щоб показати, що правило застосовується тільки до цього рівня, або !=, щоб показати, що правило застосовується до всіх рівнів, крім цього. Нижче наведено кілька прикладів (man syslog.conf можна знайти безліч інших прикладів):

Запуск демона syslogd

Ось деякі можливі параметри запуску демона syslogd:

Після запуску демону syslogd створюється файл статусу /var/lock/subsys/syslog нульової довжини, та файл з ідентифікаційним номером процесу /var/run/syslogd.pid.

За допомогою команди
kill -SIGNAL `cat /var/run/syslogd.pid`

Автоматична ротація (оновлення заповнених файлів) та архівування журналів

Згодом файл журналу має властивість збільшуватися, особливо при інтенсивній роботі будь-якого сервісу. Відповідно необхідно мати можливість контролювати розмір журналів. Це робиться за допомогою logrotate команди, яка зазвичай виконується демоном cron. Про роботу cron я розповім у наступних статтях. Головна мета команди logrotate полягає в тому, щоб періодично створювати резервні копії журналів та створювати нові чисті журнали. Зберігається кілька поколінь журналів і, коли закінчується термін життя журналу останнього покоління, може бути заархівований (стиснутий). Результат може бути відправлений поштою, наприклад, відповідальним за ведення архівів.

Для визначення порядку ротації та архівування журналів використовується конфігураційний файл /etc/logrotate.conf. Для різних журналів можна задати різну періодичність, наприклад, щодня, щотижня або щомісяця, крім того, можна регулювати кількість поколінь, що накопичуються, а також вказати, чи будуть копії архівів відправлятися відповідальному за ведення архівів і, якщо будуть, коли. Нижче наведено приклад файлу /etc/logrotate.conf:

Глобальні опції розміщуються на початку файлу logrotate.conf. Вони використовуються за замовчуванням, якщо десь в іншому місці не встановлено нічого більш визначеного. У прикладі ротація журналів відбувається щотижня та резервні копії зберігаються протягом чотирьох тижнів.Як тільки виконується ротація журналу, на місці старого журналу автоматично створюється новий. Файл logrotate.conf може містити специфікації інших файлів. Так, до нього включаються всі файли з каталогу /etc/logrotate.d.

У цьому прикладі після досягнення резервної копією останнього покоління вона видаляється, оскільки не визначено, що слід з нею робити.

Резервні копії журналів можуть також створюватися, коли журнали досягають певного розміру, і можуть бути створені скрипти з наборів команд для виконання до або після операції резервного копіювання. Приклад:

У цьому прикладі ротація /var/log/messages провадиться після досягнення ним розміру 100 КБ. Накопичується п'ять резервних копій, і коли закінчується термін життя найстарішої резервної копії, вона надсилається поштою на адресу logadmin@sysloger. Командне слово postrotate включає скрипт, що перезапускає демон syslogd після завершення ротації шляхом надсилання сигналу HUP. Командне слово endscript необхідне для завершення скрипта, а також у випадку, якщо є скрипт prerotate. Більш повну інформацію див. у сторінках посібника man для logrotate.

Параметри, які задаються в конфігураційному файлі logrotate.conf:

Вивчення та моніторинг журналів

Далі у файлі протоколу можна виявити версію ядра, параметри його запуску, інформацію про тип процесора та обсяг ОЗП:

Іноді може виникати необхідність моніторингу системних журналів для пошуку поточних подій. Наприклад, можна спробувати зловити подію, що рідко трапляється, в той момент, коли вона сталася. У такому разі можна використати команду tail з опцією -f для відстеження вмісту журналу системи. Приклад:

Крім файлів-журналів, вказаних у /etc/syslog.conf, існують також інші файли, наприклад файл /var/log/dmesg, який зберігає інформацію про процес завантаження системи до запуску syslogd, а також файли /var/log/ lastlog, /var/log/wtmp, /var/log/btmp, що мають двійковий формат і зберігають інформацію про останній вход користувача в систему, про всі вдалі входи користувачів до системи та про всі невдалі входи користувачів до системи відповідно. Так само в каталозі /var/log/ можуть бути лог-файли таких демонів як веб-сервер або проксі-сервер. Формат даних файлів аналогічний журналам syslogd.

Підіб'ємо невеликий підсумок:

На сьогодні це все. Сподіваюся, що описав все максимально зрозуміло. Згодом доповнюватиму статтю!