Как отключить логирование ubuntu

Обновлено: 03.07.2024

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

Данное руководство знакомит с возможностями журналирования 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 и предназначенными для этого инструментами.

Примечание: В данном руководстве используется 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" combined

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.

Подведем небольшой итог:

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

Читайте также: