Журнал событий, это компонент systemd, который захватывает сообщения Syslog, логи ядра, все события при инициализации системы (RAM, диск, boot, STDOUT/STDERR для всех сервисов), индексирует их и затем предоставляет удобной пользовательский интерфейс для поиска и фильтрации логов. Журнал (systemd journal) можно использовать вместе или вместо syslog или syslog-ng.
Утилита командной строки journalctl, если сравнивать ее с традиционным инструментами для работы с логами в UNIX (tail, grep, sed, awk) более широкие возможности.
Давайте рассмотрим основные возможности которые предоставляет журнал systemd и способы их применения.
Журнал systemd сохраняется на диск, поэтому все логи «переживают» перезагрузку системы. Посмотреть список с доступными загрузками:
Команда journalctl –b покажет все логи для текущей загрузки. Если необходимы логи какого-то определенного периода, то нужно добавить в качестве аргумента номер загрузки:
journalctl -b -1
Для того, чтобы получить все логи для текущей загрузки в обратном хронологическом порядке:
journalctl -b --all --catalog --no-pager
Все логи за все время в одном файле:
journalctl --all --catalog --merge --no-pager
Текущая загрузка, только логи ядра:
journalctl -b -k --no-pager
Для того, чтобы можно было отслеживать логи в режиме реального времени (похоже на tail –f):
journalctl -f
Просмотреть сколько места занимают журналы systemd на диске (/var/log/journal/):
Структурированные логи открывают широкие возможности для автоматизации. Больше не надо «хачить» пытаясь склеить sed, grep и awk в скриптах. Любой высокоуровневый язык программирования содержит модуль для работы с JSON.
В качестве наглядного примера можно представить себе сдающий сценарий: Приложение X записывает в журнал событий какие-то сообщения. Простая программа работающая в режиме демона Linux отслеживает события в журнале systemd. В случае появления какого-то определенного сообщения в журнале, программа следуя внутренней логике отправляет сообщение в шину данных (kafka, rabbitmq, NATS) или выполняет определенные операции в системе:
Код
package main
import (
"bufio"
"fmt"
"os"
"os/exec"
"strings"
)
func main() {
// Отслеживаем сообщения для идентификатора «events_topic»
cmdName := "journalctl -t events_topic -f"
cmdArgs := strings.Fields(cmdName)
cmd := exec.Command(cmdArgs[0], cmdArgs[1:len(cmdArgs)]...)
stdout, _ := cmd.StdoutPipe()
cmd.Start()
oneByte := make([]byte, 100)
num := 1
for {
_, err := stdout.Read(oneByte)
if err != nil {
fmt.Printf(err.Error())
break
}
r := bufio.NewReader(stdout)
line, _, _ := r.ReadLine()
fmt.Println(string(line))
num = num + 1
if num > 3 {
os.Exit(0)
}
}
}
Теперь в одной сессии терминала мы запускаем программу отслеживающую события в журнале:
go run watch.go
Jul 22 15:49:25 Pythagoras events_topic[1293240]: NEW EVENT
Jul 22 15:49:28 Pythagoras events_topic[1293250]: NEW EVENT
А в другой сессии терминала эмулируем запись приложением X сообщений в журнал с помощью встроенной утилиты systemd-cat:
echo "NEW EVENT" | systemd-cat -t events_topic
echo "NEW EVENT" | systemd-cat -t events_topic
В данном случае для работы с журналом используется пакет "os/exec" – то есть мы выполняем системные команды, но можно воспользоваться одной из существующих библиотек:
Это простой пример использования структурированных логов журнала systemd. Возможности systemd гораздо шире – многие из них используются, например облачными провайдерами для построения отказоустойчивой инфраструктуры.
sos report - когда нужно найти иголку в стоге сена
Не всегда есть возможность в спокойной, неспешной обстановке проанализировать логи и выводы различных диагностических команд на промышленной инфраструктуры. В некоторых случаях для поиска корневой причины нужен глубокий анализ, сверка логово и метрик в ретроспективе, иногда написание автоматизации для парсинга логов.
Для таких сценариев как раз и предназначен sos report. Это унифицированный инструмент для сбора логов и диагностической информации. С помощью sos report можно создавать архив со всей необходимой информацией о системе – эти данные используются для анализа и поиска проблем в режиме оффлайн.
Установка sosreport:
yum install sos
apt install sosreport
Программа написана Python. Легко расширяется. Для sos report были написаны десятки плагинов:
sos report --list-plugins
alternatives System alternatives
anaconda Anaconda installer
anacron Anacron job scheduling service
ata ATA and IDE information
auditd Audit daemon information
block Block device information
boot Bootloader information
cgroups Control groups subsystem
chrony Chrony clock (for Network time protocol)
cockpit Cockpit Web Service
conntrack conntrack - netfilter connection tracking
...
sos report --list-presets
name: none
description: Do not load a preset
note: Use to disable automatically loaded presets
name: minimal
description: Small and quick report that reduces sos report resource consumption
note: May be useful for low-resource systems, but may not provide sufficient data for analysis
Все это можно кастомизировать под определенный кейс.
Пример генерации репорта:
sos report --all-logs --batch --tmp-dir=/var
Созданный архив с логами можно забрать для дальнейшего анализа:
Your sosreport has been generated and saved in:
/var/tmp/<FILENAME>.tar.xz
Size 20.25MiB
Owner root
sha256 db71d185550428b5c3a12010fc76206b58b159671c6b74c2fce575254e388030
В зависимости от выбранного профиля и плагинов, в архиве может содержатся подробная диагностическая информация с выводами различных утилит и инструментов:
tar -xf <FILENAME>.tar.xz
boot dmidecode free ip_addr lib lspci proc root-symlinks sos_logs uname var
date environment hostname ip_route lsmod mount ps run sos_reports uptime version.txt
df etc installed-rpms last lsof netstat pstree sos_commands sys usr vgdisplay
При генерации репорта, с помощью флагов --clean, --domains и --keywords можно обфусцирвоать (подчистить) полученный архив удалив всю конфиденциальную информацию.
