Centos посмотреть ошибки - Не ошибается лишь тот, кто ничего не делает!

8 июня, 2015 12:30 пп
54 956 views
| 1 комментарий

Centos, Debian, Linux, Ubuntu, VPS

Администраторам 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 ~]#

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

Заключение

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

Tags: CentOS 6.4, Debian 7, Linux, Logrotate, rsyslog, Ubuntu 12

Источник

Содержание:

Важные логи сайта
Расположение логов
Чтение записей в логах
Просмотр с помощью команды tail
Просмотр с помощью ISPManager
Программы для анализа логов
Ведение логов медленных запросов сервера
Ведение логов с помощью Logrotate

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

Важные логи сайта

Access.log — логи посещений пользователей и ботов. Позволяет составить более точную и подробную статистику, нежели сторонние ресурсы, выполняющие внешнее сканирование сайта и отправляющие ряд ненужных запросов серверу. Благодаря данному логу можно получить информацию об используемом браузере и IP-адрес посетителя, данные о местонахождении клиента (страна и город) и многое другое. Стоит обратить внимание, если сайт имеет высокую посещаемость, то анализ логов сервера потребует больше времени. Поэтому для составления статистики стоит использовать специализированные программы (анализаторы).
Error.log — программные ошибки сервера. Стоит внимательно отнестись к анализу данного лога, ведь боты поисковиков, сканируя, получают все данные о работе сайта. При обнаружении большого количества ошибок, сайт может попасть под санкции поисковых систем. В свою очередь из записей данного журнала можно узнать точную дату и время ошибки, IP-адрес получателя, тип и описание ошибки.
Slow.log (название зависит от используемой оболочки сервера) — в данный журнал записываются медленные запросы сервера. Так принято обозначать запросы с повышенным порогом задержки, выданные пользователю. Этот журнал позволяет выявить слабые места сервера и исправить проблему. Ниже будет рассмотрен способ включить ведение данного лога на разных типах серверов, а также настройка задержки, с которой записи будут заноситься в файл.

Расположение логов

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

Стандартные пути до Error.log

Nginx

/var/log/nginx/error.log

Php-Fpm

/var/log/php-fpm/error.log

Apache (CentOS)

/var/log/httpd/error_log

Apache (Ubuntu, Debian)

/var/log/apache2/error_log

Стандартные пути до Access.log

Nginx

/var/log/nginx/access.log

Php-Fpm

/var/log/php-fpm/access.log

Apache (CentOS)

/var/log/httpd/access_log

Apache (Ubuntu, Debian)

/var/log/apache2/access_log

Чтение записей в логах

Записи в логах имеют структуру: одно событие – одна строка.

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

Примеры записей

Error.log

[Sat Sep 1 15:33:40.719615 2019] [:error] [pid 10706] [client 66.249.66.61:60699] PHP Notice: Undefined variable: moduleclass_sfx in /var/data/www/site.ru/modules/contacts/default.php on line 14

В приведенном примере:

[Sat Sep 1 15:33:40.719615 2019] — дата и время события.
[:error] [pid 10706] — ошибка и её тип.
[client 66.249.66.61:60699] — IP-адрес подключившегося клиента.
PHP Notice: Undefined variable: moduleclass_sfx in — событие PHP Notice. В данной ситуации — обнаружена неизвестная переменная.
/var/data/www/site.ru/modules/contacts/default.php on line 14 — путь и номер строки в проблемном файле.

Access.log

194.61.0.6 – alex [10/Oct/2019:15:32:22 -0700] "GET /apache_pb.gif HTTP/1.0" 200 5396 "http://www.mysite/myserver.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

В приведенном примере:

194.61.0.6 — IP-адрес пользователя.
alex — если пользователь зарегистрирован в системе, то в логах будет указан идентификатор.
[10/Oct/2019:15:32:22 -0700]— дата и время записи.
«GET /apache_pb.gif HTTP/1.0» — «GET» означает, что определённый документ со страницы сайта был отправлен пользователю. Существует команда «POST», наоборот отправляет конкретные данные (комментарий или любое другое сообщение) на сервер . Далее указан извлечённый документ «Apache_pb.gif», а также использованный протокол «HTTP/1.0».
200 5396 — код и количество байтов документа, которые были возвращены сервером.
«http://www. www.mysite/myserver.html»— страница, с которой был произведён запрос на извлечение документа «Apache_pb.gif».
«Mozilla/4.08 [en] (Win98; I ;Nav)» — данные о пользователе, которой произвёл запрос (используемый браузер и операционная система).

Просмотр логов сервера с помощью команды tail

Выполнить просмотр логов в Linux можно с помощью команды tail. Данный инструмент позволяет смотреть записи в логах, выводя последние строки из файла. По умолчанию tail выводит 10 строк.

Первый вариант использования Tail

tail -f /var/log/syslog

Аргумент «-f» позволяет команде делать просмотр событий в режиме реального времени, в ожидании новых записей в лог файлах. Для прерывания процесса следует нажать сочетание клавиш «Ctrl+C».

На место переменной «/var/log/syslog» в примере следует подставить актуальный адрес до нужных системных журналов.

Второй вариант использования Tail

tail -F /var/log/syslog

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

Если будет использоваться аргумент «-f», команда продолжит отслеживание старого, переименованного журнала. Данный метод делает невозможным просмотр логов в реальном времени, поскольку файл более не актуален.

При использовании аргумента «-F», команда, после окончания записи старого журнала, перейдёт к чтению нового файла с логами. В таком случае просмотр логов в режиме реального времени продолжится.

Аналог команды Tail

tailf /var/log/syslog

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

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

Изменение стандартного количества строк для вывода

Как и отмечалось выше, по умолчанию выводится 10 строк. Если требуется увеличить или уменьшить их количество, в команду добавляется аргумент «-n» и необходимое число строк.

Пример:

tail -f -n 100 /var/log/syslog

При использовании данной команды будут показаны последние 100 строк журнала.

Просмотр логов с помощью ISPManager

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

На главной странице, в панели инструментов «WWW» нужно нажать на вкладку «Журналы».
ISPManager выдаст журналы посещений и серверных ошибок в виде:
- ru.access.log;
- ru.error.log.*
* Вместо «newdomen.ru» из примера в выдаче будет название актуального домена.

Открыть файл лога можно, нажав на «Посмотреть» в верхнем меню.
Для просмотра всех записей журнала, необходимо нажать на «Скачать» и сохранить файл на локальный носитель.
Более старые версии логов можно найти во вкладке «Архив».

Программы для анализа логов

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

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

Статические программы

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

WebLog Expert

Возможности

Предоставление информации об активность сайта, количестве посетителей, доступ к файлам, URL страницы, ссылающиеся страницы, информацию о пользователе (браузер и операционная система).
Создание отчётов в формате HTML (.html), PDF (.pdf), CSV (.csv).
Поддерживает анализ логов Nginx, Apache, ISS.
Чтение файлов даже в архивах ZIP (.zip), GZ (.gz).

Web Log Explorer

Возможности

Создание многоуровневых отчётов, включающих количество посетителей, маршруты пользователей по сайту, местоположение хостов (страна и город), указанные в поисковике ключевые слова.
Поддержка более 43 форматов логов.
Возможность прямой загрузки логов с FTP, HTTP сервера.
Чтение архивированных журналов.

Программы для анализа в режиме реального времени

Эти инструменты встраиваются в программную среду сервера, анализируют данные в реальном времени и записывают непрерывный отчёт.

GoAccess

Возможности

Автоматическая генерация отчёта в формате HTML (.html), JSON (.json), CSV (.csv).
При подключении к серверу через SSH, возможен анализ в браузере и в терминале
Поддержка почти всех форматов (Apache, Nginx, Amazon S3, Elastic Load Balancing, CloudFront и др.).

Logstash

Возможности

Постоянная генерация отчёта в файл JSON (.json).
Получение и анализ информации из нескольких источников.
Возможность пересылать журналы с помощью Filebeat.
Поддержка анализа системных журналов.
Поддерживается большое количество форматов: от Apache до Log4j (Java).

Ведения логов медленных запросов сервера

Анализ данного лога позволяет определить на какие типы запросов сервер отвечает долго. В идеале задержка должна составлять не более 1 секунды.

На некоторых типах оболочек (MySQL, PHP-FPM) ведение данного лога по умолчанию отключено. Процесс запуска и ведения зависит от сервера.

MySQL

Если сервер управляется с помощью MySQL, то необходимо создать каталог и сам файл для ведения журнала с помощью команд:

mkdir /var/log/mysql

touch /var/log/mysql/mysql-slow.log

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

chown mysql:mysql /var/log/mysql/mysql-slow.log

После выполнения предыдущих действий, нужно совершить вход в командную строку MySQL под учётной записью суперпользователя:

mysql -uroot -p

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

> SET GLOBAL slow_query_log = 'ON';

> SET GLOBAL slow_launch_time = 2;

> SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';

> FLUSH LOGS;

В примере:

slow_query_log — запускает ведение журналов медленных запросов.
slow_launch_time — указывает максимальную задержку отклика, после которой статистика запроса попадёт в журнал. В данном случае запись в логи происходит при преодолении откликом порога 2 секунды.
slow_query_log_file — задаёт путь до используемого журнала.

Проверить статус и параметры ведения лога медленных запросов можно командой:

> SHOW VARIABLES LIKE '%slow%';

Выход из консоли MySQL выполняется командой:

> exit

После выполнения всех предыдущих действий, можно просмотреть логи сервера. Для этого в терминале вводится:

tail -f /var/log/mysql/mysql-slow.log

PHP-FPM

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

vi /etc/php-fpm.d/www.conf

Далее нужно найти строки:

request_slowlog_timeout = 10s — параметр, позволяющий указать задержку, с которой запись о длительном запросе попадёт в журнал.
slowlog = /var/log/php-fpm/www-slow.log — параметр, указывающий путь до актуального файла логирования (.log).

После применения изменений, необходимо перезагрузить сервер PHP-FPM. Для этого в консоль вводится команда:

systemctl restart php-fpm

Просмотр логов запускается командой:

tail -f /var/log/php-fpm/www-slow.log

Анализ логов медленных запросов

Логи медленных запросов могут за незначительное время вырасти до огромных размеров. Для сортировки и отображения повторяющихся запросов рекомендуется использовать программу MySQLDumpSlow.

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

mysqldumpslow местонахождение/файла

Ведение логов в Logrotate

На больших ресурсах журналы могут достигать огромных размеров, поэтому нужно своевременно архивировать или очищать логи. С помощью утилиты Logrotate можно управлять ведением журналов: настроить период ротации (архивирование старого журнала и создание нового), период и количество хранения журналов и многое другое.

Изначально программа отсутствует в системе. Ниже приведены команды для инсталляции Logrotate из официальных репозиториев.

Ubuntu, Debian:

sudo apt install logrotate

CentOS:

sudo yum install logrotate

После установки необходимо проверить путь для будущих конфигурационных файлов. Для правильной работы они должны находится в папке «logrotate.d». Проверить данный параметр можно открыв конфигурационный файл командой:

nano /etc/logrotate.conf

В директории «RPM packages drop log rotation information into this directory» должна присутствовать строка:

include /etc/logrotate.d

Теперь создаётся конфигурационный файл «rsyslog.conf». В нём будет находиться конфигурацию по работе с логами. Для создания файла в терминале вводится команда:

sudo nano /etc/logrotate.d/rsyslog.conf

В окне терминала откроется текстовой редактор. Теперь нужно внести конфигурацию, как указано в образце. В качестве примера будет использоваться журнал посещений «Access.log» (Nginx).

/var/log/nginx/access.log {
daily
rotate 3
size 500M
compress
delaycompress
}

Теперь остаётся только запустить Logrotate. Для этого вводится команда:

sudo logrotate -d /etc/logrotate.d/rsyslog.conf

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

ls /var/cron.daily/

Источник

What are Linux Log Files?

All Linux systems create and store information log files for boot processes, applications, and other events. These files can be a helpful resource for troubleshooting system issues.

Most Linux log files are stored in a plain ASCII text file and are in the /var/log directory and subdirectory. Logs are generated by the Linux system daemon log, syslogd or rsyslogd.

This tutorial will walk you through how to find and read Linux log files, and configure the system logging daemon.

Tutorial on how to view and read Linux log files.

Prerequisites

Access to Linux
A user account with root user privileges

1. First, open the Linux terminal as a root user. This will enable root privileges.

2. Use the following command to see the log files:

cd /var/log

3. To view the logs, type the following command:

ls

The command displays all Linux log files, such as kern.log and boot.log. These files contain the necessary information for the proper function of the operating system.

How to list all Linux log files in command line.

Log files are accessed using root privileges. By definition, root is the default account that has access to all Linux files.

Use the following example line command to access the respective file:

sudo less [log name here].log

This command displays a timeline of all information related to that operation.

Note that log files are stored in plain text so they can be viewed by using the following standard commands:

zcat – Displays all the contents of logfile.gz

zmore – See the file in pages, without decompressing the files

zgrep – Search inside a compressed file

grep – Find all occurrences of a search term in a file or filter a log file

<a href="https://phoenixnap.com/kb/linux-tail" target="_blank" rel="noreferrer noopener">tail</a> – Output the last few lines of files

head – View the very beginning of text files

Note: Check out our comprehensive guide on grep to learn how to use it with examples.

Important Linux System Logs

Logs can tell a lot about the operations of a system. A good understanding of each type of file will help how to distinguish the respective logs.

Most directories can be grouped into one of four categories:

System Logs
Event Logs
Application Logs
Service Logs

Many of these logs can be located in the var/log subdirectory.

System Logs

Systems log files are needed for Linux to work. On its own, it contains the most significant amount of information about system functionality. The most common log files are:

/var/log/boot.log: System Boot log (the boot log stores all information related to booting operations)
/var/log/auth.log: Auth logs (the authentication log stores all authentication logs, including successful and failed attempts)
/var/log/httpd/: Apache access and error logs
/var/log/mysqld.log: MySQL database server log file
/var/log/debug: Debug logs (the debug log stores detailed messages related to debugging and is useful for troubleshooting specific system operations)
/var/log/daemon.log: Daemon logs (the daemon log contains information about events related to running the Linux operation)
/var/log/maillog: Mail server logs (the mail log stores information related to mail servers and archiving emails)
/var/log/kern.log: Kernel logs (the kernel log stores information from the Ubuntu Linux kernel)
/var/log/yum.log: Yum command logs

System Logging Daemon

A daemon log is a program that runs in the background and is essential for system operations. These logs have their own category of logs and are seen as the heart of the logging operations for any system.

The path for the system login daemon’s configuration is /etc/syslog.conf.

Each file consists of a selector and an action entry field. The syslogd daemon can forward log messages as well. This can be useful for debugging purposes.

Application Logs

Application logs store information relevant to any application that is executed. This can include error messages, signs of system compromise, and browser identification string.

Log files that fall into this category include CUPS Print System logs, Rootkit Hunter log, Apache HTTP server logs, Samba SMB server logs, and X11 server log.

Non-Human-Readable Logs

Not all logs are designed in a human-readable format. Some are designed only to be read by system applications. Such files are often related to login information. They include login failure logs, last logins logs, and login records.

There are tools and software for reading Linux log files. They are not necessary for reading files as most can be read directly from the Linux terminal.

Supplemental GUIs for Viewing Linux Log Files

System Log Viewer is a GUI that can be used to monitor system logs.

The interface provides several functions for managing logs, including a log statistics display. It is a user-friendly log monitoring GUI.

Useful features include:

A live view of logs
Number of lines in the log
Log size
Most recent log dates
Modifications made to logs
Filters
Keyboard Shortcuts

Alternatively, use Xlogmaster which can monitor a considerable number of log files. It features three different modes:

Run mode: Starts a specified program and obtains stdout
Cat mode: Cats files within specified intervals
Tail mode: Checks log files within regular intervals

Xlogmaster is useful for increasing security. It translates all data for highlighting, hiding lines, and displays this information for taking user requested action.

How to Configure Log Files on Ubuntu and CentOS

This section explains different mechanisms for configuring log files. Let’s start with a CentOS example.

To view users currently logged onto a Linux server, enter the who command as a root user:

who

List users that are logged into the Linux system.

This also lists the login history of users. To view the login history of the system administrator, enter the following command:

last reboot

View login hisotry of the system administrator.

To view information of the last login, enter:

lastlog

View information of the last login onto Linux system.

Execute Log Rotation

Log files that have zeroes appended at the end are rotated files. That means log file names have automatically been changed within the system.

The purpose of log rotation is to compress outdated logs that are taking up space. Log rotation can be done using the logrotate command. This command rotates, compresses, and mails system logs.

logrotate handles systems that create significant amounts of log files. The command is used by the cron scheduler and reads the logrotate configuration file /etc/logrotate.conf. It’s also used to read files in the logrotate configuration directory.

To include additional functionality to logrotate, start by entering the following command:

var/log/log name here].log {
Missingok
Notifempty
Compress
Size 20k
Daily
Create 0600 root root
}

It compresses and resizes the desired log file.

The commands perform the actions as follows:

missingok – Tells logrotate not to output an error if a log file is missing

notifempty – Does not rotate the log file if it is empty. It reduces the size of the log file with gzip

size – Ensures that the log file does not exceed the specified dimension and rotates it otherwise

daily – Rotates the log files on a daily schedule. This can also be done on a weekly or monthly schedule

create – Instantiates a log file where the owner and group are a root user

Conclusion

A thorough understanding of how to view and read Linux logs is necessary for troubleshooting a Linux system.

Using the proper commands and tools can simplify this process.

Источник

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. Я это уже много раз говорил ранее и вот сказал ещё раз. Раньше в Linux для сохранения журналов сервисов использовался отдельный демон под названием syslogd. Но с приходом системы инициализации systemd большинство функций касающихся управления сервисами перешли под её управление. В том числе и управление логами.

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

Синтаксис команды очень простой. Достаточно выполнить команду без опций или передав ей нужные опции. Если утилита не выводит ничего, выполните её от имени суперпользователя:

journalctl опции

А теперь давайте разберем основные опции journalctl:

—full, -l — отображать все доступные поля;
—all, -a — отображать все поля в выводе full, даже если они содержат непечатаемые символы или слишком длинные;
—pager-end, -e — отобразить только последние сообщения из журнала;
—lines, -n — количество строк, которые нужно отображать на одном экране, по умолчанию 10;
—no-tail — отображать все строки доступные строки;
—reverse, -r — отображать новые события в начале списка;
—output, -o — настраивает формат вывода лога;
—output-fields — поля, которые нужно выводить;
—catalog, -x — добавить к информации об ошибках пояснения, ссылки на документацию или форумы там, где это возможно;
—quiet, -q — не показывать все информационные сообщения;
—merge, -m — показывать сообщения из всех доступных журналов;
—boot, -b — показать сообщения с момента определенной загрузки системы. По умолчанию используется последняя загрузка;
—list-boots — показать список сохраненных загрузок системы;
—dmesg, -k — показывает сообщения только от ядра. Аналог вызова команды dmesg;
—identifier, -t — показать сообщения с выбранным идентификатором;
—unit, -u — показать сообщения от выбранного сервиса;
—user-unit — фильтровать сообщения от выбранной сессии;
—priority, -p — фильтровать сообщения по их приоритету. Есть восемь уровней приоритета, от 0 до 7;
—grep, -g — фильтрация по тексту сообщения;
—cursor, -c — начать просмотр сообщений с указанного места;
—since, -S, —until, -U — фильтрация по дате и времени;
—field, -F — вывести все данные из выбранного поля;
—fields, -N — вывести все доступные поля;
—system — выводить только системные сообщения;
—user — выводить только сообщения пользователя;
—machine, -M — выводить сообщения от определенного контейнера;
—header — выводить заголовки полей при выводе журнала;
—disk-usage — вывести общий размер лог файлов на диске;
—list-catalog — вывести все доступные подсказки для ошибок;
—sync — синхронизировать все не сохраненные журналы с файловой системой;
—flush — перенести все данные из каталога /run/log/journal в /var/log/journal;
—rotate — запустить ротацию логов;
—no-pager — выводить информацию из журнала без возможности листать страницы;
-f — выводить новые сообщения в реальном времени, как в команде tail;
—vacuum-time — очистить логи, давностью больше указанного периода;
—vacuum-size — очистить логи, чтобы размер хранилища соответствовал указанному.

Горячие клавиши journalctl

По умолчанию информация лога выводится в формате, в котором её можно листать. Давайте разберем горячие клавиши, которые вы можете для этого использовать:

Стрелка вниз, Enter, e или j — переместиться вниз на одну строку;
Стрелка вверх, y или k — переместиться на одну строку вверх;
Пробел — переместиться на одну страницу вниз;
b — переместиться на одну страницу вверх;
Стрелка вправо, стрелка влево — горизонтальна прокрутка;
g — перейти на первую строку;
G — перейти на последнюю строку;
p — перейти на позицию нужного процента сообщений. Например, 50p перенесет курсор на середину вывода;
/ — поиск по журналу;
n — найти следующее вхождение;
N — предыдущее вхождение;
q — выйти.

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

Шпаргалка по journalctl

Вывод journalctl представляет из себя цельный список всех сохраненных сообщений. Если вы запустите команду journalctl без параметров, то получите самые первые сообщения, которые были сохранены. В моем случае это данные за 13 января:

sudo journalctl

Чтобы найти именно то, что вам нужно, необходимо научится перемещаться по этому списку. Формат вывода лога довольно простой:

янв 13 20:55:55 sergiy-pc kernel: Linux version 4.15.0-43-generic

янв 13 20:55:55 — дата и время события;
sergiy-pc — хост, на котором произошло событие;
kernel — источник события, обычно это программа или сервис. В данном случае ядро;
Linux version 4.15.0-43-generic — само сообщение.

Давайте перейдем к примерам фильтрации и перемещения.

1. Просмотр логов сервисов

Самый частый случай использования journalctl — это когда вы пытаетесь запустить какой-либо сервис с помощью systemd, он не запускается и systemd выдает вам такое сообщение подобного содержания: Failed to start service use journalctl -xe for details. Система сама предлагает вам какую команду надо выполнить:

sudo journalctl -xe

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

Чтобы отфильтровать сообщения только от определенного сервиса можно использовать опцию -u. Например:

sudo journalctl -eu apache2.service

2. Просмотр логов в режиме tail

С помощью опции -f можно указать утилите, что необходимо выводить новые сообщения в реальном времени:

sudo journalctl -f

В этом режиме less не поддерживается, поэтому для выхода нажмите сочетание клавиш Ctrl+C.

3. Просмотр логов загрузки

В логе journalctl содержатся все логи, в том числе и логи загрузки. Для того чтобы открыть лог последней загрузки используйте опцию -b:

sudo journalctl -b

Посмотреть список всех сохраненных загрузок можно командой:

sudo journalctl -list-boots

Теперь, чтобы посмотреть сообщения для нужной загрузки используйте её идентификатор:

sudo journalctl -b 37d5c906c9c6404682f029b2c34ec9dc

4. Фильтрация по дате

С помощью опции —since вы можете указать дату и время, начиная с которой нужно отображать логи:

sudo journalctl --since "2019-01-20 15:10:10"

Опция —until помогает указать по какую дату вы хотите получить информацию:

sudo journalctl -e --until "2019-01-20 15:05:50"

Или сразу скомбинируем две эти опции чтобы получить логи за нужный период:

sudo journalctl --since "2019-01-20 15:10:10" --until "2019-01-20 15:05:50"

Кроме даты в формате YYYY-MM-DD в этих опциях можно использовать такие слова, как yesterday, today, и tomorrow. Также допустимы конструкции 1 day ago (один день назад) или 3 hours ago (три часа назад). Ещё можно использовать знаки + и -. Например -1h30min будет означать полтора часа назад.

5. Журнал ядра

Если вы хотите посмотреть только сообщения ядра используйте опцию -k:

sudo journalctl -ek

6. Настройка формата вывода

По умолчанию journalctl выводит информацию с помощью утилиты less, в которой вы можете её удобно листать и просматривать. Но формат вывода можно изменить:

short — используется по умолчанию;
verbose — также, как и short, только выводится намного больше информации;
json — вывод в формате json, одна строка лога в одной строке вывода;
json-pretty — форматированный вывод json для более удобного восприятия;
cat — отображать только сообщения, без метаданных.

Чтобы указать нужный формат используйте опцию -o. Например:

sudo journalctl -o json-pretty

Или:

sudo journalctl -eo json-pretty

7. Очистка логов

Сначала нужно посмотреть сколько ваши логи занимают на диске. Для этого используйте такую команду:

sudo journalctl --disk-usage

Чтобы уменьшить размер лога можно использовать опцию —vacuum-size. Например, если вы хотите, чтобы ваши файлы журналов занимали на диске не более 2 Гб, выполните команду:

sudo journalctl --vacuum-size=2G

Теперь старые логи будут удалены, пока общий объем хранилища не будет составлять 2 гигабайта. Также можно удалять логи по времени. Для этого используется опция —vacuum-time. Например, оставим только логи за последний год:

journalctl --vacuum-time=1years

Выводы

В этой статье мы разобрали как пользоваться journalctl в Linux. Наличие этой утилиты в системе не означает, что теперь вы не можете пользоваться обычными файлами логов. Большинство сервисов как и раньше пишут свои основные логи в файлы, а в лог journalctl пишутся сообщения при старте сервисов, а также различные системные сообщения.

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Источник

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

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

Демон rsyslog

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

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

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

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

Тестирование ротации

Заключение

Важные логи сайта

Расположение логов

Стандартные пути до Error.log

Nginx

Php-Fpm

Apache (CentOS)

Apache (Ubuntu, Debian)

Стандартные пути до Access.log

Nginx

Php-Fpm

Apache (CentOS)

Apache (Ubuntu, Debian)

Чтение записей в логах

Примеры записей

Error.log

Access.log

Просмотр логов сервера с помощью команды tail

Первый вариант использования Tail

Второй вариант использования Tail

Аналог команды Tail

Изменение стандартного количества строк для вывода

Просмотр логов с помощью ISPManager

Программы для анализа логов

Статические программы

WebLog Expert<img decoding="async" loading="lazy" src="https://eternalhost.net/wp-content/uploads/2020/09/4-WebLog-Expert.png" alt="WebLog Expert" width="989" height="486" />

Возможности

Web Log Explorer

<img decoding="async" loading="lazy" src="https://eternalhost.net/wp-content/uploads/2020/09/5-Web-Log-Explorer.png" alt="Web Log Explorer" width="862" height="384" />

Возможности

Программы для анализа в режиме реального времени

GoAccess

<img decoding="async" loading="lazy" src="https://eternalhost.net/wp-content/uploads/2020/09/6-GoAccess.png" alt="GoAccess" width="862" height="445" />

Возможности

Logstash

<img decoding="async" loading="lazy" src="https://eternalhost.net/wp-content/uploads/2020/09/7-Logstash.png" alt="Logstash" width="862" height="484" />

Возможности

Ведения логов медленных запросов сервера

MySQL

PHP-FPM

Анализ логов медленных запросов

Ведение логов в Logrotate

What are Linux Log Files?

Important Linux System Logs

System Logs

System Logging Daemon

Application Logs

Non-Human-Readable Logs

Supplemental GUIs for Viewing Linux Log Files

How to Configure Log Files on Ubuntu and CentOS

Execute Log Rotation

What Logs Does Syslog Generate?

What Should I Monitor Logs?

Горячие клавиши journalctl

Шпаргалка по journalctl

1. Просмотр логов сервисов

2. Просмотр логов в режиме tail

3. Просмотр логов загрузки

4. Фильтрация по дате

5. Журнал ядра

6. Настройка формата вывода

7. Очистка логов

Выводы

WebLog Expert