Строго типизированный лог

[metaclass]

А вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к grep, awk и прочей тексто-ориентированной линуксятине. Существует мнение, что это (текстово-ориентированный обмен данными между линуксовыми утилитами через |) хорошо, но у меня это усиленно ассоциируется с электронным прибором, у которого все платы соединены одинаковыми никак не различимыми разъемами, а плата сама решает, "что делать с входным сигналом", т.е. нет никакой защиты от обобщенного индуса-дяди-Васи-телемастера-из-соседнего-гаража.


Плохо то, что большинство интересующих объектов обычно содержат кучу пропертей-ссылок на всякие дебри, которые вне рабочего контекста смысла не имеют, а чтобы их исключить, нужно какой-то флаг на проперть типа атрибута/аннотации "NotLoggable". А это плохо тем, что логгинг не должен требовать лишнего от объектов, с которыми он работает.

Сейчас вывод в лог выглядит следующим образом:

  mLog.DebugFormat("OnAuthenticateRequest: {0} {1} {2}",
        httpApplication.Request.RawUrl,
        httpApplication.Request.UserAgent,
        httpApplication.Request.UserHostAddress); 

А желательно было бы так:

 
 mLog.Debug("some_user_comment",LogFlags.LocalVars | LogFlags.MethodName | LogFlags.This | LogFlags.Parameters);

А DebugAll был бы хитрым метапрограммным макросом, который бы доставал, в зависимости от флагов, имя метода, this, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.

Comments

[theiced.livejournal.com]

и чем поможнт хымыыль, кроме того что уже придётся пейсать какой то парсер, потому что оно станет human-inreadable.

[metaclass.livejournal.com]

В этом и проблема, да. Нужно чтобы было и human- и machine-readable.

[permea-kra.livejournal.com]

Нормально форматированный xml вполне human-readable. И к нему есть XQuery.

[theiced.livejournal.com]

Хрен - 100% бинарный формат, не предназначенный для чтения человеком.

[madeveloper.livejournal.com]

В каком месте он бинарный? Я даже не припомню ни одного языка, который был бы бинарным... Если считать что HTML как разновидность XML тоже бинарный, так пора запрещать пользоваться "блокнотами" как редакторами...

[theiced.livejournal.com]

Бинарный == human-inreadable. Я уже объяснял - есть люди который x86 бинарный код могут hexdumpом читать, что ни разу не делает его human-readable. Тоже самое и с хымыылем - есть ивзращенцы которые его пишут/читают руками. Но это их сексуальные проблемы.

[madeveloper.livejournal.com]

Если бы XML делали как бинарный, его бы для начала поделили на словарь и данные, типа DIANA в Оракле. А так - текст как текст. Как бы вы не пытались выразить литературным образом инстанс объекта - далеко от завоеваний XML вы не уйдете.

[migmit.vox.com (from livejournal.com)]

Вопрос не в том, как его делали (хотя я примерно догадываюсь, каким местом). Вопрос в том, что получилось. Получилась - хрень в тапочках, которую читать без специализированного на каждый чих парсера невозможно.

[metaclass.livejournal.com]

А он кстати поделен, на схему или dtd и собственно данные :)
Без этого запросы к нему особо не поделаешь. И если сериализовать объекты - в качестве словаря выступает структура класса.

[metaclass.livejournal.com]

Я пишу и читаю руками, но это не логи, а короткие файлы конфигов.

[madeveloper.livejournal.com]

Ну никто пока не страдает от незнания внутренноего формата какой-нибудь InnoDB. А текст он всегда читаем. Кроме того, я уж не припомню языка, где бы для XML небыло готовых компонент, как и для доступа к БД. Зато все, что касается журналов, анализируется в SQL на раз-два. Плюс к этому нет проблем с многопроцессным доступом к журналу, в том числе в режиме записи.

[theiced.livejournal.com]

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

Опять же - меганабор из grepов, sedов и прочих awkов становится непременим. Как жить дальше?

[madeveloper.livejournal.com]

Зачем прогу писать? Я же написал, что современные БД, тот же Оракл, умеют работать с XML полями как со структурой самой БД, даже могут поаттрибутно индексировать. Даже если не умеют, добавить в селект что-то типа "where xml_field containing "my_attribute=""101""" никаких проблем не составляет. Зато плюсов хоть завались: группировки, диапазоны дат и значений, расчет количества, прочая аналитика. Любые отчеты создадите стандартными средствами, без лишнего сетевого трафика будете их иметь их с любого места и раздачи шар. Ведь что такое журнал? Это вполне типизируемый и индексируемый набор данных, для которого самое место в какой-нибуль БД.

[theiced.livejournal.com]

То есть ещё и оракл для логов? Вы там совсем охуели, не?

[madeveloper.livejournal.com]

Это пример. Я же говорю, кладите в ЛЮБУЮ БД, хоть в MySQL, хоть в Postgre. Один фиг жизнь это значительно упростит. Оракл как всегда на верху совершенства...

[theiced.livejournal.com]

Ясно оракель головного моска приправленный буйной хымыыльманеей.

[metaclass.livejournal.com]

Ну замени его на mysql,postgresql или еще какую-нибудь трасцу.
Конечно, с ними xml не распарсишь, но достать его из базы для обработки каким-нибудь консольным xquery процессором - запросто.

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

[madeveloper.livejournal.com]

А что если "бросать" в качестве эксепшенов сами объекты или в объекте-эксепшене ссылку на них? И в обработчике раскладывать их по полям таблиц (на основе метаданных языка, хотя не со всеми прокатит)? Конечно матаданные в БД разрастутся, зато все под рукой...

[madeveloper.livejournal.com]

Кстати, пишу сейчас "тул" для генерации языковых классов на базе метаданных исходной БД и хранением там же. Что бы к объектам обращаться не через SQL или даже LINQ, а банальным вызовом конструкторов и доступом к типизированным атрибутам и методам, включая форейн-референсы. Готово для Delphi, сейчас начинаю делать для C#. Конечно пока не все реализовано, но все зависит от спроса. Есть интерес?

[metaclass.livejournal.com]

Если писать XML в базу данных(да и даже если в текст) - можно выполнять к этому запросы, а дальше уже грепы и седы и авки(которые становятся нафик не нужны, т.к. вся их функциональность, да еще в строго типизированном и разбитом на поля виды, есть в БД).

[madeveloper.livejournal.com]

Да дальше консольного доступа к БД уже ничего не нужно ;)

[permea-kra.livejournal.com]

>>И вместо того что бы тупо пойчитать лог придётся писать прогу которая из хымыыля сделает что нибудь читаемое.
Какую прогу писать???
Есть xmllint, чтобы отформатировать в читабельный вид.
Есть xqilla для тестов и обработки.

[theiced.livejournal.com]

Я просто хочу просмотреть глазами лог, не хочу какой то говнософт пускать.

[permea-kra.livejournal.com]

гыгыгыгы.
Ну, удачи в смотрении глазами 25М лога с мешаниной выводов десятка так подсистем.

[theiced.livejournal.com]

Ну вот как то спокойно смотрю глазами (cat | grep | grep | tail -n 20) 200мегабайтный лог.