Когда инцидент бьёт по двадцати виртуалкам одновременно, классическая связка scp + grep забивает канал и блокирует рабочую станцию на минуты. Поднимать ради разового расследования кластер Elasticsearch экономически бессмысленно. На проектах IT For Prof мы перешли на Nerdlog — терминальный многооконный просмотрщик логов, который агрегирует данные с десятков хостов через обычный SSH и строит интерактивную гистограмму прямо в консоли.
Почему обычный grep по SSH перестаёт работать
Типичная инфраструктура клиента малого и среднего бизнеса — это 5–20 виртуальных машин с микросервисами на systemd. Веб-интерфейсы вроде Graylog или Kibana требуют отдельной обвязки: сборщик, индекс, фронтенд, шина сообщений. Поддерживать такой стек ради разбора инцидентов раз в две недели нерационально.
Файлы /var/log/syslog на нагруженных нодах разрастаются до 1 ГБ и больше. Команда вида ssh host "journalctl -u svc | grep..." по двадцати хостам превращается в работу на полдня, а полный scp логов на рабочую станцию забивает канал и блокирует ноутбук дежурного.
Дополнительная боль — права доступа. Файлы в /var/log читаются группой adm или systemd-journal, и любой временный sudo «для отладки» рискует остаться в sudoers.d на месяцы и всплыть в отчёте аудита.
Архитектура без центрального сервера
Nerdlog построен по remote-first модели. Программа открывает SSH-сессию к каждому хосту и держит её в фоне. Никакого брокера, индекса или агента на стороне сервера нет — хватает стандартного sshd и базовых утилит. Стоимость владения нулевая: нечего обновлять, нечего мониторить, нечего ломать.
Фильтрация и подсчёт гистограммы выполняются прямо на удалённой ноде. По сети передаются только агрегированные результаты и совпавшие строки, а не сырой лог целиком. Для канала через бастион или VPN это разница между минутами ожидания и мгновенным откликом.
Лицензия BSD-2-Clause снимает юридические вопросы при встраивании во внутренние процессы корпоративного заказчика. Репозиторий собрал около 1.5k звёзд и 40 форков — для нишевого админ-инструмента показатель здоровый.
Как мы подключаем парк хостов
Запуск на новой инфраструктуре сводится к двум шагам. Первый — рабочий ~/.ssh/config с алиасами по группам: web-prod-01, db-stage-02 и так далее. Второй — указание целей при запуске Nerdlog одной строкой.
В блоке Host прописываем User, IdentityFile, ProxyJump до бастиона и ServerAliveInterval 30. Для парка из нескольких десятков машин обязательно включаем ControlMaster auto — это сокращает время холодного старта с минут до секунд за счёт мультиплексирования соединений.
Права раздаём через группы, а не через sudo. Команда usermod -aG systemd-journal,adm добавляет инженера в нужные группы и открывает доступ к системному журналу и классическим файлам /var/log без эскалации привилегий.
Гистограмма как первый шаг расследования
Главное отличие от tail -f — встроенная интерактивная шкала времени над выдачей. Та же «полоска с пиками», что в Kibana, только без Elasticsearch под капотом. Гистограмма перестраивается на каждый запрос и показывает плотность совпадений по временным корзинам.
Порядок расследования меняется. Раньше при всплеске 5xx мы шли снизу вверх: фильтр по статусу, потом по эндпоинту, потом сужение времени дихотомией. С Nerdlog сначала смотрим на форму распределения. Узкий пик? Постоянный шум? Ступеньки каждые 60 секунд — значит, кривой health-check. Один взгляд экономит дежурному в три часа ночи десятки минут.
Типовой запрос выглядит как level:error AND host:web-prod-* AND time:[-30m,now]. После каждого уточнения гистограмма перерисовывается. Когда пик в nginx совпадает по времени со спайком в journalctl -u postgres, гипотеза о связи проявляется без построения отдельных дашбордов.
Где Nerdlog выигрывает, а где проигрывает
В нише консольных просмотрщиков уже живут lnav и multitail. Каждый закрывает свой класс задач:
- lnav — локальный анализатор одного файла с автодетектом форматов и SQLite-индексом. Однохостовая модель: десять SSH-сессий параллельно сводить в голове неудобно.
- multitail — наблюдение за живым потоком нескольких файлов, в том числе по SSH. Нет общего временного окна, нет гистограммы плотности, нет серверного фильтра.
- Graylog и Kibana — индекс, ретенция, дашборды, алерты. Стоимость владения — отдельный кластер и DevOps-ресурс, которого у SMB-клиента обычно нет.
Nerdlog берём, когда парк до нескольких десятков хостов, нужен ad-hoc разбор и визуальная корреляция, а инфраструктура спрятана за бастионом. Заменять им долгосрочное хранение бессмысленно: если logrotate уничтожил данные двухнедельной давности, никакой TUI их не воскресит. Для compliance и ретенции нужен отдельный приёмник логов.
Что меняется в работе дежурной смены
После внедрения на проектах IT For Prof мы зафиксировали несколько устойчивых эффектов:
- среднее время выхода на гипотезу о причине инцидента сократилось примерно втрое;
- еженедельный аудит парка — ошибки SSH-аутентификации, OOM-killer, рестарты юнитов — занимает минуты даже на инфраструктуре с файлами по 1 ГБ;
- периметр клиента не меняется: не открываем новых портов, не разворачиваем коллектор, не ставим агенты;
- pre-mortem перед миграцией прогоняется одним проходом, а не десятками SSH-сессий вручную.
Чтобы инструмент действительно прижился, договоритесь о едином ssh_config в общем репозитории команды и о пресетах запросов под типовые инциденты. Без этого каждый инженер изобретает свой набор regex, и при передаче дежурства теряется до получаса на «а как ты это искал?». Результаты расследования — запрос, временное окно, ключевые строки — копируйте в тикет в момент находки, а не по памяти. Через полгода новый инженер повторит тот же запрос за минуту, и расследование станет частью документированного incident response, а не знанием одного человека в голове.