Короче, продолжаем. Теперь я для вас подготовил некую уже не маленькую статью, на тему мониторинга Linux систем. В некотором роде эта статья мне будет служить в качестве мини-справочника по необходимым командам, для того, чтобы можно было понимать, все ли нормально с системой. Поговорим об основных командах типа top/htop/uptime/ps, о том где какие логи лежат и что они означают и так далее. Короче, начнем..
Log-файлы (журналы)
Все логи по умолчанию хоронятся в директории /var/log/ (ну так принято по стандарту иерархии файловой системы) и эти файлы — сведения о происходящих процессах в системе. Кстати, если вы поддерживайте систему, которая может быть интересна взломщикам, то настоятельно рекомендуется обзавестись системой дублирования логов, например, на туже почту. Взломщик будет думать, что все «зачистил» за собой, но доказательства его пребывания в системе останутся. Но речь не об этом..
Рассмотрим пример стандартных файлов в директории /var/log/, на примере ОС Debian Linux 7:
QuikFlow позволяет создавать блок-схемы с рабочим процессом отображения логики. #стартап #macos
- /var/log/syslog — syslog является основным системным журналом и в нем сохраняются сообщения демонов и других программ, работающих в системе, например, dhclient, cron, init, xscreensaver, а также некоторые сообщения ядра. Этот журнал — первое место, откуда надо начинать просмотр при попытке отследить типичные системные ошибки
- /var/log/auth.log — содержит информацию системы авторизации, в том числе логины и механизм проверки подлинности, которые были использованы
- /var/log/daemon.log — содержит информацию о различных демонах/сервисах запущенных в системе. С помощью него можно находить проблемы во время падения системы
- /var/log/dmesg — в файле содержаться все сообщения ядра, начиная с этапа загрузки системы, а просмотреть содержимое этого файла можно используя команду dmesg
- /var/log/kern.log — файл журнала ядра, предоставляет подробный лог сообщений от ядра Linux, которые могут быть полезны при анализе и устранении неисправностей
- /var/log/messages — файл содержит глобальные настройки, в том числе сообщения, которые регистрируются при запуске системы
- /var/log/debug — журнал отладки, предоставляющий подробную отладочную информацию системы и приложений, которые используют syslogd для отладки
- /var/log/user.log — содержит информацию о всех журналах на уровне пользователя
- /var/log/btmp — файл содержит записи обо всех неудавшихся попытках регистрации пользователей в системе. Посмотреть неудачные попытки входа в систему можно с помощью команды lastb
- /var/log/faillog — в этом файле хранится число неудачных попыток входа в систему и их предельное число для каждой учётной записи. А если в консоли ввести команду faillog, то можно увидеть содержимое этого файла
- /var/log/mail.log, /var/log/mail.err, /var/log/mail.info, /var/log/mail.warn — файлы журналирующие почтовые события
- /var/log/lastlog — файл содержащий записи о предыдущих входах в систему
- var/log/apt — директория содержит информацию, которая пишется при установки/удалении пакета с помощью программы apt
- /var/log/alternatives.log — файл программы update-alternatives, которая является механизмом выбора предпочтительного ПО среди нескольких вариантов в таких дистрибутивах Linux, как Debian и Ubuntu
- /var/log/aptitude — файл программы aptitude содержащий информацию об установке/удалении пакетов
- /var/log/dbconfig-common — в случае использования утилиты dbconfig все действия будут журналироваться в файлах, в этой лиректории
- /var/log/dpkg.log — файл содержит информацию, которая пишется при установки/удалении пакета с помощью программы dpkg
- /var/log/fsck — если в вашей системе запускалась проверка файловой системы то она будет журналироваться в файлы находящиеся в этой директории
- /var/log/wtmp — файл содержит двоичные данные о времени регистрации и продолжительность работы всех пользователей системы. Он пользуется командой last для вывода списка регистрировавшихся пользователей
- /var/log/apache2 — если в вашей системе установлен apache, то в данной директории будут находиться журналы access_log и error_log
- /var/log/mysql.err и /var/log/mail.info — если у вас установлена СУБД MySQL, то в этих файлах будут журналироваться сведения о работе и об ошибках СУБД
Теперь приведем пример, что когда нам понадобится..
Что такое лог (log) программы
-
Если у нас не запускается какая то служба, то имеет смысл посмотреть файл /var/log/syslog, хотя скажу сразу, туда логируется почти все, даже bind9, если таковой стоит, поэтому лучше смотреть этот файл при помощи «tail -f»:
tail -f /var/log/syslog
На этом про логи, я думаю, достаточно..
Правки в файлах
Иногда бывает полезно выявлять факты изменения файлов в такой директории, как /etc, особенно, если администрированием сервера занимайтесь не только вы. Сделать это все можно при помощи команды find с параметром -mtime. Например, следующая команда покажет файлы, которые были изменение в течении последних двух суток:
find /etc -mtime 2
Более подробно поиск по различным временам описан тут.
Какова загрузка системы?(LoadAverage)
Вы наверное часто обращали внимание на такую строчку, как LoadAverage, которая показывает числа. Собственно эти числа отображают число блокирующих процессов на исполнение в определенный интервал времени, а именно 1 минута, 5 минут и 15 минут. Под блокирующим процессом подразумевается процесс, который ждет ресурсы для того, чтобы продолжить свою работу, а под ресурсами подразумевается ЦП, дисковая подсистема ввода вывода и сетевая подсистема ввода/вывода.
Не обязательно быть специалистом, чтобы понимать, что высокие показатели LA говорят о том, что система не справляется, например эти цифры могут говорить об аппаратных проблемах.
Чтобы посмотреть эти показания, достаточно воспользоваться командой top или uptime (о top мы поговорим несколько позднее)
[email protected]:~$ uptime 16:54:50 up 5 days, 18:54, 3 users, load average: 0,59, 0,77, 0,84
Большинство (как и я ) будут думать, что чем меньше эти числа, тем лучше, но нужно понимать, когда бить тревогу, если значения этих цифр начнет расти.
Отличная аналогия «на машинках» о том, что эти цифры обозначают приведена в статье на хабре, поэтому приведу краткую выдержку от туда: представим, что одноядерный процессор это однополосный мост, а мы управляем движением на этом мосту. Если мост перегружен, то машины ждут (ну или стоят в пробке). Собственно количество машин в очереди это и есть то число, которое вы видите. Пример можно увидеть на этих картинках из этой прекрасной статьи:
![]()
Исходя из того, что мы видим, можно понять, что Load Average равный 1,00 — идеальное значение, но это не так. Идеальным значением для меня можно считать 0,50 ну или на худой конец 0,70, так как должен сохраняться какой-то запас на случай внезапной нагрузки или нештатного поведения той или иной программы.
И имейте в виду, пример выше это пример для одноядерного процессора. Если у вас четырехядерный процессор или два двухядерных процессора, то идеальным LA для вас будет 2,00 или 2,80.
Теперь подытожим эту тему,
- Какое значение лучше смотреть? За минуту, 5 минут или 15 минут?
Если на одноядерном процессоре LA за 5 или 15 минут, то следует на это обратить внимание - Как понять сколько процессоров в системе?
ну тут все просто, нужно отфильтровать grep-ом вывод cpuinfo:
[email protected]:~$ cat /proc/cpuinfo | grep ‘cpu cores’ cpu cores : 2 cpu cores : 2 cpu cores : 2 cpu cores : 2
Что происходит в системе (процессы)
Собственно. чтобы увидеть эти показатели, понять, где у нас есть проблемы, и вообще получить информацию о процессах воспользуемся утилитой top:
Рассмотрим по порядку, что есть что:
- Общая информация:
- текущем времени
- uptime времени (сколько система работает)
- количество пользовательских сессий (3 users)
- LoadAverage (ну о нем написан целый раздел)
- Статистика процессов:
- общее количество процессов в системе
- количество работающих в данный момент процессов
- количество спящих процессов (они работающие, просто «ждут» события)
- количество остановленных событий (я их останавливаю с помощью команды ctrl+z)
- количество процессов, ожидающих родительский процесс для передачи статуса завершения (0 zombie)
- Статистика использования CPU:
- 6,8 us — процент использования центрального процессора пользовательскими процессам
- 1.1 sy — процент использования центрального процессора системными процессами
- 0.0 ni — процент использования центрального процессора процессами с приоритетом, повышенным при помощи вызова nice
- 92.1 id (id это idle cpu time, т.е. время простоя CPU) — процент простоя процессора
- 0.0 wa — процент использования центрального процессора процессами, ожидающими завершения операций ввода-вывода (например чтение/запись на диск)
- 0.0 hi (hi это Hardware IRQ, т.е. аппаратные прерывания) — процент использования центрального процессора обработчиками аппаратных прерываний
- 0.0 si (si это Software Interrupts, т.е. программные прерывания) — процент использования центрального процессора обработчиками программных прерываний
- 0.0 st (st это Steal Time , т.е. заимствованное время) — количество ресурсов центрального процессора «заимствованных» у виртуальной машины гипервизором для других задач (таких, как запуск другой виртуальной машины); это значение будет равно нулю на не использующих виртуальные машины
- Статистика использования физической и swap памяти:
- общее количество памяти (total)
- количество используемой памяти (used)
- количество свободной памяти (free)
- количество памяти в кэше буферов (buffers)
- Список процессов, отсортированный по степени использования центрального процессора (по умолчанию), опишем столбцы:
- PID — идентификатор процесса
- USER — имя пользователя, который является владельцем процесса
- PR — приоритет процесса
- NI — значение «NICE», влияющие на приоритет процесса
- VIRT — объем виртуальной памяти, используемый процессом
- RES — объем физической памяти, используемый процессом
- SHR — объем разделяемой памяти процесса
- S — указывает на статус процесса: S=sleep (ожидает событий) R=running (работает) Z=zombie (ожидает родительский процесс)
- %CPU — процент использования центрального процессора данным процессом (0.3)
- %MEM — процент использования оперативной памяти данным процессом (0.7)
- TIME+ — общее время активности процесса (0:17.75)
- COMMAND — имя процесса (bb_monitor.pl)
Что нам тут интересно? Да интересно почти все :). Например, статистика CPU: высокие значения (более 80%) параметра wa говорят о простое из-за ввода вывода, что может говорить о проблемах с HDD. Кстати, если сложить все эти значения, то у вас получится 100%.
Что мы там можем делать в утилите top?
- Нажав на клавишу k мы можем убить процесс, достаточно будет ввести его PID
- нажав на клавишу u и введя имя пользователя мы можем увидеть все процессы определенного пользователя
- нажав на клавишу b или z и работающие процессы будут выделены цветом
Более подробнее о ключах top можно почитать в страницах man. Кстати, есть еще и отличный аналог утилиты top — htop:

ps — process status
Существует еще генератор снимков процессов ps. Подробнее о нем можно почитать его man, а ниже я приведу примеры использования этой команды:
-
при помощи следующей команды мы можем выяснить, выполняется ли в данный момент программа apache:
ps -aux | grep apache
ps aux
ps -ef
ps axjf
ps -f -u www-data
[email protected]:~$ ps -f -p 11947,11950,11957 UID PID PPID C STIME TTY TIME CMD www-data 11947 11943 0 июля30 ? 00:00:00 /usr/sbin/apache2 -k start www-data 11950 11943 0 июля30 ? 00:00:00 /usr/sbin/apache2 -k start www-data 11957 11943 0 июля30 ? 00:00:00 /usr/sbin/apache2 -k start
Этого я думаю достаточно. Есть еще масса интересных примеров на просторах интернета, например тут.
В заключение…
начиная писать эту статью, я не думал что все получится на столько громоздко, поэтому еще будет как минимум вторая или третья часть средств мониторинга linux систем.
- http://cyberforby.blogspot.ru/2012/04/varlog.html
- http://rus-linux.net/nlib.php?name=/MyLDP/BOOKS/ubuntu_hacks_ru/ubuntuhack82.html
- http://www.thegeekstuff.com/2011/08/linux-var-log-files/
- https://help.ubuntu.com/community/LinuxLogFiles
- http://www.softpanorama.org/Tools/Find/selecting_files_by_age.shtml
- http://habrahabr.ru/post/216827/
- http://habrahabr.ru/post/71020/
- http://habrahabr.ru/post/49204/
- http://rus-linux.net/MyLDP/consol/komanda-top-v-linux.html
- http://linux.die.net/man/1/top
- http://linuxopen.ru/2010/01/21/15-primerov-ispolzovanija-v-linux.html
Источник: maxidrom.net
Как использовать journalctl для анализа логов на Linux

Мануал
Автор cryptoparty На чтение 14 мин Опубликовано 19.03.2021
systemd – это системный менеджер по умолчанию в большинстве основных дистрибутивов Linux, который поставляется с новым демоном ведения журнала под названием «journald».
В течение многих лет системные логи и журналы ядра в традиционной системе SysVinit обрабатывались syslogd, который хранит логи в простых текстовых файлах, тогда как journald хранит логи в двоичном формате.
systemd собирает логи из нескольких источников, таких как система, ядро и различные службы или демоны, и предоставляет решение для централизованного управления через journald.
Это очень оптимизированный процесс, и логи можно просматривать в зависимости от требований, тогда как журналы syslogd анализируются вручную с помощью различных команд, таких как find, grep, cut и т. д.
В этой статье мы продемонстрируем, как просматривать и анализировать системные логи Linux с помощью команды journalctl.

Что такое journald?
journald – это демон из systemd, который собирает логи из различных источников, таких как система, ядро и службы, и сохраняет их в двоичном формате для упрощения манипуляций.
Все эти события журналирования обрабатываются демоном journald, который обеспечивает централизованный способ обработки журналов независимо от того, откуда исходят сообщения.
Что такое journalctl?
journalctl – это инструмент командной строки, используемый для просмотра логов, которые собирает демон journald в systemd.
Логи хорошо проиндексированы и структурированы таким образом, что позволяет системным администраторам легко анализировать их и управлять ими на основе различных параметров, таких как фильтрация логов по времени, последовательности загрузки, конкретной службе, серьезности и т. д.
1) Как сделать логи постоянным в вашей системе?
По умолчанию логи включены в большинстве дистрибутивов Linux, но данные журнала хранятся в папке «/run/log/journal/», которая по умолчанию стирается при перезагрузке.
Чтобы сделать их постоянными, выполните следующие действия, которые автоматически создадут для вас каталог «/var/log/journal/».
Обратите внимание: каталог «/var/log/journal/» должен существовать с правильным владельцем и правами, чтобы служба systemd-journald могла хранить свои данные.
От пользователя root откройте файл «/etc/systemd/journald.conf» и раскомментируйте строку, содержащую «Storage = auto», и измените ее на «Storage = persistent».
В качестве альтернативы вы можете использовать команду sed для замены соответствующей строки в файле.
$ sudo sed -i ‘/Storage/ cStorage=persistent’ /etc/systemd/journald.conf
После внесения изменений вы можете подтвердить их вступление в силу, выполнив следующую команду:
$ cat /etc/systemd/journald.conf [Journal] Storage=persistent #Compress=yes #Seal=yes #SplitMode=uid #SyncIntervalSec=5m #RateLimitIntervalSec=30s #RateLimitBurst=1000
Перезапустите systemd-journald, как показано ниже:
$ sudo systemctl restart systemd-journald
Измените права доступа к файлу, как показано ниже:
sudo chown -R root:systemd-journal /var/log/journal
Теперь вы сможете просматривать журналы из следующего каталога:
$ ls -lh /var/log/journal total 0 drwxr-sr-x 1 root systemd-journal 392 Mar 15 15:56 7a138ee71db94e8785d1a4dbe54dde7e
2) Понимание полезных флагов journalctl
Прежде чем переходить к команде Journalctl, вы должны знать список часто используемых флагов, которые упростят использование journalctl.
Они перечислены ниже:
- -f: показывает только самые последние логи и сообщения журнала в реальном времени.
- -e: перейти в конец журнала, чтобы показать последние события.
- -r: вывести сообщения логов в обратном хронологическом порядке.
- -k: показать только сообщения ядра.
- -u: показать только сообщения для указанного модуля systemd.
- -b: показать сообщения о конкретной загрузке и отображает текущие загрузочные сообщения, если определенные загрузочные сеансы не включены.
- –List-boots: показывает сеансы загрузки в таблице, включая их идентификаторы и временные метки первого и последнего сообщения, относящегося к загрузке.
- –Utc: выразить время в формате всемирного координированного времени (UTC).
- -p, –priority =: фильтровать вывод по приоритетам сообщений.
- -S, –since =: фильтровать журналы по времени начала.
- -U, –until =: фильтровать журналы по времени окончания.
- –Disk-usage: показывает текущее использование диска всеми файлами логов.
3) Как использовать journalctl для чтения логов
Вы можете фильтровать логи в соответствии с вашими потребностями с помощью различных параметров и полей.