metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2009-04-26 11:28 am

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

А вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к 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, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.

[identity profile] thesz.livejournal.com 2009-04-26 09:07 am (UTC)(link)
Show/Read Haskell classes are your friends. ;)

[identity profile] lionet.livejournal.com 2009-04-26 09:15 am (UTC)(link)
А сериализуй прям лог-объекты в файл, зачем их маршалить в текст?

[identity profile] metaclass.livejournal.com 2009-04-26 10:00 am (UTC)(link)
Там проблема в том, что класс объекта, записываемого в лог, должен создаваться прямо по факту вызова функции записи в лог, т.е. неявно, и причем сразу с функциями сериализации.
Потому что я ж пишу не один объект какого-то уже существующего класса, а стопку объектов - комментарий, имя функции, параметры, локальные переменные. Не создавать же каждый раз руками новый класс для этого. В лучшем случае там будет базовый с пропертями вроде UserName, CurrentTimestamp, SourceModule, FunctionName, Comment, а от него должен унаследоваться новый, с полями-пропертями типа "localVar_A","localVar_B", "parameter_A",... итд

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

[identity profile] guamoka.livejournal.com 2009-04-26 10:01 am (UTC)(link)
А по-моему, ты заморачиваешься. Надо исходить все же из функции лога. Вероятно, для более полного и детального анализа должен служить уже например дамп. И сравнение с платами не совсем корректное. Лог- тестеровочный интерфейс с человеком. Вот когда в плату тестером тыкаешь, ты же смотришь вполне конкретные параметры ограниченного числа типа напряжения/силы тока и т.п.? Ты же не видишь атомную структуру детали, параметры техпроцесса, по которому она была произведена и т.п.? :)
ЗЫ. А вообще, совершенная конструкция- это не та, к которой прибавить уже нечего. Это та, от которой отнять уже нечего. Кажется так какой-то авиаконструктор советский сказал.

[identity profile] mudasobwa.livejournal.com 2009-04-26 10:31 am (UTC)(link)
На реализацию Hibernate гляньте. Там java, конечно, но идей там полно.

[identity profile] madeveloper.livejournal.com 2009-04-26 11:00 am (UTC)(link)
Пишите все в базу данных. Объекты сериализуйте в поле с XML-текстом. Причем современные БД позволяют дескрайбить структуру таких полей и работать с ними в запросах.

[identity profile] permea-kra.livejournal.com 2009-04-26 11:53 am (UTC)(link)
А что за язык?
Имею мнение, что на плюсах это через жопу, но реализуемо.

[identity profile] theiced.livejournal.com 2009-04-26 12:38 pm (UTC)(link)
и чем поможнт хымыыль, кроме того что уже придётся пейсать какой то парсер, потому что оно станет human-inreadable.

[identity profile] metaclass.livejournal.com 2009-04-26 12:55 pm (UTC)(link)
Текущий вариант - C# в .NET 2.0
А предлагаемый - реализуем разве что на Nemerle и прочих языках с метапрограммированием.

[identity profile] metaclass.livejournal.com 2009-04-26 12:56 pm (UTC)(link)
В этом и проблема, да. Нужно чтобы было и human- и machine-readable.

[identity profile] permea-kra.livejournal.com 2009-04-26 01:03 pm (UTC)(link)
А. Понял.
тут ничего кроме ILoggable и doLog(ILoggable) в голову не приходит.

[identity profile] permea-kra.livejournal.com 2009-04-26 01:04 pm (UTC)(link)
Нормально форматированный xml вполне human-readable. И к нему есть XQuery.

[identity profile] theiced.livejournal.com 2009-04-26 02:24 pm (UTC)(link)
Хрен - 100% бинарный формат, не предназначенный для чтения человеком.

[identity profile] madeveloper.livejournal.com 2009-04-26 02:46 pm (UTC)(link)
Ну никто пока не страдает от незнания внутренноего формата какой-нибудь InnoDB. А текст он всегда читаем. Кроме того, я уж не припомню языка, где бы для XML небыло готовых компонент, как и для доступа к БД. Зато все, что касается журналов, анализируется в SQL на раз-два. Плюс к этому нет проблем с многопроцессным доступом к журналу, в том числе в режиме записи.

[identity profile] theiced.livejournal.com 2009-04-26 03:25 pm (UTC)(link)
И вместо того что бы тупо пойчитать лог придётся писать прогу которая из хымыыля сделает что нибудь читаемое.

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

[identity profile] madeveloper.livejournal.com 2009-04-26 04:11 pm (UTC)(link)
Зачем прогу писать? Я же написал, что современные БД, тот же Оракл, умеют работать с XML полями как со структурой самой БД, даже могут поаттрибутно индексировать. Даже если не умеют, добавить в селект что-то типа "where xml_field containing "my_attribute=""101""" никаких проблем не составляет. Зато плюсов хоть завались: группировки, диапазоны дат и значений, расчет количества, прочая аналитика. Любые отчеты создадите стандартными средствами, без лишнего сетевого трафика будете их иметь их с любого места и раздачи шар. Ведь что такое журнал? Это вполне типизируемый и индексируемый набор данных, для которого самое место в какой-нибуль БД.

[identity profile] metaclass.livejournal.com 2009-04-26 04:12 pm (UTC)(link)
Если писать XML в базу данных(да и даже если в текст) - можно выполнять к этому запросы, а дальше уже грепы и седы и авки(которые становятся нафик не нужны, т.к. вся их функциональность, да еще в строго типизированном и разбитом на поля виды, есть в БД).

[identity profile] madeveloper.livejournal.com 2009-04-26 04:16 pm (UTC)(link)
В каком месте он бинарный? Я даже не припомню ни одного языка, который был бы бинарным... Если считать что HTML как разновидность XML тоже бинарный, так пора запрещать пользоваться "блокнотами" как редакторами...

[identity profile] theiced.livejournal.com 2009-04-26 04:25 pm (UTC)(link)
То есть ещё и оракл для логов? Вы там совсем охуели, не?

[identity profile] theiced.livejournal.com 2009-04-26 04:26 pm (UTC)(link)
Бинарный == human-inreadable. Я уже объяснял - есть люди который x86 бинарный код могут hexdumpом читать, что ни разу не делает его human-readable. Тоже самое и с хымыылем - есть ивзращенцы которые его пишут/читают руками. Но это их сексуальные проблемы.

[identity profile] madeveloper.livejournal.com 2009-04-26 04:44 pm (UTC)(link)
Это пример. Я же говорю, кладите в ЛЮБУЮ БД, хоть в MySQL, хоть в Postgre. Один фиг жизнь это значительно упростит. Оракл как всегда на верху совершенства...

[identity profile] madeveloper.livejournal.com 2009-04-26 04:50 pm (UTC)(link)
Если бы XML делали как бинарный, его бы для начала поделили на словарь и данные, типа DIANA в Оракле. А так - текст как текст. Как бы вы не пытались выразить литературным образом инстанс объекта - далеко от завоеваний XML вы не уйдете.

[identity profile] madeveloper.livejournal.com 2009-04-26 05:04 pm (UTC)(link)
Да дальше консольного доступа к БД уже ничего не нужно ;)

[identity profile] migmit.vox.com (from livejournal.com) 2009-04-26 05:11 pm (UTC)(link)
Вопрос не в том, как его делали (хотя я примерно догадываюсь, каким местом). Вопрос в том, что получилось. Получилась - хрень в тапочках, которую читать без специализированного на каждый чих парсера невозможно.

[identity profile] metaclass.livejournal.com 2009-04-26 05:11 pm (UTC)(link)
Ну замени его на mysql,postgresql или еще какую-нибудь трасцу.
Конечно, с ними xml не распарсишь, но достать его из базы для обработки каким-нибудь консольным xquery процессором - запросто.

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

Page 1 of 4