Так уж получилось, что мне регулярно приходится просматривать множество логов.
Одно меня радует, не так сильно, как люди, работающие со мной, для которых порой это основная работа.
Эти логи не находятся ни в одной централизованной системе, а хранятся в s3 и мы просматриваем их, скачивая с перенаправлением вывода в less. У всех меньше установлено, все привыкли с ним работать, знают про базовые вещи вроде поиска вперед и назад, фильтрации по &, перехода в конец (G) файла, перехода в начало (g) и так далее.
А еще все уже смирились с тем, что в любой момент при добавлении фильтра less может зависать на неопределенный срок, отображать строку каждые 5 секунд и так далее.
В конечном счете, особенно при чтении журналов со стандартного ввода, нужно быть осторожным.
Фильтр может работать, а может и не работать.
Собственно, в тот момент, когда мне тоже выпала судьба просмотреть за несколько дней пару сотен лог-файлов, стало очевидно, что мир нужно менять к лучшему.
Ниже под катом демо (гифка 2,2мб) и немного истории.
Демо (2,2 Мб): 
Было 3 основные жалобы на меньшее:
1) Фильтр может выйти из строя в любой момент;
2) Фильтр в принципе работает довольно медленно, особенно со стандартным вводом, особенно с логами > 5МБ;
3) Невозможно добавить несколько фильтров.
Покопавшись в Интернете, я понял, что ничего нет. Есть один «навигатор по журналу» — но он не интуитивно понятен, много ненужного, а то, что нужно, очень неудобно.
Начав писать свой ПЕЙДЖЕР на Go, я первым делом начал сравнивать разные подходы.
Первый появился совершенно неожиданно, идея о том, что у всех на машинах много памяти, можно просто загрузить весь файл в память, подготовить его, а потом быстро все там искать.
Все оказалось не так тривиально, файл размером 50 МБ с его построчным разделением, распознаванием управляющих символов для отделения текста от цвета, выделением памяти под результирующие данные (отдельная информация о цветах, отдельный текст для быстрого поиск по тексту) - заняло больше времени, чем если бы просто прочитать все, разбить, поискать, но не выделять память для хранения.
При потоковой обработке данные перемещаются в стеке от функции к функции, что происходит гораздо быстрее.
В конечном итоге я пришел к выводу, что память выделяется только для хранения смещения каждой строки, а отделение текста от цветов и передача в буфер готовых подходящих строк происходит в потоковом режиме.
В буфере всегда хранится по 2-3 окна в каждом направлении для быстрой навигации вперед-назад без дополнительных чтений.
Если возможно, поиск осуществляется в этом буфере; если этого недостаточно, то файл читается еще раз с нужной позиции.
Конечно, преимущество такого подхода в том, что вам не придется вначале ждать, пока загрузится весь файл.
В принципе, в будущем думаю добавить флаг, который позволит в любом случае держать в памяти весь файл, но с потоковой обработкой.
Но я не уверен, что это необходимо :) В целом поиск и фильтрация, в том числе многоуровневая, оказались намного быстрее, чем в менее, и намного стабильнее.
Примерно в 4 раза простой поиск, разница в фильтрации доходит до бесконечности, так как меньше может просто зависнуть.
А даже если и нет, то уже на порядок
Говоря о убийственных функциях
Многоуровневые фильтры- & — пересечение с предыдущим образцом.
То есть то же самое, что и в less, но с учетом всех предыдущих фильтров.
- + Добавить совпадения в подборку
- — Исключить совпадения из выборки
Также для более детального изучения активно поможет следующее:
- У(шифт+у) - удалить последний фильтр
- = - удалить все фильтры
- C(shift+c, Контекст) — временно отключить все фильтры, позволяет видеть все, что было после этой строки, эта строка считается первой на экране
Позволяет указать количество символов с начала строки, которое будет отображаться при сдвиге экрана по горизонтали.
Таким образом, вы можете записывать время, фиксировать хэш и т. д. Вы можете либо ввести число, либо использовать стрелки вверх и вниз, чтобы настроить количество фиксированных символов.
- В основном горячие клавиши следуют меньше — Фильтры поиска сохраняют истории между сеансами.
Поиска по ctrl+r пока нет, это в планах.
— Файлы (на данный момент) можно просматривать только по одному или со стандартного ввода.
- Если щель запущен с перенаправлением вывода - тогда входящий поток будет просто перенаправлен, без какой-либо логики, аналогично cat и меньше — Активно тестировался на linux, osx, немного на windows, на freebsd вообще не тестировался.
Собрал для него, но проверить не на чем.
По идее должно работать Проект находится на очень ранней стадии, лично я уже заменил ПЕЙДЖЕР в системе.
Но, возможно, кто-то упускает что-то, что кажется очевидным.
Не молчи :) Есть еще ряд планов: — Добавлено переключение чувствительности к регистру.
В настоящее время только поиск с учетом регистра; — Добавлено переключение типа поиска (regex/plain/extended glob); — Добавить меню фильтров для просмотра того, что доступно на данный момент, с выборочным удалением и отключением; — Добавлена поддержка нескольких файлов.
Для начала переключаемся между ними как в less; — CTRL+R поиск по истории; — Удаление подстроки из каждой строки для удаления шума, без удаления самих строк; — Прямой вывод на терминал, если текст меньше экрана (аналог -F флага в less-e), возможно, с поддержкой -F из переменной окружения LESS. О чем идет речь: — Читать весь стандартный ввод или нет? Лично мне очень помогает то, что это всё читается до того, как я решу, что оно мне нужно.
Но обычно ПЕЙДЖЕРЫ этого не делают. — простые возможности работы со временем, то есть распознавание временных меток и возможность фильтрации по ним.
Не знаю, нужно ли это кому-нибудь в логах Что должно остаться, несмотря на добавление функций:
— Берите не более одной строки с терминала
— Открытие файла не должно занимать больше времени, чем в случае с меньшим
И немного о Го
Это мой второй Go-проект, первый был здесь .Отсутствие разнообразного функционала, например пресловутых дженериков, а иногда и необходимость реализации, казалось бы, банальных вещей (атомарных логических значений) иногда расстраивают. Я гораздо больше пишу на Python, но каждый раз, когда я касаюсь go, мне действительно нравятся ограничения, которые на меня наложили :) Но что меня больше всего радует, так это экосистема.
По какой-то причине люди часто забывают упомянуть об этом должным образом при сравнении или критике языка.
Возможно, язык тормозит письмо, пока вы не нажмете кнопку «Выполнить» в первый раз.
После этого Го быстро выходит вперед. 1) иди собирай/запускай/устанавливай --race Приложение перейдет в режим поиска состояния гонки, получая доступ к данным из разных потоков без синхронизации.
На самом деле это очень помогает при обнаружении ошибок, которые довольно сложно обнаружить.
И иногда понимаешь, что не стоило идти по простому пути и передавать указатель, а не добавлять дополнительный уровень связи между частями приложения через потоки.
2) сеть/http/пппроф - Это замечательно.
Простой импорт, регистрация локального порта, а в случае возникновения тупика можно зайти через браузер на выбранный порт и посмотреть всю информацию о горутинах, которые в данный момент запущены 3) Кросс-компиляция .
Конечно, об этом сказано больше, но это не перестает радовать.
Что не нужно танцевать с бубном, устанавливать дополнительные зависимости - просто работает 4) Гогланг , спасибо Jetbrains за то, что собрали все воедино, опять же не надо танцевать с бубном, и как и в случае с Pycharm, я продолжаю работать в аналогичной среде, с режимом vim, автоимпортом, auto go get, объявлением методов и так далее.
Прежде чем снова выбрать язык, я сравнил, как обстоят дела с некоторыми другими развивающимися языками, и стало очевидно, что им еще есть куда расти.
И о главном, где это взять: Если у вас уже настроена среда Go, лучше всего просто собрать:
Если вы предпочитаете готовые бинарники, то с страницы релиза .go get github.com/tigrawap/slit
И вопрос к студии, хотелось бы как-то оповестить пользователей, что вышла более новая версия.
Неприятно, если делаю релиз, вдруг замечаю ошибку, через 5 минут выпускаю новый релиз, а он уже скачан.
Какие есть варианты ненавязчивого, но понятного уведомления? Пока думаю выходить в сеть не раньше, чем раз в час и при запуске, пока не будет выполнено какое-либо действие, показывать сообщение в навигационной панели.
Возможно, будут и более элегантные идеи.
Я также рад идеям о том, что следует улучшить или добавить.
Но я не могу обещать всего :) Теги: #logs #Go #terminal #console #less #slit #open source #debugging #Go
-
Широкая Утилизация Компьютеров
19 Oct, 24 -
Обзор Htc Sensation
19 Oct, 24 -
Исправление И Создание Пиджина Дома
19 Oct, 24 -
Uberx Запрещен В Южной Корее
19 Oct, 24 -
Выпуск Pypy 1.3
19 Oct, 24
