Journalctl и бинарный лог

лучше спросить что плохого в текстовых логах
а ответ — всё. кроме тех случаев когда ты что-то хочешь испортить. тогда это наруку.

Если собеседование. Обязательно ли спросят и про rsyslog и journald? Имеет ли смысл учить старый вариант системы логирования rsyslog?

учить

Мы вам перезвоним.

Имеет ли смысл учить старый вариант системы логирования rsyslog?

настоятельно рекомендую. и рфц можно почитать. https://tools.ietf.org/html/rfc5424
а чего на собеседовании спросят ни знаю.

для экономии места на диске, и чтобы было удобнее индексировать, искать и т.п. Что-то подобное сделано в PowerShell.

Кстати, «в одном месте» не совсем правда - там можно настроить и передачу логов по сети

Имеет. До сих пор многие его юзают в чистом виде, или юзают связку journald + rsyslog. Если рассматривать удобство использования, то journald очень крут, а бинарные логи рулят. system-root дело говорит. Один только быстрый поиск по нужному service, дате или временному промежутку и другим критериям чего стоят. Можно в один момент посмотреть логи с последней загрузки, прошлой или к примеру n-ой загрузки. А не велосимедить с grep и awk просто что-бы найти что-то по определённым критериям.

Есть и минус бинарных логов - их можно смотреть только специально заточенным для этого journalctl, ковырять любым редактором, выводить любым пейджером или cat не получится. К примеру если система упала и вы загрузились с Live USB/PXE что-бы глянуть что с ней, вам понадобится параметр -D с путём к каталогу с журналами упавшей системы задать journalctl ручками, при запуске journalctl. Что не так интуитивно, как cat путь_к_какому-то_логу с корневого раздела упавшей тачки).

rsyslog не обязательно, но syslog простой стандарт, которому уже почти 40 лет. Хотя syslog уступает место SNMP, его ещё не выкинули из энтерпрайзных железяк, а systemd завязан только на линукс. В journald хоть и не стали реализовывать сетевую часть syslog, но он читает стандартные UNIX-сокеты в этом формате, ведь без этого все программы пишущие туда(почти все журналирующие) пришлось бы переписывать. И писать в сокет тоже может. Почему jourlald такой, разработчики отвечали. Только они нередко путаются в показаниях даже в пределах одного текста.

А чем отличается cat /path/to/broken-system/journal от journalctl -D /path/to/broken-system/journal?

Интуитивностью. Вы знаете где есть файл, и что его можно вывести десятком разных способов, самый простой из которых - кат. А в случае с journald нужно помнить что только эта тулза читает эти логи, и для этого нужно заюзать ключик -D, который нужно ещё запомнить)

Да какая тут интуитивность, знание о cat и прочих утилитах не с рождения в человеке находятся, и так же приобретаются, и приобрести знание о journalctl -D - никаких проблем, просто дело нескольких применений на практике.

его можно вывести десятком разных способов, самый простой из которых - кат.

Особенно просто, когда логи на национальном языке в неизвестной кодировке.

не всем нужно запускать софт, написанный саахрикту

ключик -D, который нужно ещё запомнить)

А помнить все ключи grep и регекспы, конечно, не нужно.

Пока ты зубоскалишь, саахрикту вербует бойцов в КГРУ(кои8смическое государство России и Украины) (пока еще не запрещённая террористическая организация)"

Часто тебе нужны регекспы для чтения логов?

Если собеседование. Обязательно ли спросят и про rsyslog и journald?

Смотря на какую позицию собеседование же. Если на инженера по логам - думаю что спросят обязательно.

Имеет ли смысл учить старый вариант системы логирования rsyslog?

Имеет, еще имеет смысл и популярный сейчас ELK-стек рассмотреть.

формально любой аргумент grep-а - регэксп

Это ж надо такое жирное 4.2 прям с первого коммента.

Ну если для кого проблема запомнить конструкцию «grep $keyword», то это уже что-то из психоневрологии.

Последние годы — ни разу, journalctl хватало. До этого — _каждый_ раз.

Юзкейсы плз

ты хочешь поговорить об этом? начни с аргументов а не размахиваний 4.2 в таком случае.

а если внезапно в твоём $keyword спецсимволы регэкспов обнаружатся, тогда что? Например, ищешь в логах апача имя файла с с расширением, а точка - чего-то там значит для регэкспа :)

Читать то, что надо, а не то, чего не надо.

Пожалуй, вы правы... Вероятно это дело привычки уже, что мне такой подход кажется интуитивным, ведь на самом деле jornalctl и в этом плане удобней будет.

Не надо переусложнять на ровном месте,

grep "file.txt"

Юзкейсы плз.

Щемта это ты безапелляционно вбросил.

# echo "file1txt"|grep "file.txt"
file1txt

Сразу видно специалиста.

Столлман и systemd (комментарий)

а я считаю, что ты вбрасываешь о том что я вбрасываю.
и вообще, можно найти много примеров чтобы показать как плохо делать логи текстовыми, но всего несколько примеров когда это типа «удобно».
т.к. ты считаешь что «текстовые логи — плохо» вбросом, наверное, если ты всё ещё хочешь поговорить на эту тему, а не вбрасывать про вбрасывание, тебе стоит начать с хотя бы парочки примеров когда «текстовые логи — хорошо»

О да, это прямо типично для логов вебсервера. Сразу видно человека, который недавно узнал, что в регексах точка - это любой символ, и теперь тычет своим знанием в лицо собеседнику.

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

А теперь будь добр, раз ты не вбрасываешь, объясни популярно, чем это плохо.

Я не увидел там юзкейсов, кроме признания «я не осилил греп, но осилил ключи journalctl». Приведи, пожалуйста, хотя бы два IRL примера того, как ты использовал регексы для чтения логов; тебе это должно быть несложно, ведь ты это делал «каждый раз».

Что такое журнал - это передача информации во времени. Передача информации: источник - кодирование - среда - декодирование - приемник (время тоже среда передачи).
В случае journald кодирование/декодирование жестко завязано на journald своей «бинарностью». Вплоть до того что разные версии journald не понимают друг друга. Какой, говоришь, формат журнала journald, есть для него кодер/декодер от сторонних разработчиков? Как обработать журнал на mac или win?
В случае с текстовым логом есть стандартизированные независимые от платформы кодировщик/декодировщик «текста».
Если нужен более структурированный журнал, то есть, например, экспорт/импорт в стандартизированный sql, который реализован разными субд в разной степени фичастости в плане обработки.
В свете этого journald выглядит разработка от любителя искать «фатальные недостатки».

абсолютно универсально

нет. формат syslog даёт тебе «стандартный» набор полей и ограничивает тебя со всех сторон. а в реализациях ещё и длину полей ограничивают, ну т.е. полная огороженность в том, что ты можешь передать в сообщении это «абсолютная универсальность» — вот уж нет.
чем же плохо делать текстовые логи в формате который придумали много лет назад? ещё раз, всем. вот вообще всем.
начиная от отсутствия любого ACL кроме posix, заканчивая io и latency. где-то по середине ещё отсутствие индексации и выборки, без сторонних инструментов, по тем самым «полям» которые декларирует формат.
за время существования этого самого syslog ни он, ни grep далеко не эволюционировали, но логов стало больше в много раз.
в следствии чего — логи в первую очередь читаются машиной. а в будущем и вообще, анализироваться будут машиной. текст для этого не подходит совершенно. потому его и парсят всякими парсилками в бинарные форматы, вроде баз банных. а некоторые ещё и пишут сразу бинарно, вроде dnstap.
текстовые логи отлично подходят для 1990-х годов, и то с оговоркой, если ты не телеком.
это просто очередное дурацкое решение которых в товарных количествах напринимали диды.

обычные субд тоже завязаны своей бинарностью и грепать в pg или sqlite файлы тоже неприятно. что с того?
и вообще, причём здесь journald? частный случай.

Экспорт/импорт не в СУБД, а стандартный SQL. Внутренние проблемы СУБД - это внутренные проблемы СУБД, это не проблемы журналирования. То что journald прикидывается СУБД, но при этом не является «системой управления базой данных» - это вот проблема.

journald прикидывается СУБД

чё правда? или сам придумал?

То есть когда ты от syslog застребовал многопользовательский доступ, acl, io latency, индексацию, выборки - это не совсем не про СУБД?
При этом с этой затребованной тобой функциональностью journald плохо справляется, потому что journald - это не субд.

фанатики, что же с них взять

а ведь через 10яток другой лет, кто-то будет реверсить это поделие «какого буя оно бинарное, да на этом гогне мамонта»

причём здесь journald? я описывал проблемы непожатого plan text в формате syslog. причём здесь journald то, ещё раз спрашиваю?
то, что journald или СУБД решают какие-то проблемы это частный случай. можешь придумать своё решения, хоть с ИИ и инопланетным методом хранения из будущего.

Syslog занимается передачей информации посредством текста. Как субд используется файловая система и записи делаются в текстовом формате. Тут «бинарно» только ФС, но проблемы субд - это проблемы субд. Сислог свою часть работы сделал - передал информацию во времени.
Как передать информацию в неизвестном бинарном формате? подключать bigdata с ml, чтобы вытащить информацию?

ваще не понимаю чё ты хочешь.
что такое бинарный формат? это всё что не текст. что такое текст? это последовательность байтов которую нужно расшифровать кодовой таблицей символов. несмотря на то, что есть наркоманы, вроде фанбоев КОИ-8, которые считают что всё текст, даже /dev/random — это не так.
через это, любая фигня вроде zcat читает бинарный формат. и чёт никто не плакал, мол какого хрена у нас тут логи бинарные после ротации.
и с какого перепугу этот формат должен быть неизвестен? это что за пример такой? криптолокер?

Это у тебя надо спрашивать, что такое «бинарный» формат. «Текстовый» формат сислога есть в документации сислога. Эта документация публично доступна. Можно написать свой кодек, который практически однозначно интерпретирует этот «текст». А вот твой «бинарный» формат как интерпретировать вне твоего сознания?
Повторю, передача информации - это не только что-то крикнуть, нужен еще понимающий слушатель.

Опять двадцать пять... Это плохо тем, что текст неструктурирован. Его сложнее обрабатывать, когда нужна чуть более сложная обработка, чем «поиск вхождений подстроки».

Дано: /var/log/messages.
Найти: эквивалент команды journalctl --since '22.07.2018 01:23:45' _PID=6789 и journalctl _SYSTEMD_INVOCATION_ID=$(systemctl -p InvocationID show UNIT | cut -d= -f2).

Ответы вида «настроить rsyslog так, чтобы он разбивал логи на файлы по нужным критериям» не принимаются, потому что машину времени ещё не изобрели и при первичной настройке машины не всегда очевидно, по каким критериям придётся искать впоследствии.

ну договорись со слушателем как расшифровывать чё ты ему кричишь.
всё IT держится на контрактах. где ты тут проблему нашёл?

Слушатель - пользоваетель windows xp, который открыл файл system.journal в notepad. Он там видит кракозябры. Что ему делать, к кому обратиться за контрактом, на котором держится мифический IT?

Если свободный текст запихали в поле - этот текст от этого не станет структурированным