TurboJedi: окна Turbo Vision для journald вместо journalctl

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Разбор инцидентов на Linux-сервере перестаёт быть цепочкой одиночных команд: несколько окон с независимыми фильтрами и синхронизация по времени дают корреляцию логов без tmux и без нового хранилища.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Одна команда за раз — вот и вся проблема

journald индексирует поля, фильтрует по юниту, процессу, пользователю и загрузке, ищет по времени, отдаёт записи по курсору. Смотреть на всё это приходится через journalctl: один запрос — один экран. Поменять фильтр значит выйти из пейджера и набрать команду заново, потеряв место, где вы были.

Автор под ником performer27 выложил на GitHub проект TurboJedi — просмотрщик системного журнала с оконным интерфейсом. Внутри — порт Turbo Vision magiblot/tvision, той самой библиотеки, что вышла в 1990 году вместе с Turbo Pascal 6.0. Тридцать шесть лет спустя оконная среда для текстового экрана закрывает ровно ту дырку, которую оставил journalctl.

Начиналось как обработчик логов для собственных демонов на C: вместо потока строк в консоли — экран с окнами внутри процесса. Довольно быстро выяснилось, что окон несколько и они удобны, а демонов, которые пишут в journald, на сервере куда больше. Так появилась отдельная программа, которая про ReportTools ничего не знает и просто разговаривает с журналом.

Что внутри

Главное решение: окно не фильтрует общий поток, а само открывает журнал через sd_journal_open и задаёт матчи. Окно с ошибками nginx читает только ошибки nginx, сколько бы ни писали остальные.

Семантика journald такая: значения одного поля складываются через OR, разных полей — через AND. Диалог источника собирает фильтр по этой логике: юнит и пользователь, а внутри уровней — предупреждения или ошибки. Уровней восемь, PRIORITY от 0 до 7. Если не выбрано ни одного, в матчи уходит PRIORITY=-, который не может удовлетворить ни одна запись.

Текст сообщения в матч не отправить: libsystemd сравнивает поле целиком. Поэтому поиск по строке (обычная или PCRE2-regex, на показ или на исключение) проверяется уже на стороне программы, как это делает journalctl --grep. Порядок простой: запись сначала проходит матчи, потом проверяется по тексту.

Хвост живёт на sd_journal_get_fd и sd_journal_process в цикле простоя. Новые записи читаются пачками по 5000, чтобы длинный диапазон не подвешивал экран. Прокрутка выше первой строки подтягивает историю отдельным экземпляром журнала: он встаёт по курсору первой строки и идёт назад, а основной в это время продолжает следить за хвостом. Строки нумеруются абсолютно, поэтому выделение, поиск и возврат не рвутся ни от подгрузки, ни от обрезки буфера.

Диалог источника по F7 подтягивает уникальные значения полей через sd_journal_query_unique: юниты, загрузки с временем первой записи, пользователи с именем и UID, PID с галкой «Running only». Галка опирается на /proc: процесс считается живым, если его PID там есть и стартовал не позже последней записи. Время ставится через Ctrl-T в том же виде, что и в --since, с календарём. Раскладки с фильтрами, колонками и подсветкой сохраняются в INI, а копирование строк уходит в буфер рабочей машины по OSC 52 прямо через SSH.

Всё это — около 6000 строк C++ в 22 модулях. Внешних зависимостей, кроме tvision, одна: ncurses. UTF-8, 24-битный цвет и мышь в современных терминалах приносит сам порт.

Чем отличается от того, как вы разбираете инцидент сейчас

• Один запрос — один вид. Смена фильтра в journalctl стоит вам точки, на которой вы стояли.
• Корреляция держится на tmux. Либо единый поток с -u nginx -u postgresql и перемешанные строки, либо несколько терминалов с независимой прокруткой.
• Слежение и листание конфликтуют. В -f есть хвост, но нет навигации по истории; в пейджере наоборот, и слежение включается вручную.
• Значения фильтров надо знать заранее — точное имя юнита, PID упавшего процесса, boot ID позавчерашней загрузки.

Кому нужно и как применить

Сценарий один. На сервере что-то падает, вы заходите по SSH и открываете три-четыре окна: nginx, база, systemd, всё остальное. Окна живут одновременно, каждое со своим фильтром и своей прокруткой.

Дальше работает то, ради чего всё затевалось — синхронизация по времени.

Нашёл ошибку в одном окне — нажимаешь Alt-G, и все остальные окна переходят к ближайшей по времени строке, сохраняя свои фильтры.

Alt-← возвращает окно назад. Это и есть замена четырём терминалам: вам не надо пересказывать себе время ошибки, вы видите, что делали соседние сервисы в ту же секунду.

Отдельная выгода для тех, кто заходит в журнал раз в месяц: имена полей помнить не нужно. F7 показывает список того, что реально лежит в журнале, со строкой фильтра по списку. А галка «Running only» отсекает мёртвые PID, чтобы вы не искали по номеру, который уже достался другому процессу.

Где подвох

Поиск по тексту идёт по уже прочитанным записям. На узком фильтре это незаметно, на суточном диапазоне с широким матчем машина будет честно перечитывать всё, что под условие попало. Индекс journald здесь не помогает — такова цена той же семантики, что у --grep.

Каждое окно — отдельный клиент журнала. Пять окон означают пять курсоров и пять наборов матчей; на слабой машине с большим журналом это чувствуется.

«Running only» опирается на /proc. В контейнерах и неймспейсах PID с точки зрения хоста и с точки зрения гостя — разные числа, и галка может показать не то, чего вы ждёте.

TurboJedi смотрит локальный journald. Он не собирает логи с других машин, не хранит их и не притворяется SIEM. Если у вас десять серверов и нужен один общий экран — это другая задача и другой софт.

И трезвая часть: проект молодой, автор один, аудитория на момент публикации — 622 читателя. Это не повод не пробовать. Это повод не делать его единственным способом смотреть логи на продакшене в первый же день.

Брать или подождать: вердикт за 30 секунд

Брать — если вы админ или дежурный, разбираете инциденты на одном-двух Linux-серверах по SSH и уже устали держать tmux с четырьмя панелями.

Пробовать на тестовом — если журнал большой и вы активно ищете по тексту: сначала замерьте, сколько окно думает на суточном диапазоне.

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

FAQ

Это замена journalctl?

Нет. Тот же journald, тот же индекс, тот же формат полей. Меняется форма работы: несколько запросов открыты одновременно, фильтры правятся в диалогах, а не перенабором команды.

Заработает по SSH на обычном терминале?

Да, интерфейс текстовый. Копирование строк идёт через OSC 52, то есть в буфер вашей рабочей машины, а не сервера. Ставить что-то дополнительно на клиент не нужно.

Почему Turbo Vision, а не веб и не модный TUI-фреймворк?

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

Сколько это стоит и где лежит?

Open source, код на GitHub: github.com/cyanide-burnout/TurboJedi.

Что сделать на этой неделе

Поставьте TurboJedi на тестовый сервер, где журнал не критичен, и разберите с его помощью один старый инцидент, который вы уже закрыли. Откройте три окна, прожмите Alt-G по времени ошибки и посмотрите, нашлось ли что-то, чего вы не увидели через journalctl. Если да — переносите на дежурные машины. Если нет — вы потратили полчаса и точно знаете, за что не платите вниманием.