Введение в лог-файлы Linux. Лог файлы Linux по порядку Ubuntu где логи

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

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

Файлы журналов веб-сервера Apache содержат самую полную информацию о посетителях веб-сайта и запросах, пришедших к серверу. Журналы веб-сервера представляют собой обычные текстовые файлы, в которых хранится информация о сделанных к серверу запросах, в том числе IP адрес, запрошенная страница, статус ответа, информация о ссылающейся страницы (реферер), количество переданных данных, пользовательский агент, дата и время.

Если всё работает нормально, то обычно необходимость в анализе логов отсутствует. К журналам веб-сервера мы обращаемся когда начинаются проблемы, либо для профилактики этих проблем.

С помощью логов Apache можно выловить битые ссылки — найти страницы, на которые ведёт ссылка, но которые отсутствуют на сайте; можно найти IP, User Agent и Referer пользователей, которые создают слишком большую нагрузку на веб-сайт или проявляются странную активность (в случае DoS атак и скликивания рекламы). Анализ журналов даст информацию о профиле посетителей: в какие часы и дни максимальная нагрузка на сервер, какое количество данных передаётся (такую информацию не даст ни один счётчик), из каких стран и городов посетители и прочее.

Кстати, если сравнивать анализ сторонних метрик (например, ) и анализ журналов веб-сервера, то по факту это довольно разные вещи — в логах сервера данных может быть в разы больше, чем покажет сторонняя метрика, поскольку она собирает информацию только со страниц, которые содержат счётчик, из его поля зрения выпадают, например, работа сканеров по поиску скрытых файлов и папок на сервере, а также отправка данных методами HEAD и другими необычными. Метрики не показывают IP адреса пользователей. То есть метрики не могут заменить собой анализ логов если нужно найти источник проблемы. Точно также как логи не заменят сбор статистики с помощью сторонних метрик или установленного не сервере/сайте ПО, поскольку файлы журналов сервера обычно хранятся ограниченное время. Кстати, по этой причине при подозрении на серьёзные эксцессы (взлом сайта или веб сервера), нужно сделать копию файлов журналов, чтобы они не были удалены в процессе ротации.

В этой заметке я покажу несколько способов автоматизированного анализа файлов журналов Apache:

  • онлайн сервис
  • программа для Linux
  • как анализировать логи в Windows

Выводы

В каталоге /var/log вы можете найти всю необходимую информацию о работе Linux. Из сегодняшней статьи вы достаточно узнали, чтобы знать где искать, и что искать. Теперь просмотр логов в Linux не вызовет у вас проблем. Если остались вопросы, задавайте в комментариях!

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

Зачастую, лог содержит тысячи строк, так мало того, может каждую секунду увеличиваться на еще несколько записей. А смотреть желательно в живую, отслеживая реакцию на те или иные действия. Тут нам помогут две утилиты tail и less .

Изучение конфигурации Logrotate

Информация о конфигурации LogRotate в целом можно найти в двух местах на Ubuntu:

  • /etc/: этот файл содержит некоторые настройки по умолчанию и устанавливает вращения для нескольких журналов, которые не принадлежат какой-либо системой пакетов. Он также использует заявление include для загрузке конфигурации из любого файла в каталоге /etc/logrotate.d.
  • /etc/logrotate.d/: Здесь все устанавливаемые пакеты, нуждающиеся в помощи при вращении журнала, размещают конфигурацию Logrotate. На стандартной установке вы уже должны иметь файлы здесь для основных системных инструментов, таких как apt, dpkg, rsyslog и так далее.
Читайте также:  Загрузочная флешка Ubuntu. Создание и настройка

По умолчанию файл настроен на еженедельную ротацию журналов (weekly), с лог-файлами, находящихся в собственности пользователя root и группа системный журнал (su root syslog), с сохраненными четырьмя файлами журналов (rotate 4), и новые файлы пустого журнала создаются после того, как только один производит ротацию (create),

Давайте посмотрим на файл конфигурации пакета LogRotate, в файле /etc/logrotate.d. cat для утилиты пакета apt:

cat/etc/logrotate.d/apt

Вывод

/var/log/apt/ { rotate 12 monthly compress missingok notifempty } /var/log/apt/ { rotate 12 monthly compress missingok notifempty }

Этот файл содержит конфигурационные блоки для двух различных файлов журналов в каталоге /var/log/apt/: и Они оба имеют одни и те же параметры. Любые варианты не установленные в этих блоках конфигурации наследуют значения по умолчанию или те, которые в файле /etc/ Комплект для вариантов журналов apt являются:

  • rotate 12: Хранить двенадцать старых лог-файлов.
  • monthly: Сделать ротацию один раз в месяц.
  • compress: Сжать повернутые файлы. Используется gzip по умолчанию и приводит к файлам, заканчивающимся на расширение .gz. Команду сжатия можно изменить с помощью опции compresscmd.
  • missingok: Не пишите сообщение об ошибке, если файл журнала отсутствует.
  • notifempty: Не делайте ротацию файла журнала, если он пуст.

Есть много доступных вариантов конфигураций. Вы можете прочитать обо всех из них, набрав man logrotate в командной строке, чтобы вызвать страницу руководства LogRotate.

Далее, мы создадим конфигурационный файл для обработки журналов для вымышленной службы.

Выполнение действий по расписанию

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

Программисты имели в виду Хроноса, стихийное божество времени у древних греков. Уже сами греки часто называли так «владыку неба» титана Крона (отца богов-кронидов и, среди прочих, Зевса, который впоследствии папу и других титанов заключил в Тартар, и стал владыкой неба сам). У древних римлян и Крон и Хронос почитались под именем Сатурна, божества неумолимого времени.

Время от времени в системе необходимо обновлять разнообразные файлы, например, базы данных антивирусов (вирусов в Linux нет, а антивирусы есть!), базу данных whatis или список всех доступных на чтение файлов системы, locatedb (поискать по этому списку можно командой locate); нужно собирать статистику по работе системы, анализировать цельность системы (этим занимаются службы OSec, TripWire или AIDE) и производить множество других регулярных действий. Всем этим и занимается демон cron.

Конфигурационный файл демона cron называется /etc/crontab.

[[email protected] root]# cat /etc/crontab #minute (0-59), #| hour (0-23), #| | day of the month (1-31), #| | | month of the year (1-12), #| | | | day of the week (0-6 with 0=Sunday). #| | | | | user #| | | | | | commands 01 * * * * root run-parts /etc/ 02 4 * * * root run-parts /etc/ 22 4 * * 0 root run-parts /etc/ 42 4 1 * * root run-parts /etc/Пример 11. Настройка cron

Первые пять полей этого файла определяют время запуска команды: минуту, час, число месяца, месяц и день недели. Символ «*» означает, что соответствующая часть даты не учитывается. Шестое поле — имя пользователя, от лица которого зпускаются команда, указанная в остальных полях строки. Так, в примере команда run-parts /etc/ будет запускаться в 4 часа 22 минуты каждое воскресенье (нулевой день) любого числа любого месяца.

Как видно из примера, обычно /etc/crontab невелик: чаще всего он состоит из почасового, подённого, понедельного и помесячного запуска специального сценария (в примере — run-parts). Этот сценарии реализует упрощённую схему «. d», он попросту запускает отсортированные в лексикографическом порядке сценарии из соответствующего каталога (например, из /etc/):

То есть в таком порядке, в котором они были бы расставлены в словаре. Причём цифры предшествуют алфавитным знакам, а между собой сортируются по возрастанию, от 0 до 9. Отсюда «000anacron» — такое имя обеспечит, чтобы этот сценарий был выполнен самым первым.

Читайте также:  Прокачай терминал! Полезные трюки, которые сделают тебя гуру консоли

[[email protected] root]# ls /etc/ 000anacron logrotate makewhatis osec stmpclean updatedbПример 12. Сценарии, запускаемые ежедневно

Вот что происходит каждый день на машине Мефодия: запуск anacron и «прокручивание» системных журналов (об этом речь пойдёт далее), обновление базы whatis, проверка цельности системы с помощью osec, прореживание старых и неиспользуемых файлов в /tmp (утилита stmpclean) и, наконец, обновление базы locatedb.

Пользователям системы можно разрешить иметь собственные расписания, также обрабатываемые демоном cron. Эти расписания имеют тот же синтаксис, что и crontab, только шестое поле («user») в них отсутствует. Редактировать пользовательские таблицы рекомендуется с помощью команды crontab -e (чтобы не подсунуть демону синтаксически неверный файл). Сами таблицы могут храниться, в зависимости от версии и настроек cron, в /var/spool/cron/crontabs, /var/spool/cron, /var/cron/tabs или ещё где-нибудь.

Служба anacron появилась в Linux-системах в то время, когда их начали активно использовать на пресональных рабочих станциях. Такие станции, в отличие от серверов, не обязаны работать круглосуточно. Скорее всего, на ночь, на праздники и на время отпуска их выключают. Это значит, что все настройки cron надо менять в соответствии с графиком включений/выключений (иначе никогда не выполнится в четыре часа ночи) — или запускать отдельную службу, которая будет выполнять некоторые задачи не по расписанию, а потому что их давно уже пора запустить.

Название этого демона пародирует cron с намёком на анахронизм, то есть несвоевременность выполнения заданий.

Дополнительно anacron рассчитывает запуск задач так, чтобы не перегрузить компьютер работой, если их накопилось слишком много. Конфигурационный файл anacron называется /etc/anacrontab.

Каналы

Канал — это особая концепция системы Linux, которая автоматизирует перенаправление вывода одной команды посредством использования входных данных на следующую команду. Такое использование каналов приводит к эффективным комбинациям независимых команд. Ниже приведены некоторые из них:

  • find .| less — позволяет прокручивать длинный список файлов постранично;
  • head | grep -i ‘little’ echo $PATH | tr ‘:’ ‘\n’ — переводит на новую строку;
  • history | tail — отображает последние 10 команд;
  • free -m|grep Mem:|awk ‘{print $4}’ — отображает доступную память;
  • du -s *|sort -n|tail — отображает 10 наиболее больших файлов/каталогов в pwd.

Расшифровка и отладка команд каналов

free -m|grep Mem:|awk ‘{print $4}’

Приведённая выше команда эквивалентна выполнению следующих 4 команд:

  • free -m >
  • grep Mem: >
  • awk ‘{print $4}’
  • rm

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

free -m|awk ‘/Mem:/{print $4}’

Ниже приведено ещё несколько примеров каналов:

Чтобы получить доступ к pdf-файлам страниц справочника man:

man -t diff | ps2pdf —  

Чтобы получить актуальные на сегодняшний день файлы:

ls -al —time-style=+%D | grep `date +%D`

Топ-10 самых часто используемых команд:

history | awk ‘{a[$2]++}END{for(i in a){print a[i] » » i}}’ | sort -rn | head

Далее будут команды терминала Linux, которые принимают только литеральные аргументы.

Большинство команд получают входные данные, например, из stdin (канала) и файла:

wc < #ок 

wc #ок

Однако, существуют определённые исключения. Например, некоторые команды получают входные данные только из stdin, а не из файла:

tr ‘N’ ‘n’ #работать не будет

tr ‘N’ ‘n’ < #работать будет

Некоторые команды не получают входные данные ни из stdin, ни из файла. Например, следующие:

  • echo <  — не подходит. Предполагается, что вы собираетесь распечатать содержимое файла;
  • echo  — не подходит. Предполагается, что вы собираетесь распечатать содержимое файла;
  • echo «Привет, как дела?» —  принимает литеральные аргументы.

cp, touch, rm, chmod относятся к другим примерам.

log файлы и их расположение в Linux

Как уже отмечалось, в системах UNIX и Linux нет чётких соглашений о том, где и как должны храниться журналы регистрации. Они могут быть разбросаны хоть по всей файловой системе, поэтому для каждого администратора важно сразу разобраться, где и для каких пакетов и демонов находятся соответствующие файлы журналов. Но несмотря на отсутствие чётких формальных регламентов относительно мест хранения журналов, всё же существует традиционно сложившееся правило, что эти файлы должны находиться в каталогах /var/log, /var/log/syslog, а также в /var/adm.

Читайте также:  Cockpit: веб-интерфейс управления сервером CentOS/RHEL

Как правило, доступ для чтения файлов в указанных каталогах предоставляется только суперпользователю, однако нет ничего страшного, если для часто просматриваемых журналов, в которых также нет важной системной информации настроить более «демократический» режим доступа. Обычно к такому варианту также прибегают для удобства и экономии времени, когда нужно часто и регулярно изучать некоторые журналы, например для веб-сервера Apache, которые обычно находятся в /var/log/apache2 или /var/log/httpd.

Стоит также помнить и о том, что бывают случаи, когда (особенно на сбойных конфигурациях) общий объём файлов журналов резко увеличивается, при этом велик риск «уложить» систему. Для удобства контроля за свободным пространством на устройствах хранения, а также для надёжности каталог /var часто выносят в отдельную файловую систему на отдельном разделе.

Запуск демона syslogd

Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog , однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт — начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian) .

Вот некоторые возможные параметры запуска демона syslogd:

  • -a /folder/socket — указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
  • -d — отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
  • -f имя-конфигурационного-файла . Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/;
  • -l список-хостов — задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN — Full Qwalified Domain Name);
  • -m минут — запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
  • -p socket — задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
  • -r — разрешение принимать сообщения от удаленных хостов;
  • -x — запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
  • -v — показать версию и закончить работу

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/ .

С помощью командыkill -SIGNAL `cat /var/run/`

можно послать демону syslogd один из следующих сигналов: SIGHUP — перезапуск демона; SIGTERM — завершение работы; SIGUSR1 — включить/выключить режим отладки.

Вообще-то в системе запускаются два демона протоколирования — syslogd и klogd . Оба демона входят в состав пакета sysklogd .

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

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