Комментарии 42
Понравилось. Поставил дежурным пейджером. Хочется man.
а может ли он работать как less в режиме tail?
в less активируется нажатием F
в less активируется нажатием F
Идея хорошая, мне тоже приходится смотреть логи. Но ваше приложение, при попытке открыть лог размером 7 Гб (это всего за 3 часа работы), начало кушать 100% CPU и отъело кучу памяти, пока не было убито. У less же навигация по такому логу не вызывает затруднений.
Просто при попытке открытия? Посмотрю, несколько странно, но в любом случае, фильтры на 7gb без расхода памяти и нагрузки cpu это мистика, поэтому я пока не брал в расчёт очень большие файлы, обычно всюду логротейт
Но виснуть на старте это баг. Буду смотреть
Нет, не просто. Еще нужно стрелочку вниз или page down нажать.
Сравнил только что 7GB файл less и slit
Оба открывают мгновенно :)
Но у меня с небольшой задержкой после чтения начинается считывания файла до конца (by design)
И оно блокирует. (not by design, издержки борьбы с тем что понаподсказывал race detector)
В любом случае, что происходит — считывается файл до конца.
Для перехода в конец less тоже считывает до конца.
В этом плане — если цель перейти в конец файла, то на 7ГБ файле у меня получилось 2 минуты с less, 25 секунд с slit
То что навигация вышла блокируемая во время разметки файла — это бага. Буду править
Но после загрузки такого большого файла, если начать фильтровать и оставить скажем 100 записей из 7GB файла — там все же будут очень существенные(некомфортные) задержки
Но передвигаться поиском — все же значительно быстрее чем с less
Тут еще свою лепту (в плане потребления памяти) может внести средний размер строки, так как храню оффсет каждой строки. То есть как минимум 2 x int * num_of_lines (map)
Так же, сравнил 64bit и 32bit сборки (на 64 bit системе, другие еще живы?) — 64bit работает намного стабильней с большими файлами.
Я бинарники собирал только 32bit, так как они меньше и предполагал(неверно, почему не совсем понимаю) что будут потреблять меньше памяти.
Я сейчас добавлю на github сборку 64bit, скажите как файлик себя ведет. Я ожидаю задержку секунд 20-60 (в зависимости от cpu, диска) — но потом вполне шустрая навигация
Кстати, на какой это платформе и какая в среднем длинна строки? Либо кол-во строк :)
Оба открывают мгновенно :)
Но у меня с небольшой задержкой после чтения начинается считывания файла до конца (by design)
И оно блокирует. (not by design, издержки борьбы с тем что понаподсказывал race detector)
В любом случае, что происходит — считывается файл до конца.
Для перехода в конец less тоже считывает до конца.
В этом плане — если цель перейти в конец файла, то на 7ГБ файле у меня получилось 2 минуты с less, 25 секунд с slit
То что навигация вышла блокируемая во время разметки файла — это бага. Буду править
Но после загрузки такого большого файла, если начать фильтровать и оставить скажем 100 записей из 7GB файла — там все же будут очень существенные(некомфортные) задержки
Но передвигаться поиском — все же значительно быстрее чем с less
Тут еще свою лепту (в плане потребления памяти) может внести средний размер строки, так как храню оффсет каждой строки. То есть как минимум 2 x int * num_of_lines (map)
Так же, сравнил 64bit и 32bit сборки (на 64 bit системе, другие еще живы?) — 64bit работает намного стабильней с большими файлами.
Я бинарники собирал только 32bit, так как они меньше и предполагал(неверно, почему не совсем понимаю) что будут потреблять меньше памяти.
Я сейчас добавлю на github сборку 64bit, скажите как файлик себя ведет. Я ожидаю задержку секунд 20-60 (в зависимости от cpu, диска) — но потом вполне шустрая навигация
Кстати, на какой это платформе и какая в среднем длинна строки? Либо кол-во строк :)
добавил linux/amd64 и darwin/amd64
А зачем считывать все при перемещении в конец? Если речь про обычный файл, то делаем lseek на -n байт от конца и парсим строки. Если недостаточно — еще откатываемся назад. Это сложнее, конечно, но быстрее работает. Меня в less это убивает — очень долго в конец переходит…
Я это уже изменил в последнем релизе, переход мгновенный, строчки считаются независимо
Меня в less это убивает — очень долго в конец переходит…
Переходит-то он шустро, а потом считает строки. Долго считает, т. к. для того, чтобы посчитать количество строк в файле его надо пройти целиком.
Но ctrl+c позволяет остановить этот процесс.
Скажите пожалуйста, а вы не рассматривали возможность агрегации логов? Думаю Вам и Вашей команде было бы намного удобнее работать в браузере, через какой-нибудь ELK.
Рассматривали, «скачивать» с s3 звучит сложнее чем на самом деле
Обычно это как — есть тест (который может бежать 2-120 часов на 10-очень много машин).
Он генерирует n-ое колво логов. Десятка два по каждой машине, несколько файлов от основного процесса теста. Очень редко нужно смотреть одновременно несколько файлов, переключаться да — для этого есть свой интерфейс навигации логов по ID теста(в консоли), при открытии идет в пейджер
В сам этот интерфейс попадают по клику на линк в Jira. Ну либо в ручную простую команду запустить. В целом у нас все консоль предпочитают :)
Держать огромный кластер elasticsearch это просто расточительно, особенно когда совершенно не нужно искать по всем тестам сразу. А так в s3 и быстро, и дешево и надежно, без дополнительной головной боли поддержки.
Обычно это как — есть тест (который может бежать 2-120 часов на 10-очень много машин).
Он генерирует n-ое колво логов. Десятка два по каждой машине, несколько файлов от основного процесса теста. Очень редко нужно смотреть одновременно несколько файлов, переключаться да — для этого есть свой интерфейс навигации логов по ID теста(в консоли), при открытии идет в пейджер
В сам этот интерфейс попадают по клику на линк в Jira. Ну либо в ручную простую команду запустить. В целом у нас все консоль предпочитают :)
Держать огромный кластер elasticsearch это просто расточительно, особенно когда совершенно не нужно искать по всем тестам сразу. А так в s3 и быстро, и дешево и надежно, без дополнительной головной боли поддержки.
Вчера на Reddit про него прочитал :-)
А если по существу, у Log Navigator есть одно главное преимущество: аггрегация нескольких логов.
Например, с нескольких машин в кластере.
И при этом он ещё умеет тот самый "логротейт" распаковывать автоматически.
Я специально не стал в этом посте комментировать свое видение имени, чтобы не замыливать взгляд хаброжителей и посмотреть на местную реакцию :)
Я не сомневаюсь что весь навороченный функционал который там есть кому то нужен
Но мне как то попроще хотелось, чтоб «как less, только лучше». Плюс именно то, что хотел — там нет (удобного управления фильтрами. Там убрать фильтр это как увидевшему vim первый раз выйти из него )
Несколько файлов однозначно будет, и видимо прийдется в нескольких режимах.
1) как в less — переключение
2) Как в навигаторе — аггрегация.
Я не сомневаюсь что весь навороченный функционал который там есть кому то нужен
Но мне как то попроще хотелось, чтоб «как less, только лучше». Плюс именно то, что хотел — там нет (удобного управления фильтрами. Там убрать фильтр это как увидевшему vim первый раз выйти из него )
Несколько файлов однозначно будет, и видимо прийдется в нескольких режимах.
1) как в less — переключение
2) Как в навигаторе — аггрегация.
Скажите пожалуйста, а Вы не рассматривали возможность агрегации логов? Думаю Вам и Вашей команде было бы намного удобнее работать в браузере, через какой-нибудь ELK.
НЛО прилетело и опубликовало эту надпись здесь
peco?
Правильно ли я понял, что slit загружает весь файл в память? У меня типичный размер логов от сотни мегабайт до нескольких гигабайт. При этом часто пользуюсь less на продакшене и хорошо себя чувствую (как и сервер). Но использую только поиск по regexp. Переход в конец файла — достаточно быстрый (не знаю, где вы вычитали, что для это less загружает весь файл), тормозит только подсчёт количества строк который отменяется по ctrl-с.
Для фильтрации мне всегда было удобнее использовать cat | grep или специализированные средства вроде graylog.
Для фильтрации мне всегда было удобнее использовать cat | grep или специализированные средства вроде graylog.
Про весь файл — нет, не так
Он весь считывается, но не хранится. Хранятся оффсеты по номеру строки.
Но видимо буду менять это поведение и прыгать в конец не зная какая это строка, попутно в фоне считая сколько же их есть на самом деле. Подход который сейчас удобен для файлов этак до 200м, все что выше — уже не комильфо. Как по начальному времени перехода в конец, так и отжираемой памяти
" cat | grep или специализированные средства вроде graylog"
Цель как раз в том что бы сделать это самое специализированное средство, но в консоли. Само собой всегда будут use case-ы когда какое либо решение основанное на БД подходит лучше. БД нужно настроить. она должна хранить в себе терабайты памяти, все это нужно поддерживать, а любой лог который пришел с нового источника сам по себе мгновенно там не появится
cat/grep — это боль, хотелось менять фильтры не отходя от кассы. Боль через которую и сам прошел, вместо прямого открытия из stdina — сохранял в файл, потом греп-лесс, поменять греп-лесс, итд
Но само собой, если вы не ощущаете необходимости, значит оно вам и не надо :)
На самом деле, должен сказать, что я удивлен что это достаточно частое явление — хранение гигабайтных логов. Всегда полагал что общепринятая практика — ограничивать каждый файл этак по 50-100 мб размером
Он весь считывается, но не хранится. Хранятся оффсеты по номеру строки.
Но видимо буду менять это поведение и прыгать в конец не зная какая это строка, попутно в фоне считая сколько же их есть на самом деле. Подход который сейчас удобен для файлов этак до 200м, все что выше — уже не комильфо. Как по начальному времени перехода в конец, так и отжираемой памяти
" cat | grep или специализированные средства вроде graylog"
Цель как раз в том что бы сделать это самое специализированное средство, но в консоли. Само собой всегда будут use case-ы когда какое либо решение основанное на БД подходит лучше. БД нужно настроить. она должна хранить в себе терабайты памяти, все это нужно поддерживать, а любой лог который пришел с нового источника сам по себе мгновенно там не появится
cat/grep — это боль, хотелось менять фильтры не отходя от кассы. Боль через которую и сам прошел, вместо прямого открытия из stdina — сохранял в файл, потом греп-лесс, поменять греп-лесс, итд
Но само собой, если вы не ощущаете необходимости, значит оно вам и не надо :)
На самом деле, должен сказать, что я удивлен что это достаточно частое явление — хранение гигабайтных логов. Всегда полагал что общепринятая практика — ограничивать каждый файл этак по 50-100 мб размером
На самом деле, должен сказать, что я удивлен что это достаточно частое явление — хранение гигабайтных логов. Всегда полагал что общепринятая практика — ограничивать каждый файл этак по 50-100 мб размером
Делать ротацию чаще чем раз в день обычно не очень хочется, если говорить про rsyslog+logrotate, потом искать нужный файл не очень приятно, учитывая, что часть чанков за день уже будет пожата gz. А за день может набежать на порядки больше сотен мегабайт.
Спасибо за разъяснение. Файлы от сотен МБ и несколько ГБ — это лог за один день, при этом ещё не всегда самые подробный. Всё зависит от нагрузки.
Из консоли мне часто не хватает (или я не умею) следующего — искать в диапазоне времени (например от 10 часов до 11) и часто ещё с подзапросом. На больших файлах получается большой оверхед на поиск по всему файлу несколько раз. Наверно тоже однажды соберусь и напишу свой велосипед.
Из консоли мне часто не хватает (или я не умею) следующего — искать в диапазоне времени (например от 10 часов до 11) и часто ещё с подзапросом. На больших файлах получается большой оверхед на поиск по всему файлу несколько раз. Наверно тоже однажды соберусь и напишу свой велосипед.
Уберите своё "небольшое" демо под кат. То, что картинка в спойлере не значит, что она не грузится. А мобильный интернет не очень рад таким картинкам.
Пока что думаю лезть в сеть не раньше, чем раз в час и при запуске, пока не будет произведено какое либо действие показывать сообщение в навигационной панеле. Может будут более элегантные идеи.
Так же рад идеям что стоит улучшить-добавить. Но все не обещаю :)
Лучше не надо. Обычно крайне неприятно, когда какая-либо программа/библиотека пытается лезть в сеть без явного указания/разрешения. В крайнем случае можно сделать флаг/настройку, которая разрешает автоматически проверять наличие обновлений или отдельный флаг, который запускает программу в режиме проверки обновления.
Простите я бы хотел попробовать ваш тул. Но пока мы логим в CloudWatch только и смотрим там ( Хватает, но те кто привыкли к копаться в логах недовольны...)
Не посоветуете что-то не тормозящее что может выкичивать из CloudWatch напрямую или переброс в S3 это стандартных подход к вопросу? Если да то как это делают?
Не посоветуете что-то не тормозящее что может выкичивать из CloudWatch напрямую или переброс в S3 это стандартных подход к вопросу? Если да то как это делают?
А родной aws cli сильно тормозит? Через него можно получить логи в json формате, на ходу можно pipe-ить в читалку json-a и оттуда уже пайпить в slit либо куда душа пожелает
Плюс есть куча всяких сервисов, предоставляющие syslog service, к ним можно направлять логи напрямую если речь идет о ECS и смотреть уже там.
Дороговато они только выходят, если данных много, но например — papertrail
Плюс есть куча всяких сервисов, предоставляющие syslog service, к ним можно направлять логи напрямую если речь идет о ECS и смотреть уже там.
Дороговато они только выходят, если данных много, но например — papertrail
А родной aws cli сильно тормозит? Через него можно получить логи в json формате, на ходу можно pipe-ить в читалку json-a и оттуда уже пайпить в slit либо куда душа пожелает
Месяца 3 назад бегло пробовал. Да тормозило сильно…
Но можно посерьезнее постмотреть и хитро пайпить… это верно.
papertrail
да именно к нему присмариваюсь в часном проекте… Но на фирме там разные сложные констрейны с банковскими клиентами. так просто уйти в следующий клауд сервис да еще с логами не реально пока ;))
Про multitail не слышали?
У меня лажа з запуском. Тоесть с ехе, ни 64, ни 86, не запускается, вылетает командное окно, и все, гейм овер. Не понимаю в чем проблема…
Залил новый релиз
— улучшена работа с большими файлами
— Так же с большими файлами теперь нормально должна работать и x86 и amd64 версия
— Счетчик линий теперь не блокирует, переход в конец мгновенный
Карту оффсетов больше не храню, потребление памяти должно быть минимально
Но в любом случае, если фильтры должны найти 300 строчек из 7ГБ — это не будет быстро… Но в плане того, что поиск блокируем — планирую улучшить, чтоб хоть отменить неудачный фильтр можно было и не ждать
— улучшена работа с большими файлами
— Так же с большими файлами теперь нормально должна работать и x86 и amd64 версия
— Счетчик линий теперь не блокирует, переход в конец мгновенный
Карту оффсетов больше не храню, потребление памяти должно быть минимально
Но в любом случае, если фильтры должны найти 300 строчек из 7ГБ — это не будет быстро… Но в плане того, что поиск блокируем — планирую улучшить, чтоб хоть отменить неудачный фильтр можно было и не ждать
Обновил, 1.1.0 (не фанат версий начинающихся с 0.0000)
— Добавлена поддержка RegEx, переключение между режимами поиска по CTRL + /
— И добавлен флаг запуска --version, для грамотных багрепортов
— Добавлена поддержка RegEx, переключение между режимами поиска по CTRL + /
— И добавлен флаг запуска --version, для грамотных багрепортов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
slit — новое слово в мире PAGERов, либо как тратить меньше времени на просмотр логов