17 февр. 2015 г.

Чем смотрят логи многопоточных приложений?

Добрый день.

Хорошей программы для просмотра логов мне пока найти не удалось. Иногда чешутся руки написать свою, но позвать grep оказывается гораздо быстрее. Видимо, это одна из причин, почему подобных программ мало и они умеют не совсем то, что лично мне в данный момент требуется. Иногда попадаются вроде бы достаточно продуманные системы подсветки нужных ключевых слов, фильтрации подстрок, которые ещё и позволяют быстро сохранять профили (чтобы при последующем открытии логов с той же целью быстро настроить систему под тот же режим), но как же они тормозят... Или не умеют на растущем файле жить, что тоже делает работу почти невозможной. Да, grep выигрывает с большим отрывом. (ругань в сторону: вот если я попросил «покрасить подстроку 'not created' красненьким», то зачем это начинать делать с самого начала полугигабайтного файла, если я смотрю на его последние строчки? перекрась мне сперва текущий экран, а уже потом занимайся чем хочешь)

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

Thread0 001 Message00
Thread1 002 Message10
Thread0 005 Message01
Thread1 006 Message11
Thread0 007 Message03
Thread1 008 Message12
Thread0 017 Message04

Читать это всё вполне легко, столбец времени фильтруется запросто, жизнь прекрасна. Но вот у нас есть два лога, которые надо сравнить. Второй выглядит, например, так:

Thread0 001 Message00
Thread0 003 Message01
Thread1 006 Message10
Thread1 007 Message11
Thread1 008 Message12
Thread0 007 Message03
Thread0 017 Message04

Легко видеть, что не поменялось ничего, просто так распорядилась судьба, что в этот раз Thread1 успел выдать три сообщения подряд. Мне надо сравнивать эти два файла, не замечая подобных перестановок строк (естественно, замечая всё остальное). Что значит «не замечая»? Например, когда вы средствами какого-нибудь KDiff3 сравниваете два почти одинаковых файла, то программа обращает ваше внимание на изменившиеся строки, а одинаковые (или одинаковые с точностью до замены табов на пробелы и т.д.) игнорирует. Вот хочется как-то так. Вам попадались средства для решения этой задачи? Было удобно? На каких объёмах файлов?

Хорошего дня!

(о других хороших программах мы говорили в записи Три программы для удобной работы)

14 комментариев:

  1. Обработка логов - сложный вопрос. Например, я не придумал ничего лучше grep, или же преднастроенного Hadoop-кластера, но второе - оверкилл почти всегда. Что тут посоветовать - не знаю.

    А тебе зачем, кстати? Просто для тестов можно подобное засунуть в РСУБД и запросы погонять.

    PS: сорри, если дабл-пост. Блогпост - та еще радость.

    ОтветитьУдалить
    Ответы
    1. Пока наливал чай вспомнил вот что. Есть такая штука, как LogParser (http://www.microsoft.com/en-us/download/details.aspx?id=24659) - по сути продвинутый grep, с возможностью писать sql-like запросы к логам. Работает относительно шустро (однопоточный - это его минус).
      Им можно преобразовать твой файл, отсортировав как надо и затем сравнивать чем угодно.

      Удалить
    2. Анатолий, спасибо за ссылки и идеи!
      Мне эта задача была нужна, чтобы быстрее обнаружить, в какой момент начинается расхождение в промежуточных вычислениях (заметно поменяли алгоритм, но это должно было повлиять только на скорость вычислений, а не на их результат). В однопоточном случае гораздо проще сравнениям логов "до" и "после" обнаружить, на каком этапе возникли различия. Ещё раз благодарю за ссылки и советы!

      Удалить
  2. Анонимный17.02.2015, 14:59

    А посмотрите LogExpert. Есть много вкусностей, вроде объединения нескольких логов в один виртуальный, и вполне приличная скорость работы с файлами в сотни мегабайт. Ваша задача, как мне кажется, может быть решена двумя окнами, в каждом из которых будет отфильтрован нужный тред.

    ОтветитьУдалить
    Ответы
    1. Спасибо за совет! Да, это интересное решение.

      Удалить
  3. вроде написал про спланк, а в комментариях не вижу..

    ОтветитьУдалить
    Ответы
    1. Николай, это очень странно, так как в списке "подозрительных" сообщений от Вас тоже ничего нет. Сообщение потерялось, но трудно понять, из-за чего :-(

      Удалить
  4. Анонимный18.02.2015, 00:21

    Посмотрите http://www.logfusion.ca/, может понравится.

    ОтветитьУдалить
  5. Давно для нашей системы писали свою тулзу, у нас мало того что многопоточная, так еще и приоритетов лога много и пишется они в разные файлы для разных уровней логирования со своими настройками закольцовывания, так же еще группы по компонентам были (типа логи от ядра в одну папку, логи от плагинов в другую).
    Вся эта муть была нужна что бы в тоннах лога от какого-то взбесившегося девайса не пропало критическое сообщение от ядра.
    Но при этом превратило логи в вообще непонятную, неюзабельную муть.
    Писали свои тулзы каждый раз рашпилем допиливали её под хотелки - вроде стало возможно пользоваться, но она хлипкая была и даже приходилось править движок логирования что бы можно было более простой автомат прасинга написать...

    ОтветитьУдалить
    Ответы
    1. Да, такие сложные штуки сложно передавать наружу. Спасибо, что поделились опытом.

      Удалить
  6. У себя пользуюсь скриптами на Python. Для разбора логов осваивается за 20 минут.

    В этом случае я бы сделал так: рассортировал файл по потокам. То есть логи от одного потока в одном файле. А дальше сравнивал уже эти новые файлы.

    ОтветитьУдалить
  7. Ответы
    1. Интересно, это такая форма спама или комментарий искренен? Если спам, то кто-нибудь знает, какой в этом смысл?

      Удалить

Понравилась заметка? Подпишитесь на RSS-feed или email-рассылку.

Хотите поделиться ссылкой с другими? Добавьте в закладки:



Есть вопросы или предложения? Пишите письма на адрес mytribune АТ yandex.ru.

С уважением,
      Илья Весенний