Запись времени в логе

← →
Пит (2009-07-03 15:54) [0]

Кто как предпочитает выводить время в лог-файл?

I. При старте лога писать текущую дату, а потом вести отчет от этого момента или в каждой строчке писать настоящее время?

Вариант 1:
0:0:0.0 - Старт: 25.06.2009 14:53:15 0:0:3.456 - произошло событие 1 11:25:58.209 - произошло событие 2

Вариант 2:
25.06.2009 14:53:15.200 - старт 25.06.2009 14:53:18.656 - произошло событие 1 25.06.2009 2:19:16.409 - произошло событие 2

II. Выравнивать время, дополняя нулями?

Невыровненные варианты показаны в пункте I. Выровненные:

00:00:00.000 - Старт: 25.06.2009 14:53:15 00:00:03.456 - произошло событие 1 11:25:58.209 - произошло событие 2

25.06.2009 14:53:15.200 - старт 25.06.2009 14:53:18.656 - произошло событие 1 25.06.2009 02:19:16.409 - произошло событие 2

Также вообще интересны мысли по поводу оформления лога, использование тех или иных разделителей и т.д.

← →
Ega23 © (2009-07-03 16:00) [1]

Да как угодно. Где-то каждый день - новый файл, в нём только время.
Где-то один файл, внутри - дата-время.
Где-то с точностью до секунд, где-то - до миллисекунд.
Сильно зависит от задачи и объемов логов.

← →
DVM © (2009-07-03 16:02) [2]

> Вариант 2:
> 25.06.2009 14:53:15.200 - старт
> 25.06.2009 14:53:18.656 - произошло событие 1
> 25.06.2009 2:19:16.409 - произошло событие 2

я вот так, если лог один, если же лог на каждый день свой то дату в имя файла, а в строках даты нет.

← →
Rouse_ © (2009-07-03 16:11) [3]

У меня вообще в виде бинарника пишется с кодами ошибок и дополнительной инфой, из плюсов - можно выводить как угодно, хоть так: http://rouse.drkb.ru/tmp/1.jpg хоть так: http://rouse.drkb.ru/tmp/2.jpg фильтровать и прочее-прочее...
А от текстовых логов давно отказались - не удобные они...

← →
DVM © (2009-07-03 16:13) [4]

> Rouse_ © (03.07.09 16:11) [3]
>
> У меня вообще в виде бинарника пишется

Это на базе СУБД?

← →
Ega23 © (2009-07-03 16:13) [5]

> Rouse_ © (03.07.09 16:11) [3]

Ты не путай History и ExceptionLog

← →
Ega23 © (2009-07-03 16:14) [6]

> Это на базе СУБД?

У нас именно History писалось в БД, а вот ExceptionLog (у каждого АРМа - свой) - уже в текстовый файл.

← →
Rouse_ © (2009-07-03 16:16) [7]

> DVM © (03.07.09 16:13) [4]

Нет, собственный движок.

> Ega23 © (03.07.09 16:13) [5]

Какой эксепшен лог Легыч? Это наши серверные конфигуратор и монитор, там логируются все события включая исклчюения, если таковые сервер генерит :)

← →
Игорь Шевченко © (2009-07-03 16:21) [8]

> А от текстовых логов давно отказались - не удобные они..
> .

ты их готовить не умеешь

← →
DVM © (2009-07-03 16:25) [9]

Текстовый лог он самый имхо удобный в некоторых случаях. Возьмем, к примеру, web-сервер. Количество запросов к нему может запросто составлять 500 в секунду. Писать такое в СУБД имхо только грузить процессор. В текстовый же лог скопом все строки раз в несколько секунд записываются мгновенно.

← →
Rouse_ © (2009-07-03 16:28) [10]

> ты их готовить не умеешь

Покажи свой :)

← →
Ega23 © (2009-07-03 16:31) [11]

> Какой эксепшен лог Легыч? Это наши серверные конфигуратор
> и монитор, там логируются все события включая исклчюения,
> если таковые сервер генерит :)

Да я вижу, что это такое. Тут как бэ специфика другая.
Вот есть лог событий, которые вообще произошли. Например
"Пользователь Пупкин добавил в справочник товаров "Гвоздь на стописят"".
"Администратор Аникеев изменил права пользователя Пупкин: только просмотр"
и т.п.

Т.е. это то, что творится с "комплексом" целиком. Это - History.
А вот уборщица Тётя Мотя мыла пол рядом с рабочим местом Васи Пупкина, и задела кабель сетевой. И вместо добавления "гвоздя на стописят" Вася Пупкин видит MessageBox("Bla-bla-bla; Connection lost"#13#10"Trying to reconnect")
И вот это - уже ExceptionLog, причём вполне конкретного рабочего места, т.к. весь остальной комплекс продолжает работать, невзирая на проблемы Васи Пупкина.

Ну а в случае SSH - это как бы весь "комплекс" целиком. Если он рухнет - ну тогда пушистый зверёк всем.

← →
Пит (2009-07-03 16:36) [12]

> А от текстовых логов давно отказались - не удобные они..
> .

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

← →
Rouse_ © (2009-07-03 16:39) [13]

> Возьмем, к примеру, web-сервер. Количество запросов к нему
> может запросто составлять 500 в секунду

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

> Ega23 © (03.07.09 16:31) [11]

Олег, у нас сделано так - есть очередь событий, (уведомление, там исключение и т.п.), набор жестко заданных кодов, которым может описываться то или иное событие, текстовое описание событие, его параметры и обстрактный буффер с информацией куда пишется расширенная информация, из всего этогго стоится просмотрщик, для доп параметров в буффере есть набор классов-парсеров (например парсеры CallStack-а для исключений, парсеры IP пакетов - для сетевых исключений и прочее прочее) Благодаря всей этой пертушке я двумя кликами могу отследить что происходило от возникновения ошибки и откатиться до того места где что-то пошло не так. И не нужно ничего сидеть глазками смотреть в огроменном тектовике.

← →
Anatoly Podgoretsky © (2009-07-03 16:46) [14]

> Пит (03.07.2009 16:36:12) [12]

Как же не надо?

← →
Ega23 © (2009-07-03 16:46) [15]

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

← →
DVM © (2009-07-03 16:47) [16]

> Rouse_ ©

> Во - во а потом при ошибке попробый быстро разобраться в
> чем косяк - будешь часа полтоа выковыривать нужные тебе
> строчки и только потом приступишь к разбору полетов, плавали-
> знаем, второй раз чего-то не хочется :)

Обычно я загонял файл в БД, но уже потом, а не во время работы сервера.

← →
Ega23 © (2009-07-03 16:47) [17]

> не нужно спец. программ для их просмотра,

Ну вот у меня как-то апач ErrorLog сугенерил. Хороший, подробный. Всё по полочкам расписано. Занимает - гигабайт с волосьями.
Ну и нахрена мне это щщастье нужно. Чем я его смотреть буду?

← →
Rouse_ © (2009-07-03 16:49) [18]

> И вот тут появляется второй лог. Клиентский.

Он там такой-же как и на сервере :) И спокойно пересылается нам, если пользователь сам допетрить не может :)

> DVM © (03.07.09 16:47) [16]

Ну только если в БФ с формализацией - то тогда да...

← →
Anatoly Podgoretsky © (2009-07-03 16:52) [19]

> Ega23 (03.07.2009 16:47:17) [17]

У меня Squid обычно логи генерировал такого размера.
Тестовый редактор встроеный тогда брал только 64 кб

← →
Пит (2009-07-03 16:52) [20]

> например парсеры CallStack-а для исключений

а мона поподробнее?

> Ну и нахрена мне это щщастье нужно. Чем я его смотреть буду?

нормальным текстовым редактором, а не убожеством блокнотом.

Я в общем точно также посмотрю, как ты блокнотом посмотришь гигибайт с волосьями базу данных ))

← →
Ega23 © (2009-07-03 16:53) [21]

> Я в общем точно также посмотрю, как ты блокнотом посмотришь
> гигибайт с волосьями базу данных ))

Там я тебе Select-ом вытащу всё, что нужно.

← →
Пит (2009-07-03 16:54) [22]

> Там я тебе Select-ом вытащу всё, что нужно

в блокноте нету select"а

← →
Rouse_ © (2009-07-03 16:55) [23]

> > например парсеры CallStack-а для исключений
>
> а мона поподробнее?

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

← →
DVM © (2009-07-03 16:55) [24]

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

← →
DVM © (2009-07-03 16:57) [25]

> Ega23 © (03.07.09 16:53) [21]

Класть лог в БД при высокой нагрузке веб-сервера мне кажется все таки накладно. Ведь будет отдельный запрос на каждую запись, несколько сотен записей скопом же не добавить как можно добавить в текстовый файл?

← →
Ega23 © (2009-07-03 16:59) [26]

> Класть лог в БД при высокой нагрузке веб-сервера мне кажется
> все таки накладно. Ведь будет отдельный запрос на каждую
> запись, несколько сотен записей скопом же не добавить как
> можно добавить в текстовый файл?

Ну у нас проект не был High-Load Web Server.. :)
Там можно было каждую запись писать.

← →
Игорь Шевченко © (2009-07-03 17:18) [27]

DVM © (03.07.09 16:55) [24]

В том же Windows их тоже хватает

← →
Медвежонок Пятачок © (2009-07-03 17:34) [28]

текстовый файл + Ф3 в фаре.
и смотрится в реальном времени

← →
Пит (2009-07-03 17:52) [29]

сразу было интересно куда выведет обсуждение.

Пока из сабжа превратилось в "Текстовые файлы" vs "БД".
Ну блин даже про логи пока речь ))

> Пит (03.07.2009 16:52:20) [20]

Назови чем? Только без спецпрограмм, встроеными средствами и размер лога пускай гигабайт будет, оставим за скпобками даже вопрос о том, что с этой кашей делать. Я лично быстро написал конверторв из Squid в DB, и красота сразу наступила.

> Название у "SSH Log Viever" надо бы перекомпильнуть, а? :)

Ты че? Это фича!!! :)))

← →
Иа (2009-07-04 18:19) [33]

> Текстовый лог он самый имхо удобный в некоторых случаях.
> Возьмем, к примеру, web-сервер. Количество запросов к нему
> может запросто составлять 500 в секунду. Писать такое в
> СУБД имхо только грузить процессор. В текстовый же лог скопом
> все строки раз в несколько секунд записываются мгновенно.
>

Что мешает писать в базу аналогично, пакетом? Файловые логи при наличии доступа к db это пережиток прошлого. Поиск, фильтрация, и самое главное возможность доступа без физического доступа к машине - ковырятся на production сервере шаловливыми ручками программистов? увольте...

Если использовать к примеру log4net, к нему написаны аппликухи для просмотра, которые можно доверить саппорту.

http://demo.l4ndash.com/PageDashboard/Dashboard.aspx?period=3

> Иа (04.07.09 18:19) [33]

Спасибо на наводочку, есть что интересного взять...

> Иа

> Что мешает писать в базу аналогично, пакетом?

Но как? Я, может не в курсе, но как занести несколько записей одним запросом к базе?

← →
Иа (2009-07-05 03:05) [36]

>
> > Иа
>
>
> > Что мешает писать в базу аналогично, пакетом?
>
> Но как? Я, может не в курсе, но как занести несколько записей
> одним запросом к базе?

Э, может вы что-то странное имеете ввиду? Я под одним пакетом подразумеваю открыть транзакцию, запустить скрипт в котором будет много insert & go, закоммитить. Я бы рекоммендовал так делать конечно только если нагрузка действительно велика - и только если событие которое пишется не критично - если скажем произошла ощибка ее стоит немедленно писать, пока не упало.

> Иа (05.07.09 03:05) [36]

> в котором будет много insert

Ааа. Этот способ то известный. Запрос то тут не один, а множество, т.е. получается все же не скопом, а по отдельности, хоть и транзакция одна. Только так значительно медленней все равно, чем в текстовый файл и процессор грузит сильнее.

← →
Иа (2009-07-05 18:18) [38]

> Только так значительно медленней все равно, чем в текстовый
> файл и процессор грузит сильнее.

Что значит "значительно медленнее" в абсолютных цифрах? Что значит "процессор грузится сильнее" в абсолютных цифрах?

Не занимайтесь тем что называется premature optimization :)

У меня сейчас во время работы (распределенная система, приложения раскиданы по разным машинам) пишется в базу примерно 120-150 записей в секунду. Сервер, худосочный, на обычной машине, с парой гигов памяти и обычным 7200 диском (тестовый, не production) работает не особо напрягаясь.

> Иа (05.07.09 18:18) [38]

> пишется в базу примерно 120-150 записей в секунду.

> работает не особо напрягаясь.

Тут и напрягаться не от чего собственно, т.к. 200 запросов на добавление базе в секунду это не нагрузка. Нет, я конечно не спорю, что в подавляющем большинстве случаев это вполне подходит, но в то же время скорость записи в текстовый файл десятки Мбайт/сек при ничтожной загрузке процессора.

← →
Иа (2009-07-05 20:28) [40]

> Тут и напрягаться не от чего собственно, т.к. 200 запросов
> на добавление базе в секунду это не нагрузка. Нет, я конечно
> не спорю, что в подавляющем большинстве случаев это вполне
> подходит, но в то же время скорость записи в текстовый файл
> десятки Мбайт/сек при ничтожной загрузке процессора.

У вас логи - десятки мегабайт в секунду? Мы говорим о конкретных системах которые вы пишете или вы теоретизируете? Нет, конечно, бывают и такие нагрузки но мы же не о предельных случаях - и если в каком то конкретном варианте база не работает то это не значит в большинстве своем так не надо делать. Или вы пытаетесь доказать что идеального решения не бывает? так никто и не спорит.

И повторю совет - не пытайтесь заоптимизировать приложение (систему) заранее. То есть думать головой и откровенных глупостей не делать надо но и считать проценты cpu заранее то же не стоит. Это удорожает и удлинняет работу а толку скорее всего не будет - ибо bottle neck (узкое место) окажется так где не ждали.

> Иа

> У вас логи - десятки мегабайт в секунду? Мы говорим о конкретных
> системах которые вы пишете или вы теоретизируете?

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

Это конечно частная ситуация, но именно она теперь заставляет меня задуматься иногда, а стоит ли лог класть сразу в базу.

Запись времени в логе Найти похожие ветки