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

[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

[thesz.livejournal.com]

Show/Read Haskell classes are your friends. ;)

[lionet.livejournal.com]

А сериализуй прям лог-объекты в файл, зачем их маршалить в текст?

[metaclass.livejournal.com]

Там проблема в том, что класс объекта, записываемого в лог, должен создаваться прямо по факту вызова функции записи в лог, т.е. неявно, и причем сразу с функциями сериализации.
Потому что я ж пишу не один объект какого-то уже существующего класса, а стопку объектов - комментарий, имя функции, параметры, локальные переменные. Не создавать же каждый раз руками новый класс для этого. В лучшем случае там будет базовый с пропертями вроде UserName, CurrentTimestamp, SourceModule, FunctionName, Comment, а от него должен унаследоваться новый, с полями-пропертями типа "localVar_A","localVar_B", "parameter_A",... итд

А уж во что его сериализовать - это не так важно, но текст нужен для случая "под руками ничего кроме grep для анализа нету".

[guamoka.livejournal.com]

А по-моему, ты заморачиваешься. Надо исходить все же из функции лога. Вероятно, для более полного и детального анализа должен служить уже например дамп. И сравнение с платами не совсем корректное. Лог- тестеровочный интерфейс с человеком. Вот когда в плату тестером тыкаешь, ты же смотришь вполне конкретные параметры ограниченного числа типа напряжения/силы тока и т.п.? Ты же не видишь атомную структуру детали, параметры техпроцесса, по которому она была произведена и т.п.? :)
ЗЫ. А вообще, совершенная конструкция- это не та, к которой прибавить уже нечего. Это та, от которой отнять уже нечего. Кажется так какой-то авиаконструктор советский сказал.

[mudasobwa.livejournal.com]

На реализацию Hibernate гляньте. Там java, конечно, но идей там полно.

[madeveloper.livejournal.com]

Пишите все в базу данных. Объекты сериализуйте в поле с XML-текстом. Причем современные БД позволяют дескрайбить структуру таких полей и работать с ними в запросах.

[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]

Ну никто пока не страдает от незнания внутренноего формата какой-нибудь 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. Один фиг жизнь это значительно упростит. Оракл как всегда на верху совершенства...

[metaclass.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[madeveloper.livejournal.com]

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

[permea-kra.livejournal.com]

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

[theiced.livejournal.com]

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

[permea-kra.livejournal.com]

А что за язык?
Имею мнение, что на плюсах это через жопу, но реализуемо.

[metaclass.livejournal.com]

Текущий вариант - C# в .NET 2.0
А предлагаемый - реализуем разве что на Nemerle и прочих языках с метапрограммированием.

[permea-kra.livejournal.com]

А. Понял.
тут ничего кроме ILoggable и doLog(ILoggable) в голову не приходит.