Имеет. До сих пор многие его юзают в чистом виде, или юзают связку 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 такой, разработчики отвечали. Только они нередко путаются в показаниях даже в пределах одного текста.
Интуитивностью. Вы знаете где есть файл, и что его можно вывести десятком разных способов, самый простой из которых - кат. А в случае с journald нужно помнить что только эта тулза читает эти логи, и для этого нужно заюзать ключик -D, который нужно ещё запомнить)
Да какая тут интуитивность, знание о cat и прочих утилитах не с рождения в человеке находятся, и так же приобретаются, и приобрести знание о journalctl -D - никаких проблем, просто дело нескольких применений на практике.
Пока ты зубоскалишь, саахрикту вербует бойцов в КГРУ(кои8смическое государство России и Украины) (пока еще не запрещённая террористическая организация)"
а если внезапно в твоём $keyword спецсимволы регэкспов обнаружатся, тогда что? Например, ищешь в логах апача имя файла с с расширением, а точка - чего-то там значит для регэкспа :)
Пожалуй, вы правы... Вероятно это дело привычки уже, что мне такой подход кажется интуитивным, ведь на самом деле jornalctl и в этом плане удобней будет.
а я считаю, что ты вбрасываешь о том что я вбрасываю.
и вообще, можно найти много примеров чтобы показать как плохо делать логи текстовыми, но всего несколько примеров когда это типа «удобно».
т.к. ты считаешь что «текстовые логи — плохо» вбросом, наверное, если ты всё ещё хочешь поговорить на эту тему, а не вбрасывать про вбрасывание, тебе стоит начать с хотя бы парочки примеров когда «текстовые логи — хорошо»
О да, это прямо типично для логов вебсервера. Сразу видно человека, который недавно узнал, что в регексах точка - это любой символ, и теперь тычет своим знанием в лицо собеседнику.
Я не увидел там юзкейсов, кроме признания «я не осилил греп, но осилил ключи journalctl». Приведи, пожалуйста, хотя бы два IRL примера того, как ты использовал регексы для чтения логов; тебе это должно быть несложно, ведь ты это делал «каждый раз».
Что такое журнал - это передача информации во времени. Передача информации: источник - кодирование - среда - декодирование - приемник (время тоже среда передачи).
В случае journald кодирование/декодирование жестко завязано на journald своей «бинарностью». Вплоть до того что разные версии journald не понимают друг друга.
Какой, говоришь, формат журнала journald, есть для него кодер/декодер от сторонних разработчиков? Как обработать журнал на mac или win?
В случае с текстовым логом есть стандартизированные независимые от платформы кодировщик/декодировщик «текста».
Если нужен более структурированный журнал, то есть, например, экспорт/импорт в стандартизированный sql, который реализован разными субд в разной степени
фичастости в плане обработки.
В свете этого journald выглядит разработка от любителя искать «фатальные недостатки».
нет. формат syslog даёт тебе «стандартный» набор полей и ограничивает тебя со всех сторон. а в реализациях ещё и длину полей ограничивают, ну т.е. полная огороженность в том, что ты можешь передать в сообщении это «абсолютная универсальность» — вот уж нет.
чем же плохо делать текстовые логи в формате который придумали много лет назад? ещё раз, всем. вот вообще всем.
начиная от отсутствия любого ACL кроме posix, заканчивая io и latency. где-то по середине ещё отсутствие индексации и выборки, без сторонних инструментов, по тем самым «полям» которые декларирует формат.
за время существования этого самого syslog ни он, ни grep далеко не эволюционировали, но логов стало больше в много раз.
в следствии чего — логи в первую очередь читаются машиной. а в будущем и вообще, анализироваться будут машиной. текст для этого не подходит совершенно. потому его и парсят всякими парсилками в бинарные форматы, вроде баз банных. а некоторые ещё и пишут сразу бинарно, вроде dnstap.
текстовые логи отлично подходят для 1990-х годов, и то с оговоркой, если ты не телеком.
это просто очередное дурацкое решение которых в товарных количествах напринимали диды.
обычные субд тоже завязаны своей бинарностью и грепать в pg или sqlite файлы тоже неприятно. что с того?
и вообще, причём здесь journald? частный случай.
Экспорт/импорт не в СУБД, а стандартный SQL. Внутренние проблемы СУБД - это внутренные проблемы СУБД, это не проблемы журналирования. То что journald прикидывается СУБД, но при этом не является «системой управления базой данных» - это вот проблема.
То есть когда ты от syslog застребовал многопользовательский доступ, acl, io latency, индексацию, выборки - это не совсем не про СУБД?
При этом с этой затребованной тобой функциональностью journald плохо справляется, потому что journald - это не субд.
причём здесь 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 так, чтобы он разбивал логи на файлы по нужным критериям» не принимаются, потому что машину времени ещё не изобрели и при первичной настройке машины не всегда очевидно, по каким критериям придётся искать впоследствии.
Слушатель - пользоваетель windows xp, который открыл файл system.journal в notepad. Он там видит кракозябры. Что ему делать, к кому обратиться за контрактом, на котором держится мифический IT?