Комментарии 82
Мало того, что нет FAR, так еще и такой подход как поиск в логах, вместо фильтрации и просмотра уже результата поиска.
Тут видимо у меня сложности перевода. Изначально конечно хочется отфильтровать лог, и потом уже с результатми работать. Именно этот сценария я и рассматривал. Добавлю этот момент в статью.
В Notepad++ эта функция называется "Find all in current document".
Тут прикол в том, что сперва notepad++ откроет документ, а принцип работы РЕДАКТОРА с плейн текстом в основном в том, что он все грузит в память, а потом фильтрует.
Если же фильтровать предварительно каким-нить grep, который читает файл построчно, не аллоцирует гигабайты памяти, то в редактор попадет уже маленький кусочек.
Ну то есть это реально принципиальное различие, кто и когда фильтрует данные. Нужно ли их фиьтровать повторно, как часто. От этого и зависит инструмент.
Можно grep blabla | less, можно less и там +F.
FAR именно для поиска я не использовал. Открывает он большие файлы и правда быстро. Он умеет выводить все совпадения для искомой строки? Я файл открыл и он только по порядку результаты показывает.
Если использовать Find file, то он только название файла выдает, где строка найдена (нет кол-ва)
Для подсчёта можно заменить все вхождения, если мне память не изменяет, то он сообщит, сколько он замен сделал. А потом не сохранять.
Неоспоримым достоинством FAR является то, что он может открыть файлы достаточно большие, чтоб Notepad++ сообщил "File too big to open". Попробуйте на 40Гб файле, например.
Плагин для поиска и замены в текстовом редакторе FAR. Заменяет стандартные функции Поиск и замена рядом повышенной способности: * Настраиваемые режимы выделений и выделений * Выделение всех найденных вхождений * Быстрый поиск выявленных слов * Циклический поиск/замена * Выявление всех найденных вденподобных в едином списке * Подсчет количества вхождений
Обсуждение:
http://forum.farmanager.com/viewtopic.php?f=5&t=5098
в фаре это можно вот так:
edit:<<grep "mystring" file.txt
github.com/variar/klogg
я такой пользуюсь, посмотрю на вашу, спасибо
https://github.com/zarunbal/LogExpert/
Добавлю. В klogg есть крутейшая фича, которой я не видел в других программах, разве что в шедеврах от sysinternals.
К примеру можно найти все строки в которых есть "Error", но нет "Super Error"
https://klogg.filimonov.dev/docs/news/boolean_combination/
А вот это грустная новость. Мне нравилось его для заметок использовать. Правдка с тех пор, как иногда работаю за ноутом с 16 Гб оперативы, стараюсь все эти программы вроде Atom, Teams, Outlook и Zoom не открывать =)
Вместо Atomа бы Visual Studio Code протестировать. По ощущениям - куда быстрее Atomа.
Для заметок лучше какой-нибудь Obsidian, QOwnNotes... Atom на фоне тех же VSCode, vim, notepad++ - бессмыссленный и мёртвый проект.
Да и статья какая-то странная изначально. Большой лог-файл? grep, vim, F3 в любимом FM.
Но вообще-то лог обычно далеко не один, плюс хочется выкусить что-то в моменте и тогда чиппендейл grep, lnav, multitail, для куба stern во всю, если не прикручен какой-нибудь ELK/NewRelik... никогда даже не задумывался о таком изврате, как использование Atom для сколь-нибудь продуктивной работы вообще и тем более для разгребания больших логов
А где Sublime text и какой-нибудь vim?
Как это "какой-нибудь vim"? Передовой инструмент для работы с большими объёмами текста! Особенно, если смотреть на потребление памяти и скорость работы при огромном наборе функций.
Еще можно добавить vs code. Говорят он в последних версиях стал очень неплох в плане скорости работы с большими файлами.
Рекомендую попробовать так же Geany и neovim/vim.
Geany является весьма не плохой заменой Notepad++ на Linux, хотя для винды так же еть сборки. Поддерживает плагины. Все написано на C++.
Советую автору изучить тему утилит командной строки из юникс систем, благо на винду они все ставятся сейчас без проблем https://habr.com/ru/post/267697/
Спасибо! Правда, тогда нужно уже будет сравнивать не текстовые редакторы, а разные наборы команд, видимо.
Зачем, если есть Powershell?
затем что powershell есть только на windows. Ну и мне лень приводить примеры где powershell аналоги древних никсовых тулов будут драматически медленнее чем оригиналы.
Здрасьте, приехали.
https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.2
Приведите лучше пример, как вы события в evt/evtx на удалённой машине древними юниксовыми утилитами грепаете.
Я анализировал 2..3 Гб логи (это за 1 час работы). Скрипт на Powershell при поиске regexp-строки в текстовых логах nginx показал худшие результаты, чем скрипт на wshell.vbscript.
LTFViewr - еще один хороший просмотрщик для огромных файлов логов
del
Было бы любопытно дополнить бенчмарки для грепа.
Воспользуйтесь для замеров утилитой time (которую надо отдельно доустановить, не ту, которая built-in в shell).
/usr/bin/time grep "hi" java_error_in_PYCHARM_3828.log
0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 2784maxresident)k 0inputs+0outputs (0major+113minor)pagefaults 0swaps
2784k - потребление памяти, как правильно интерпретировать все эти циферки с временем я ещё сам не разобрался.
Я уже наметил несколько утилит, которые тут упоминали. С грепом тоже попробую. Только момент по поводу результатов вызова grep - результаты поиска всё же далеки от того, что Notepad++ показывает в отфильтрованных (после запуска Find all in open document)
А чего там разбираться?
real - реально потраченное время (почему-то оно у вас откушен этот префикс). Wall-clock, как пишут в гайдах.
user - время в user-space (вам не надо)
sys - время в ядре (вам не надо)
Всякие нюансы типа "user и sys считает процессорное время и в случае многопоточных приложений может превышать real" - в данном случае тоже не важно
В таких обзорах зачастую не хватает ещё одного фактора - способности открыть большой файл (хотя бы 4-8 ГБ) и, как подвариант, открыть файл размером более оперативной памяти.
Вот Notepad++ такое не умеет. Приходится пользоваться FAR-ом, хотя в целом он менее удобен для меня.
Файлы в несколько гигов мне больше всего понравилась открывать www.emeditor.com
Очень быстро с ними работает и хорошо ищет текст в них, включая rx
Не проводил детального сравнения, но использую hippoedit. Он достаточно шустро большие файлы открывает и умеет искать regexp по каталогам.
А кто может подсказать программы действительно для чтения\анализа логов? Очень круто искать по 150 метровому логу строку, но если "вдрук" ты не знаешь что искать, и искать нужно нестандартности, было бы приятнее делать это в программах которые могут на это как-то указать, а не 600к строк глазами бежать в надежде уловить какие-то ужасы.
Может бывают какие-то программы которые сразу подсветят все "эрор" или "акес дынайд", повторяющиеся строки, или которым можно задать направленность лога (почта, веб иис\апач\джинскс,) и они в удобном виде выведут все "шероховатости"?
Понимаю что трусеньёры всё делают грепом, а что бы не ловить разночтений прямо в двоичном коде всё считывают, но вдруг есть те кому приятнее в графическом окружении работать.
В Notepad++ можно сделать свою подсветку (Language -> User defined language).
С другой стороны, когда уже с логом работаешь, очень удобно подсвечивать нужный текст: текст выделяется, пкм->Style token. После этого строка (слово), кот было выделено будет подсвечено во всём документе.
Может бывают какие-то программы которые сразу подсветят все "эрор" или "акес дынайд",
CMTrace.exe из поставки Microsoft SCCM попробуйте.
Вообще говоря автор занался откровенно не тем. Вот смотрите: логи большие, по-этому открывать их именно в редакторах - это использовать редактор не по назначению. От этого и проблемы типа "файл слишком большой" и "долго открывается". Для просмотра надо пользоваться (неожиданно!) просмотрщиком. Он не грузит файл в память и открывает все мгновенно. Однако лог - информация структурированая. И использовать просто просмотрщик - это терять структуру. Просмотр части лога - это занятие от безисходности, когда нормальные инструменты помочь не могут.
Какие нормальные? Это конечно-же индексаторы логов - Splunk, ElasticSearch и что там еще появилось. В Splunk можно писать довольно сложные запросы, которые сделают всю работу за вас - нечего глаза на логах ломать. Это вам не grep! Это нормальный язык работы с именно логами. Если Splunk'у помочь и немного разметить сообщения (я не люблю логи в Json - я все еще иногда их глазами читаю), то он может выделять значения, агрегировать, строить условия. И на худой конец можно посмотреть кусок сырого лога выше/ниже выбранной строки. А еще он агрегирует логи со многих машин и можно следить за распределенными транзакциями.
Читать логи редактором? Фу!
Splunk и ElasticSearch - это, конечно, хорошо, но индексаторы логов помогут только если они установлены на сервере. Бывают ситуациии когда логи приходят в виде файлов, тогда нужны просмотрщики логов, а не индексаторы.
Можно попробовать загнать логи в базу sqlite, и уже там делать извращенные выборки.
Ну так просмотрщики, не редакторы-же. Автор рассматривает редакторы общего назначения, что на мой взляд не верно. Если лог такой маленький что лезет в редактор, так и смотрите его FAR'ом или абсолютно любым другим редактором. А то начинается "долго стартует", "не может загрузить" и т.д. :)
Спасибо, что переживаете, чем я занимаюсь =) Ваш подход конечно на голову серьёзней, но в моей работе есть несколько моментов, когда приходится логи крутить руками. Вот в такие моменты мне интерфейс и удобство работы кажутся важными моментами.
Да, Киабана тоже есть, но не все логи там доступны, к сожалению.
Может бывают какие-то программы которые сразу подсветят все "эрор" или "акес дынайд",
Могу порекомендовать https://github.com/sevdokimov/log-viewer , может фильтровать записи по Severity, кликаете "Error" и видите только записи с severity=error. Так же можно скрыть неинтересные записи, если они зафлудили лог. Выделяете текст на не нужной записи и нажимаете "Скрыть записи с таким текстом".
Я использую glogg. Мне вполне нравится. Жаль не увидел в списке сравнения
+1, glogg легко переваривает 100 гигабайтные логи
Есть живой форк с плюшками github.com/variar/klogg
Софт в тесте, мягко говоря, не самый актуальный. Когда тестировал редакторы на открытие 600 МБ файла, хорошо себя показали Sublime Text и неожиданно VS Code, а Atom завис.
Куда удобнее под Windows запустить WSL и использовать нормальный человеческий терминал.
ну и где FAR?
Когда посмотрел на заголовок, почему-то сразу вспомнился journald. Можно получить интересующий фагмент логов, а потом уже оп нему сделать нужный grep, если нужно. Если нет тонны текстовых файлов, то и поиск становится проще. К тому же и место на диске экономится и подробнее информация о событиях сохраняется.
Изначально я пытался использовать меню “Открыть с помощью” из проводника, так как чаще всего логи открываю именно так.
??? Самое частое это дабл-клик по файлу или перетаскивание в окно. И тут время открытия файла выходит на первое место.
Ну а вообще, зачем открывать лог на овердофига строк, потом его парсить, если можно сразу парсить (да еще и пачку файлов)?
wsl > grep -r "Jul 25 04:" .../log/ > full_log.txt
и вуаля мы имеем файл со всем что происходило в 4 утра 25 июля.
Да, это будет работать если 1 запись - 1 строка. Для всего остального надо добавлять или -А или -B.
Кстати у MS есть классная штука для просмотра логов - CMTrace. Это часть system center 2012 r2 configuration manager toolkit. Это маленький exeшничек, который сильно упрощает просмотр живого потока событий.
Не могу не заметить что есть специализированные программы именно для просмотра логов, например вот: https://github.com/sevdokimov/log-viewer. Она может мгновенно открывать файл любого размера, не тратя много памяти, потому что читает только ту часть лога, которая отображается в данный момент. Определяет формат лога и подсвечивает некоторые поля, чтобы было удобнее читать. Так же позволяет открыть несколько логов в одном view, записи будут смёржены по таймстемпу.
Плюсы Notepad++ :
Может искать по регуляркам и спец. символам (\n \r \t и т.д.)
Может искать по всем открытым файлам
Может подсвечивать и помечать найденное по тексту
Может считать число найденных вхождений (очень удобно для подсчета объектов)
Пользуюсь Notepad++ исключительно из-за его супер-невероятного Find All, как раз для просмотра не очень больших логов (меньше 100Мб). Что-то похожее есть в Visual Studio конечно, но по ресурсам вообще несоизмеримо. Для кодинга, скриптинга может и есть редакторы гораздо интереснее, но не в этом случае.
Listener из Total Commander тоже очень неплохо выполняет открытие и поиск по большим файлам, как и в FAR он не загружает весь файл в память.
Из быстрых текстовых редакторов под Windows раньше пользовался Bred 3.0.3 который похоже застрял в развитии, и теперь BowPad. Быстро запускается, разумно большие файлы открывает без проблем, есть подсветка вхождений строки в тексте даже без использования поля поиска.
Под MacOSX пользовался TextMate, пока не открыл для себя BBEdit. Не то чтобы инструменты специально для логов, но для быстрого и частого инспектирования текстовых и не очень файлов размера до нескольких гигабайт норм.
после Sublime, Notepad++ и т.д. использую CudaText, nvim (spacevim), VSCode.
PS
CudaText is a cross-platform text editor, written in Object Pascal. It is open source project and can be used free of charge, even for business. It starts quite fast: ~0.3 sec with ~30 plugins, on Linux on CPU Intel Core i3 3GHz. It is extensible by Python add-ons: plugins, linters, code tree parsers, external tools. Syntax parser is feature-rich, from EControl engine.
PPS CudaText VS other editors тут про производительность.
Более сложная задача, чем просмотр логов - просмотр XML. Тут https://xmlexplorer.github.io в помощь.
Выбираем лучший текстовый редактор для поиска логов