> согласен, если оно делает «…цатигиговые логи» — то оно именно то, Логи бывают разные. В частности,
1) Логи могут быть по поводу внешних событий. Ну там например боты пришли стайкой на ssh или что там еще. Хотелось бы чтобы логи от этого не заваливались а выцепляние особо интересного айпи не становилось бы при этом задачей на полчаса грепа.
2) Бывают нештатные ситуации. Скажем при натыкании на диск с ошибками чтения ядро может довольно круто наспамить в логи. Вот тут не прочитался сектор 10, а вон там - 100500. И еще два миллиона секторов. Поэтому rate limiter помог очень условно и лог отрос на несколько гигз, предоставив целый ассортимент секторов проблемного диска. Реально виденные случаи, btw. Грепать по подобным логам может быть не прикольно. А энтерпрайзный логгинг на каком-нибудь ноуте - явно оверкилл.
> а вот делить логи на части в тексте намного проще, например.
То-то каждый сервис городит кучу своих костылей по этому поводу и каждый по разному. Проще всего - дергать логгер и не париться. А он там уже пусть режет и лимитирует размеры. Програмеру не придется писать кучу кода а админу не придется настраивать 20 разных сервисов где это 20 разных програмеров сделало напрочь по разному. Сплошной профит.
> если же у тебя бинарь с индексами — то изволь бережно найти
> место, где можно порезать,
Если текст резать не парясь местом разделения - какая-то запись может оказаться порушенной. Логгинг спецсимволов и прочего - отдельный головняк. И ротация. Ну и так далее. Не так уж и просто получается. Просто привыкли...
> потом бережно индексы перестроить. это в лучшем случае.
А зачем их перестраивать? По идее забираешь индексы к старому блоку. А в новом начинаешь строить по новому. При этом индексы остаются валидны и никакой перестройки не надо. Хотя конечно можно и прострелить себе ногу себе лишний раз. А зачем?
> вместо того, чтобы просто найти перевод строки и всё.
...по поводу чего может быть достаточно интересно покормить приложения странными последовательностями байтов и посмотреть сколько из них лоханется на фэйковом переводе строки, например.
> далее. что, не умеем грепать предварительно в отдельный файл по грубому образцу,
> и потом уже уточнять?
Для начала - сам греп более или менее большого файла занимает немало времени. А если еще и декомпрессить - и подавно. Особенно если bz2, который Шигорин предлагал.
> лопатить? так эти ваши индексы тут не сильно помогут, потому что
> или бинарный лог с индексами не помещается в память, и тогда
> всё равно все ждут данных с диска,
Так запросов к диску будет меньше. Индексы на то и нужны, чтобы не читать вообще ВСЕ записи, даже явно не удовлетворяющие критериям, а сразу выхватить то что надо. А полный скан как с грепом - не особо оптимальный подход в плане ресурсов.
> или помещается — но и текст если помещается, то отрабатывает grep на нём очень быстро.
Тут можно полечить про разбивку по датам и прочая, но это не поможет если вопрос вида "а что айпи такой-то делал с нами с начала времен?".
> вообще, если ты не можешь сначала сделать грубую выборку, чтобы сократить свои
> «…цать гигов» до приемлемого объёма, то что-то с логами ты делаешь не так.
Для того чтобы ...цать гигов сократились до приемлимого объема твоим методом надо всего ничего - сначала их с диска прочитать. Все ...цать гигов. Потом греп конечно выкинет 99.9(9)% записей, но радости с этого будет мало. А при человечески сделанных индексах я получу только записи относящиеся к делу. Без чтения и парсинга вообще всех ...цати гигов.
> индексы, кстати, тоже не бесплатные. на их построение и обновление требуется время,
Это время относительно небольшое и размазано (в том плане что я машину при этом не жду). А вот греп читающий ...цать гигов, чтобы отбросив 99.9(9)% данных выдать мне пару страниц на которых можно более тонкий фильтр делать - заставит ждать полное время чтения и парсинга всех ...цати гигов, что как-то совсем не прикольно с моей точки зрения.
Кроме того бинарное представление компактнее (айпи как текст почти в 4 раза жирнее бинарного представления) и не требует например процессинга на всякое там экранирование дурных символов - в бинарном формате можно хранить данные так как они по факту пришли, а не так как исхитрился это законопатить очередной програмер в своем сервисе.
> на их хранение требуется место, и как только у тебя более-менее
> сложный запрос, то всё равно лопатить будет много.
Ну так кому надо крутую бизнес-аналитику - те пусть и берут энтерпрайзные инструменты. А это лишь дефолтовый системный логгер.
> всякий случай» мне не проблемно преобразовать текстовый лог в таблицу, если
> надо будет. с индексами, подстроеными именно под конкретную мою нужду в этот раз.
С таким же успехом можно перегнать и это в таблицу, если стало надо. Просто это стало надо - будет случаться сильно реже, только при реально энтерпрайзных запросах к аналитике.
> ну не дают бинарные логи никаких мегавыигрышей, не дают. зато вот беспроблемное
> чтение логов глазами иногда очень полезно.
Я не умею декомпрессовать глазами LZ+Huffman в том же гзипе, прикинь? Что ж мне теперь, старые логи не сжимать чтоли? Ну а раз оказывается что это лишь вопрос утилсов то не вижу чему противоречат утилсы и для работы с поттеровским форматом.
