Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе Linux, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.
Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.
Основные лог файлы
Все файлы журналов, можно отнести к одной из следующих категорий:
- приложения;
- события;
- службы;
- системный.
Большинство же лог файлов содержится в директории /var/log
.
- /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
- /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
- /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ
--level=
можно отфильтровать вывод по критерию значимости.
Поддерживаемые уровни журналирования (приоритеты):
emerg - система неиспользуемая
alert - действие должно быть произведено немедленно
crit - условия критичности
err - условия ошибок
warn - условия предупреждений
notice - обычные, но значимые условия
info - информационный
debug - отладочные сообщения
(5:520)$ dmesg -l err
[1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81
[1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81
- /var/log/alternatives.log — Вывод программы
update-alternatives
, в котором находятся символические ссылки на команды или библиотеки по умолчанию. - /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
- /var/log/audit — Записи, созданные службой аудита
auditd
. - /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
- /var/log/cron — Отчет службы
crond
об исполняемых командах и сообщения от самих команд. - /var/log/cups — Все, что связано с печатью и принтерами.
- /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды
faillog
. - var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
- /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
- /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
- /var/log/samba/ — Логи файлового сервера
Samba
, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux. - /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
- /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.
Для каждого дистрибутива будет отдельный журнал менеджера пакетов.
- /var/log/yum.log — Для программ установленных с помощью
Yum
в RedHat Linux. - /var/log/emerge.log — Для
ebuild
-ов установленных изPortage
с помощьюemerge
в Gentoo Linux. - /var/log/dpkg.log — Для программ установленных с помощью
dpkg
в Debian Linux и всем семействе родственных дистрибутивах.
И немного бинарных журналов учета пользовательских сессий.
- /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой
last
. - /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты
pam_tally2
. - /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
- /var/log/utmp — Список входов пользователей в систему на данный момент.
- /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой
utmpdump
.
(5:535)$ sudo utmpdump /var/log/wtmp
[5] [02187] [l0 ] [ ] [4.0.5-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:07 2015]
[1] [00000] [~~ ] [shutdown] [4.0.5-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:08 2015]
[2] [00000] [~~ ] [reboot ] [3.18.12-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:57 2015]
[8] [00368] [rc ] [ ] [3.18.12-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:57 2015]
[1] [20019] [~~ ] [runlevel] [3.18.12-gentoo ] [0.0.0.0 ] [Вт авг 11 16:50:57 2015]
И другие журналы
Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.
- /var/log/mysql/ — Лог базы данных MySQL.
- /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в
access_log
, а ошибки — вerror_log
. - /var/log/lighthttpd/ — Лог веб сервера lighttpd.
В домашнем каталоге пользователя могут находится журналы графических приложений, DE.
- ~/.xsession-errors — Вывод
stderr
графических приложений X11.
Initializing "kcm_input" : "kcminit_mouse"
Initializing "kcm_access" : "kcminit_access"
Initializing "kcm_kgamma" : "kcminit_kgamma"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing.
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
Qt: Session management error: networkIdsList argument is NULL
- ~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.
Чем просматривать — lnav
Почти все знают об утилите less
и команде tail -f
. Также для этих целей сгодится редактор vim
и файловый менеджер Midnight Commander. У всех есть свои недостатки: less
неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim
понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>
.
Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.
Установка пакета как обычно одной командой.
$ aptitude install lnav #Debian/Ubuntu/LinuxMint
$ yum install lnav #RedHat/CentOS
$ dnf install lnav #Fedora
$ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords
$ yaourt -S lnav #Arch
Навигатор журналов lnav понимает ряд форматов файлов.
- Access_log веб сервера.
- CUPS page_log
- Syslog
- glog
- dpkg.log
- strace
- Произвольные записи с временными отметками
- gzip, bzip
- Журнал VMWare ESXi/vCenter
Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.
(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log
Программа умеет напрямую открывать архивный файл.
(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz
Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу <i>
. Это с моего syslog-а.
Mon May 02 20:25:00 123 normal 3 errors 0 warnings 0 marks
Mon May 02 22:40:00 2 normal 0 errors 0 warnings 0 marks
Mon May 02 23:25:00 10 normal 0 errors 0 warnings 0 marks
Tue May 03 07:25:00 96 normal 3 errors 0 warnings 0 marks
Tue May 03 23:50:00 10 normal 0 errors 0 warnings 0 marks
Wed May 04 07:40:00 96 normal 3 errors 0 warnings 0 marks
Wed May 04 08:30:00 2 normal 0 errors 0 warnings 0 marks
Wed May 04 10:40:00 10 normal 0 errors 0 warnings 0 marks
Wed May 04 11:50:00 126 normal 2 errors 1 warnings 0 marks
Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.
Использованные материалы
Комментарии (23)
web_creater
07.07.2017 15:24-2я бы посоветовал в
~/.my_app/log/Sirikid
08.07.2017 01:42+3Ага, чтобы весь
~
был засран этими.my_app
, лучше уж в~/.config/my_app/...
hdfan2
08.07.2017 17:39Если уж совсем правильно, то в $XDG_CONFIG_HOME/my_app/…
ZyXI
09.07.2017 01:03+1Ссылку знаете, а читать не умеете. Там ясно написано, что XDG_CONFIG_HOME для “user specific configuration files”. Журналы являются файлами настроек пользователя? Из всех каталогов подходит только
$XDG_DATA_HOME/my_app
.
evnp
07.07.2017 16:37+11я все понимаю, но совсем не упомянуть journald мне кажется неприличным
PavelZhigulin
10.07.2017 16:49Тоже удивился, когда читал раздел про бинарные логи. Как будто бы и нет systemd нигде :) Но вообще статья-то всё равно очень полезная. Вообще, я бы хотел иметь какой-нибудь сайтик где можно было бы узнать куда какая софтина пишет и как это правильно искать.
esudnik
08.07.2017 05:22У меня такой вопрос: Какие есть логи или другие возможности проанализировать причину Kernel Panic?
kolu4iy
08.07.2017 15:13Неотключенные, сэр… И /var/spool/abrtd, если мне не изменяет память.
P.S. коллеги, не забывайте настраивать logrotate. Это правда очень важно, когда надо быстро разобрать инцидент.
lexore
09.07.2017 12:37Причину kernel palic можно узнать двумя способами:
- увидеть на консоли, если запретить перезагрузку после kernel panic (sysctl kernel.panic=0)
- настроить отправку сообщения по сети на какой-нибудь сервер (гуглить netconsole)
При втором способе ядро посылает предсмертное сообщение по udp на указанный вами адрес.
На сервере-источнике нужно будет подгрузить модуль ядра с нужными параметрами.
А на сервере-приемнике нужно заранее запустить что-нибудь, постоянно слушающее udp порт.
Самый простой вариант — nc в режиме сервера (nc -u -l 6666).
Более надежный — настроить syslog сервер слушать в raw режиме udp порт и записывать все, что туда
приходит.
ademaro
09.07.2017 02:12А ещё можно разукрашивать вывод логов (и не только) с помощью ccze, например:
tail -f /var/log/syslog | ccze -A
kbu
11.07.2017 15:44+1Также для этих целей сгодится редактор vim
Простите, vim для просмотра логов?
А если у Вас лог в несколько гигабайт(про ротацию логов не стоит сейчас пожалуйста). Вы все еще используете vim для просмотра логов? Тогда мы идем к вам…
Sane
Подскажите, пожалуйста, куда лучше писать логи от своих приложений?
saboteur_kiev
Если вы системный программист, который пишет системные приложения — /var/log/
Если очень популярные прикладные продукты — то в /var/log/app/
Если не очень популярные, или еще не уверены — в app/log/
Sane
Приложение собственное — web server на dotnet core.
socrat3z
сначала в логгер, типа serilog, log4net или nlog, а затем использовать sinks к любому удобному типу вывода — syslog, console, tcp, db etc.
mike_y_k
А как сие запускается?
Если это демон — в качестве аналогии модель ведения логов от Apache очень к месту.
Для пользовательского процесса (что несколько странно наверное) — в ~/…
Тут надо бы понять для чего и с чем они, как с ними работать планируется.
modjo
/var/log/'название вашего приложения'/и т.д.
onix74
/dev/null тоже подойдёт…
hdfan2
Спасибо, очень удобно! Теперь логи совсем не занимают места! Скажите, а как их теперь прочитать?
alix_ginger
lnav /dev/null, вы вообще статью читали?
Googolplex
Логи своих приложений лучше писать в stdout и полагаться на супервизор (systemd, Docker) в плане их сохранения.
vanburg
я бы еще добавил, что если логи предполагается анализировать машинным путем, то очень удобно хранить их в JSON формате
rPman
По строчно, событие — json объект, так удобнее всего (я обычно время храню в float unixtime в начале строки а уже после него через пробел/tab json).