Pull to refresh

Comments 25

Век живи — век учись.
Статья отличная, автору респектище.
PS. внезапно в RUVDS есть нормальные авторы (один шт.), а не только «кунг-фу...» чтецы манов вслух.
Справедливости ради, всё это есть в манах по journald
Я больше скажу — в манах вообще практически всё есть.
Надо просто их почитать.
Все 14694 штуки например (только-что на своей машине посчитал).
Он до сих пор не умеет чистить логи отдельных юнитов? А поиск?

Не отношусь к хейтерам systemd, но journald получился у них не очень. Конкретные предъявы такие: 1) структурированные данные дело полезное, но плата за это — оверхед места = 2 порядка (x100) по сравнению с обычными текстовыми логами. Поэтому если у вас много логов, то готовьте или много места или подключайте старый-добрый ( r ) syslog.
2) Нет возможности хранить логи раздельно по службам. Т.е нжинкс в один файл, мускуль — в другой и тп. Т.е имеем вариант только, когда все селёдки в одной бочке. Опять же, на десктопе мне без разницы, а на прод серверах это неудобно, особенно, с учетом п.1, когда какой-нибудь говорливый сервис вымывает другие логи. И это эпик фейл.


А logrotate как бы и до journald работает уже 100 лет в обед и есть не просит.

По поводу первого пункта. Удобство часто требует оверхэд. Это нормально. К счастью живём в мире где дисковое пространство достаточно дешёвое.
Не у всех компьютеров есть физический диск.

Удобство требует, но понятие "достаточно" не имеет смысла без уточнения для чего именно. Если у вас сервер в облаке, то оверхед за удобство может превратиться в круглую сумму в конвертируемой валюте. Если у вас VPS с диском 50-100 гб, то какая-нибудь внезапная ошибка, приводящая к спаму в логи может уложить весь раздел с логами. И хорошо, если они раздел сделан отдельно от общего.
А конкретно у нас была необходимость хранить несколько недель относительно говорливых сервисов. На сервере были диски на несколько Тб, но их хватало для хранения менее, чем 1 неделя. А нужно было больше. Переход на 10тб диски несет в себе не только финансовые затраты, это совсем другие затраты на ребилд, например, и в разы другая надежность.

Вот с службами, это, да, очень неудобно. Особенно когда логи nginx и mysql — это по сути логи целевого приложения сервера, а не общесистемные.

Экспериментируя с Linux, заметил такой эффект — если вручную удалить все файлы журналов, то компьютер потом работает быстрее (вернее, открытие директорий). Это заметно на слабом пк с hdd. Потом, после нескольких дней активного использования linux производительность падает (но это незаметно до очистки директории).
Можно настроить правила, чтобы журналы чистились автоматически.
Представьте, что вам приходится иметь дело с проблемным сервером, который даже не загружается — в таком случае можно загрузиться с live-дистрибутива, смонтировать системный раздел и просмотреть логи systemd, чтобы понять, в чем проблема.

И чем это отличается от варианта с syslog? :)

На всякий случай у journald лучше включать ForwardToSyslog, если на машине есть достаточный запас IO на диск с логами. Обычно в случае падений текстовые логи намного более восстановимы, чем бинарные

С помощью этой тулзы можно ответить на вопрос: «кто и когда удалил файлы из %этого% каталога»? «Что и откуда именно удалил %пользователь%»?
Просто посмотреть «логи за конкретную дату» малоинформативно.
С помощью этой тулзы можно ответить на вопрос: «кто и когда удалил файлы из %этого% каталога»? «Что и откуда именно удалил %пользователь%»?

Я тоже не сторонник сабжа, но это уже скорее аудит файловой системы, и для этого есть другие средства. Все зависит от конкретной задачи. Например, если у вас файлопомоечка на samba, то там есть встроенные модули аудита и даже «Корзина» для удаленных файлов. Если нужно мониторить всю файловую систему или каталоги, то есть несколько утилит и библиотек для inotify, например inotify-utils, iwatch. Или можно написать свой кастом на fsnotify.

Тут вопрос, наверное, больше про то, что аудит есть, в логи пишется кто-что сделал, но хотелось бы фильтровать по конкретным полям, а не тупо грепать

Не знаю как в systemd(не сторонник), но в rsyslog поля настраиваемые + можно выводить логи в отдельные файлы. И почему grep тупо?
Вы формат даты в логе видите? Вы думаю можете grep отсортировать даты с глубиной до 10 секунд. Там где не справится grep помогут sed и awk. Но даже grep может делать выборку по нескольким условиям объединяя их AND/OR/NOT. Производительность этого метода конечно будет сильно зависеть от того, как вы построите сортировку, но всяко в сотни раз быстрее, чем фильтр в журнале сообщений windows, который миллион событий может несколько секунд сортировать.

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

Какой-нибудь встроенный grep по тексту сообщений, желательно с pcre, уже подвезли ?

-g, --grep=
Filter output to entries where the MESSAGE= field matches the specified regular expression. PERL-compatible
regular expressions are used, see pcre2pattern(3) for a detailed description of the syntax.

В гайде забыли рассказать про "-o verbose" где можно посмотреть переменные и их названия чтобы потом фильтровать, например для фильтрации журналов из директории по _MACHINE_ID journalctl -D /var/log/journal/remote _MACHINE_ID=... -u ssh

Sign up to leave a comment.