Здравствуйте, Sheridan, Вы писали:

AG>Мне нужено логирование — по дням, когда каждому дню будет соответствовать свой лог-файл.

S>Это умеет journald делать прямо из твоего stderr/stdout. Ну, точнее journalctl можно попросить вывести логи твоего приложения начиная с такойто датывремени и заканчивая этаким.

Спасибо, уважаемый Sheridan, буду в курсе!

S>Если тебе нужен именно файл, то опять неправильный подход. Просто пиши в файл.

И вот тут вот начинается самое интересное:
a) Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм,
позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
b) Переход на следующие сутки (и время переоткрытия суточного лога).
с) Возможность ведения одним процессом более чем одного файла лога (для больших проектов — это актуально).
d) Если в файл одновременно пишет несколько потоков исполнения, то поторебуется защитить вывод мьютексом.
e) Возможность асинхронного формирования лога — когда поток, запросивший логирование не ждёт окончания записи лог-файла.
Да, я (несколько лет назад) сделал свой велосипед, позволяющий вести многоптоточное логирование по нескольким категориям.
Но тем не менее, поизучав spdlog, пришёл к выводу — что эта библиотека намного удобнее и проработанее моего лога.

S>А на файл натравливается logrotate, который по куче параметров умеет то что ты хочешь — файлы по дням/размеру/архивированное старое и так далее.
Ну то, что я хочу, можно выяснить простым текстовым редактором

S>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
+100500
Я в курсе понятия UNIX-way.
Однако, я не сторонник догм

Здравствуйте, Sheridan, Вы писали:

AG>Мне нужено логирование — по дням, когда каждому дню будет соответствовать свой лог-файл.

S>Это умеет journald делать прямо из твоего stderr/stdout. Ну, точнее journalctl можно попросить вывести логи твоего приложения начиная с такойто датывремени и заканчивая этаким.

Спасибо, уважаемый Sheridan, буду в курсе!

S>Если тебе нужен именно файл, то опять неправильный подход. Просто пиши в файл.

И вот тут вот начинается самое интересное:
a) Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм,
позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
b) Переход на следующие сутки (и время переоткрытия суточного лога) — как уже упоминалось, каждые сутки — свой файл.
с) Возможность ведения одним процессом более чем одного файла лога (для больших проектов — это актуально).
d) Если в файл одновременно пишет несколько потоков исполнения, то поторебуется защитить вывод мьютексом.
e) Возможность асинхронного формирования лога — когда поток, запросивший логирование не ждёт окончания записи лог-файла.
Да, я (несколько лет назад) сделал свой велосипед, позволяющий вести многоптоточное логирование по нескольким категориям.
Но тем не менее, поизучав spdlog, пришёл к выводу — что эта библиотека намного удобнее и проработанее моего "лога".

S>А на файл натравливается logrotate, который по куче параметров умеет то что ты хочешь — файлы по дням/размеру/архивированное старое и так далее.
Ну то, что я хочу, можно выяснить простым текстовым редактором

S>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
+100500
Я в курсе понятия UNIX-way.
Однако, я не сторонник догм