Как быстро искать в journalctl

системдэ – не для торопливых

А если --grep=blabla?

1. Ограничивать объем логов размером на диске или временем хранения. Вручную vacuum или настроить один раз конфиг. Кстати /var/log/* тоже нужно было ограничивать.

2. Не использовать жесткие диски.

https://habr.com/ru/companies/ruvds/articles/533918/

Зачем тебе --no-pager в команде?

journalctl --disk-usage

Что говорит?

Ему уже раз 10 сказали что для пайпа не нужно но он продолжает.

Всего пару недель назад чуваку писали и об этом, и о ключе –grep.

Плохеет с головой у человека, в прямом эфире.

Ну вот гуглишь ты мучительно, на форумах спрашиваешь, в итоге выстраиваешь пайп с какими-то длинными опциями… А тут оказывается, что это не нужно всё, можно сразу наложить фильтры и получить результат с сохранением форматирования текста. Не интересно.

Зачем ты плодишь темы, если всё равно не читаешь ответов в них?

Ведь тебе и в прошлый раз и про необязательность --no-pager говорили (и я и другие — уже не один раз), и про --grep.

P.S. Понимаю, что вероятнее всего и этот комментарий прочитан не будет, но раз уж есть небольшой шанс, стоит попробовать.

А это не тот персонаж, который травмирован головой? (физически)

А чем ключ грепа поможет? Греп что-ли медленно работает или копеечный пайп тормозит всё? Не, там проблема в том, что сам системд туповат, а логи пухлые и размазаны по всему винту, откуда оно по кусочку их собирает (винт это тебе не SSD с одинаковой скоростью доступа к любой ячейке памяти)

1. Объем кстати довольно большой, приложение сыпит как из пулемета. Но все равно я помню грепал гигабайтные файлы и норм, а тут ну оочень долго. За час фильтр, ну сколько там, допустил 50 мб насрет. Это много? Или по дате фильтрует долго. Не понять


2. Аватар крутой! )

Чтобы не разбивал на страницы?

О , а вы с предыдущим комментатором прям братья по аватарам )

Archived and active journals take up 2.6G in the file system.

Чтобы не разбивал на страницы?

А он и не разбивает на страницы при выводе в пайп.

Брат, а что ты быкуешь то сразу? Коли сказал про ключик этот, так приведи пример пожалуйста.

journalctl -u http –grep «session-update»
Failed to add match '–grep': Invalid argument

Хорошо, значит у меня осталась привычка (когда я не знал), исправлюсь. Я смотрю тут этот ключик уже многих раздражает )

Очень много для системд. Конечно будет лагать. https://askubuntu.com/questions/1012912/systemd-logs-journalctl-are-too-large-and-slow

давай почитаем вместе man 1 journalctl?

-g, --grep=
           Filter output to entries where the MESSAGE= field matches the
           specified regular expression.

Хочешь, я расскажу, чем это отличается от твоего grep «blabla»?

нет, видимо ты этого имел ввиду: www.linux.org.ru/people/n0mad/profile

journalctl -u http --grep «play» -S -1h --no-pager

Также ооочень долго. По сути ничем не изменилось, если использовать пайп | grep

Зачем ты плодишь темы, если всё равно не читаешь ответов в них

Там другая тема была наверное, возможно я и не обратил должного внимания на ваш комментарий, извините пожалуйста

Ладно, видимо надо сокращать логи, либо в файлы отдельные выносить...

А у grep есть же ещё всякие параметры полезные, типа -o -E -i

Хочешь, я расскажу, чем это отличается от твоего grep «blabla»?

Расскажи

Расскажи

рассказываю: (с аллегорическими примерами)

твоё:

psql -c 'select * from heroboras' | grep ze_best_of_heroboras

из мана:

psql -c 'select * from heroboras where herobora=ze_best_of_heroboras'

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

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

Ну понятно, я в целом так и думал. Но все равно долго и так и так )

все равно долго и так и так

ssd купи уже и не ной

Но все равно долго и так и так )

А если ещё добавить --reverse?

Также ооочень долго. По сути ничем не изменилось

Ну systemd он и есть systemd. Бывет, наверное.

Но комменты посоветую всё же читать — бывает всякое интересное и полезное, даже если не прям сейчас по теме, а как в прошлый раз — предвосхищая следующую ;)

Ну ваще-та ссд и так есть (а у кого его нет то в наше время?)

и не ной

не психуй брат

Да господи, что вы так въелись за эти темки. Вопросики одни же возникают спонтанно в контексте и что-то там перечитывать, искать... Повторяю - тема другая была, смежная, но все же другая. Голова вмещает только то, что нужно сейчас (Шерлок Холмс) От вас что убудет много, если магический ключик повторите в Nый раз? )

Попробуй ripgrep, он пошустрей grep, вдруг тебе поможет.

Если тебе надо на одних данных сделать несколько поисков, я бы выгрузил логи в один текстовый файл и потом по нему бы искал через ripgrep. Это точно будет быстро.

А вообще для логов если специализированные системы, к примеру loki. При правильной настройке поиск будет очень быстрым, если искать по индексированным данным. Но это тема очень сложная.

В общем и в целом journald беспонтовый и ничего тут по большому счёту не сделать.

Голова вмещает только то, что нужно сейчас (Шерлок Холмс) От вас что убудет много, если магический ключик повторите в Nый раз? )

Да нет, не убудет. И повторили. Скорее просто беспокойство это вызывает, когда человек настолько теряет восприятие информации. Шерлок Холмс как раз держал в голове то, что ему полезно для дела, и замечал даже самые мелочи — в том числе те, которые прямо сейчас кажутся незначительными, но могут потом пригодиться или быть как-то привязаны к делу, при этом не забивая голову не относящейся к делу болтовнёй. У тебя противоположная ситуация — ты именно по делу не замечаешь, так что сравнение здесь вообще не уместно.

Да это понятно, но логами отдельно заниматься как-то времени нет. Они ведь нужны на этапе отладки в большинстве случаев, потом забьешь (до поры). Просто у меня никогда такой проблемы не возникало, поэтому интересуюсь «че-каво» )

Скорее просто беспокойство это вызывает

Зачем ты беспокоишься? Лето, иди жарь шашлык, кайфуй! )

Зачем ты беспокоишься? Лето, иди жарь шашлык, кайфуй! )

У меня пока хватает когнитивного ресурса, чтобы одно никак не препятствовало другому.

Классно! Всем бы так мочь, красавчик )

Объем кстати довольно большой, приложение сыпит как из пулемета.

Это и есть ответ. journald пишет логи в свою БД. Уже видел, как journald давится большими объемами и начинает их дропать. А если отключить лимит, то давиться начинает уже диск

Если логов реально много, нафиг journald, пусть приложение пишет в файл