Nerdlog: быстрый TUI-просмотрщик логов с удалённых хостов с таймлайном

но вот эти UX приколы отбили желание пользоваться.

Жаль, и спасибо за отзыв. TODO-список и так огромный, так что не уверен когда именно до этих улучшений доберусь, но согласен, что есть возможность UX улучшить.

Логин у меня прописан так

Host *.server.com
    User me

Ясно, вот этот * не парсится как надо. Добавлю еще один пункт в TODO.

Группу adm наверно можно настроить, но честно говоря, первый раз про такой способ слышу

По мне так это самое оптимальное, вне зависимости от Nerdlog. Юзеры в этой группе могут читать логи без всяких sudo и паролей, но не могут ничего менять. На мой взгляд, оптимально: я не хочу вводить пароль даже чтобы просто логи прочитать; но, конечно, вам решать.

Сходу абстракции совсем неясные.

Это да, надо хоть немного доку прочитать сначала. Но все же скажу, что в том диалоге, который вам показался страшной плашкой, указан формат с примерами:

Logstreams. Comma-separated strings in the format "[user@]myserver.com[:port[:/path/to/logfile]]"
Examples: "user@myserver.com", or "user@myserver.com:22:/var/log/syslog"

Я надеялся, что это поясняет вещи достаточно для быстрого старта.

Если стрим это файл или несколько файлов, то дефолтный стрим 'localhost' сбивает с толку, по идее он дожен быть localhost:/var/log/syslog?

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

myuser@localhost:22:auto:auto

Где myuser - это ваш текущий пользователь на локальной машине, а auto резолвится в конкретные файлы или journalctl на стороне хоста, пробуя следующие варианты в порядке очередности: /var/log/messages, /var/log/syslog, journalctl.

То есть, если нужно именно /var/log/syslog указать, то самый полный вид будет таким:

myuser@localhost:22:/var/log/syslog:/var/log/syslog.1

Ну и еще, для справки, для localhost есть специальное условие: на самом деле, тут юзер и порт игнорятся, и вместо ssh будет использован просто локальный шелл (но логстрим все равно указывается так же).

из всего это непонятно как указать стрим journalctl определенного юнита?

journalctl пока что поддерживается только целиком, нельзя указать аналог journalctl -u myunit.service. Фильтрацию надо будет делать только посредством awk pattern. Запрос по отдельным юнитам - это тоже TODO.

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

но и аггрегирует их,

А можно скрин агрегации логов с 10ка хостов?

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

Ок, но а почему именно плохо во время разработки при работе с большими данными? Слишком медленно получается?

А можно скрин агрегации логов с 10ка хостов?

Быстро - нет, мне бы пришлось этот десяток хостов поднять сейчас на каком-нибудь Digital Ocean, включить рандомную генерацию логов, подождать пока логи понаберутся. Того оригинального проекта из 2022г, где у нас было несколько дюжин хостов, уже нет.

А что именно хотели увидеть на этом скрине? Выглядеть будет также, как и с одного хоста, только в колонке lstream будут разные значения (это логстрим, в котором была запись).

Если что, в readme на гитхабе есть gif-демка с четырьмя демо-хостами, но вы ее, наверное, уже видели.

Мне не хватает возможности в подобной утилите читать docker logs с разных хостов. В проде оно и так собирается со всех машин при помощи vector в Grafana (что используется для хранения, я точно не знаю, создавал не я). А на тестовых стендах подобного нет, и приходится в случае чего ручками лезть и запускать docker logs/docker service logs.

Мне не хватает возможности в подобной утилите читать docker logs с разных хостов

Хмм, мысль интересная. Пока никто не просил такого, но добавить можно, думаю. Надо посмотреть, что docker logs именно может, и насколько трудно будет добавить его поддержку.

Без центрального сервера: Nerdlog подключается по ssh к каждому хосту напрямую.

У меня настроен remote syslog; можно ли натравить на директорию, а там оно само по полям RFC-3164 (или RFC-5424, фрячий ksyslogd умеет) определит с какого хоста прилетел лог?

Логи очень большие )

У меня настроен remote syslog; можно ли натравить на директорию, а там оно само по полям RFC-3164 (или RFC-5424, фрячий ksyslogd умеет) определит с какого хоста прилетел лог?

Натравливать надо на каждый файл по-отдельности, т.е. просто на директорию не получится (пока). А там, если формат файла такой же, как обычно в /var/log/messages (без поля «priority» в начале), то должно работать.

Натравливать надо на каждый файл по-отдельности

... /var/log/foreign/*.conf

Глобы педалят. (=

Насчет глобов, поясню еще: хотя просто заглобить все файлы в директории напрямую пока нельзя, но можно добавить интересующие файлы как логстримы в ~/.config/nerdlog/logstreams.yaml, типа такого:

log_streams:
  myforeign-01:
    hostname: localhost
    log_files:
      - /var/log/foreign/host01_syslog

  myforeign-02:
    hostname: localhost
    log_files:
      - /var/log/foreign/host02_syslog

  myforeign-03:
    hostname: localhost
    log_files:
      - /var/log/foreign/host03_syslog

  myforeign-04:
    hostname: localhost
    log_files:
      - /var/log/foreign/host04_syslog

И после этого в поле Logstreams (или с флагом --lstreams) можно уже просто написать: myforeign-*

Если так, то как тогда комбинировать с другими файлами (точнее, логстримами)? Когда у каждой записи в логе есть временная метка, то записи из разных файлов можно скомбинировать на единой временной шкале, и все будет на своих местах. А без временных меток уже нет такого разумного способа.

Да очень просто: если есть временная метка то отображать ее на временной шкале. Если нет то не отображать. Вот в примеру, лог laravel: там в одной строке идет временная метка а дальше идет многострочный трейс. В итоге, на временной шкале отображать только строки с временными метками и навигация будет по ним. А все что между строк с временными метками, на шкале не отображать но при этом показывать в придачу к предыдущей строке с временной меткой.

Да очень просто: если есть временная метка то отображать ее на временной шкале. Если нет то не отображать

Так я думал, вы имеете в виду файлы логов, где вообще нет временной метки. Вы еще предложили показывать просто шкалу в процентах.

Но оказывается, вы имели в виду логи, где есть временные метки, просто не у всех строк?

Оно может читать логи в реалтайме?

Оно может читать логи в реалтайме?

Нет, только запрос-ответ.

Но оказывается, вы имели в виду логи, где есть временные метки, просто не у всех строк?

В принципе, я выше описал оба варианта: вариант где нет временной метки, а потом, там где есть, но не в каждой строке лога.

я выше описал оба варианта: вариант где нет временной метки, а потом, там где есть, но не в каждой строке лога.

Ок.

Если временные метки есть, но не у всех строк, то это в теории решаемо.

Если временных меток нет вообще, то я не вижу смысла пытаться этот кейс как-то поддерживать.

Прочитал управление, логично и просто сделано, классическая UNIX-way утилита, однозначно лайк.

Если бы это можно было использовать просто как фильтр, запустить ваншотом с :w в файл, а уже этот файл пайпом дальше, те же фильтры IP делать на awk, ещё и централизованно — просто пушка!

Жаль только во FreeBSD Ports Collection старая версия, 1.7.2. Может к тому моменту как я доберусь до, обновят до актуальной.

Если временные метки есть, но не у всех строк, то это в теории решаемо.

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

Если временных меток нет вообще, то я не вижу смысла пытаться этот кейс как-то поддерживать.

Очень хорошо бы поддерживать, иначе прогой не открыть часть логов. А на временной шкале достаточно располагать информацию о точки в процентах просматриваемого лога.

Если временных меток нет вообще, то я не вижу смысла пытаться этот кейс как-то поддерживать.

Очень хорошо бы поддерживать, иначе прогой не открыть часть логов. А на временной шкале достаточно располагать информацию о точки в процентах просматриваемого лога.

Ну тогда переформулирую вопрос, который я пылатся задать ранее: если открыты два или более отдельных логстрима (файла, для простоты), где нет временных меток вообще: как предполагаете их комбинировать? Тут, между файлами, уже нет никаких ориентиров, что было до, что после.

если открыты два или более отдельных логстрима, где нет временных меток вообще: как предполагаете их комбинировать?

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

Ясно, вот этот * не парсится как надо. Добавлю еще один пункт в TODO.

Я не совсем понимаю зачем вообще что-либо парсить из ~/.ssh/config. В проге достаточно сказать, мол давай хост и через двоеточее путь (либо к папке с логами, либо к конкретному логу). И передавать в ssh как есть. А пользователь уже нашаманит в конфиге ssh все что нужно для конкретного хоста. К примеру, если подлючаться по локальной сети то есть смысл поставить более быстрый алгоритм шифрования. Посмотри как сделано подключение по sftp или ssh в том же mc – там нужно просто указать хост и путь. Все остальные настройки для хоста оно возьмет из конфига.

Я бы каждый из них отображал отдельно, в отдельных табах (если это возможно).

Ну вот это как раз и переходит грань разумных усложнений, как мне кажется; поэтому я и сказал, что не вижу в смысла реализовывать такую поддержку. Эти совсем уж особые случаи (нельзя комбинировать с другими, шкалу рисовать по-особенному), отдельные табы делать специально для этого, итд.

Ну и полезность сомнительная: для обычных логов (с таймстампами) Nerdlog значительно улучшает жизнь благодаря комбинированию логстримов, временной шкале и гистограмме; а тут я не вижу особых преимуществ перед даже текстовым редактором или lnav.

Вообще, как по мне, так одна универсальная проблема в индустрии - переусложнение всего, что можно. Люди городят нереально сложные системы, а потом страдают от последствий (трудность сопровождения, ненадежность итд). Нам нужно больше KISS в жизни; ведь надежные системы - это простые системы. Nerdlog должен остаться сравнительно простым. Как Go. :) Ну, почти.

В общем, если когда-нибудь получится, что эта фича (поддержка логов без таймстампов) впишется оргранично в Nerdlog, то хорошо. Пока что она не вписывается совсем, так что я лучше займусь другими фичами, с вашего позволения (TODO-список и так нереально длинный).

Я не совсем понимаю зачем вообще что-либо парсить из ~/.ssh/config. В проге достаточно сказать, мол давай хост и через двоеточее путь (либо к папке с логами, либо к конкретному логу). И передавать в ssh как есть.

Nerdlog для соединения по ssh использует не внешнюю программу ssh, а почти-стандартную Go библиотеку ssh. Эта библиотека, к сожалению, не поддерживает чтение ssh конфига итд.

И еще, даже если предположить, что я это переделаю и добавлю поддержку внешнего ssh, то Nerdlog все равно не сможет все полностью отдать на откуп внешнему ssh и вообще не заниматься хостами: знать сконфигурированные хосты (из ssh конфига, плюс из ~/.config/nerdlog/logstreams.yaml) необходимо для реализации glob по именам хостов (я приводил пример этого logstreams.yaml выше). То есть, если у нас есть например сконфигурированные хосты myhost-01, myhost-02, myhost-03, то в поле Logstreams (или с флагом --lstreams) можно указать myhost-*, и Nerdlog законнектится ко всем трем.

Я не против вашего проекта, но ни как не могу понять зачем он мне может понадбиться.

Про агрегацию заговорили вы, ну так вот агрегация это обьединение. К примеру в графане график с десяток хостов и видно кто выбивается.

Я гифку глянул и не понял где тама обьединение и вообще обьединение логов хз что это может быть.

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

Вы в курсе что по ssh из rhel 9 к rhel 6 и ниже подключиться нельзя без 4х строк в конфиге по поводу шифрования?

Ну вот это как раз и переходит грань разумных усложнений

И где же тут переусложнение? Эта программа – смотрелка логов в удобной форме. ИМХЛ, то, что она не может открыть любой лог – это скорее недостаток нежели отсутствующая фича.

Вообще, как по мне, так одна универсальная проблема в индустрии - переусложнение всего, что можно…

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

В общем, если когда-нибудь получится, что эта фича (поддержка логов без таймстампов) впишется оргранично в Nerdlog, то хорошо. Пока что она не вписывается совсем, так что я лучше займусь другими фичами, с вашего позволения (TODO-список и так нереально длинный).

Ну не вопрос, буду ждать этой фичи. А пока, что останнусь на lnav, который открывает любые логи. Это, пожалуй, более важно, нежели удобная навигация по временной шкале в Nerdlog.

Эта библиотека, к сожалению, не поддерживает чтение ssh конфига итд.

Используя готовую библиотеку вместо ssh клиента, ты тем самым упростил себе разработку и в то же время ограничил пользователей ее возможностями.

То есть, если у нас есть например сконфигурированные хосты myhost-01, myhost-02, myhost-03, то в поле Logstreams (или с флагом –lstreams) можно указать myhost-*, и Nerdlog законнектится ко всем трем.

И в чем здесь проблема? Прочитать все хосты из конфига ssh и в цикле подключиться ко всем через консольный ssh клиент. Не совсем улавливаю причину по которой это нереализуемо либо сложнореализуемо.

Вы в курсе что по ssh из rhel 9 к rhel 6 и ниже подключиться нельзя без 4х строк в конфиге по поводу шифрования?

Не в курсе, ибо красношляпы не юзаю. К чему ты написал эту безумно-познавательную информацию?

Я хз как он будет парсить logs в этом случае без чтения конфигов ssh

Согласен. Но важно найти золотую средину, между отсутствующими важными фичами и переусложнением

И я согласен, но мы просто в разных местах эту золотую середину видим. Это окей.

А пока, что останнусь на lnav, который открывает любые логи. Это, пожалуй, более важно, нежели удобная навигация по временной шкале в Nerdlog.

Дело хозяйское, конечно. Я сам lnav использую для некоторых вещей, если что. А Nerdlog использую там, где он хорош. The right tool for the job и все такое.

Кстати, nerdlog не задумывался как альтернатива lnav, он скорее был специфической альтернативой Graylog и подобным системам. Так что фокус на другие вещи, нежели lnav; в FAQ даже есть секция про сравнение с lnav. Этот фокус уже меняется в некоторой степени, но вот реализовывать поддержку логов без таймстампов, что требует отдельного подхода к многим вещам - это слишком, по крайней мере пока.

Но еще спрошу: насколько это частое явление - логи без таймстампов? Можете привести самые распространенные примеры?

И в чем здесь проблема? Прочитать все хосты из конфига ssh и в цикле подключиться ко всем через консольный ssh клиент.

Нет проблемы как таковой, но я вам отвечал на сообщение, где вы говорили, что не понимаете, зачем вообще парсить ssh конфиг. Я объяснял, почему nerdlog все же должен его парсить, и, например, отсутствие поддержки Include как сейчас - это реальное ограничение, и использование внешнего ssh клиента тут не поможет.

Но да, действительно, гибридное решение может оказаться наилучшим здесь: как вы и говорите, nerdlog может распарсить ssh конфиг насколько может, а само соединение отдать внешнему ssh если он доступен; и даже если что-то не распарсится, то это отразится только на списке известных хостов, а не на самом соединении к хостам. Фича разумная, у меня есть желание ее реализовать.

Вы в курсе что по ssh из rhel 9 к rhel 6 и ниже подключиться нельзя без 4х строк в конфиге по поводу шифрования?

Можете раскрыть тему? Сейчас nerdlog ничего по поводу шифрования из ssh конфига не берет, так что если действительно нельзя подключиться из rhel 9 к rhel 6, то nerdlog и не сможет сейчас. Интересно узнать подробности.

Я не против вашего проекта, но ни как не могу понять зачем он мне может понадбиться.

Ну так, наверное, он вам просто не нужен в таком случае? У меня нет цели вам его продать или навязать. Используйте, что нужно и что нравится.

Про агрегацию заговорили вы, ну так вот агрегация это обьединение. К примеру в графане график с десяток хостов и видно кто выбивается.

Я гифку глянул и не понял где тама обьединение и вообще обьединение логов хз что это может быть.

Не понимаете, что такое агрегация логов? Я не знаю, троллинг это или нет, но отвечу как есть: в контексте Nerdlog, агрегация логов — это процесс сбора записей логов с разных источников (в данном случае - разных серверов) в одном центральном месте (в клиентском приложении Nerdlog) для последующей визуализации.

То, что на гифке непонятно, где объединение - ну так это наверное даже хорошо, что все вместе отображается, и выглядит одинаково как с одним источником логов, так и с несколькими. Единственное, что выдает аггрегацию - это колонка lstream в таблице логов. В этой гифке есть 4 логстрима : mydemo-01, mydemo-02 и т.д. Каждый логстрим здесь собирается с отдельного сервера, и отображается в объединенном виде (аггрегируется).

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

Хехе, нам то же самое говорили и те инфраструктурщики, которые решили выключить быстрый Graylog и дать вместо этого нереально медленный Splunk (в статье на Хабре рассказывается более подробно). Аргумент был - быстрый просмотр логов не нужен.

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

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

Хотя мне это не нужно, бо у нас тут энетрпрайзный энтерпрайз с сотнями узлов и терабайтами логов и без Opensearch никак, но крайне рад, что лёгкие и быстрые альтернативы до сих пор делают. Значит не так уж и плохо всё в этом нашем ИТ. Спасибо автору.

И где же тут переусложнение?

мимокрокодил: Такой вопрос-утверждение звучит гораздо сильнее, когда сопровождаются PR’ом, добавляющим искомую возможность.

Ну типа:

https://rwmj.wordpress.com/2022/08/08/ssh-from-rhel-9-to-rhel-5-or-rhel-6/

насколько это частое явление - логи без таймстампов? Можете привести самые распространенные примеры?

Вообще без таймстампов – явление не частое. Здесь я согласен, что возможно проще обойтись текстовым редактором или шел скриптом. А вот логи где нет таймстампа в каждой строке – явление часnое. Тот же, laravel лог:

[2025-05-27 16:02:06] production.ERROR: Expected response code "250/251/252" but got code "550", with message "550 5.7.1 Relaying denied". {"userId":35,"exception":"[object] (Symfony\\Component\\Mailer\\Exception\\UnexpectedResponseException(code: 550): Expected response code \"250/251/252\" but got code \"550\", with message \"550 5.7.1 Relaying denied\". at /home/httpd/web/public_html/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php:338)
[stacktrace]
#0 /home/httpd/web/public_html/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(197): Symfony\\Component\\Mailer\\Transport\\Smtp\\SmtpTransport->assertResponseCode()
#1 /home/httpd/web/public_html/vendor/symfony/mailer/Transport/Smtp/EsmtpTransport.php(118): Symfony\\Component\\Mailer\\Transport\\Smtp\\SmtpTransport->executeCommand()
#2 /home/httpd/web/public_html/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(264): Symfony\\Component\\Mailer\\Transport\\Smtp\\EsmtpTransport->executeCommand()
#3 /home/httpd/web/public_html/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(216): Symfony\\Component\\Mailer\\Transport\\Smtp\\SmtpTransport->doRcptToCommand()
#4 /home/httpd/web/public_html/vendor/symfony/mailer/Transport/AbstractTransport.php(69): Symfony\\Component\\Mailer\\Transport\\Smtp\\SmtpTransport->doSend()
...

Вообще без таймстампов – явление не частое. Здесь я согласен, что возможно проще обойтись текстовым редактором или шел скриптом. А вот логи где нет таймстампа в каждой строке – явление часnое.

А, ну так значит у нас, похоже, разногласий нет, только если недопонимание есть. Я же выше писал:

Если временные метки есть, но не у всех строк, то это в теории решаемо.

Если временных меток нет вообще, то я не вижу смысла пытаться этот кейс как-то поддерживать.

То есть, да, я согласен, что поддерживать логи, где не у всех строк есть таймстампы - имеет смысл (и это уже в TODO). А там, где их нет вообще - не имеет.

Такой вопрос-утверждение звучит гораздо сильнее, когда сопровождаются PR’ом, добавляющим искомую возможность.

Для PR’а с патчем по добавлению фичи нужно программить на том языке, на котором написана тулза. Очевидно, не?

В проекты, написанные на тех языках с которыми я знаком, мне не лень отправить патчи или как минимум, детальный PR со всеми трейсами.

А что с мультилайн - простыни стектрейсов от явы, например?

Для PR’а с патчем по добавлению фичи нужно программить на том языке, на котором написана тулза. Очевидно, не?

Понимаю. Go является языком запутанным и эзотерическим. Не каждый разберётся. Но как же вы тогда берётесь утверждать что является сложным, а что нет?

А что с мультилайн - простыни стектрейсов от явы, например?

Если приложение на Java запущено как systemd-сервис (как было в нашем случае), то каждая отдельная строка стектрейса уже будет сохранена в /var/log/syslog с таймстампом в каждой строке, так что будет работать (или в выводе journalctl место для таймстампов будет залито пробелами в multiline-записях - так тоже работает).

Ну а если речь идет о каком-то другом лог файле, где эти стектрейсы сохранены в голом виде без таймстампов в каждой строке, то это именно тот случай, о котором мы только что с iron говорили. Фича полезная и нужная, но пока что TODO.

Но как же вы тогда берётесь утверждать что является сложным, а что нет?

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

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

А смысл если systemd-journal-remote доступен из коробки?

Не все коробки одинаковы.

взял отпуск на неделю и устроил себе личный хакатон

Взял отпуск, чтобы работать?

Отпуск это фигня, я дааавно ещё будучи на больничном в связи с травмой (локоть на куски разбило) зафигачил очень полезныю хрень в виде репликатора для IB/FB. Успешно ушло в прод и как минимум проработало 19 лет.

раз пробовали его запускать (не прогресс-бар, но проценты пишет).
В общем, согласен, что может быть полезно иногда. Сделаю, когда руки дойдут.

Если пишет проценты, то этого достаточно, не надо усложнять лишними прогрессами, оно тоже ресурсы жрет.

Если пишет проценты, то этого достаточно, не надо усложнять лишними прогрессами, оно тоже ресурсы жрет.

Согласен, я и не собирался усложнять прогресс-барами. То, что я сказал «Сделаю, когда руки дойдут» относилось к отсутствующей фиче, с которой и начался этот разговор с iron:

Если я хочу открыть лог, в котором не известно за какой период времени логи или вообще нет временной метки, как это сделать?

То есть, если не указать временной промежуток, то Nerdlog будет читать все логи, что есть (хотя с journalctl это будет реально медленно)