Данные syslog в Телеграмм

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

Основные log файлы Ubuntu

Традиционно логи в Linux хранятся в директории /var/log . Вот описание стандартных лог файлов Ubuntu, которые там присутствуют. Кстати, если вы только планируете устанавливать ubuntu, то можете воспользоваться моей подробной статьей на этот счет — установка ubuntu server. Так же вам может быть интересен мой обзор и сравнение сервера убунту с другими linux системами — Ubuntu Server — обзор для начинающих, сравнение, отзывы.

1. syslog или messages. Последнего чаще всего нет и вместо него только syslog. Это традиционные глобальные системные журналы операционной системы linux. Сюда пишутся события загрузки, ядра системы, системы инициализации systemd и т.д.
2. auth.log — лог авторизации и аутентификации в системе.
3. dmesg — в этом логе хранится информация о загрузке ядра и драйверов оборудования.
4. alternatives.log — лог файл программы update-alternatives. Не знаю, за какие такие заслуги ей выделили отдельный лог файл, а cron, к примеру, нет.
5. kern.log — лог сообщений ядра ubuntu, да и любой другой linux системы.
6. maillog — сообщения почтовой системы. Обычно postfix или exim. Если на сервере ubuntu они не установлены, то и почтового лога не будет.
7. dpkg.log — логирование работы пакетных менеджеров ubuntu. Обычно это apt или apt-get.
8. lastlog и wtmp — информация о прошлых авторизациях пользователей.

Лог загрузки

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

LPIC 108.2 часть первая. Журналирование событий: syslog

sudo dmesg

У вас получится очень длинный вывод всего того, что происходило с системой на старте. Если ищите что-то конкретное, то можете сделать фильтрацию вывода с помощью grep. Допустим, вам надо узнать информацию только о диске.

sudo dmesg | grep sda

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

sudo dmesg | grep error

И так далее. Информация, которую выводит команда dmesg, хранится в log файле /var/log/dmesg .

Логи авторизации, в том числе ssh

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

sshd[2774]: Accepted publickey for root from 21.17.214.129 port 2673 ssh2: RSA SHA256:MCDja9Ve7rYZCzeVGpYXpqRxfAanWwVkcd+lU3GS sshd[2774]: pam_unix(sshd:session): session opened for user root by (uid=0) systemd-logind[628]: New session 6 of user root.

Здесь мы видим ip адрес, с которого произошло подключение и слепок сертификата, так как аутентификация была произведена с его помощью. Если хотите повысить уровень логирования подключений по ssh и получать больше информации, то можете отредактировать конфигурационный файл sshd — /etc/ssh/sshd_config , добавив туда следующий параметр.

LogLevel VERBOSE

Не забудьте перезапустить службу sshd для принятия изменений:

sudo systemctl restart sshd

После этого логирование подключений по ssh будет более подробное.

Лог локального входа в ubuntu тоже хранится в файле auth.log . Информация о подключении через консоль выглядит следующим образом.

login[680]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) systemd-logind[628]: New session 9 of user root. login[3094]: ROOT LOGIN on ‘/dev/tty1’

Устройство /dev/tty1 говорит о том, что вход локальный.

Вы можете быстро посмотреть информацию о последних входах в систему с помощью команды last. Эта информация хранится в бинарном логе /var/log/lastlog .

Примерно то же самое можно увидеть с помощью utmpdump.

sudo utmpdump /var/log/wtmp

Логи ошибок в Ubuntu

Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:

• error или err
• critical или crit
• debug
• warn

Например, посмотрим в логе загрузки dmesg все сообщения уровня предупреждений (warn).

sudo dmesg -l warn

А теперь проверим ошибки в системном логе.

sudo cat /var/log/syslog | grep error

Видим некоторые ошибки в службе systemd-resolved.

Cron logs

Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.

Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.

cron.* /var/log/cron.log

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

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

Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.

sudo systemctl restart rsyslog sudo systemctl restart cron
sudo cat /var/log/cron.log

Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.

Лог действий пользователя

Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.

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

Defaults logfile=/var/log/sudo.log

Теперь выполните какую-нибудь команду через sudo.

sudo cat /var/log/cron.log
Nov 25 23:10:36 : root : TTY=pts/3 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/cat /var/log/cron.log

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

На сегодня по логам в Ubuntu у меня все. Желаю вам логов без ошибок и вечного аптайма (шутка, надо ставить обновы и перезагружаться).

Один отзыв для “ Основные log файлы в Ubuntu — загрузка, авторизация, ошибки и др. ”

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

Источник: ubuntu-admin.ru

Просмотр и анализ логов сайта на Linux сервере

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

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

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

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

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

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

Nginx

/var/log/nginx/error.log

Php-Fpm

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

Apache (CentOS)

/var/log/httpd/error_log

Apache (Ubuntu, Debian)

/var/log/apache2/error_log

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

Nginx

/var/log/nginx/access.log

Php-Fpm

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

Apache (CentOS)

/var/log/httpd/access_log

Apache (Ubuntu, Debian)

/var/log/apache2/access_log

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

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

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

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

Error.log

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

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

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

Access.log

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

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

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

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

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

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

tail -f /var/log/syslog

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

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

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

tail -F /var/log/syslog

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

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

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

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

tailf /var/log/syslog

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

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

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

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

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

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

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

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

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

* Вместо «newdomen.ru» из примера в выдаче будет название актуального домена.

Открыть файл лога можно, нажав на «Посмотреть» в верхнем меню.

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

Более старые версии логов можно найти во вкладке «Архив».

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

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

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

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

Как фильтровать сообщения в RSyslog

Перевод: How To: Filter RSyslog Messages by String

RSyslog Я наконец-то заканчиваю работать над проектом Центральный сервер RSyslog — практически всё работает так, как и задумывалось. Один из последних штрихов — фильтрация сообщений с перенаправлением в отдельные файлы, чтобы получались файлы с важными сообщениями и файлы со всеми остальными логами.

Зачем Может Понадобиться Фильтровать Логи

Большинство причин связаны с облегчением фокуса на истинно важных сообщениях и ошибках.

ВАЖНО: хочу подчеркнуть, что бывает два типа фильтрации. Первый тип — сообщения отбрасываются и больше нигде не хранятся. Второй тип — сообщения отбрасываются, но сохраняются в отдельный файл — вы их не видите, но они всегда доступны для более глубокого расследования. Я считаю, что вы не должны выбрасывать никакие логи — так что следуйте фильтрации второго типа. Риск пропустить (и навсегда потерять) какие-то важные сообщения в фильтрации первого типа слишком велик.

Так что собирайте и храните все логи, но фильтруйте их в различные файлы и просматривайте только важные и наиболее полезные элементы. А всё остальное хранится в других файлах и даже может подвергаться ротации (регулярной чистке). Но если вдруг случится серьёзная проблема или инцидент — вы с лёгкостью сможете просмотреть полный объём логов, а не только файл с важными сообщениями.

Конкретные Причины Фильтровать Логи

1. У вас есть несколько команд или участников команды с различными обязанностями – кто-то следит за логами приложений, кто-то за логами операционной системы
2. У вас есть процессы и задачи, нуждающиеся в особо внимательном мониторинге – например, авто-деплои или cron-задачи — часто их логи находятся среди других логов такого же формата — HTTPS, SSH или SUDO логи — так что приходится фильтровать по каким-то ключевым словам
3. Часть ваших логов предоставляет слишком много информации – для каждодневного использования эти логи и отладочная информация могут и не понадобиться. Например, при логине на удалённый SSH сервер вам могут быть не нужны логи pam_unix, но при именно отладке PAM модулей это будет полезная информация. Важно знать, чьи попытки логинов были неудачны (это может быть атака), тогда как следить за тем, когда и кто закончил сессию — уже второстепенно.

Как Фильтровать Логи по Строке/Выражению

Сравнительно новый подход — использование так называемых expression-based filters в RSyslog – это лёгкие для чтения и понимания конструкции типа if-then (если-то):

if $msg contains ‘ssh’ then /logs/security.log

Как Фильтровать Сообщения Syslog по Имени Приложения или Сервиса

Очень полезная фильтрация — можно указать имя программы или процесса.

Например, в этом сообщении sudo — это название процесса, а не текст сообщения, так что фильтрация по примеру выше не сработала бы:

Mar 29 09:45:38 s7 sudo: greys : TTY=pts/0 ; PWD=/home/greys ; USER=root ; COMMAND=/bin/grep -E ^pi: /etc/shadow

А вот пример совместного использования фильтров: нас интересует сервис sudo, и только те его сообщения, которые имеют элемент COMMAND — в них будут записаны команды, выполненные с повышенными привилениями:

if $programname == ‘sudo’ and $msg contains ‘COMMAND’ then /logs/security.log

Ссылки

• Проект: централизованный сервер логов на базе RSyslog
• RSyslog – пишем логи каждого клиента в отдельный файл
• Ошибка запуска RSyslog: reading fork pipe

Источник: www.unixtutorial.ru