Просмотр огромных логов

sublime

Когда-то именно для этого придумали perl…

Не, без богомерзкой проприетарщины плиз. Мне это потом (после пандемии, даже если карантин снимут раньше) ещё неокрепшим умам надо будет показать. glogg всем хорош, только с поиском и длинными строками не очень удобен.

Нет, perl хорош, но не для этого. Мне глазками на колонку чисел быстрее взглянуть, чем perl-ом тыкаться на угад.

Ну кто виноват, что нормального foss текстового редактора нет. Лучше sublime для больших файлов пока не придумали.

В консольку всё не помещается

Это как?

Это так. 80k строк на тестовом множестве и 800k строк на реальных данных. График то я построил, так что примерно знаю что там ждать, теперь хочется посмотреть на каких данных происходит принципиальный перелом ситуации, возможно глазками точную границу увидеть получится точнее, чем производной или любым другим автоматическим алгоритмом (хотя да, они все +- в одно место тычат с погрешностью в сотку).

Чем тогда обычный less не устроил?

1. Поднимаешь ELK
2. Загоняешь лог в ElasticSearch
3. Открываешь Kibana
4. ???
5. PROFIT

Интересная штука, спасибо.

VS Codium. Всю «пропиетарщину» вместе с телеметрией выпилили, как говорят, КЕМ.

Perl это, вообще-то, Practical Extraction and Report Language. Когда хотя бы представление имеешь что именно искать в лога, то самое оно.

Ну а так-то да… Как говорится, барин знает что с кобылой делать, наше дело хвост держать. =)))

обычный less не устроил

Присоединяюсь к вопросу. Там и поиск есть по регуляркам, если нужно.

Особенно рекомендую вгрузить лог в ML. Помогает по быстренькому, без возни посмотреть.

vim yourbigfile

1230gg

/searchstring<CR>nnn<S-n><S-n><S-n>

Я 50 миллионов записей смотрю через grep | less, к чему усложнять?

Плюсую кибану

Иногда тормозит, переход на середину медленный, поэтому я использую most.

Скроллить надо. Наверное к этому. Если искать что знаешь, то лучше грепа нет ничего.

вим уже попробовал?

Конкретно на этом файле нет, но на ещё более большом ложилось всё, кроме glogg-а.

Плюсую, сам хотел это упомянуть

А в каком редакторе ты прогаешь?

И наслаждаешься тормозами.

Я год уламывал админов на ELK, но когда они всё сделали я дико пожалел. Когда не умеют готовить, получается полнейшая шняга.

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

grep+less как-то поюзабельшей, чем поиск в самом less.

800k строк

А терабайт сколько?

А терабайт - это 1000 гигабайт. Так то

От 80к строк? Там тормоза будут если эластик на калькуляторе развернуть, разве что. И то не факт.

Жалкие 20 мегабайт текста. Там всего слово и некоторая цифра в строке, всё в utf8. а вот gedit-у и leafpad-у плохо от такой мелочи. Но вообще приходится иногда смотреть логи по 2-3 гигабайта с поиском по ним нужного района и оттуда плясать.

Хз со скольки оно начинает тормозить, на моём основном проекте 13-15 миллионов строк в сутки. По соседству какой-то вообще с соотнями миллионов. Я просто предупреждаю, что ELK — днище.

VSCode на раз прохавает.

Ну есть же GNU Emacs!!!!

Скроллить надо

Поэтому и less

Инфраструктура должна соответствовать объемам, 13-15 в сутки это ещё мало.

vim падал..? Я файл на 50гб листал в нем (лог лок-фри очереди)

Тупил. Может плагины мешались, у меня то vim намазан немного.

Перловку уже рекомендовали. Плюсую.

Но можно же логи в СУБД залить и дальше sql-запросами. У нас так все логи централизованно и хранятся. Дико удобно.

Тебе глаза-то не жалко? Нельзя ли выбрать, скажем, каждую 1000-ю запись?

Логи в реляционке? А вы знаете толк.

Не, без богомерзкой проприетарщины плиз.

Ну этим Ed или как его там пользуйся. Который для телетайпов в одну сторону

Логи в реляционке? А вы знаете толк.

Ну а зачем тогда в syslog-ng по дефолту есть схемы для разных СУБД? Например, вот – https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.17/administration-guide/43

Да, если мне флуктуации трафика посмотреть надо на сети из нескольких тысяч машин, то такой подход проще, чем парсить тем же перлом хренову гору отдельных файлов и изображать поиск иголки в итоге сена. И тут не важно от чего логи – от цисок, от серверов, от отдельных хостов… Пофиг.

Ну и да. У нас даже на виндовых машинах, если они где и остались, используется конвертер Events->syslog. Ибо это просто удобно.

А так-то… Барин, кобыла, еённый хвост (см. выше). =)))

Каждую тысячную нельзя. Пока справился при помощи графика и приблизительного номера интересующих строк.

Советую посмотреть в сторону ripgrep там есть и multiline и регулярки перловые и тд и тп и он быстрее всех

1024, попрошу!

https://www.sql.ru/forum/1246020-1/eshhyo-odin-redaktor Ещё один редактор

и

https://www.google.ru/search?newwindow=1&source=hp&ei=v9q8XsXoKoibrgTFzIvwAg&q=sql.ru+%D0%9F%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80+%D0%BE%D0%B3%D1%80%D0%BE%D0%BC%D0%BD%D1%8B%D1%85+%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2&oq=sql.ru+%D0%9F%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80+%D0%BE%D0%B3%D1%80%D0%BE%D0%BC%D0%BD%D1%8B%D1%85+%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2&gs_lcp=CgZwc3ktYWIQAzoCCAA6BQgAEIMBOgQIABADOgQIABAKOgQIABAeUNkGWNweYPUjaABwAHgAgAFuiAH5BJIBAzcuMZgBAKABAaABAqoBB2d3cy13aXo&sclient=psy-ab&ved=0ahUKEwiFxN6G07LpAhWIjYsKHUXmAi4Q4dUDCAc&uact=5

Владимир

Конкретно на этом файле нет, но на ещё более большом ложилось всё, кроме glogg-а.

я вимом 10Gb логи открывал

1024 это гиби, меби, киби и т.д.

а если зайти с другой стороны:

почему это софт не ротирует логи? так надо софт править!

Потому что он в состоянии разработки (уже готов)! Я его пишу, а этот лог генерировался только временно, для отладки того, что происходит в цикле (отладчиком уж очень неудобно информацию было собирать, да и в gui тыкаться миллион раз уж увольте).