Как нам реорганизовать [s]Рабкрин[/s] лог-файл?

Как в старом анекдоте про чукчу и вскрытие...
Анализ лог-файла real-time процесса показал, что причиной торможения и, как следствие неправильной работы, явилась запись в лог-файл.
Как это исправить, в общем, понятно, но раз уж все равно код переписывать, пришла в голову мысль - а может заодно и формат поменять?
Что нужно:
1. Точная хронология и хронометраж всех действий.
2. Запись неоднородной информации
3. Максимальная надежность работы.
4. Возможность автоматического анализа.
В текстовом файле, который сейчас используется, пп.1-3 выполняются, но с п. 4, понятное дело, все плохо - нужно писать кучу парсеров.
С СУБД, ввиду п. 2-3 в этом месте связываться боязно.
Может я чего-то не знаю, и человечество придумало еще какие-то варианты?

Соколинский Борис,

угу. пишет в текстовый файл код ошибки и параметры в каких нибудь скобочках

Siemargl
пишет в текстовый файл код ошибки и параметры в каких нибудь скобочках

или этот текст со скобочками в сеть отправляет

хотя отклонения бывают - логи Windows

Соколинский Борис

Как в старом анекдоте про чукчу и вскрытие... Анализ лог-файла real-time процесса показал, что причиной торможения и, как следствие неправильной работы, явилась запись в лог-файл. Как это исправить, в общем, понятно, но раз уж все равно код переписывать, пришла в голову мысль - а может заодно и формат поменять? Что нужно: 1. Точная хронология и хронометраж всех действий. 2. Запись неоднородной информации 3. Максимальная надежность работы. 4. Возможность автоматического анализа. В текстовом файле, который сейчас используется, пп.1-3 выполняются, но с п. 4, понятное дело, все плохо - нужно писать кучу парсеров. С СУБД, ввиду п. 2-3 в этом месте связываться боязно. Может я чего-то не знаю, и человечество придумало еще какие-то варианты?

любая база данных имеет негарантированное время реакции, потому пункты 1 и 3 отпадают

а так вообще есть такая штука как syslog-ng. в нем можно настраивать 100500 разных приемников лог сообщений, хоть куда.
https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/chapter-destinations.html

это если примитив

не примитив - это область CEP https://en.wikipedia.org/wiki/Complex_event_processing
https://en.wikipedia.org/wiki/Complex_event_processing#Vendors_and_products

есть еще вот эти товарищи https://en.wikipedia.org/wiki/Reliable_multicast

короче, гугли на тему real time messaging

Соколинский Борис
С СУБД, ввиду п. 2-3 в этом месте связываться боязно.

Совершенно непонятно, почему.

Соколинский Борис
2. Запись неоднородной информации

Вот что там у вас за неоднородная информация такая, что запись её в БД может вызвать какие-то проблемы? это при том, что в текст всё пишется - то есть ничего хитромудрого в данных нет. Пишите как есть, сырцом, но в БД, в текстовое поле, и всё.

Соколинский Борис
3. Максимальная надежность работы.

Современные СУБД достаточно надёжны. И в чём-то даже получше plain text будут.

dbpatch
любая база данных имеет негарантированное время реакции, потому пункты 1 и 3 отпадают

Ну по поводу пункта 3 - так ведь и жёсткий диск не гарантирует real-time записи.
А по первому пункту - записываемая информация, если это действительно лог, обязана содержать в себе временнЫе метки (штамп времени, синтетический штамп или ещё что), устанавливающие порядок, и, значит, сортировка по этим меткам выстроит последовательность событий в правильном порядке, даже если они до сервера добрались перемешанными. А ориентироваться на физический порядок следования - это даже не смешно.

dbpatch
а так вообще есть такая штука как syslog-ng

Ага, которая хранит логи на сервере БД. Только дополнительно организует ещё слой буферизации, чтобы чего не потерять. Но если товарищ логирует собственное приложение, так он и сам организовать такую буферизацию может, без привлечения сторонних средств. И процесс слива буфера на сервер БД - низкоприоритетный рядом с приложением или нормальный рядом с сервером БД.

Akina
Пишите как есть, сырцом, но в БД, в текстовое поле, и всё.

В этом случае теряется все преимущество БД по сравнению с текстовым файлом.

Akina
Современные СУБД достаточно надёжны. И в чём-то даже получше plain text будут.

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

Соколинский Борис
В текстовом файле, который сейчас используется, пп.1-3 выполняются, но с п. 4, понятное дело, все плохо - нужно писать кучу парсеров.

а плохго то что?
а почему кучу, а не один полнофункцинальный?

платформа какая и объём логирования?

Изопропил
а плохго то что? а почему кучу, а не один полнофункцинальный?

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

Изопропил
платформа какая и объём логирования?

Винда XP - 10. Объем зависит от длительности работы и состава логгируемых операций. От 100К до 10М.

Соколинский Борис
Объем зависит от длительности работы и состава логгируемых операций. От 100К до 10М.

байт(записей) в секунду сколько в пике?

Соколинский Борис
В этом случае теряется все преимущество БД по сравнению с текстовым файлом.

Не понял. Что теряется? Ничего не теряется. Просто у тебя должно быть ТРИ этапа.

1) Накопление данных
Данные складываются в БД как есть, без парсинга и преобразований. Задача этапа - сохранить данные максимально быстро и без потерь. Одноразово.

2) Предобработка, парсинг и формализация данных
Данные парсятся, параметры раскидываются по полям, а то и таблицам, конвертируются в необходимые типы, проводятся необходимые предобработки и предрасчёты. Одноразово, выполняется по завершении первого этапа.

3) Обработка и анализ
Получение необходимых результатов на основании обработанных данных. При необходимости - обращение к оригиналам. Сколько угодно раз.

Соколинский Борис
Меня беспокоит исключительно механизм передачи. Если программа упадет, намного больше шансов, что какая-то информация потеряется.

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

Соколинский Борис
у меня многопоточное приложение и логи пишутся отовсюду.

Тем более - кэширующий процесс, в фоне, когда время есть, сливающий логи на сервер, не будет лишним.
Сколько у тебя там суммарно логов в одном сеансе, ежели в гигабайтах мерить?