Centos 7 журнал ошибок

Overview

The guides will help in understanding the RHEL / CentOS 7 logging system “journalctl”. Journald Daemon centralizes the management of logs regardless of where the messages are originated.

Applies To

RHEL 7, CentOS 7

Pre-requisites

None

journald.conf – Configurable Values Table

Configuration Attribute

Configurable Values

Storage

“volatile”, “persistent”, “auto” and “none”

Compress

“yes”, “no”

Seal

“yes”, “no”

SplitMode

“login”, “uid” and “none”

SyncIntervalSec

User defined

RateLimitInterval

User defined

RateLimitBurst

User defined

SystemMaxUse

Customizable, applies when Storage set to persistent

SystemKeepFree

Customizable, applies when Storage set to persistent

SystemMaxFileSize

Customizable, applies when Storage set to persistent

RuntimeMaxUse

Customizable, applies when Storage set to persistent

RuntimeKeepFree

Customizable, applies when Storage set to persistent

RuntimeMaxFileSize

Customizable, applies when Storage set to persistent

MaxRetentionSec

User defined

MaxFileSec

User defined

ForwardToSyslog

“yes”, “no”

ForwardToKMsg

“yes”, “no”

ForwardToConsole

“yes”, “no”

TTYPath

/dev/console

MaxLevelStore

“emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”

or integer value from 0 – 7

MaxLevelSyslog

“emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”

MaxLevelKMsg

or integer value from 0 – 7

MaxLevelConsole

“emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”

journald.conf – Attribute Purpose Table

Configuration Attribute

Purpose

Storage

Where to store journal data, for persistent data storage, create /run/log/journal/

Compress

Takes a boolean value. If enabled (the default)

Seal

Takes a boolean value. If enabled (the default)

SplitMode

Controls whether to split up journal files per user

SyncIntervalSec

Configures the rate limiting that is applied to all messages generated on the system

RateLimitInterval

Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitInterval=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over

RateLimitBurst

SystemMaxUse

Enforce size limits on the journal files stored.

The options prefixed with “System” apply to the journal files when stored on a persistent file system, more specifically /var/log/journal.

The options prefixed with “Runtime” apply to the journal files when stored on a volatile in-memory file system, more specifically /run/log/journal.

The former is used only when /var is mounted, writable, and the directory /var/log/journal exists. Otherwise, only the latter applies.

SystemKeepFree

SystemMaxFileSize

RuntimeMaxUse

RuntimeKeepFree

RuntimeMaxFileSize

MaxRetentionSec

The maximum time to store journal entries. This controls whether journal files containing entries older then the specified time span are deleted.

MaxFileSec

The maximum time to store entries in a single journal file before rotating to the next one.

ForwardToSyslog

Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users.

ForwardToKMsg

ForwardToConsole

ForwardToWall

TTYPath

 Change the console TTY to use if ForwardToConsole=yes

MaxLevelStore

Controls the maximum log level of messages that are stored on disk, forwarded to syslog, kmsg, the console or wall (if that is enabled)

MaxLevelSyslog

MaxLevelKMsg

MaxLevelConsole

MaxLevelWall

 Default Setting – Configuration File – journald.conf

Logs are controlled by file “journald.conf” which is located in the folder “/etc/systemd/”.

[Journal]

Storage=

…….

The below snippet is default setting configuration file “journald.conf” for journalctl daemon.

journalctl – List Entries – Old Top

List all journal entry that is in the system will be displayed within a pager. The oldest entrieswill be displayed at top.

journalctl

journalctl – List Entries – New Top

List all journal entry that is in the system will be displayed within a pager. The newest entrieswill be displayed at top.

journalctl –reverse 

journalctl – List Entries – Tail

List all journal entry that is in the system will be displayed. Last 10 lines would be displayed, similar to running tail /var/log/messages.

journalctl -n

journalctl – List Entries – Tail N Lines

List all journal entry that is in the system will be displayed. Last 15 lines would be displayed, similar to running tail /var/log/messages -n 15.

journalctl -n 15

journalctl – List Entries – Tail Real-time

List all journal entry that is in the system will be displayed in real-time. Last 15 lines would be displayed, similar to running tail /var/log/messages -f.

journalctl -f

journalctl – List Entries – From a Time

List all journal entries that is in the system starting from specific time onwards.

journalctl –since 02:50

journalctl – List Entries – Current Boot

List all journal entries that is in the system starting from current boot.

journalctl -b

journalctl – List Entries – Kernel Logs

List all journal entries pertaining to that of kernel, that is in the system will be displayed.

journalctl -k

journalctl – List Entries – Between Timeframes

List all journal entries that is in the system starting from specific time onwards and until a specific time.

journalctl –since 02:00 –until 02:50

journalctl – List Entries – From Today

List all journal entries that is in the system for today only.

journalctl –since=today

journalctl – List Entries – From Yesterday

List all journal entries that is in the system for yesterday onwards and till now.

journalctl –since=yesterday

Filter Message – By UID (User ID)

List all journal entries that is in the system for a User ID.

journalctl _UID=1000

Filter Message – By GID (Group ID)

List all journal entries that is in the system for a Group ID.

journalctl _GID=1000

Filter Message – By PID (Process ID)

List all journal entries that is in the system for Process ID.

journalctl _PID=1

Filter Message – By Unit (service)

List all journal entries that is in the system for a unit name (service).

journalctl -u httpd.service

Filter Message – By Unit (service) – Verbose

List all journal entries that is in the system for a unit name (service) in verbose mode.

journalctl -f -o verbose UNIT=httpd.service

Filter Message – By Unit (service) – Debugging

List all journal entries that is in the system for a unit name (service) for debugging.

journalctl -f -u httpd.service -l

Filter Message – By Unit from today

Alternatively, you can filter messages by today, yesterday, since and until as well.

journalctl -u httpd.service –since=today

Filter Message – By Hours ago

You can filter messages by hours, minutes and seconds elapsed as well.

journalctl -u httpd.service –since “20 hours ago”

Filter Message – By Minutes ago

You can filter messages by minutes, hours and seconds elapsed as well.

journalctl -u httpd.service –since “1460 min ago”

Filter Message – By Seconds ago

you can filter messages by seconds, hour and minutes elapsed as well.

journalctl -u httpd.service –since “40 sec ago”

Filter Message – By DateTime

you can also filter messages by, from datetime to from datetime using the datetime format “yyyy-mm-dd hh:mm:ss” elapsed as well.

journalctl -u httpd –since “2015-11-16 23:15:00” –until “2015-11-17 23:20:00”

Filter Message – By Syslog Priority

List all journal entries that is in the system by syslog priority.

Value

Severity

0

Emergency

1

Alert

2

Critical

3

Error

4

Warning

5

Notice

6

Informational

7

Debug

Filter Message – By Priority Name

journalctl -p err

or

Filter Message – By Priority Number

journalctl -p 3

Filter Message – By Executable

journalctl /usr/bin/dbus-daemon

journalctl /usr/lib/systemd/systemd

Journalctl – Service Management

Start system-journald

systemctl start systemd-journald

Stop system-journald

systemctl stop systemd-journald

Note: You will not be able to stop journalctl service, because of dependency with systemd

Restart system-journald

systemctl restart systemd-journald

Status system-journald

systemctl status systemd-journald

Verify Corruption

Check the journal file for internal consistency.

journalctl –verify

Disk Space Consumed

To check disk space consumed by all the journals files.

journalctl –disk-usage

Slideshare Information

Guide to manage and use Journalctl is uploaded with screenshots.

Источник

In the past SystemV used syslog (or rsyslog) to log events to a log file. Many times there is a separate log file for each service.

With the switch to SystemD, Red Hat, Fedora, CentOS, etc. also introduced a new logging facility and tool called the journal.  This centralized the collection of logs and allowed administrators one simple robust tool and one location to inspect and manipulate log data.  Here we will cover some of the basics of journalctl, the program used to interface with the logs.

To simply view the logs on your system, you can execute the following command:

journalctl

This will display the logs with the oldest entries first.  Although this is simple, it is not very useful since we do not tend to read logs like a book.

By default journalctl displays the logs in a pager.  It shows you one page of logs requiring you to hit the space bar to proceed.  Also long log lines WILL NOT wrap, they will trail off the right side of the screen.  You can use the right arrow to see the rest of the line.

We will talk more about changing the way the logs are displayed in a different article.  Let’s move on to some basic log viewing commands.

Diplaying Logs by Date

More than likely you are looking for an event. One way to find something is the logs is to display the logs from a certain time.  You can specify a single time and it will display all logs SINCE that time, or you can specify a time window.

To find all logs since December 25th 2015 at 07:00 PM you can run:

journalctl --since "2015-12-25 19:00:00"

To find all logs between December 25th 2015 and January 1st 2016:

journalctl --since "2015-12-25" --until "2016-1-1"

You can also use the more human friendly relative terms.  For example, to see all logs since yesterday:

journalctl --since yesterday

You also have the option to mix the absolute and relative terms:

journalctl --since "2015-12-25" --until "2 hours ago"

Displaying Logs by Unit or Service

Another way to find the logs you need would be to filter the results by unit (or service).  For example, if you want to see all the logs vsftpd (FTP software) produced you can specify that in the journalctl command like so:

journalctl -u vsftpd.service

You can mix in a time, or a time window to find logs from a specific service during a specific time.

To find all the vsftpd logs from December 5 2015 to January 8 2016 you can runt he following command:

journalctl -u vsftpd.service --since "2015-12-05 16:17:47" --until "2016-1-8 15:03:02"

You can also request logs from two different services at the same time.  This comes in handy when trying to get information about how two services are interacting or debugging an issue.

To see all the logs from vsftpd and firewalld you can run this command:

journalctl -u vsftpd.service -u firewalld.service

You can also specify a time in absolute, relative or any combination.

journalctl -u vsftpd.service -u firewalld.service --since "2 days ago"

Displaying Logs by User or Group

Other things you can do is find logs generated by a specific user (UID) or group (GUID).

For example, let’s say I wanted to see all logs from the user «savona».  First I would find their UID like so:

[[email protected] ~]# id savona
uid=1000(savona) gid=1000(savona) groups=1000(savona)

Now that I know their UID is 1000, I can use the _UID filter in journalctl like so:

journalctl _UID=1000

And of course I can mix this with a time window:

journalctl _UID=1000 --since "2 days ago"

Displaying Logs by Process ID

You can also use _PID to search for process id, or _GUID for group id.

journalctl _PID=1221

Displaying Kernel Logs

Since all the logs are kept in one place, we can use the same tool (journalctl) to view just the kernel logs:

journalctl -k

The above command will show you all the kernel messages from the current boot. You can specify a different boot using the boot selection option like so:

journalctl -k -b 2

The above command will show you all the kernel messages from 2 boots ago.

Displaying Logs Since Last Boot

The boot selection option will work on it’s own as well.  If you would like to see all the logs generated since the last boot up, simply give the -b option:

journalctl -b

Displaying Logs by Priority

You can also select to view logs by priority.  The journal uses the same syslog message levels:

0: emerg
1: alert
2: critical
3: error
4: warning
5: notice
6: info
7: debug

To see all logs from priority 4 (warning) and higher:

journalctl -p 4

To see all the logs from priority 3 (error) and higher since last boot:

journalctl -p 3 -b

And of course you can use time windows if you like:

journalctl -p 3 --since "2 days ago"

Tailing or Following the Log

In my opinion on for the most useful commands for viewing logs, follow allows you to view the log as they are bring written.  You may of used «tail -f» in the past.  The journalctl utility has the same function.

journalctl -f

Also, similar to tail, you can view the last 10 entries by using the -n option like so:

journalctl -n

Or you can see the last 50 entries by specifying a number of the «-n» option:

journalctl -n 50

You can also see the last 50 entries, then begin to follow by mixing the commands like so:

journalctl -n 50 -f

Finding Size of Logs / Log Maintenance

To find how much disk space is being used by the journal simply ask:

journalctl --disk-usage

If you are concerned about disk space, you can trim (remove oldest) the logs.

You can do this by specifying the amount of disk space you want to keep or the time you would like to keep.

For example, if you want to delete all logs and keep just 5GB of data:

journalctl --vacuum-size=5GB

If you want to keep only logs from the last year:

journalctl --vacuum-time=1years

Now you should have a decent idea of how to find the logs you are looking for (I just said that in the voice of Obi-Wan). If you have any questions or require further explanation, please feel free to sound off in the comments.

Источник

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, ответ часто находится в логах. На 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. Расширенные функции логов».

Источник

ЧТЕНИЕ И НАСТРОЙКА ЛОГОВ 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

Источник

Понравилась статья? Поделить с друзьями:
  • Cem b109b15 ошибка вольво
  • Cem b104421 volvo ошибка
  • Cem 5f40 ошибка вольво
  • Cem 4a37 ошибка
  • Cem 1a64 volvo xc90 ошибка