 аппликуха и варианты логгирования,  fail, 25-Июн-15, 18:17 [смотреть все]ситуация вроде как банальная, но ранее не сталкивался: - в приложении необходимо будет вести лог(и)/историю(и) сообщений прикладного ( пользоватeльского ) уровня
- по T3 использовать надо или файловую систему, или встроенную в приложение библиoтеку для работы с XML
- основной и единственный пользовательский режим чтение(поиск) по:
- id source - ид. источника ( строго фиксированный - в рамках текщего контекста приложения )
- datetime stamp - вчера, день, неделю, ..., все время ( задается пользователем )
- text in message - текст для поиска в сообщении ( задается пользователем ) в случае с ипользованием XML вроде особых проблем нет...
а в случае использования файлухи, что-то не особо вырисовывается, пока набросал следующюю схему:
a. app_DIR->id_source_DIR->year[20xx]_DIR->month_[1-12].LOG_FILE b. возникает вопрос по внутренней структуре month_[1-12].LOG_FILE - думается припаять
хранение сообщений прикладного уровня в TLV структуре( и также в TLV пркирутить необходимyю служебную хрень вроде заголовка лога и т.д.) если кто пересекался с подобной проблемой
и/или пересекался с граблями схожей схемы на файловой системе - был бы благодарен услышать мнение(я) - достаточно ли "правильно" ?
- подводные грабли ?
p.s.:
вообщем с одной стороны надо заложить какой-то базис для расширения,
с другой не охотa двухколесную промышленность развивать.
|
- аппликуха и варианты логгирования, Square, 18:38 , 25-Июн-15 (1)
> - id source - ид. источника ( строго фиксированный
> - в рамках текщего контекста приложения )
> - datetime stamp - вчера, день, неделю, ..., все
> время ( задается пользователем )
> - text in message - текст для поиска в
> сообщении ( задается пользователем ) Жжоте :) filename.log
id application <tabulation> id source <tabulation> datetime stamp <tabulation> text in message формат называется CSV, описан тут: https://ru.wikipedia.org/wiki/CSV Широко используется в ИТ последние лет 50 :)
- аппликуха и варианты логгирования, fail_, 20:43 , 25-Июн-15 (2)
> Жжоте :)
> filename.log
> id application <tabulation> id source <tabulation> datetime stamp <tabulation> text in
> message id source <tabulation> datetime stamp <tabulation> message
так было бы корректней сказать в данном предложении;
text in message - это что искать в сообщениях, не совсем правильно поняли > формат называется CSV, описан тут: https://ru.wikipedia.org/wiki/CSV
> Широко используется в ИТ последние лет 50 :) про csv и прочие "a:b:c" в курсе: - кортежи выходят дюже "фиксированные" - трабля даже на cr, lf всплывает: уже +1 к костыллингу при этом подходе + по моим прикидкам будут еще 2-3 итерации улучшизмофф и поликостыллинга пока "хотелки и ресурсы не устаканятся и прийдут в равновесие" пока по файлухе все же видится:
app_DIR/id_source_DIR/year[20xx]_DIR/month_[1-12].LOG_FILE
+
month_[1-12].LOG_FILE с внутренней структурой на базe TLV
- аппликуха и варианты логгирования, Square, 21:06 , 25-Июн-15 (3)
>> Жжоте :)
>> filename.log
>> id application <tabulation> id source <tabulation> datetime stamp <tabulation> text in
>> message
> id source <tabulation> datetime stamp <tabulation> message
> так было бы корректней сказать в данном предложении;
> text in message - это что искать в сообщениях, не совсем правильно
> поняли Зачем что-то искать? Вы вообще о чем? Вы написали, что пишите приложение, которое будет шпионить за действиями пользователя ( вести лог) и далее описали какие данные хотите видеть в этом логе.
id source <tabulation> datetime stamp <tabulation> message message - это и есть я так понимаю описание действий пользователя.. названия кнопок,вводимый текст... координаты мышки... теперь оказалось, что "message" у вас оказывается многострочный...и судя по упорному желанию определить их длинну- то чуть ли не бинарный. Да, с бинарным содержимым message конечно плантекстовому файлу будет непросто... если вы далее с этими логами (это же логи, не база данных) планируете что-то делать вроде парсинга и извлечения из них данных, полнотекстового поиска по ним... это совершенно другая задача...
и лучше сразу засовывать логи в нечто-базоподобное....xml например.или просто в базу...встроенную напрмиер..чтото вроде sqlite То есть вопрос вобщем то простой: вы хотите обеспечить в этой программе логирование (воспользовавшись готовыми отлаженными механизмами) или хотите под предлогом этой работы изобрести свою собственную файл-ориентированную базу данных. На мой взгляд - это совершенно разные задачи :) PS: SqLite поддерживает тип данных blob- можно пихать что угодно :)
- аппликуха и варианты логгирования, fail_, 22:07 , 25-Июн-15 (4)
> Зачем что-то искать? Вы вообще о чем?наверное вы не внимательно прочли первый пост; пользователь будет искать (например текущая статистика: per 'id source' раз в квартaл) в истории какие-то данные; возможно даже через regexp и/или пакетной обработкой по таймеру, событию...
>Вы написали, что пишите приложение, которое будет шпионить за действиями пользователя ( >вести лог) и далее описали какие данные хотите видеть в этом логе.
>id source <tabulation> datetime stamp <tabulation> message
не пришьете :)
а если без шуток, это лучше сказать "история" (лог) ПРЕДМЕТНОЙ области - ближайшая аналогии: история пользовaтеля (по ИД) в Call-центре, история переписки Instant Messaging и т.п.
> message - это и есть я так понимаю описание действий пользователя.. названия
> кнопок,вводимый текст... координаты мышки...
нет, текстовка поступаемая на один из каналов аппликухи - к-рую надобно локально расположить "наиправильнейшим" образом для приложения
> теперь оказалось, что "message" у вас оказывается многострочный...и судя по упорному желанию
> определить их длинну- то чуть ли не бинарный. Да, с бинарным
> содержимым message конечно плантекстовому файлу будет непросто...
message - многострочный текст ( UTF-8 )
> если вы далее с этими логами (это же логи, не база данных)
> планируете что-то делать вроде парсинга и извлечения из них данных, полнотекстового
> поиска по ним... это совершенно другая задача...
> и лучше сразу засовывать логи в нечто-базоподобное....xml например.или просто в базу...встроенную
> напрмиер..чтото вроде sqlite
в том-то печаль, по Т3 СУБД использовать нельзя, а использумеая библиотека XML сильно не равнодушна к памяти...
- аппликуха и варианты логгирования, fail_, 22:36 , 25-Июн-15 (5)
> То есть вопрос вобщем то простой:
> вы хотите обеспечить в этой программе логирование (воспользовавшись готовыми отлаженными
> механизмами) или хотите под предлогом этой работы изобрести свою собственную файл-ориентированную
> базу данных.повторюсь:
вообщем с одной стороны надо заложить какой-то базис для расширения,
с другой не охотa двухколесную промышленность развивать. > На мой взгляд - это совершенно разные задачи :) согласен В любом случае, придется два варианта на стенде погонять: на файлухе и XML p.s.:
приблизительная статистика по предметке: user -> app ( read by 'id source'(90%), 'time stamp'(9%), 'text'(0.999%); delete by 'id source'(0.001 %) )
source -> app ( 100 % insert data )
- аппликуха и варианты логгирования, universite, 09:29 , 28-Июн-15 (6)
>> То есть вопрос вобщем то простой:
>> вы хотите обеспечить в этой программе логирование (воспользовавшись готовыми отлаженными
>> механизмами) или хотите под предлогом этой работы изобрести свою собственную файл-ориентированную
>> базу данных.
> повторюсь:
> вообщем с одной стороны надо заложить какой-то базис для расширения,
> с другой не охотa двухколесную промышленность развивать.Почитайте книжку "Искусство программирования для Unix" Эрик C. Реймонд.
Там такие вещи рассказаны.
- аппликуха и варианты логгирования, fail, 12:51 , 28-Июн-15 (7)
> Почитайте книжку "Искусство программирования для Unix" Эрик C. Реймонд.
> Там такие вещи рассказаны.Благодарствуем, заодно освежим память.
|
Версия для распечатки
