Nerdlog — многооконный TUI-просмотрщик логов с SSH и временными диаграммами

nerdlog многооконный tui-просмотрщик логов: что важно знать перед принятием решения.

Разбираем контекст, ключевые критерии, риски и практические шаги без привязки к шаблонным сценариям.

Когда инженер сталкивается с задачей разбора логов на десятке-другом удалённых машин, привычные веб-интерфейсы вроде Graylog или Kibana требуют отдельной инфраструктуры: сборщик, индекс, фронтенд, шину сообщений. Nerdlog — многооконный TUI-просмотрщик логов — решает ту же задачу принципиально иначе: это терминальное приложение, спроектированное для удалённой многохостовой работы. На наших проектах мы регулярно поднимаем подобные стенды, и нам важно, чтобы инструмент диагностики запускался за минуту, а не неделю.

Ключевая архитектурная особенность Nerdlog — отсутствие центрального сервера. Программа открывает SSH-соединение к каждому хосту, с которого нужно собрать данные, и держит эти сессии в фоне. Нет ни брокера, ни хранилища индексов, ни отдельного агента — всё, что требуется на стороне сервера, это стандартный sshd и базовые утилиты. Для команды эксплуатации это означает нулевую стоимость владения: нечего обновлять, нечего мониторить, нечего ломать.

Ещё одно следствие архитектуры — данные не качаются на локальную машину целиком. Анализ выполняется на удалённых нодах, по сети передаются только результаты запроса. Когда у нас на прод-стенде один файл `/var/log/syslog` разрастался до 1ГБ , классическая связка `scp + grep` забивала канал и блокировала рабочую станцию на минуты. Nerdlog в той же ситуации возвращает агрегированные данные практически мгновенно, потому что фильтрация и подсчёт гистограммы выполняются прямо на хосте.

TUI здесь не дань хипстерству, а инженерный выбор. Терминальный интерфейс работает поверх SSH-туннеля без X-форвардинга и VNC, не требует браузера, не зависит от шрифтов и DPI монитора. В дороге с ноутбука, по слабому каналу через бастион — поведение одинаковое. По нашему опыту, именно это сочетание скорости и предсказуемости делает консольные просмотрщики основным инструментом дежурных смен.

Проект распространяется под лицензией BSD-2-Clause , то есть его можно безбоязненно встраивать во внутренние процессы и коммерческие продукты. На момент нашего знакомства репозиторий собрал около 1.5k звёзд и 40 форков — небольшое, но активное сообщество, что для нишевого админ-инструмента вполне здоровый показатель.

Запуск Nerdlog на новой инфраструктуре сводится к двум вещам: рабочий SSH-доступ и описание хостов. Поскольку никакого централизованного сервера не требуется , всё что нужно проверить — это ~/.ssh/config и возможность открыть интерактивную сессию под нужным пользователем. На наших проектах мы предпочитаем заранее завести алиасы для каждой группы машин: web-prod-01, db-stage-02 и так далее, чтобы потом перечислять их одной строкой.

Базовая конфигурация в ~/.ssh/config типично выглядит как блок Host web-prod-* с параметрами User, IdentityFile, ProxyJump bastion.example.com и ServerAliveInterval 30. После этого запуск Nerdlog с подключением к группе хостов производится через стандартный синтаксис указания целей. Инструмент изначально нацелен на чтение системных логов: файлов /var/log/messages, /var/log/syslog и вывода journalctl. Это покрывает большую часть задач системного администратора без дополнительной настройки парсеров.

Отдельно стоит поговорить о правах. Файлы в /var/log обычно читаются только группой adm или systemd-journal, а journalctl без флага --user требует прав на чтение системного журнала. Не делайте root-доступа ради удобства — мы однажды столкнулись с ситуацией, когда временно выданный sudo-без-пароля для отладки логов остался в sudoers.d на полгода и попал в отчёт аудита. Корректный путь — добавить пользователя в нужную группу через usermod -aG systemd-journal,adm.

Поскольку SSH-сессии Nerdlog держит в фоне, мы рекомендуем настраивать ServerAliveInterval и ControlMaster auto на стороне клиента. Это резко снижает накладные расходы при переоткрытии соединений и помогает на нестабильных каналах. Для парка из нескольких десятков машин это сокращает суммарное время холодного старта с минут до секунд.

Когда инфраструктура спрятана за бастионом или VPN — а у нас в аутсорсинге это базовый сценарий, — связка ProxyJump + ключи в ssh-agent работает без доработок: Nerdlog наследует стандартное поведение OpenSSH. Мы не разворачивали отдельный коллектор и не открывали дополнительных портов; периметр остался без изменений, а доступ к логам появился у всей команды через привычные SSH-ключи.

Главная фишка, которая отличает Nerdlog от условного tail -f — встроенная интерактивная гистограмма по времени. Это та самая «полоска с пиками» сверху экрана, которую мы привыкли видеть в Kibana или Graylog, но без необходимости поднимать Elasticsearch. Гистограмма перестраивается на каждый запрос и показывает плотность совпавших записей по временным корзинам.

На практике это меняет процесс расследования инцидента. Раньше при разборе всплеска 5xx мы шли «снизу вверх»: фильтр по статусу, потом по эндпоинту, потом сужение времени методом дихотомии. С Nerdlog порядок обратный: сначала смотрим на форму распределения. Видно ли узкое пиковое окно? Постоянный шум? Регулярные ступеньки каждые 60 секунд (привет, неудачно настроенный health-check)? Один взгляд — и понятно, где копать.

Запросы поддерживают фильтрацию по временному диапазону и шаблонам , так что типичная сессия выглядит как несколько итераций сужения: например level:error AND host:web-prod-* AND time:[-30m,now]. После каждого уточнения гистограмма перерисовывается, и мы видим, как меняется характер распределения. Это особенно полезно для корреляции: если на одном пике в nginx совпадают всплески в application.log и спайки в journalctl -u postgres, гипотеза о связи проявляется без построения отдельных дашбордов.

По нашему опыту, гистограмма даёт ещё один важный эффект — она экономит когнитивные ресурсы. Дежурный инженер в 3 часа ночи не должен мысленно «складывать» столбики из 500 строк лога; ему достаточно увидеть, что аномалия локальна и закончилась 12 минут назад. Это снижает риск ложных эскалаций и спешных откатов релиза.

Не делайте типичной ошибки — не пытайтесь анализировать гистограмму без явного фильтра по уровню или сервису. Мы как-то полчаса искали «всплеск активности», который оказался обычным дебагом тестового скрипта на staging-хосте, попавшем в общую выборку. Узкий фильтр по unit= или severity= экономит часы и нервы.

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

Изначально Nerdlog создавался под конкретную задачу: автор разбирал логи веб-бэкенда, работающего как набор systemd-сервисов на нескольких Linux-инстансах. Этот сценарий близок и нам — на типичном проекте малого или среднего бизнеса у клиента крутится 5–20 виртуалок с микросервисами, и никто не готов платить за полноценный SIEM или managed-Graylog.

Первый сценарий — оперативная отладка инцидента в проде. Поднимать стек ELK ради одного расследования экономически бессмысленно; писать одноразовые ssh host "journalctl -u svc | grep..." по двадцати хостам — занятие на полдня. Nerdlog закрывает середину: подключился к группе хостов, отфильтровал по времени и шаблону , получил агрегированную картину. На наших проектах среднее время выхода на гипотезу о причине инцидента после внедрения этого инструмента сократилось ощутимо — на глаз раза в три.

Второй сценарий — регулярный аудит. Раз в неделю мы прогоняем по парку клиента типовые проверки: ошибки SSH-аутентификации в auth.log, OOM-killer в dmesg, рестарты юнитов через journalctl. Поскольку анализ выполняется на хостах и сеть не нагружается полными логами , такой аудит занимает минуты даже на инфраструктуре с большими файлами в 1ГБ и более.

Третий сценарий — расследование распределённых багов. Когда запрос проходит через шлюз, очередь, два сервиса и базу, локализация ошибки требует одновременного взгляда на все звенья цепочки. Nerdlog позволяет открыть несколько хостов в одной сессии и применить общий временной фильтр; trace-id или request-id выступает шаблоном поиска: например pattern:"req_id=8a3f2e" AND time:[14:32,14:35].

Четвёртый сценарий, нелюбимый, но регулярный — pre-mortem перед миграцией. Перед переключением трафика мы прогоняем хосты на предмет «грязных» логов: предупреждений ядра, deprecation-warnings приложений, проблем с диском. Без агрегатора это десятки SSH-сессий; с Nerdlog — один проход.

Чего мы инструмент не рекомендуем делать — не пытайтесь заменить им долгосрочное хранение. Nerdlog читает то, что лежит на хосте сейчас; если logrotate уничтожил данные двухнедельной давности, никакой TUI их не воскресит. Для compliance-сценариев и длительной ретенции нужен отдельный приёмник логов.

В нише консольных просмотрщиков логов уже давно живут `lnav` и `multitail`, плюс есть тяжеловесы вроде Graylog и Kibana. Каждый инструмент решает свою задачу, и Nerdlog — многооконный TUI-просмотрщик логов — занимает специфическую позицию, которую важно понимать перед выбором.

`lnav` — отличный локальный анализатор. Он умеет автодетектить форматы, индексировать в SQLite, рисовать собственные сводки. Но `lnav` по природе своей однохостовый: запустить его на десяти SSH-сессиях параллельно и сводить результаты в голове — занятие неблагодарное. Nerdlog здесь выигрывает за счёт изначально многохостовой модели: одна сессия, общий фильтр, общая гистограмма по всем нодам.

`multitail` решает задачу одновременного наблюдения за несколькими файлами, в том числе по SSH. Однако он работает в режиме «много отдельных tail-ов на экране» и не делает агрегацию: нет ни общего временного окна, ни гистограммы плотности, ни серверного фильтра. Если задача — наблюдать живой поток, `multitail` достаточен; если нужен анализ постфактум на нескольких машинах, выбор за Nerdlog.

Graylog и Kibana — другая весовая категория. Они дают индекс, долгое хранение, дашборды и алерты. Но и стоимость владения соответствующая: отдельный кластер, индекс на дисках, маршрутизация логов через Filebeat/Fluent Bit, RBAC. На наших SMB-проектах у заказчика обычно нет ни бюджета, ни DevOps-ресурса на поддержку такого стека. Nerdlog в этих условиях — практичный компромисс: визуальная гистограмма «как в Graylog», но без центрального сервера и сопутствующей инфраструктуры.

Когда мы выбираем Nerdlog:

– парк до нескольких десятков хостов, логи лежат локально в `/var/log` или доступны через `journalctl` ; – нужен ad-hoc разбор и визуальная корреляция, а не постоянный сбор и хранение; – инфраструктура за бастионом и SSH — единственный универсально доступный канал; – бюджет и состав команды не позволяют поддерживать тяжёлый стек.

Когда выбираем что-то другое:

– требуется ретенция более срока ротации логов на хосте — нужен отдельный приёмник; – нужны алерты и расследования задним числом по событиям прошлого месяца — это работа SIEM; – разработчику нужна локальная глубокая SQL-аналитика одного файла — `lnav` удобнее.

По нашему опыту, в реальной эксплуатации эти инструменты не конкуренты, а слои: `lnav` на локальной машине разработчика, Nerdlog у дежурного эксплуатации, Graylog/Loki — в долгосрочном хранилище. Каждый закрывает свой класс задач, и попытка решить всё одним инструментом обычно заканчивается раздутой инфраструктурой или, наоборот, медленными расследованиями.

Внедрение нового инструмента в команду эксплуатации — это не «поставили и забыли». На наших проектах мы прошли через типовые грабли и сформулировали несколько правил, которые экономят время и нервы. Nerdlog — TUI-инструмент, и максимум отдачи от него получается, когда конфигурация и привычки команды настроены под него.

Первое — единый файл ~/.ssh/config на всю команду. Если у одного инженера хост называется prod-web1, а у другого web-prod-01, общие плейбуки расследований превращаются в перевод с одного диалекта на другой. Мы держим базовый ssh_config в общем репозитории и подключаем его через директиву Include — например Include ~/work/infra/ssh/clients.conf в файле ~/.ssh/config каждого инженера.

Второе — пресеты запросов. Любой повторяющийся фильтр (ошибки nginx, OOM, рестарты systemd-юнитов) стоит превратить в шорткат и положить в общий справочник команды. Без этого каждый инженер изобретает свой набор regex-выражений, и при передаче дежурства теряется до получаса на «а как ты это искал?».

Третье — клавиатурные привычки. TUI-инструменты раскрывают потенциал, когда руки не уходят на мышь. Базовый минимум, который мы требуем от дежурных: навигация по выдаче без PageUp/Down (использовать движение к следующему/предыдущему совпадению), быстрый сброс фильтра, переключение между хостами в многохостовой сессии, копирование строки лога в системный буфер. Конкретные раскладки лучше уточнять в актуальной документации Nerdlog, поскольку они могут меняться между версиями.

Четвёртое — гигиена сессий. Поскольку Nerdlog держит SSH-соединения открытыми в фоне , мы рекомендуем явно закрывать сессии после расследования. Не делайте как мы однажды — оставленная на ночь сессия с десятком хостов через бастион удерживала лимит одновременных подключений и блокировала плановые задания cron-агента у заказчика. С тех пор у нас в рабочей инструкции есть пункт «закрыл инцидент — закрыл TUI».

Пятое — интеграция с тикетами. Мы договорились с командой, что результаты расследования (запрос, временное окно, ключевые строки) копируются в комментарий к тикету в момент находки, а не «потом по памяти». Это превращает Nerdlog из эфемерного инструмента в часть documented incident response: через полгода новый инженер видит точный запрос, который дал ответ, и повторяет его за минуту.

Шестое — обучение. Запланируйте 30–60 минут на демо для команды и сделайте короткий внутренний чек-лист: подключение к группе, фильтр по уровню, фильтр по шаблону , чтение гистограммы. Этого хватает, чтобы дежурный смог самостоятельно отработать типовой инцидент уже после первой смены. Лицензия BSD-2-Clause позволяет встраивать инструмент во внутренние процессы без юридических рисков, что особенно важно при работе с корпоративными заказчиками.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий DevOps-инженер IT For Prof. Специализируется на построении отказоустойчивых инфраструктур и оптимизации процессов наблюдения за системами. Имеет более 10 лет опыта в администрировании высоконагруженных Linux-кластеров.