Посмотреть логи linux ubuntu

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

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

emerg — авария, наивысший приоритет;
alert — тревога;
crit — критическое событие;
err — ошибка;
warn — внимание;
notice — уведомление;
info — информационное сообщение;
debug — отладочная информация;

На сегодняшний день в Linux основными службами сбора логов являются rsyslog и systemd-journald, они работают независимо друг от друга и входят в состав большинства современных дистрибутивов.

rsyslog

Журналы службы находятся в директории “/var/log/” в виде обычных текстовых файлов. В зависимости от типа события, сообщения записываются в разные файлы. Например файл “/var/log/auth.log” содержит информацию о входе пользователей в систему, а в файл “/var/log/kern.log” записываются сообщения ядра. В разных дистрибутивах названия файлов могут отличаться, поэтому для точного понимания куда именно происходит запись сообщений рассмотрим файл конфигурации “/etc/rsyslog.d/50-default.conf”.

Правила описывают место хранения логов в зависимости от типа сообщения. В левой части строки указан тип сообщения в формате “[Источник].[Приоритет]”, а в правой части имя файла журнала. При записи типа сообщения можно применять символ “*”, обозначающий любое значение или параметр “none”, обозначающий исключение из списка. Рассмотрим более подробно первые два правила.

“auth,authpriv.* /var/log/auth.log”
“*.*;auth,authpriv.none -/var/log/syslog”

Первое правило означает, что все сообщения принятые от механизма авторизации будут записаны в файл “/var/log/auth.log”. В этом файле будут зарегистрированы все попытки входа пользователей в систему, как удачные так и не удачные. Второе правило говорит о том, что все сообщения, кроме тех, которые связаны с авторизацией будут записаны в файл “/var/log/syslog”. Именно к этим файлам приходится обращаться наиболее часто. Следующие правила определяют место хранения журналов ядра “kern.*” и почтовой службы “mail.*”

Журналы логов можно открыть любой утилитой для просмотра текста, например less, cat, tail. Откроем файл “/var/log/auth.log”

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

Дата и время регистрации сообщения — “Feb 12 06:18:33”
Имя компьютера, с которого пришло сообщение — “vds”
Имя программы или службы, к которой относится сообщение — “sshd”
Идентификатор процесса, отправившего сообщение — [653]
Текст сообщения — “Accepted password for mihail from 188.19.42.165 port 2849 ssh2”

Это был пример успешного подключения по ssh.
А так выглядит неудачная попытка:

В этом файле также фиксируется выполнение команд с повышенными правами.

Откроем файл /var/log/syslog

На скриншоте выделено сообщение о выключении сетевого интерфейса.

Для поиска нужной информации в больших текстовых файлах можно использовать утилиту grep. Найдем все сообщения от службы pptpd в файле “/var/log/syslog”

grep ‘pptpd’ /var/log/syslog

Во время диагностики можно использовать утилиту tail, которая выводит последние строки в файле. Команда “tail -f /var/log/syslog” позволит наблюдать запись логов в реальном времени.

Служба rsyslog является очень гибкой, высокопроизводительной и может использоваться для сбора логов как на локальных системах, так и на уровне предприятия. Полную документацию можно найти на официальном сайте https://www.rsyslog.com/

Ротация логов Linux

Запись логов происходит непрерывно и размер файлов постоянно растет. Механизм ротации обеспечивает автоматическое архивирование старых журналов и создание новых. В зависимости от правил, обработка журналов может выполняться ежедневно, еженедельно, ежемесячно или при достижении файлом определенного размера. По мере создания новых архивов, старые могут быть просто удалены или предварительно отправлены по электронной почте. Ротация выполняется утилитой logrotate. Основная конфигурация находится в файле “/etc/logrotate.conf”, также обрабатывается содержимое файлов в директории “/etc/logrotate.d/”

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

Рассмотрим файл “/etc/logrotate.d/rsyslog”, который содержит правила ротации для журналов службы rsyslog.

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

rotate 7 — необходимо постоянно хранить 7 файлов
daily — ежедневно будет создаваться новый файл
compress — старые файлы необходимо архивировать.

На скриншоте видно, что в каталоге “/var/log/” находится основной журнал “syslog” и семь архивов, что соответствует правилам ротации.

Более подробное описание по настройке утилиты logrotate можно найти в мануале, выполнив команду “man logrotate”

journald

Служба сбора логов systemd-journald является частью системы инициализации systemd. Файлы журнал хранятся в директории “/var/log/journal/” в специальном формате и могут быть открыты с помощью утилиты journalctl. Формат записей такой же как у службы rsyslog.

Команда journalctl без параметров выводит на экран все записи, но учитывая, что объем журнала может достигать нескольких гигабайт, такой способ просмотра не подходит для практического применения. Рассмотрим некоторые опции утилиты.

вывод записей с момента последней загрузки
journalctl -b
вывод записей за определенный период времени
journalctl -S «2020-02-17 12:00» -U «2020-02-17 12:10»
вывод записей, принятых от определенной службы
journalctl -u pptpd
вывод сообщений ядра
journalctl -k
вывод сообщений с определенным приоритетом, в данном случае будут выведены ошибки и более высокие приоритеты(crit, alert, emerg).
journalctl -p err
вывод сообщений в реальном времени
journalctl -f

Для более гибкого поиска опции можно совмещать. Выведем все ошибки службы pptpd

journalctl -u pptpd -p err

Если в качестве аргумента указать путь к исполняемому файлу, утилита выведет все сообщения, отправленные этим файлом. Выведем сообщения, отправленные файлом “/usr/bin/sudo” начиная с 04:15 18-го февраля 2020 года. Фактически будут выведены все команды, выполненные с повышенными правами.

journalctl -S «2020-02-18 04:15» /usr/bin/sudo

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

Для ограничения объема журнала размером 1Gb выполним команду

Открытие бинарных файлов

В заключении рассмотрим несколько специальных файлов в директории “/var/log/”, в которых регистрируются попытки входа пользователей в систему. Это бинарные файлы, которые могут быть открыты только специальными утилитами.

/var/log/wtmp — содержит информацию об успешном входе пользователей в систему, для открытия используется утилита last

/var/log/btmp — в файле регистрируются все неудачные попытки входа в систему, открывается командой lastb с повышенными правами. Параметр -n определяет количество выводимых строк начиная с конца файла.

/var/log/lastlog — содержит время последнего входа для каждой учетной записи, может быть открыт одноименной утилитой lastlog

Источник

Отслеживание логов Linux в реальном времени

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

Мониторинг лог-файлов командой tail

Если выполнить команду tail ИмяФайла без каких-либо дополнительных аргументов, то будет выведено 10 последних строк файла, и команда завершит свою работу.

Для того, чтобы команда tail непрерывно выводила последние записи в файле, то есть, если в файле появились новые записи, то информация на экране обновлялась, используется опция -f :
tail -f ИмяЛогФайла

Выполним команду tail -f для вывода лог-файла /var/log/syslog

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

Чтобы прервать выполнение команды, нажмите сочетание клавиш Ctrl+C

Команда tailf

Аналогом команды tail -f является команда tailf

Важным отличием команды tailf от tail -f является то, что tailf не обращается к файлу, когда он не изменяется. В следствии этого время доступа к файлу не обновляется и система не выполняет постоянный сброс файла на диск, когда файл не обновляется.

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

tail -F. Если файл был переименован или удален

Обычно в Linux лог-файлы записываются не до бесконечности, иначе такой файл было бы очень неудобно в дальнейшем использовать. Вместо этого применяется так называемая ротация файлов. Когда лог-файл становится большим, то он либо удаляется, либо переименовывается (создается резервная копия файла), а дальнейшие сообщения начинают записываться в новый, пустой файл.

У команды tail есть две опции: -f и -F

Если используется опция -f и происходит переименование, отслеживаемого файла, то команда tail продолжает отслеживать уже переименованный файл. Команда tail в данном случае привязывается к идентификатору (inode) файла.
Если используется опция -F и происходит переименование, отслеживаемого файла, то команда tail определит это, и как только будет создан новый лог-файл (с тем именем, которое мы указали команде tail), команда tail начнет отслеживать этот новый файл.

Будем отслеживать лог-файл /var/log/apache2/error.log . Выполняем команду tail с опцией -F

Если система переместит (переименует) файл error.log в файл error.log.1 и создаст новый файл error.log , то наша команда tail продолжит отслеживать уже новый файл error.log

Если бы мы в этом примере использовали опцию -f , то команда tail продолжила бы отслеживать файл error.log.1 , который для нас уже неактуален при просмотре логов в реальном времени.

Отслеживание нескольких лог-файлов одновременно

Команда tail поддерживает отслеживание нескольких файлов одновременно. Для этого необходимо указать имена файлов через пробел.

Как только какой-либо из файлов меняется, на экран выводится имя этого файла и новые записи в нем.

Утилита multitail

Для одновременного отслеживания нескольких лог-файлов существует очень удобная утилита multitail

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

Утилиту multitail можно установить из штатных репозиториев вашего дистрибутива. Для установки выполните команду (выберите соответствующую команду для вашего дистрибутива):

Источник

«Помедленнее, я записываю»: туториал по системным логам Linux

Из этой статьи вы узнаете, что такое журналы Linux, какие инструменты их генерируют и где эти журналы хранятся, — пишет proglib.io. — Рассмотрим, как и зачем искать и читать результаты journald и syslog, а также о том, как собрать логи нескольких серверов в одном месте.

Что такое логи?

Логи (журнал сервера, англ. server log) – это записываемые фрагменты данных, описывающие то, что в конкретный момент времени делает сервер, ядро, службы и приложения. Вот пример лога SSH из /var/log/auth.log :

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

Логи в Linux поступают из разных источников. Ниже перечислены основные.

Подсистема systemd. Большинство дистрибутивов Linux для управления службами имеют в своём составе systemd. Подсистема инициализации и управления ловит выходные данные служб и записывает их в журнал. Для работы с логами systemd используется система журналирования journalctl (шпаргалка по работе с journalctl):

Сообщения процессов по стандарту syslog. При отсутствии systemd такие процессы, как SSH, могут записывать данные в UNIX-сокет в формате syslog. Демон syslog, например, rsyslog, выбирает сообщение, анализирует и по умолчанию записывает его в /var/log .

Ядро Linux пишет собственные логи в особый буфер. Подсистемы systemd или syslog могут считывать журналы из этого буфера, а затем записывать их в свои журналы или файлы – обычно /var/log/kern.log . Чтобы посмотреть логи ядра, воспользуйтесь dmesg:

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

Журнал приложений. Несистемные приложения имеют тенденцию записывать данные в /var/log :

Apache (httpd) обычно пишет в /var/log/httpd или /var/log/apache2 . Журналы HTTP-доступа находятся в файле /var/log/httpd/access.log .
Логи MySQL обычно находятся в /var/log/mysql.log или /var/log/mysqld.log .
Старые версии Linux могут записывать свои логи загрузки с помощью bootlogd в /var/log/boot или /var/log/boot.log . В современных ОС об этом заботится systemd: вы можете просматривать связанные с загрузкой журналы с помощью journalctl -b . Дистрибутивы без systemd снабжены syslog-демоном, считывающим данные из буфера ядра. Таким образом, вы можете найти свои boot/reboot-журналы в /var/log/messages или /var/log/syslog .

Если коротко: где искать логи?

Как правило, вы найдете журналы пингвиньего сервера в каталоге /var/log и подкаталогах. Это место, где syslog -демонам даны полные права на запись. Также это то место, которое у большинства приложений (например, Apache) указано по умолчанию, как место хранения логов.

Для systemd расположение по умолчанию – /var/log/journal , но просматривать файлы логов напрямую не получится – они хранятся в двоичном формате. Как же быть?

Как анализировать журналы

Если ваш дистрибутив Linux использует Systemd (как и большинство современных дистрибутивов), то все ваши системные журналы находятся в специальной области journal. Просмотреть их можно с помощью journalctl (наиболее важные команды journalctl).

Если ваш дистрибутив использует syslog, для их просмотра используются стандартные инструменты: cat, less или grep:

Если для управления журналами вы используете auditd, всё найдётся в файле /var/log/audit.log . В поиске и анализе поможет ausearch.

Заметим, что хорошим тоном является хранение всех логов централизованно, в одном месте. Особенно если у вас несколько серверов. Обсудим эту задачу подробнее.

Централизация логов в Linux

Системные журналы могут находиться в двух местах: в systemd или в обычных текстовых файлах, записанных демоном syslog . В некоторых дистрибутивах, например, Ubuntu, есть и то, и другое: journald настроен на пересылку в syslog . Это осуществляется путем установки ForwardToSyslog=Yes в конфиге journald.conf .

Централизация журналов с помощью Journald

Если в ваш дистрибутив включён systemd, для централизации журналов мы рекомендуем использовать journal-upload.

Централизация журналов с помощью syslog

Существует несколько случаев, в которых подойдет централизация с применением syslog :

Если в ваш дистрибутив не включён journald. Это означает, что системные журналы направляются непосредственно в syslog-демон.
Когда необходимо собирать и анализировать журналы приложений. Например, в случае с журналами для Apache через rsyslog и Elasticsearch.
Если вы хотите перенаправить записи – ForwardToSyslog=Yes . Для этого в качестве транспорта следует использовать syslog-протокол. Однако подход приведет к потере некоторых структурированных данных journald т. к. он пересылает только поля syslog-specific .
Когда вы настроили syslog-демон для чтения из журналов (как это делает journalctl). Такой подход не приводит к потере структурированных данных, но более чувствителен к ошибкам (например, в случае повреждения журнала) и увеличивает накладные расходы.

Во всех перечисленных ситуациях информация будут проходить через демон syslog , а оттуда их можно отправить в любое место и использовать на своё усмотрение.

Большинство дистрибутивов Linux поставляются с rsyslog . Чтобы пересылать данные на другой сервер через TCP, добавьте следующую строку в /etc/rsyslog.conf :

Эта строка будет заворачивать данные на сервер example.com. Вы можете заменить logsene-syslog-receiver.[…..] именем своего syslog-хоста.

Некоторые демоны могут выводить данные в Elasticsearch через HTTP/HTTPS. Одним из них является наш rsyslog. Например, если вы юзаете rsyslog на Ubuntu, сначала установите модуль Elasticsearch:

Затем в конфигурационном файле вам потребуется поправить два элемента: шаблон JSON для Elasticsearch:

и action, который пересылает данные в Elasticsearch, используя указанный выше шаблон:

В приведенном примере показано, как отправлять сообщения в API Elasticsearch на example.com. Настройте action на ваш локальный Elasticsearch:

searchIndex – будет вашим алиасом;
server – имя хоста (ноды) Elasticsearch;
serverport может быть 9200 или кастомным, главное, чтобы на нем слушал Elasticsearch;
usehttps= «off» – отправление данных по http.

Независимо от того, используете ли вы syslog-протокол или что-то еще, лучше перенаправлять данные непосредственно из демона, чем искать проблемы в отдельных файлах из /var/log .

Это не значит, что файлы в /var/log бесполезны. Они пригодятся в следующих случаях:

приложения пишут туда свои логи, например, HTTP, FTP, MySQL и т. д.,
требуется обработать системные журналы, например, с помощью grep.

Важные файлы журналов для мониторинга

Здесь мы рассмотрим ключевые файлы логов, какую информацию они хранят, как настраивается rsyslog для записи и как посмотреть информацию с помощью journalctl .

Журнал /var/log/syslog или /var/log/messages

Это «всеохватывающий» системный лог:

Вы найдёте здесь все сообщения: ошибки, информационные сообщения и все другие серьёзности. Исключением является stop action.

Если в /var/log/syslog или /var/log/messages пусто, скорее всего, journald не перенаправляет данные в syslog. Все те же данные можно просмотреть, вызвав journalctl без параметров.

Журналы /var/log/kern.log или /var/log/dmesg

Сюда по умолчанию отправляются сообщения ядра:

И снова, если у вас нет syslog (или файл пустой/отсутствует) – используйте journalctl:

Журналы /var/log/auth.log или /var/log/secure

Здесь вы найдете сообщения об аутентификации, генерируемые такими службами, как sshd :

Вот ещё один фильтр по значениям auth и authpriv :

Вы можете использовать такие фильтры в journalctl, используя числовые уровни объектов:

Журнал /var/log/cron.log

Сюда отправляются ваши cron-сообщения (jobs-ы, выполняемые регулярно):

С journalctl можно сделать так:

Журнал /var/log/mail.log или /var/log/maillog

Практически все демоны (такие как Postfix, cron и т. д.) обычно пишут свои логи в syslog. Затем rsyslog раскладывает эти логи по файлам:

С помощью journald просматривать журналы можно так:

Подведём итоги

Расположение и формат системных журналов Linux зависят от того, как настроен дистрибутив.
Большинство дистрибутивов имеют systemd, и все логи «живут» там. Чтобы что-то просмотреть и найти, используйте journalctl.
Некоторые дистрибутивы передают системные журналы в syslog, либо напрямую, либо через journal. В этом случае у вас, скорее всего, есть логи, записанные в отдельные файлы в /var/log .
Если вы управляете несколькими серверами, вам потребуется централизовать журналирование с помощью специального ПО или использовать собственный ELK-стек.

Логгирование событий невероятно важная и серьёзная штука в любой сфере администрирования и ОС. Рекомендуем отнестись ответственно к данной теме – она будет полезна при дебагинге, разработке и просто в управлении инфраструктурой.

Источник