Комментарии 22
такие утилиты как awk
это не утилита, а язык программирования
а чем лучше елки?
Тем, что ёлку надо: 1) иметь, 2) получить разрешение на залив в неё твоих логов с дев или тестового стенда, точнее, два разрешения - от группы ёлки и от админов сети для физического доступа, 3) настроить. 4) часто логи в центральном хранилище любого типа запаздывают на минуты, а надо здесь и сейчас, немедленно. Но без перевода в БД, конечно, если в идеале.
Тем, что решили вы переключить сервис в дебаг, а дебага там столько и он настолько ситуативный, что жалко этим нагружать ELK. Другой сценарий - контейнер, бегущий локально на машине разработчика. Для него поднимать елк или аналог - бессмысленно, как и подключать его локальный контур к центральному елк, а пару - тройку гигабайт дебаг лога проанализировать надо. Либо, как третий вариант - это может быть вообще пет проект.
Согласен, для своей ниши интересный инструмент, как и goaccess.
(хотя и немного прошлый век - ну, я и сам такой)
Я пытался использовать goaccess для казалось бы банальной задачи — анализ логов nginx на почти ничем не занятой машине (логов кот наплакал). Честно говоря, гораздо практичней оказались grep, awk и less. goaccess по факту даёт только очень поверхностную картинку происходящего. Как только надо изучить частности — он всё. Но это мой опыт. Было бы интересно послушать как применить goaccess с реальной пользой. Я тут имею в виду, например, хотя бы отчёты о том, сколько за последнее время было 5XX кодов, на какие URL и от кого были эти запросы.
За наводку на goaccess - спасибо, изучу. Я вообще очень люблю tui ещё со времён расцвета fido и bbs. :)
lnav переводит весь лог в SQLite базу, которую хранит в оперативной памяти
Хм, а зачем хранить SQLite в памяти? Он с диска работает не намного медленнее. Кстати, с чего Вы взяли, что в памяти? В документации не нашел такого, а наоборот, написано, что используется vtable.
Я просто наблюдал в момент подгрузки логов за тем, как уменьшалась оперативная память и размеры сравнимы. Других объяснений у меня нет. Насчёт "с диска не намного медленнее" - не проверял, утверждать не буду, но есть сомнения, что выборка из sqlite базы с таблицей в 20гб, скажем, пусть даже с ssd или sas диска займёт сравнимое время, что и из оперативной памяти.
Как насчёт (1) кеширования файла в ОЗУ силами ОС (2) mmap?
У меня по работе встречались машинки, у которых за день логов набиралось под 120-140 GB (например, Fortigate NGFW, на котором есть куча фв политик и несколько сервисов поднято), если всё это попытаться подгрузить в ОЗУ... А ведь иногда ещё надо и логи за последние 7-10 дней просмотреть. Надеюсь, на самом там не ОЗУ хранит данные.
Удобная навигация и навигация в стиле Vim - это абсолютно разные штуки. Но ради хорошего инструмента можно и потерпеть.
Я больше 15 лет пользуюсь vim'ом и это накладывает свой отпечаток. Можно считать, что это что-то вроде профдеформации и это удобно для меня и других пользователей вим. Впрочем, навигация с помощью обычных курсорных клавиш и pgup/pgdwn/home/end тоже работает, так что поддержка вим хоткеев скорее опция или бонус.
lnav очень узколоб и ограничен, когда видит JSON-логи (где каждая запись/строка — это JSON-объект). Для каждого, даже очень популярного решения, нужно писать свой формат. А что, если схема у JSON поменяется? Снова формат писать? Самостоятельно он парсить JSON почему-то не умеет и никаких попыток не предпринимает вообще. Мой issue это подтверждает.
Поэтому jl всему голова.
умеет делать prettify для xml и json
умеет форматировать xml и json?
lnav — супернедооценённый инструмент для работы с логами