На чём написать логгер

а чобы не просто в файл, где 1 строка — 1 сообщение?

sqlite подойдёт вполне. в принципе, тут любая БД подойдёт, какая тебе больше нравится.

echo «msg» >>ylogfile

journald

elastic+logstash+grafana?

Подойдёт ли sqlite?

Да. только не забудь добавить поля с датой/временем и пр., если они могут понадобится для запросов.

подойдет. Можеь использовать еще hdf5

долго обрабатывать. статистика должна формировать достаточно быстро: она важна не только для пользователя, на её основе также работает программа.

На чём написать логгер (комментарий)

Да, так и думал: номер запуска программы, номер операции, дата и время, сообщение, или как-то так.

Огонь!

syslog + прием в syslog-ng, который дальше может классифицировать сообщения, видоизменять их, писать в SQL и NoSQL базы, в общем что душе угодно

Хорошо, спасибо!

Спасибо!

Спасибо!

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

Все таки в текстовых файлах удобней.

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

Да уж, “удобней” некуда. Чем запись в sqlite-базу сложнее, чем это?

C#

Ты ТСа ни с кем не перепутал? :)

нет, у меня настроение плохое просто. Невлезай тут не причём

Подойдёт ли sqlite?

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

Возможно, это не твой случай, но почитай про graphite.

Нужно будет думать как чистить старые данные и тут sqlite со временем фрагментируется и может устроить пц.

https://sqlite.org/lang_vacuum.html

Да и не та задача у ТС, чтоб получить подобные проблемы. SQLite вполне себе справляется как основное хранилище данных для десятков гигов разномастных данных, а тут просто логи.

к примеру удобней читать, что можно без тулзы просто открыть tail и смотреть что в лог попадает

Чем запись в sqlite-базу сложнее, чем это?

абсолютно ничем. Поэтому я и предложил

Рекомендую предусмотреть разные источники хранения и далее уже выбирать для удобства

а зачем это делать на c ? есть же много готовых инструментов: pandas под python например

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

а зачем это делать на c ? есть же много готовых инструментов: pandas под python например

Предлагаешь прикручивать питон, что писать логи из сишной программы?

нет чтобы их анализировать

нет чтобы их анализировать

У ТС другая задача.

Спасибо! Тема по ссылке оказалась очень познавательна.

Думаю, начну всё же с текстовых файлов. Спасибо!

Если хочешь именно на основе какой-либо БД да еще с индексами, то подойдет все что угодно. Хоть люценовский поисковый двиг, или уже готовые обертки а-ля эластика или сфинкса как тут уже советовали выше. Но нужно отличать логгер от собственно средств обработки. Я бы пихал все в стандартные логи, а парсил это уже отдельно в нужный формат для отчетов/статистики/etc. Уже там бы и работал кэш и все прочее, но за собственно хранение самих «черновых» мессаг в логах не парился бы.

Не то, но штука интересная

Ну и как, сам то читал что там написано? Компактизация БД очень дорогая операция и на время её работы с базой ничего делать нельзя. Кроме этого рСУБД c ACID доставляет и другие проблемы, можешь посмотреть тут сколько fsync() минимум уйдёт на одну запись лога и к чему смело можно накинуть несколько IOPSов на поддержку индекса без которого нельзя будет делать выборки в хронологическом порядке. Итого, получается около 50-80 записей в лог в секунду.

Это всё против обычного добавления данных в конец файла которое с буферизацией даст эффективный RPS ближе к 1M в условиях топикстартера.

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

Да и не та задача у ТС, чтоб получить подобные проблемы.

Менее 100 записей в лог в секунду это вообще ничто для любого приложения, какой-нибудь простенький hellow world для отладки может херачить в разы больше и на таком RPS будет тормозить.

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

Как формат записи в плоский файл разноформатных табличек с возможностью редактирования несоменно sqlite справляется. Но СУБД нужно то справляться не только с этой, вторичной, задачей.