Comments 25
Статья отличная, автору респектище.
PS. внезапно в RUVDS есть нормальные авторы (один шт.), а не только
Не отношусь к хейтерам systemd, но journald получился у них не очень. Конкретные предъявы такие: 1) структурированные данные дело полезное, но плата за это — оверхед места = 2 порядка (x100) по сравнению с обычными текстовыми логами. Поэтому если у вас много логов, то готовьте или много места или подключайте старый-добрый ( r ) syslog.
2) Нет возможности хранить логи раздельно по службам. Т.е нжинкс в один файл, мускуль — в другой и тп. Т.е имеем вариант только, когда все селёдки в одной бочке. Опять же, на десктопе мне без разницы, а на прод серверах это неудобно, особенно, с учетом п.1, когда какой-нибудь говорливый сервис вымывает другие логи. И это эпик фейл.
А logrotate как бы и до journald работает уже 100 лет в обед и есть не просит.
Удобство требует, но понятие "достаточно" не имеет смысла без уточнения для чего именно. Если у вас сервер в облаке, то оверхед за удобство может превратиться в круглую сумму в конвертируемой валюте. Если у вас VPS с диском 50-100 гб, то какая-нибудь внезапная ошибка, приводящая к спаму в логи может уложить весь раздел с логами. И хорошо, если они раздел сделан отдельно от общего.
А конкретно у нас была необходимость хранить несколько недель относительно говорливых сервисов. На сервере были диски на несколько Тб, но их хватало для хранения менее, чем 1 неделя. А нужно было больше. Переход на 10тб диски несет в себе не только финансовые затраты, это совсем другие затраты на ребилд, например, и в разы другая надежность.
Вот с службами, это, да, очень неудобно. Особенно когда логи nginx и mysql — это по сути логи целевого приложения сервера, а не общесистемные.
Представьте, что вам приходится иметь дело с проблемным сервером, который даже не загружается — в таком случае можно загрузиться с live-дистрибутива, смонтировать системный раздел и просмотреть логи systemd, чтобы понять, в чем проблема.
И чем это отличается от варианта с syslog? :)
На всякий случай у journald лучше включать ForwardToSyslog, если на машине есть достаточный запас IO на диск с логами. Обычно в случае падений текстовые логи намного более восстановимы, чем бинарные
Просто посмотреть «логи за конкретную дату» малоинформативно.
С помощью этой тулзы можно ответить на вопрос: «кто и когда удалил файлы из %этого% каталога»? «Что и откуда именно удалил %пользователь%»?
Я тоже не сторонник сабжа, но это уже скорее аудит файловой системы, и для этого есть другие средства. Все зависит от конкретной задачи. Например, если у вас файлопомоечка на samba, то там есть встроенные модули аудита и даже «Корзина» для удаленных файлов. Если нужно мониторить всю файловую систему или каталоги, то есть несколько утилит и библиотек для inotify, например inotify-utils, iwatch. Или можно написать свой кастом на fsnotify.
Тут вопрос, наверное, больше про то, что аудит есть, в логи пишется кто-что сделал, но хотелось бы фильтровать по конкретным полям, а не тупо грепать
Например, дат у вас в записи лога 10, а вам нужна конкретная типа created_at
Дело не в нескольких условиях, а в том, что греп и ко тупо ищет соответствие текстовой строки паттерну. Поддержка семантики только на уровне границ слова и т. п. и именованных областей. Для него не существует даже чисел, только последовательности цифр максимум. Я уж молчу про поля, атрибуты и т. п.
Какой-нибудь встроенный grep по тексту сообщений, желательно с pcre, уже подвезли ?
В гайде забыли рассказать про "-o verbose" где можно посмотреть переменные и их названия чтобы потом фильтровать, например для фильтрации журналов из директории по _MACHINE_ID journalctl -D /var/log/journal/remote _MACHINE_ID=... -u ssh
Использование journalctl для просмотра и анализа логов: подробный гайд