Centos 7 логи ошибок - Ремонт и установка крупной бытовой техники

Using log files is critical to monitoring the Operating System and troubleshooting any problems. CentOS 7 has a built-in syslog that is used to build your log files.

What Logs Does Syslog Generate?

/var/log : The directory that you can find any logs generated by the syslog in this directory
/var/log/messages : Stores all of the syslog messages other than those mentioned below.
/var/log/secure stores authentication and security-related messages and errors. This also keeps track of authentication requests.
/var/log/maillog : Where you can find mail-related messages. This also keeps track of email error messages.
/var/log/cron : Contains files that are kept for automated tasks
/var/log/boot.log : Has system startup logfiles

What Should I Monitor Logs?

If something goes wrong with your VPS, the first place you will want to look is /var/log/messages to determine if there are any critical errors.

It is always wise to check /var/log/secure to ensure that logins are being monitored. Having a piece of mind that you have not been brute force attacked, a username and password has been compromised, or finding any failed login attempts are highly suggested to monitor consistently. This should be the first place to look if you find any malicious files or suspicious files on your server so you can identify right away that only trusted users have authenticated to your server.

You can review any ssh login activity and errors logged by the system security daemon in the following path.

/var/log/secure

If there are problems with your server being shut down, or if you are having an issue booting up your server, /var/log/boot.log can help you determine the duration of unplanned downtime.

Automation is used frequently, and to ensure your system can continue automation, checking the file below can confirm that any planned execution is going as scheduled.

/var/log/cron

Mail sent from your server is important to monitor and can be investigated further by monitoring the mail logs frequently.

 /var/log/maillog

Sometimes, just knowing where to look is half the battle, and this guide is intended to lead you in the right direction to monitor your logs frequently and actively.

Источник

ЧТЕНИЕ И НАСТРОЙКА ЛОГОВ LINUX В UBUNTU И CENTOS

Администраторам Linux часто нужно заглядывать в лог-файл для устранения неполадок. По сути, это действие первой необходимости для любого админа.

Система Linux и ее приложения могут создавать разные типы сообщений, которые записываются в различные журналы. Linux использует набор конфигурационных файлов, каталогов, программ, команд и демонов для создания, хранения и повторного использования таких сообщений. Поэтому зная, где система хранит свои журналы и как воспользоваться определенными командами, можно сэкономить драгоценное время во время устранения неполадок.

Данное руководство рассматривает различные части механизма журналирования Linux.

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

Стандартные логи

По умолчанию журналы в Linux хранятся в /var/log.

Для просмотра списка журналов, находящихся в данном каталоге, используйте команду ls -l /var/log.

В системе CentOS это выглядит так:

[root@TestLinux ~]# ls -l /var/log  
total 1472  
-rw-------. 1 root root   4524 Nov 15 16:04 anaconda.ifcfg.log  
-rw-------. 1 root root  59041 Nov 15 16:04 anaconda.log  
-rw-------. 1 root root  42763 Nov 15 16:04 anaconda.program.log  
-rw-------. 1 root root 299910 Nov 15 16:04 anaconda.storage.log  
-rw-------. 1 root root  40669 Nov 15 16:04 anaconda.syslog  
-rw-------. 1 root root  57061 Nov 15 16:04 anaconda.xlog  
-rw-------. 1 root root   1829 Nov 15 16:04 anaconda.yum.log  
drwxr-x---. 2 root root   4096 Nov 15 16:11 audit  
-rw-r--r--  1 root root   2252 Dec  9 10:27 boot.log  
-rw-------  1 root utmp    384 Dec  9 10:31 btmp  
-rw-------. 1 root utmp   1920 Nov 28 09:28 btmp-20131202  
drwxr-xr-x  2 root root   4096 Nov 29 15:47 ConsoleKit  
-rw-------  1 root root   2288 Dec  9 11:01 cron  
-rw-------. 1 root root   8809 Dec  2 17:09 cron-20131202  
-rw-r--r--  1 root root  21510 Dec  9 10:27 dmesg  
-rw-r--r--  1 root root  21351 Dec  6 16:37 dmesg.old  
-rw-r--r--. 1 root root 165665 Nov 15 16:04 dracut.log  
-rw-r--r--. 1 root root 146876 Dec  9 10:44 lastlog  
-rw-------  1 root root    950 Dec  9 10:27 maillog  
-rw-------. 1 root root   4609 Dec  2 17:00 maillog-20131202  
-rw-------  1 root root 123174 Dec  9 10:27 messages  
-rw-------. 1 root root 458481 Dec  2 17:00 messages-20131202  
-rw-------  1 root root   2644 Dec  9 10:44 secure  
-rw-------. 1 root root  15984 Dec  2 17:00 secure-20131202  
-rw-------  1 root root      0 Dec  2 17:09 spooler  
-rw-------. 1 root root      0 Nov 15 16:02 spooler-20131202  
-rw-------. 1 root root      0 Nov 15 16:02 tallylog  
-rw-rw-r--. 1 root utmp  89856 Dec  9 10:44 wtmp  
-rw-------  1 root root   3778 Dec  6 16:48 yum.log

Просмотр логов

В каталоге /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:

[root@TestLinux ~]# who  
root     tty1         2013-12-09 10:44  
root      pts/0        2013-12-09 10:29 (10.0.2.2)  
sysadmin pts/1        2013-12-09 10:31 (10.0.2.2)  
joeblog  pts/2        2013-12-09 10:39 (10.0.2.2)

Команда «sysadmin» выводит историю входа пользователей:

[root@TestLinux ~]# last | grep sysadmin  
sysadmin pts/1        10.0.2.2         Mon Dec  9 10:31   still logged in  
sysadmin pts/0        10.0.2.2         Fri Nov 29 15:42 - crash  (00:01)  
sysadmin pts/0        10.0.2.2         Thu Nov 28 17:06 - 17:13  (00:06)  
sysadmin pts/0        10.0.2.2         Thu Nov 28 16:17 - 17:05  (00:48)  
sysadmin pts/0        10.0.2.2         Thu Nov 28 09:29 - crash  (06:04)  
sysadmin pts/0        10.0.2.2         Wed Nov 27 16:37 - down   (00:29)  
sysadmin tty1                          Wed Nov 27 14:05 - down   (00:36)  
sysadmin tty1                          Wed Nov 27 13:49 - 14:04  (00:15)

В данном примере нужно было получить историю входа пользователя sysadmin. Как можно видеть, было пару случаев, когда он приводил к сбою системы.

Чтобы узнать время последней перезагрузки системы, используйте следующую команду:

[root@TestLinux ~]# last reboot

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

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:

[root@TestLinux ~]# 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:

debian@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. Данный сервис отвечает за прослушивание зарегистрированных сообщений различных частей системы Linux и маршрутизацию сообщения к соответствующему журналу в каталоге /var/log. Он также может передавать зарегистрированные сообщения другому серверу Linux.

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

Демон rsyslog получает конфигурации из файла «rsyslog.conf», который находится в каталоге /etc.

В основном, файл rsyslog.conf говорит демону, где хранить сообщения. Данная информация имеет вид серии строк, состоящих из двух частей.

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

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

Селектор указывает на источник и важность сообщения, а действие говорит, что нужно сделать с данным сообщением.

Сам селектор также разделен на 2 части символом точки (.). Часть перед символом точки называется объектом (источник сообщения), а часть за символом называется приоритетом (степень важности сообщения).

Комбинация объекта-приоритета и действия говорит rsyslog, что делать, если сообщение соответствует указанным параметрам.

Вот отрывок из файла rsyslog.conf на CentOS:

# rsyslog v5 configuration file  
...  
...  
# Include all config files in /etc/rsyslog.d/  
IncludeConfig /etc/rsyslog.d/*.conf  
#### RULES ####  
# Log all kernel messages to the console.  
# Logging much else clutters up the screen.  
#kern.*  /dev/console  
# Log anything (except mail) of level info or higher.  
# Don't log private authentication messages!  
*.info;mail.none;authpriv.none;cron.none                /var/log/messages  
# The authpriv file has restricted access.  
authpriv.*                                              /var/log/secure  
# Log all the mail messages in one place.  
mail.*                                                  -/var/log/maillog  
# Log cron stuff  
cron.*                                                  /var/log/cron  
# Everybody gets emergency messages  
*.emerg                                                 *  
# Save news errors of level crit and higher in a special file.  
uucp,news.crit                                          /var/log/spooler  
# Save boot messages also to boot.log  
local7.*                                                /var/log/boot.log  
...  
...

Чтобы понять, что все это значит, нужно рассмотреть типы объектов, которые распознает Linux:

auth or authpriv: Сообщения, поступающие от сервисов авторизации и безопасности;
kern: сообщения ядра Linux;
mail: сообщения подсистемы почты;
cron: сообщения демона Cron;
daemon: сообщения от демонов;
news: сообщения подсистемы новостей сети;
lpr: сообщения, связанные с печатью;
user: сообщения пользовательских программ;
local0 до local7:Зарезервировано для локального использования.

Ниже приведен список приоритетов по возрастанию:

Debug: Отладочная информация от программ;
info: простое информационное сообщение – никакого вмешательства не требуется;
notice: состояние, которое может потребовать внимания;
warn: Предупреждение;
err: ошибка;
crit: критическое состояние;
alert: состояние, требующее немедленного вмешательства;
emerg: аварийное состояние.

Изучите следующую строку из файла:

cron.* /var/log/cron

Она говорит rsyslog сохранять все сообщения, приходящие от демона cron, в файле /var/log/cron. Звездочка (*) поле точки значит, что зарегистрированы будут сообщения всех приоритетов. Аналогичным образом, если объект был определен звездочкой, это объединяет все источники.

Объекты и приоритеты могут быть связаны в несколькими способами.

Вид по умолчанию, когда после точки указан только один приоритет, значит, что будут охвачены все сообщения с таким или высшим уровнем приоритета. Таким образом, данное указание регистрирует все сообщения, приходящие от почтовой подсистемы с приоритетом «warn» и выше в специальном файле в /var/log:

mail.warn /var/log/mail.warn

Такие параметры будут регистрировать все сообщения с таким же или высшим, чем warn, приоритетом и пропускать все остальное. То есть, сообщения с приоритетом err, crit, alert и emerg также будут внесены в файл.

Знак равности (=) после точки указывает регистрировать только сообщения с указанным приоритетом. То есть, если нужно регистрировать только сообщения от почтовой подсистемы с приоритетом info, указание будет таким:

mail.=info /var/log/mail.info

Опять же, если нужно регистрировать все сообщения почтовой подсистемы, кроме сообщений с приоритетом info, строка будет выглядеть так:

mail.!info /var/log/mail.info

или так:

mail.!=info /var/log/mail.info

В первом случае файл mail.info содержал бы все сообщения с приоритетом ниже info. Во втором случае он содержал бы все сообщения с приоритетом выше info.

Несколько объектов в одной строке нужно разделить запятой.

Несколько селекторов в одной строке также разделяются запятой.

Отмеченное звездочкой действие объединяет всех пользователей.

К примеру, об этом говорит запись в файле rsyslog.conf на CentOS:

# Everybody gets emergency messages *.emerg *

По возможности проверьте, что говорит rsyslog.conf на других системах Linux. Вот отрывок из Debian:

#  /etc/rsyslog.conf    Configuration file for rsyslog.  
#  
#           For more information see  
#           /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html  
...  
...  
auth,authpriv.*         /var/log/auth.log  
*.*;auth,authpriv.none      -/var/log/syslog  
#cron.*             /var/log/cron.log  
daemon.*            -/var/log/daemon.log  
kern.*              -/var/log/kern.log  
lpr.*               -/var/log/lpr.log  
mail.*              -/var/log/mail.log  
user.*              -/var/log/user.log  
#  
# Logging for the mail system.  Split it up so that  
# it is easy to write scripts to parse these files.  
#  
mail.info           -/var/log/mail.info  
mail.warn           -/var/log/mail.warn  
mail.err            /var/log/mail.err  
#  
# Logging for INN news system.  
#  
news.crit           /var/log/news/news.crit  
news.err            /var/log/news/news.err  
news.notice         -/var/log/news/news.notice

Как можно видеть, Debian сохраняет сообщения безопасности/авторизации всех уровней в /var/log/auth.log, в то время как CentOS делает это в /var/log/secure.

Конфигурации для rsyslog могут исходить также от других пользовательских файлов. Эти файлы пользовательских конфигураций, как правило, расположены в разных каталогах в /etc/rsyslog.d. Файл rsyslog.conf включает эти каталоги, используя директиву «$IncludeConfig».

Так это выглядит в Ubuntu:

#  Default logging rules can be found in /etc/rsyslog.d/50-default.conf  
....  
....  
$IncludeConfig /etc/rsyslog.d/*.conf  
Содержимое каталога /etc/rsyslog.d выглядит так:  
-rw-r--r-- 1 root root  311 Mar 17  2012 20-ufw.conf  
-rw-r--r-- 1 root root  252 Apr 11  2012 21-cloudinit.conf  
-rw-r--r-- 1 root root 1655 Mar 30  2012 50-default.conf

Теперь сохранять сообщение в журнал необязательно; сообщение можно переслать консоли пользователя. В таком случае, поле действия будет содержать имя пользователя. Если сообщение нужно отправить нескольким пользователям, их имена нужно разделить запятыми. Если же сообщение нужно распространить между всеми пользователями, в поле действия вносится символ *.

Будучи частью сетевой операционной системы, демон rsyslog может не только хранить зарегистрированные сообщения локально, но и передавать их на другие серверы Linux, а также действовать как репозиторий для других систем. Демон прослушивает сообщения через UDP-порт 514. В приведенном ниже примере он пересылает критические сообщения ядра на сервер под названием «texas»:

kern.crit @texas

Создание и тестирование сообщений

Теперь попробуйте сами создать сообщение.

Для этого нужно будет сделать следующее:

Задать спецификацию в файле /etc/rsyslog.conf;
Перезапустить демон rsyslog;
Проверить конфигурацию с помощью утилиты «logger».

В следующем примере внесены две строки в файл rsyslog.conf на CentOS. Как видите, обе они исходят от объекта local4 и имеют разные приоритеты.

[root@TestLinux ~]# vi /etc/rsyslog.conf  
....  
....  
# New lines added for testing log message generation  
local4.crit                                             /var/log/local4crit.log  
local4.=info                                            /var/log/local4info.log`

Затем нужно перезапустить сервис, чтобы обновить данные файла:

`[root@TestLinux ~]# /etc/init.d/rsyslog restart  
Shutting down system logger:                               [  OK  ]  
Starting system logger:                                    [  OK  ]  
[root@TestLinux ~]#`

Теперь нужно вызвать приложение logger, чтобы создать сообщение:

`[root@TestLinux ~]# logger -p local4.info " This is a info message from local 4"`

Каталог /var/log показывает два новых сообщения:

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

Размер local4info.log не равен нулю, а это значит, что сообщение было записано:

[root@TestLinux ~]# cat /var/log/local4info.log  
Dec  9 11:22:32 TestLinux root:  This is a info message from local 4

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

Со временем журналы становятся больше, поскольку в них появляется новая информация. Это создает потенциальную проблему производительности. Кроме того, управление файлами становится затруднительным.

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

Ротация выполняется при помощи утилиты «logrotate».

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

Как и rsyslog, logrotate зависит от конфигурационного файла по имени logrotate.conf, который находится в /etc.

Вот что находится в данном файле на Debian:

debian@debian:~$ cat /etc/logrotate.conf  
# see "man logrotate" for details  
# rotate log files weekly  
weekly  
# keep 4 weeks worth of backlogs  
rotate 4  
# create new (empty) log files after rotating old ones  
create  
# uncomment this if you want your log files compressed  
#compress  
# packages drop log rotation information into this directory  
include /etc/logrotate.d  
# no packages own wtmp, or btmp -- we'll rotate them here  
/var/log/wtmp {  
missingok  
monthly  
create 0664 root utmp  
rotate 1  
}  
/var/log/btmp {  
missingok  
monthly  
create 0660 root utmp  
rotate 1  
}  
# system-specific logs may be configured here

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

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

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

debian@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 показывает, как вернуть логи в исходное состояние:

debian@debian:~$ 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:

[root@TestLinux ~]# ls -l /var/log  
total 800  
...  
-rw-------  1 root root    359 Dec 17 18:25 maillog  
-rw-------. 1 root root   1830 Dec 16 16:35 maillog-20131216  
-rw-------  1 root root  30554 Dec 17 18:25 messages  
-rw-------. 1 root root 180429 Dec 16 16:35 messages-20131216  
-rw-------  1 root root    591 Dec 17 18:28 secure  
-rw-------. 1 root root   4187 Dec 16 16:41 secure-20131216  
...  
...

Неполное содержимое файла logrotate.conf выглядит так:

[root@TestLinux ~]# cat /etc/logrotate.conf  
# see "man logrotate" for details  
# rotate log files weekly  
weekly  
# keep 4 weeks worth of backlogs  
rotate 4  
# create new (empty) log files after rotating old ones  
create  
...  
...

Затем запустите команду logrotate:

[root@TestLinux ~]# logrotate -fv /etc/logrotate.conf

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

[root@TestLinux ~]# ls -l /var/log/mail*  
-rw-------  1 root root    0 Dec 17 18:34 /var/log/maillog  
-rw-------. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20131216  
-rw-------  1 root root  359 Dec 17 18:25 /var/log/maillog-20131217  
[root@TestLinux ~]# ls -l /var/log/messages*  
-rw-------  1 root root    148 Dec 17 18:34 /var/log/messages  
-rw-------. 1 root root 180429 Dec 16 16:35 /var/log/messages-20131216  
-rw-------  1 root root  30554 Dec 17 18:25 /var/log/messages-20131217  
[root@TestLinux ~]# ls -l /var/log/secure*  
-rw-------  1 root root    0 Dec 17 18:34 /var/log/secure  
-rw-------. 1 root root 4187 Dec 16 16:41 /var/log/secure-20131216  
-rw-------  1 root root  591 Dec 17 18:28 /var/log/secure-20131217  
[root@TestLinux ~]#

Как можно видеть, все три новых журнала были созданы. Почтовый журнал и журнал безопасности все еще пусты, но новый журнал сообщений уже содержит некоторые данные.

CentOS
логи
Ubuntu
logger
rsyslog

Источник

Анализ логов является важной задачей системного администратора. Если что-то идет не так в системе Linux, ответ часто находится в логах. На CentOS 7 две разные системы логирования используются бок о бок, и важно знать, как и где найти информацию. Эта статья научит вас всему этому. Вы узнаете, как читать логи, настраивать rsyslogd и journald, а также как настроить свою систему на ротацию логов, чтобы предотвратить полное заполнение дисков службами, которые регистрируют события в этих самых логах.

Понимание логирования

Большинство сервисов, используемых на сервере Linux, записывают информацию в лог-файлы. Эта информация может быть записана в разных местах, и существует несколько решений для поиска соответствующей информации в системных логах. Сервисы могут использовать не менее трех разных подходов для записи информации в логи:

Прямая запись: некоторые сервисы записывают информацию напрямую в лог-файлы, даже некоторые важные сервисы, такие как веб-сервер Apache и файловый сервер Samba.
rsyslogd: rsyslogd — это усовершенствование сервиса syslogd, который занимается централизованным управлением лог-файлов. Syslogd существует уже давно.
journald: с введением systemd также был представлен сервис логирования journald. Этот сервис тесно интегрирован с systemd, что позволяет администраторам читать подробную информацию из journald, одновременно отслеживая состояние сервиса с помощью команды systemctl status.

Понимание ролей rsyslogd и journald

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

Поскольку журнал, который пишет journald, не является постоянным между перезагрузками, сообщения также перенаправляются в службу rsyslogd. rsyslogd записывает сообщения в разные файлы в каталоге /var/log.

rsyslogd предлагает функции, которых нет в journald, такие как централизованное ведение журнала и фильтрация сообщений с использованием модулей. В текущем состоянии journald не является заменой rsyslogd; это просто еще один способ регистрации информации. journald тесно интегрирован с systemd и поэтому регистрирует всё, что делает ваш сервер. rsyslogd добавляет к нему некоторые сервисы. В частности, он заботится о записи данных журнала в определенные файлы (которые будут постоянными между перезагрузками) и позволяет настраивать удаленные журналы и серверы журналов.

Чтобы получить больше информации о том, что происходит на машине, администраторы должны использовать три подхода:

Файлы в /var/log, которые пишутся rsyslogd, должны контролироваться.
Команда journalctl может использоваться для получения более подробной информации из журнала.
Для краткого обзора последних значимых событий, которые были зарегистрированы модулями systemd через journald, администраторы могут использовать команду systemctl status <unit>. Эта команда показывает состояние сервисов, а также последние пару строк, которые были логированы. В листинге 1 показан пример, в котором эта команда четко указывает, что пошло не так при запуске сервиса.

Листинг 1

[root@server1 ~]# systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: failed (Result: exit-code) since Fri 2019-10-25 05:25:18
PDT; 2s ago
Process: 2893 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited,
status=0/SUCCESS)
Process: 2890 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
(code=exited, status=1/FAILURE)
Main PID: 2890 (code=exited, status=1/FAILURE)
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address [::]:443
Oct 25 05:25:18 server1.example.com httpd[2890]: (13)Permission
denied: AH00072: make_sock: could not bind to address 0.0.0.0:443
Oct 25 05:25:18 server1.example.com httpd[2890]: no listening sockets
available, shutting down
Oct 25 05:25:18 server1.example.com httpd[2890]: AH00015: Unable to
open logs
Oct 25 05:25:18 server1.example.com systemd[1]: httpd.service: main
process exited, code=exited, status=1/FAILURE
Oct 25 05:25:18 server1.example.com systemd[1]: Failed to start The
Apache HTTP Server.
Oct 25 05:25:18 server1.example.com systemd[1]: Unit httpd.service
entered failed state.

Чтение лог-файлов

Помимо сообщений, которые записываются journald и которые можно прочитать с помощью команды journalctl, в системе Linux вы также найдете различные лог-файлы в каталоге /var/log. Эти файлы могут быть прочитаны, например, с помощью less.

Точное количество файлов в каталоге /var/log будет меняться в зависимости от конфигурации сервера и сервисов, работающих на этом сервере. Однако некоторые файлы существуют в большинстве случаев, и, как администратор, вы должны знать, какие это файлы и какое содержимое можно ожидать в этих файлах.

В таблице 1 представлен обзор некоторых стандартных файлов, созданных в этом каталоге.

Таблица 1

log-файл	Объяснение
/var/log/messages	Наиболее часто используемый файл журнала, это общий файл журнала, в который записывается большинство сообщений.
/var/log/dmesg	Содержит сообщения журнала ядра.
/var/log/secure	Содержит сообщения, связанные с аутентификацией.
/var/log/boot.log	Сообщения, связанные с запуском системы.
/var/log/audit/audit.log	Содержит сообщения аудита. SELinux пишет в этот файл.
/var/log/maillog	Сообщения, связанные с почтой.
/var/log/samba	Предоставляет файлы журналов для сервиса Samba. Обратите внимание, что по умолчанию Samba не управляется через rsyslog, а записывается непосредственно в каталог /var/log.
/var/log/sssd	Содержит сообщения, записанные сервисом sssd, который играет важную роль в процессе аутентификации.
/var/log/cups	Содержит сообщения, сгенерированные службой печати CUPS.
/var/log/httpd/	Каталог, содержащий лог-файлы, которые записываются веб-сервером Apache. Обратите внимание, что Apache пишет сообщения в эти файлы напрямую, а не через rsyslog.

Понимание содержимого лог-файла

Как администратор, вы должны уметь интерпретировать содержимое лог-файлов. Например, в листинге 2 показан частичный контент из файла /var/log/messages.

Листинг 2

[root@kvm ~]# tail -n 20 /var/log/messages
Oct 31 22:05:56 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:06:09 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 15 (xid=0x278ccc34)
Oct 31 22:06:24 kvm dhclient[24837]: DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 16 (xid=0x278ccc34)
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5185] dhcp4 (em1):request timed out
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5186] dhcp4 (em1):state changed unknown -> timeout
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):canceled DHCP transaction, DHCP client pid 24837
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5270] dhcp4 (em1):state changed timeout -> done
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5274] device (em1): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm NetworkManager[2577]: <warn>  [1572523586.5284] device (em1): Activation: failed for connection 'Wired connection 1'
Oct 31 22:06:26 kvm NetworkManager[2577]: <info>  [1572523586.5288] device (em1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Oct 31 22:06:26 kvm avahi-daemon[2499]: Withdrawing address record for fe80::6bbe:cb13:850c:d799 on em1.
Oct 31 22:06:41 kvm journal: g_array_unref: assertion 'array' failed
Oct 31 22:10:01 kvm systemd: Created slice User Slice of root.
Oct 31 22:10:01 kvm systemd: Started Session 413 of user root.
Oct 31 22:10:01 kvm systemd: Removed slice User Slice of root.
Oct 31 22:10:08 kvm systemd-logind: New session 414 of user admin.
Oct 31 22:10:08 kvm systemd: Started Session 414 of user admin.
Oct 31 22:10:08 kvm dbus[2512]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Oct 31 22:10:08 kvm dbus[2512]: [system] Successfully activated service 'org.freedesktop.problems'
Oct 31 22:10:15 kvm su: (to root) admin on pts/11

Как видно из листинга 2, каждая записываемая строка имеет определенные элементы:

Дата и время: каждое сообщение начинается с отметки времени. В целях фильтрации метка времени записывается как военное время.
Хост: хост, с которого отправлено сообщение. Это важно, потому что rsyslogd также может быть настроен для обработки удаленных логов.
Имя службы или процесса: имя сервиса или процесса, сгенерировавшего сообщение.
Содержимое сообщения: содержимое сообщения, которое содержит точное сообщение, которое было зарегистрировано.

Чтобы прочитать содержимое лог-файла, вы можете использовать, например less, или вы можете в реальном времени наблюдать за тем, что там происходит с помощью команды tail -f. Например: tail -f /var/log/messages.

Команда logger

Большинство сервисов самостоятельно записывают информацию в лог-файлы. Команда logger позволяет пользователям записывать сообщения в rsyslog из командной строки. Использовать эту команду просто. Просто введите logger, и затем сообщение, которое вы хотите записать в логи. Таким образом, утилита logger предлагает удобное решение для написания сообщений из скриптов. Это позволит вам записывать скрипт в syslog, если что-то пойдёт не так.

При использовании logger вы также можете указать приоритет и что вы хотите логировать. Команда logger -p kern.err my_message записывает my_message в объект kern, например, используя приоритет error. Эта опция позволит проверить работу конкретных rsyslog объектов.

Настройка rsyslogd

Чтобы убедиться, что информация, которая должна быть залогирована, записана в то место, где вы хотите ее найти, вы можете настроить сервис rsyslogd в файле /etc/rsyslog.conf. В этом файле вы найдете различные разделы, которые позволяют указать, где и как должна быть записана информация.

Секции rsyslog.conf

Файл rsyslog.conf используется для указания того, что должно быть зарегистрировано и где это должно быть зарегистрировано. Для этого вы найдете различные разделы в файле конфигурации:

■ #### MODULES ####: rsyslogd является модульным. Модули включены для улучшения поддерживаемых функций в rsyslogd.

■ #### GLOBAL DIRECTIVES ####: Этот раздел используется для указания глобальных параметров, таких как место, где записываются вспомогательные файлы, или формат метки времени по умолчанию.

■ #### RULES ####: Это самая важная часть файла rsyslog.conf. Он содержит правила, которые определяют, какая информация должна быть залогирована и в каком месте.

Объекты, приоритеты, и места назначения

Чтобы указать, какая информация должна логироваться и в каком месте назначения, rsyslogd использует объект (Facility), приоритет (Priority) и место назначения (Destination):

■ Объект определяет категорию информации, которая логируется. Rsyslogd использует фиксированный список объектов, который не может быть расширен. Это связано с обратной совместимостью с устаревшей службой syslog.

■ Приоритет используется для определения серьезности сообщения, которое необходимо залогировать.
При указании приоритета по умолчанию с таким приоритетом логируются все сообщения, а так же все сообщения с приоритетом выше текущего.

■ Назначение определяет, куда должно быть записано сообщение. Типичными адресатами являются файлы, но модули rsyslog также могут использоваться в качестве места назначения для дальнейшей обработки через модуль rsyslogd.

В листинге 3 приведен пример раздела RULES в rsyslog.

Листинг 3

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

В листинге 3 вы можете увидеть, как различные объекты и приоритеты используются для определения местоположений, в которые можно логировать информацию. Доступные объекты и приоритеты являются фиксированными и не могут быть добавлены. Таблица 2 показывает, какие объекты доступны, а таблица 3 показывает список всех приоритетов.

При указании назначения часто используется файл. Если имя файла начинается с дефиса (как -/var/log/maillog), сообщения не будут немедленно переданы в файл, а будут буферизированы для повышения эффективности записи. Файлы устройств также могут быть использованы, как /dev/console. Если используется устройство, сообщения записываются в режиме реального времени на консоль. На современных серверах это не имеет смысла, поскольку администраторы часто входят в систему удаленно и не видят, что происходит на консоли сервера.

Для расширения функциональности rsyslogd могут использоваться модули для дальнейшей обработки сообщений. Если это требуется, имя модуля может быть указано как :имя_модуля:.

Таблица 2

Объект	Что логируется
auth / authpriv	Сообщения, связанные с аутентификацией.
cron	Сообщения, сгенерированные сервисом crond.
daemon	Универсальный объект, который можно использовать для неопределенных демонов.
kern	Сообщения ядра.
lpr	Сообщения, сгенерированные через систему печати.
mail	Сообщения, связанные с электронной почтой.
mark	Специальный объект, который можно использовать для периодической записи маркера.
news	Сообщения, генерируемые системой новостей NNTP.
security	То же, что и auth / authpriv. Не должен больше использоваться.
syslog	Сообщения, генерируемые системой syslog.
user	Сообщения генерируемые в пространстве пользователя.
uucp	Сообщения, сгенерированные устаревшей системой UUCP.
local0-7	Резервные объекты, которые необходимы для использования тех объектов, которые отсутствуют в этой таблице.

Объекты syslog были определены в 1980-х годах, и для обеспечения обратной совместимости никакие новые объекты не могут быть добавлены. В результате все еще существуют некоторые объекты, которые в основном больше не используются, а некоторые сервисы, которые стали актуальными на более позднем этапе, не имеют своего собственного объекта. Как решение, два конкретных типа объекта могут быть использованы. Объект daemon — это общий объект, который может использоваться любым демоном. И могут быть использованы объекты local0 — local7.

Если есть сервисы, которые не имеют своих собственных объектов rsyslogd, которым необходимо в любом случае записывать сообщения в определенный лог-файл, эти сервисы можно настроить для использования любого из объектов от local0 до local7. Затем вы должны настроить сервисы для использования этих объектов. Процедура, которой вы пользуетесь, зависит от используемого вами сервиса. Затем вам нужно добавить правило в файл rsyslog.conf, чтобы отправлять сообщения, поступающие через этот объект, в определенный флог-файл. Упражнение 2 показывает, как вы можете это сделать.

Чтобы определить, какие типы сообщений должны логироваться, в строках rsyslog.conf могут использоваться разные уровни серьезности. Эти серьезности являются syslog-приоритетами. В таблице 3 представлен обзор доступных приоритетов в порядке возрастания.

Таблица 3

Приоритет	Используется для
debug	Отладочные сообщения, которые дадут как можно больше информации о работе сервиса.
info	Информационные сообщения о нормальной работе сервиса.
notice	Используется для информационных сообщений об элементах, которые позже могут стать проблемой.
warning / warn	Что-то не оптимальное, но ошибки пока нет.
err /error	Произошла некритическая ошибка.
crit	Произошла критическая ошибка.
alert	Используется, когда сервис перестал быть доступен.
emerg / panic	Сообщение генерируется, когда доступность сервиса прекращается.

Когда используется определенный приоритет, все сообщения с этим приоритетом и выше логируются в соответствии со спецификациями, используемыми в этом конкретном правиле. Если вам необходимо детально настроить логирование, когда сообщения с разными приоритетами отправляются в разные файлы, вы можете указать приоритет со знаком равенства (=) перед ним, как в следующем файле конфигурации, который будет отправлять все отладочные сообщения cron в файл с именем /var/log/cron.debug. Обратите внимание на использование дефиса (-) перед именем файла, который гарантирует, что сообщения буферизуются и не записываются немедленно на диск (что хорошо для производительности диска).

Рассмотрим следующую строку, где все сообщения cron только с приоритетом отладки записываются в определенный файл. Обратите внимание на — перед строкой, который буферизует записи, чтобы информация логировалась более эффективным способом:

cron.=debug                     -/var/log/cron.debug

Нет необходимости учить наизусть названия rsyslogd объектов и приоритетов. Все они перечислены в man 5 rsyslog.conf.

Упражнение 2. Изменение правил в rsyslog.conf
В этом упражнении вы узнаете, как изменить rsyslog.conf. Вы настроите сервис Apache для логирования сообщений через syslog и создадите правило, которое записывает сообщения отладки в определенный файл.

1. По умолчанию сервис Apache не логируется через rsyslog, но ведет собственное логирование. Вы измените это. Для начала установите Apache командой yum install -y httpd.

2. После установки Apache откройте его файл конфигурации /etc/http/conf/httpd.conf и добавьте в него следующую строку:

ErrorLog    syslog:local1

3. Введите systemctl restart httpd.

4. Теперь создайте строку в файле rsyslog.conf, которая будет отправлять все сообщения, которые он получает для объекта local1 (который теперь используется сервисом httpd), в файл /var/log/httpd-error.log. Для этого включите следующую строку:

local1:error                    -/var/log/httpd-error.log

5. Скажите rsyslogd перезагрузить его конфигурацию, выполнив команду systemctl restart httpd.

6. Все сообщения об ошибках Apache теперь будут записываться в файл httpd-error.log.

7. В браузере Firefox перейдите по адресу http://localhost/nowhere. Так как страницы, к которой вы пытаетесь получить доступ, не существует, она будет записана в журнал ошибок Apache.

8. Теперь давайте создадим snap-in файл, который также записывает сообщения отладки в определенный файл. Для этого введите echo «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.conf.

9. Снова перезапустите rsyslogd с помощью systemctl restart rsyslogd.

10. Выполните tail -f /var/log/messages-debug, чтобы открыть трассировку для вновь созданного файла.

11. Введите logger -p daemon.debug «Daemon Debug Message». Вы увидите сообщение отладки.

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

Чтобы syslog сообщения не заполняли вашу систему, сообщения можно ротировать. Это означает, что когда будет достигнут определенный порог,
старый лог-файл закроется и откроется новый. Утилита logrotate периодически запускается через сервис crond, чтобы позаботиться о ротации лог-файлов.

Когда лог-файл ротируется, старый файл копируется в файл с датой ротации. Таким образом, если /var/log/messages ротируется 3 ноября 2019 года, то ротируемое имя файла будет /var/log/messages-20191103. По умолчанию в системе хранятся четыре старых лог-файлов. Файлы старше этого периода удаляются из системы автоматически.

ВНИМАНИЕ! Лог-файлы, которые были ротированы, нигде не хранятся; они просто исчезают. Если политика вашей компании требует от вас доступа к информации о событиях, которые произошли более 5 недель назад, вам следует принять меры. Вы можете либо создать резервную копию лог-файлов, либо настроить сервер логов, где logrotate хранит ротированные сообщения в течение значительно более длительного периода.

Настройки по умолчанию для ротации логов хранятся в файле /etc/logrotate.conf

[root@kvm ~]# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.
[root@kvm ~]#

Наиболее важные настройки, используемые в этом файле конфигурации, заставляют logrotate еженедельно ротировать файлы и сохранять четыре старые версии файла. Вы можете получить больше информации о других параметрах в этом файле с помощью команды man logrotate.

Если для определенных файлов требуются определенные настройки, вы можете создать файл конфигурации для этого файла в /etc/logrotate.d. Настройки для этого файла перезаписывают настройки по умолчанию в /etc/logrotate.conf.

Работаем с journald

Сервис systemd-journald хранит лог-сообщения в журнале в двоичном виде, который хранится в файле /run/log/journal. Этот файл можно просмотреть с помощью команды journalctl.

Использование journalctl для поиска событий

Самый простой способ использовать journalctl — просто набрать команду. Он показывает последние события, которые были записаны в журнал с момента последнего запуска вашего сервера. Обратите внимание, что результат этой команды отображается в меньшем количестве страниц, и по умолчанию вы увидите начало журнала.

Поскольку журнал записывается с момента загрузки сервера, в нем отображаются сообщения журнала, связанные с загрузкой. Если вы хотите просмотреть последние сообщения, которые были зарегистрированы, вы можете использовать journalctl -f, который показывает последние строки сообщений, в которые автоматически добавляются новые строки журнала.

Вы также можете ввести journalctl и нажать кнопку G (заглавная буква) , чтобы перейти к концу журнала. Также обратите внимание, что в выводе journalctl работают параметры поиска / и ?. В листинге 4 показан частичный вывод journalctl.

Листинг 4

Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5648] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5652] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:39:03 kvm NetworkManager[2577]: <info>  [1572752343.5672] dhcp4 (em2): dhclient started with pid 23750
Nov 03 13:39:03 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:39:03 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 7 (xid=0x48a6ece5)
Nov 03 13:39:10 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 12 (xid=0x48a6ece5)
Nov 03 13:39:18 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:39:22 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 20 (xid=0x48a6ece5)
Nov 03 13:39:42 kvm dhclient[23750]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 18 (xid=0x48a6ece5)
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5190] dhcp4 (em2): request timed out
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5191] dhcp4 (em2): state changed unknown -> timeout
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): canceled DHCP transaction, DHCP client pid 23750
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5281] dhcp4 (em2): state changed timeout -> done
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5284] device (em2): state change: ip-config -> failed (reason 'ip-config-
Nov 03 13:39:48 kvm NetworkManager[2577]: <warn>  [1572752388.5291] device (em2): Activation: failed for connection 'Wired connection 2
Nov 03 13:39:48 kvm NetworkManager[2577]: <info>  [1572752388.5295] device (em2): state change: failed -> disconnected (reason 'none',
Nov 03 13:39:48 kvm avahi-daemon[2499]: Withdrawing address record for fe80::8cce:3bf7:7f8b:9335 on em2.
Nov 03 13:40:01 kvm systemd[1]: Created slice User Slice of root.
Nov 03 13:40:01 kvm systemd[1]: Started Session 867 of user root.
Nov 03 13:40:01 kvm CROND[23918]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Nov 03 13:40:01 kvm systemd[1]: Removed slice User Slice of root.
Nov 03 13:40:03 kvm gnome-shell[3798]: g_array_unref: assertion 'array' failed
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:41:12 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.208 52:54:00:01:b4:d3
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:16 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.169 52:54:00:d2:7d:a4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPREQUEST(virbr1) 192.168.122.145 52:54:00:66:3d:c4
Nov 03 13:43:27 kvm dnsmasq-dhcp[3529]: DHCPACK(virbr1) 192.168.122.145 52:54:00:66:3d:c4 server2
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6056] policy: auto-activating connection 'Wired connection 2' (17698f02-4
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6067] device (em2): Activation: starting connection 'Wired connection 2'
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6068] device (em2): state change: disconnected -> prepare (reason 'none',
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6073] device (em2): state change: prepare -> config (reason 'none', sys-i
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6339] device (em2): state change: config -> ip-config (reason 'none', sys
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6347] dhcp4 (em2): activation: beginning transaction (timeout in 45 secon
Nov 03 13:44:48 kvm NetworkManager[2577]: <info>  [1572752688.6396] dhcp4 (em2): dhclient started with pid 24344
Nov 03 13:44:48 kvm avahi-daemon[2499]: Registering new address record for fe80::8cce:3bf7:7f8b:9335 on em2.*.
Nov 03 13:44:48 kvm dhclient[24344]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8 (xid=0x4c41d823)

Что делает journalctl гибкой командой, так это то, что ее многочисленные опции фильтрации позволяют вам показать именно то, что вам нужно. Упражнение 3 показывает некоторые из наиболее интересных вариантов.

Упражнение 3
В этом упражнении вы узнаете, как работать с различными оциями journalctl.

1. Введите journalctl. Вы увидите содержимое журнала с момента последнего запуска сервера, начиная с начала журнала. Содержимое отображается в меньшем количестве, поэтому вы можете использовать, например, less для просмотра файла.

2. Введите q, чтобы выйти из пейджера. Теперь введите journalctl —no-pager. Эта опция показывает содержимое журнала без использования пейджера.

3. Введите journalctl -f. Эта опция открывает режим просмотра в реальном времени, который позволяет видеть новые сообщения в режиме реального времени.

4. Введите journalctl и дважды нажмите клавишу Tab. Будут показаны конкретные опции, которые можно использовать для фильтрации. Выполните, например, journalctl _UID=0.

5. Введите journalctl -n 20. Опция -n 20 отображает последние 20 строк журнала (так же, как tail -n 20).

6. Теперь введите journalctl -p err. Эта команда показывает только ошибки.

7. Если вы хотите просмотреть сообщения журнала, записанные за определенный период времени, вы можете использовать команды —since и —until. Оба варианта принимают параметр времени в формате ГГГГ-ММ-ДД чч:мм:сс. Кроме того, вы можете использовать yesterday, today и tomorrow в качестве опций. Итак, введите journalctl —since yesterday, чтобы показать все сообщения, которые были написаны со вчерашнего дня.

8. journalctl позволяет комбинировать различные варианты. Итак, если вы хотите показать все сообщения с приоритом err, которые были написаны со вчерашнего дня, то используйте journalctl —since yesterday -p err.

9. Если вам нужно как можно больше подробностей, используйте journalctl -o verbose.

В предыдущем упражнении вы ввели journalctl -o verbose, чтобы показать подробный вывод.
В листинге 5 приведен пример подробного вывода. Вы можете увидеть, что вывод предоставляет подробную информацию для всех элементов, которые были логированы, в том числе PID, идентификатор связанный с учетной записью пользователя и группы и многое другое.

Листинг 5

[root@kvm ~]# journalctl -o verbose
-- Logs begin at Tue 2019-10-29 13:15:14 +10, end at Sun 2019-11-03 14:04:03 +10. --
Tue 2019-10-29 13:15:14.573354 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=1;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d0a;t=596040660742a;
    PRIORITY=6
    _TRANSPORT=driver
    MESSAGE=Runtime journal is using 8.0M (max allowed 2.3G, trying to leave 3.5G free of 23.5G available → current limit 2.3G).
    MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
    _PID=184
    _UID=0
    _GID=0
    _COMM=systemd-journal
    _EXE=/usr/lib/systemd/systemd-journald
    _CMDLINE=/usr/lib/systemd/systemd-journald
    _CAP_EFFECTIVE=5402800cf
    _SYSTEMD_CGROUP=/system.slice/systemd-journald.service
    _SYSTEMD_UNIT=systemd-journald.service
    _SYSTEMD_SLICE=system.slice
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
Tue 2019-10-29 13:15:14.573478 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=2;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104d85;t=59604066074a6;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    MESSAGE=microcode: microcode updated early to revision 0x1d, date = 2018-05-11
Tue 2019-10-29 13:15:14.573513 +10 [s=4ef8b4f72a8f4b768f2ca65565a59ecc;i=3;b=eb2dcb353f4744b9933a2aa62af0ba23;m=104da8;t=59604066074c9;
    PRIORITY=6
    _BOOT_ID=eb2dcb353f4744b9933a2aa62af0ba23
    _MACHINE_ID=ee210f72c9ee465a83798398ca1e01f0
    _HOSTNAME=kvm
    _SOURCE_MONOTONIC_TIMESTAMP=0
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0

Сохранение журнала systemd

По умолчанию журнал хранится в файле /run/log/journal. Весь каталог /run используется только для информации о текущем состоянии процесса, что означает, что журнал очищается при перезагрузке системы. Чтобы сделать журнал постоянным между перезагрузками системы, вы должны убедиться, что существует каталог /var/log/journal.

Даже если журнал записывается в постоянный файл в /var/log/journal, это не означает, что журнал сохраняется вечно. Журнал имеет встроенную ротацию логов, которая будет использоваться ежемесячно. Кроме того, максимальный размер журнала ограничен 10% размера файловой системы, и он также прекратит расти, если менее 15% файловой системы все еще свободно. Если это произойдет, самые старые сообщения из журнала автоматически удаляются, чтобы освободить место для новых сообщений. Чтобы изменить эти настройки, вы можете изменить файл /etc/systemd/journald.conf. Вы увидите, что в этом файле также можно установить некоторые другие параметры (Листинг 6).

Листинг 6

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info

Сделать журнал постоянным не сложно. Упражнение 4 показывает, как это сделать.

Упражнение 4
В этом упражнении вы узнаете, как сделать журнал journald постоянным.

1. Войдите под root и введите mkdir /var/log/journal.

2. Прежде чем journald сможет записать журнал в этот каталог, вы должны установить владельца. Введите chown root:systemd-journal /var/log/journal, а затем chmod 2755 /var/log/journal.

3. Затем вы можете либо перезагрузить систему (недостаточно перезапустить службу systemd-journald), либо воспользоваться командой killall -USR1 systemd-journald.

4. Журнал systemd теперь сохраняется при перезагрузках. Если вы хотите просмотреть сообщения журнала с момента последней перезагрузки, используйте journalctl -b.

Рекомендую прочитать «Логи в Linux часть 2. Расширенные функции логов».

Источник

0

1

Здравствуйте, раньше не работал с centos. Хостер дал доступ только по ssh, зашёл через putyy.
На сайте происходит какая-то ошибка(не работает один скрипт) но я не знаю как посмотреть error.log апача через эту консоль.
даю команду /var/log/httpd/error_log (этот путь дал хостер)
но выходит сообщение
-bash: /var/log/httpd/error_log: Permission denied

А если в корне дать команду ls — так там вообще папок var, log, http — нету.

Есть ли какая нибудь системная команда чтобы посмотреть этот лог файл ?

Источник

Время на прочтение
6 мин

Количество просмотров 413K

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

Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

приложения;
события;
службы;
системный.

Большинство же лог файлов содержится в директории /var/log.

/var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
/var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
/var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.

Поддерживаемые уровни журналирования (приоритеты):
   emerg - система неиспользуемая
   alert - действие должно быть произведено немедленно
    crit - условия критичности
     err - условия ошибок
    warn - условия предупреждений
  notice - обычные, но значимые условия
    info - информационный
   debug - отладочные сообщения

(5:520)$ dmesg -l err
[1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81
[1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81

/var/log/alternatives.log — Вывод программы update-alternatives, в котором находятся символические ссылки на команды или библиотеки по умолчанию.
/var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
/var/log/audit — Записи, созданные службой аудита auditd.
/var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
/var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
/var/log/cups — Все, что связано с печатью и принтерами.
/var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog.
var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
/var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
/var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
/var/log/samba/ — Логи файлового сервера Samba, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
/var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
/var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.

/var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
/var/log/emerge.log — Для ebuild-ов установленных из Portage с помощью emerge в Gentoo Linux.
/var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

/var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last.
/var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2.
/var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
/var/log/utmp — Список входов пользователей в систему на данный момент.
/var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump.

(5:535)$ sudo utmpdump /var/log/wtmp
[5] [02187] [l0  ] [        ] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:07 2015]
[1] [00000] [~~  ] [shutdown] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:08 2015]
[2] [00000] [~~  ] [reboot  ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[8] [00368] [rc  ] [        ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[1] [20019] [~~  ] [runlevel] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]

И другие журналы

Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.

/var/log/mysql/ — Лог базы данных MySQL.
/var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
/var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

~/.xsession-errors — Вывод stderr графических приложений X11.

Initializing  "kcm_input" :  "kcminit_mouse"
Initializing  "kcm_access" :  "kcminit_access"
Initializing  "kcm_kgamma" :  "kcminit_kgamma"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing.
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
Qt: Session management error: networkIdsList argument is NULL

~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f. Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>.

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

$ aptitude install lnav #Debian/Ubuntu/LinuxMint
$ yum install lnav #RedHat/CentOS
$ dnf install lnav #Fedora
$ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords
$ yaourt -S lnav #Arch

Навигатор журналов lnav понимает ряд форматов файлов.

Access_log веб сервера.
CUPS page_log
Syslog
glog
dpkg.log
strace
Произвольные записи с временными отметками
gzip, bzip
Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

Программа умеет напрямую открывать архивный файл.

(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу <i>. Это с моего syslog-а.

Mon May 02 20:25:00        123 normal         3 errors         0 warnings         0 marks
Mon May 02 22:40:00          2 normal         0 errors         0 warnings         0 marks
Mon May 02 23:25:00         10 normal         0 errors         0 warnings         0 marks
Tue May 03 07:25:00         96 normal         3 errors         0 warnings         0 marks
Tue May 03 23:50:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 07:40:00         96 normal         3 errors         0 warnings         0 marks
Wed May 04 08:30:00          2 normal         0 errors         0 warnings         0 marks
Wed May 04 10:40:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 11:50:00        126 normal         2 errors         1 warnings         0 marks

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.

Использованные материалы

lnav — An Advanced Log File viewer for Linux
What Are Linux Logs? How to View Them, Most Important Directories, and More
Как посмотреть логи в Linux

Источник