Лог файлы Linux по порядку

  • Tutorial

Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе 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 будет активно развиваться, очень полезная программа на мой взгляд.


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


  1. lnav — An Advanced Log File viewer for Linux
  2. What Are Linux Logs? How to View Them, Most Important Directories, and More
  3. Как посмотреть логи в Linux
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 23
  • +1
    Подскажите, пожалуйста, куда лучше писать логи от своих приложений?
    • +2
      Если вы системный программист, который пишет системные приложения — /var/log/
      Если очень популярные прикладные продукты — то в /var/log/app/
      Если не очень популярные, или еще не уверены — в app/log/
      • 0
        Приложение собственное — web server на dotnet core.
        • 0
          сначала в логгер, типа serilog, log4net или nlog, а затем использовать sinks к любому удобному типу вывода — syslog, console, tcp, db etc.
          • НЛО прилетело и опубликовало эту надпись здесь
        • 0

          /var/log/'название вашего приложения'/и т.д.

          • +9
            /dev/null тоже подойдёт…
            • +1
              Спасибо, очень удобно! Теперь логи совсем не занимают места! Скажите, а как их теперь прочитать?
              • +1
                lnav /dev/null, вы вообще статью читали?
            • +2
              Логи своих приложений лучше писать в stdout и полагаться на супервизор (systemd, Docker) в плане их сохранения.
              • 0
                я бы еще добавил, что если логи предполагается анализировать машинным путем, то очень удобно хранить их в JSON формате
                • 0
                  По строчно, событие — json объект, так удобнее всего (я обычно время храню в float unixtime в начале строки а уже после него через пробел/tab json).
              • –2
                я бы посоветовал в
                ~/.my_app/log/
                • +3

                  Ага, чтобы весь ~ был засран этими .my_app, лучше уж в ~/.config/my_app/...

                  • 0
                    Если уж совсем правильно, то в $XDG_CONFIG_HOME/my_app/…
                    • +1

                      Ссылку знаете, а читать не умеете. Там ясно написано, что XDG_CONFIG_HOME для “user specific configuration files”. Журналы являются файлами настроек пользователя? Из всех каталогов подходит только $XDG_DATA_HOME/my_app.

                • +11
                  я все понимаю, но совсем не упомянуть journald мне кажется неприличным
                  • 0
                    Тоже удивился, когда читал раздел про бинарные логи. Как будто бы и нет systemd нигде :) Но вообще статья-то всё равно очень полезная. Вообще, я бы хотел иметь какой-нибудь сайтик где можно было бы узнать куда какая софтина пишет и как это правильно искать.
                  • 0
                    У меня такой вопрос: Какие есть логи или другие возможности проанализировать причину Kernel Panic?
                    • 0

                      Неотключенные, сэр… И /var/spool/abrtd, если мне не изменяет память.


                      P.S. коллеги, не забывайте настраивать logrotate. Это правда очень важно, когда надо быстро разобрать инцидент.

                      • 0

                        Причину kernel palic можно узнать двумя способами:


                        1. увидеть на консоли, если запретить перезагрузку после kernel panic (sysctl kernel.panic=0)
                        2. настроить отправку сообщения по сети на какой-нибудь сервер (гуглить netconsole)

                        При втором способе ядро посылает предсмертное сообщение по udp на указанный вами адрес.
                        На сервере-источнике нужно будет подгрузить модуль ядра с нужными параметрами.
                        А на сервере-приемнике нужно заранее запустить что-нибудь, постоянно слушающее udp порт.
                        Самый простой вариант — nc в режиме сервера (nc -u -l 6666).
                        Более надежный — настроить syslog сервер слушать в raw режиме udp порт и записывать все, что туда
                        приходит.

                    • 0
                      А ещё можно разукрашивать вывод логов (и не только) с помощью ccze, например:
                      tail -f /var/log/syslog | ccze -A
                      
                      • +1
                        Также для этих целей сгодится редактор vim

                        Простите, vim для просмотра логов?

                        А если у Вас лог в несколько гигабайт(про ротацию логов не стоит сейчас пожалуйста). Вы все еще используете vim для просмотра логов? Тогда мы идем к вам…

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

                        Самое читаемое