LINUX.ORG.RU

Нужно запилить ztail

 


0

2

Я видел множество раз запросы вида «мне нужна идея что написать». Вот вот - нужен ztail. Который tail, но чтобы работало со сжатыми файлами. Да, нужно. У нас пачка nginx пишут сжатые логи, которые мне хотелось бы смотреть В РЕАЛЬНОМ ВРЕМЕНИ.

Спасибо.

★★★★★

Обязательно добавь в задачу, что реализация должна быть на rust

cobold ★★★★★
()

Насколько я знаю, начать распаковывать gz с середины штатно нельзя. То есть ztail должен будет пробежать по всему файлу с его начала (но не показывать), что явно не то, что ждут от такой утилиты. Но если надо то это примерно zcat | tail, разве что zcat придётся подправить чтобы он при EOF не падал а ждал продолжения.

Надо будет менять формат: паковать например по 1 мбайту и записывать «пакетами» в выходной файл. Если не дописывать туда никаких метаданных для быстрой перемотки - его даже gunzip продолжит понимать. Но дописывать придётся.

У нас пачка nginx пишут сжатые логи

Это как?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Попробуй


The Logfile Navigator, lnav, is a log file viewer for the terminal.


он вроде умеет


Given a set of files/directories, lnav will:

  • decompress as needed;
  • detect their format;

alx777 ★★
()
Ответ на: комментарий от yars068

Ну как же, есть zcat, zgrep и др., а ztail – нет, из общей картины выбивается :)

И всех их сложить в один .deb пакет, как suckless-tools :)

alx777 ★★
()
Ответ на: комментарий от dataman

Увы, Haskell я совсем не знаю, даже приблизительно не понимаю, что там делается.

Chiffchaff
()
Ответ на: комментарий от madcore

С gzip’ом должна быть возможность сделать иначе. Он реализует потоковое сжатие, не блочное, что позволяет сжимать и разжимать потоки. Собственно говоря, сервер, который пишет логи, явно не сжимает каждый раз файл заново - это было бы слишком дорого и долго.

Возможно, просто, что потоковое разжатие никому до сих пор не требовалось, потому и не реализовано.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

хз как там организовать навигацию по сжатому, поток же нельзя разжимать не с начала
а так, проще такое хранить на фс со сжатием

madcore ★★★★★
()
Ответ на: комментарий от madcore

А… Я больше сконцентрировался на функционале tail -f. Который, наверное, можно реализовать, без того, чтобы разжимать файл постоянно.

Для реализации tail без опций наверное не страшно расшифровать файл с начала, если это не требуется делать постоянно.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

С gzip’ом должна быть возможность сделать иначе.

Поэтому, наверное, и написали https://github.com/circulosmeos/gztool:

GZIP files indexer, compressor and data retriever. Create small indexes for gzipped files and use them for quick and random data extraction. No more waiting when the end of a 10 GiB gzip is needed!

dataman ★★★★★
()

Зачем нужен ztail, если есть zcat file |tail?

bryak ★★★★
()
Ответ на: комментарий от targitaj

кажется, я понял, что на самом деле тебе нужно, невнимательно прочитал
только я хз как как обычный гзип к концу перемотать

Машины вообще-то под нагрузкой.

тогда и распаковывать лучше уже на своей машине, что-то типа такого

ssh nginxhost 'tail -c+0 -f /var/log/nginx/XXX.log.gz'|gzip -d

madcore ★★★★★
()

У нас пачка nginx пишут сжатые логи, которые мне хотелось бы смотреть В РЕАЛЬНОМ ВРЕМЕНИ.

Разве писать в конец gzip, не трогая начало, теоретически возможно?

Если нет, то тогда смысл tail -f пропадает.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)

Проблема решается по-другому. Нужно с другого сервера (без нагрузки) примонтировать фс с логами и локальными ресурсами разжимать файлы.

kaldeon
()
Ответ на: комментарий от kaldeon

писать можно в конец, пока не пришел конечный блок с црц и размером, читать - нет, заголовок-то в начале и дальше нужно последовательно прочесть все данные

madcore ★★★★★
()
Ответ на: комментарий от madcore

Мне кажется, со всеми словарными способами сжатия не выйдет. Там же фишка в чем – словарь строится на лету. Поэтому не получится разжать файл с его середины, поскольку будут встречаться индексы из словаря, которых пока нет.

Если немного модифицировать алгоритм словарного сжатия, чтобы сохранил словарь отдельно. Тогда бы можно было прочитав отдельно словарь, разжать файл из любой его точки.

hibou ★★★★★
()
Ответ на: комментарий от kaldeon

Разве писать в конец gzip, не трогая начало, теоретически возможно?

Можно распаковывать «склеенные» gzip-файлы:

(echo abc | gzip; echo 123 | gzip) | gzip -d
No ★★
()

логи, которые мне хотелось бы смотреть В РЕАЛЬНОМ ВРЕМЕНИ.

Отчего бы не перестать страдать фигнёй и поставить Opensearch?

ugoday ★★★★★
()
Ответ на: комментарий от hibou

либо резать поток на законченные блоки, через эн чего-то завершать и начинать снова
тогда можно будет поймать заголовок гзипа рано или поздно, не распаковывая целиком
но с произвольной навигацией по строкам это сильно поможет

madcore ★★★★★
()
Ответ на: комментарий от madcore

Кстати, одна из проблем словарных методов сжатия – размеры словаря при больших файлах. Решают эту проблему все форматы по-разному. Один из способов решения – как раз таки сброс словаря каждые N килобайт. Вот надо узнать как поступает gz. Может быть это получится использовать?

hibou ★★★★★
()
Ответ на: комментарий от hibou

Вроде нет там никакого сброса. Единственный вариант это построить индекс и потом при наличии этого индекса можно делать быстрый seek.

Но вообще надо смотреть на конкретный софт, который этот gzip формирует. Так-то можно тупо сделать cat file1.gz file2.gz > file3.gz и это будет работать. Если конкретный софт формирует конечный gzip путем таких конкатенаций независимых кусков, тогда можно попробовать.

А вообще есть прекрасный формат xz который позволяет делать произвольные seek-и. Не знаю, написал ли кто-то xztail, но формат это точно позволяет.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от hibou

есть возможность
например, если сделать gzip *.log -c >xxx.log.gz, то для каждого файла будет новый заголовок и, соответственно, словарь

с сжатыми логами nginx не работал, но он тоже умеет вставлять заголовок, через сколько он будет зависит от параметра buffer=size(возможно, ещё потребуется flush=...) в access_log

если я правильно понял задачу ТС, надо просто дождаться пока не появится очередной заголовок, либо поискать ближайший от конца файла и начать тайлить оттуда

madcore ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.