Здравствуйте, AlexGin, Вы писали:
AG>Мне нужено логирование — по дням, когда каждому дню будет соответствовать свой лог-файл.
Это умеет journald делать прямо из твоего stderr/stdout. Ну, точнее journalctl можно попросить вывести логи твоего приложения начиная с такойто датывремени и заканчивая этаким.
Если тебе нужен именно файл, то опять неправильный подход. Просто пиши в файл. А на файл натравливается logrotate, который по куче параметров умеет то что ты хочешь — файлы по дням/размеру/архивированное старое и так далее.
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.
Однако, я не сторонник догм
S>>Если тебе нужен именно файл, то опять неправильный подход. Просто пиши в файл. AG> AG>И вот тут вот начинается самое интересное: AG>a) Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм, AG>позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
Реализуется за час гдето вместе с тестами.
AG>b) Переход на следующие сутки (и время переоткрытия суточного лога) — как уже упоминалось, каждые сутки — свой файл.
Это проблема logrotate, а не твоя. Ты зря потратил время.
AG>с) Возможность ведения одним процессом более чем одного файла лога (для больших проектов — это актуально).
Допустим что это нужно, чтото типа сайтов у nginx и про каждый сайт пишет лог в отдельный файл. Не вижу проблем. Просто когда открываем файл для дописывания — генерируем имя файла динамически.
AG>d) Если в файл одновременно пишет несколько потоков исполнения, то поторебуется защитить вывод мьютексом.
Достаточно дописывать и закрывать. И ждать пока открыт для записи.
AG>e) Возможность асинхронного формирования лога — когда поток, запросивший логирование не ждёт окончания записи лог-файла.
Оформи логгер в виде отдельного потока
AG>Да, я (несколько лет назад) сделал свой велосипед, позволяющий вести многоптоточное логирование по нескольким категориям. AG>Но тем не менее, поизучав spdlog, пришёл к выводу — что эта библиотека намного удобнее и проработанее моего "лога".
Да магистры с тобой, я не против. Просто лично я не вижу смысла в ручной ротации логов.
S>>А на файл натравливается logrotate, который по куче параметров умеет то что ты хочешь — файлы по дням/размеру/архивированное старое и так далее. AG>Ну то, что я хочу, можно выяснить простым текстовым редактором
Ты распарсил о чом я тут написал или ты решил что я про поиск чегототам?
S>>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ. AG>+100500 AG>Я в курсе понятия UNIX-way. AG>Однако, я не сторонник догм
Есть ещо примерно полтора землекопа таких. Жутко неудобно с их логами работать. Приходится извращаться.
Ну, например, мне надо чтобы логи ротировались не каждый день, а если превышают 128 мегабайт. И отротейченое чтобы сжималось. А автору было срать на эти хотелки и у него логи сами ротейтятся каждые сутки, не сжимается и размером каждый файл — сотни мегабайт. Приходится извращаться.
Здравствуйте, уважаемый Sheridan, Вы писали:
S>Реализуется за час гдето вместе с тестами.
Так никто и не спорит. Вопрос — зачем велосипедить?
S>Это проблема logrotate, а не твоя. Ты зря потратил время.
Я не тратил время и не изобретал велосипед. Я просто я взял это: https://github.com/gabime/spdlog
теперь просто творю и радуюсь моему выбору.
Насчет многопоточности — дискутировать не буду.
Делай, как считаешь нужным, но на всякий случай — приготовься к сюрпризам (для реализации без мьютексов).
S>Да магистры с тобой, я не против. Просто лично я не вижу смысла в ручной ротации логов.
+100500
Я также не вижу, когда для этого есть удобная библиотека (подключаемая в виде заголовочника).
S>Ты распарсил о чом я тут написал или ты решил что я про поиск чегототам?
Хорошо, этот самый spdlog умеет и syslog поддерживать. При этом, кроме настроек логгера, ничего не надо менять.
S>Ну, например, мне надо чтобы логи ротировались не каждый день, а если превышают 128 мегабайт.
И это также умеет spdlog, но для наших проектов ежедневный лог (как правило) много меньше 128 мегабайт.
S>И отротейченое чтобы сжималось. А автору было срать на эти хотелки и у него логи сами ротейтятся каждые сутки, не сжимается и размером каждый файл — сотни мегабайт. Приходится извращаться.
Ну так ведь spdlog позволяет гибко выбрать политику логирования.
Если сисадминам на стороне Заказчика не нравиться посуточная, то можно выбрать что-то более подходящее.
При этом — в кодах меняется одна строчка. Исключаются большие и долгие изменения.
P.S. Признаюсь, что именно вследствии заботы о конечных потребителях и их сисадминах я и перешел на spdlog.
Ранее сушествовавшая самоделка — не позволила бы учесть всё это.
Ну а так — я просто с удовлетворением констатирую тот факт что,
при помощи этой библиотеки сумею закрыть запросы требовательного Заказчика!
Здравствуйте, AlexGin, Вы писали:
AG>При этом — в кодах меняется одна строчка. Исключаются большие и долгие изменения.
Где-где меняется?
Ещо раз: лучший лог — в консоль или в один файл. Не беги впереди паравоза, не придумывай как облегчить жизнь админу. Как правило это заканчивается лишь усложнением жизни админу.
Здравствуйте, AleksandrN, Вы писали:
... AN>Есть функция daemon().
Спасибо за рекомендацию, но как раз с "демоном" — как войти в этот режим — проблем у меня не возникало.
Конфликт библиотеки логирования (это spdlog) в приложении типа "демон" — да, имеет место.
Остановился на том, что имеющаяся в OS Linux система запуска приложений systemd —
избавляет моё сервисное приложение от необходимости перехода в режим "демон" (просто оно в режиме "консоли").
В общем — теперь делаем простое CLI приложение и не паримся
Здравствуйте, Reset, Вы писали:
R>Ну, т.е. исключения бывают из любого правила, но я практик и для меня сейчас двойной форк выглядит, как задротство старперов из академической сферы, которые не способны адаптироваться к реальности. Gentoo без systemd или какой-нибудь Devuan — задротство в чистом виде. Впрочем, расскажешь реальный пример нужности двойного форка — сменю мнение (я гибкий).
В каком-нибудь роутере может быть очень мало памяти/места на флешке, и тогда там может быть не systemd, а что-нибудь более архаичное (и компактное). Вплоть до того, что /sbin/init может оказаться шеловским скриптом, который только и делает, что запускает пару сервисов.
Потом, стоило бы уточнить, что сейчас в мире FreeBSD творится.
Но конечно, если твоя программа не попадет в роутеры и FreeBSD, об этом можно и не беспокоиться.
Здравствуйте, Sheridan, Вы писали:
S>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Sheridan, Вы писали:
S>>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
Pzz>Скажи это авторам systemd
Ну в состав systemd входит десятки утилит,
каждая из которых решает довольно небольшую задачу, поэтому претензия к sysytemd непонятна.
Здравствуйте, Zhendos, Вы писали:
Z>Ну в состав systemd входит десятки утилит, Z>каждая из которых решает довольно небольшую задачу, поэтому претензия к sysytemd непонятна.
systemd — это аццкий монолитный кусок г-на. Разбит он при этом на несколько процессов или нет, не имеет значения. Друг от друга независимо они все равно не работают.
С внедрением systemd процесс инициализации системы стал абсолютно непрозрачным, и отлаживать возникающие на этом этапе неисправности стало на два порядка тяжелее.
UNIX way — это когда несколько независимых, полезных по-отдельности, програм можно объединить вместе, и получить из них нечто бОльшее.
Здравствуйте, AlexGin, Вы писали:
AG>И вот тут вот начинается самое интересное: AG>a) Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм, AG>позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
Ты подумай лучше, для начала, кому ты пишешь эти логи. Кто их будет читать? Кто их целевая аудитория?
Потому что если ты пишешь их админу системы, который будет устанавливать и использовать твою программу, то писать надо в терминах, понятных ему, и внутренных подробностей жизни твоей программы не вываливать.
А если ты их пишешь себе, с целью отладки по е-мейл, то во-первых, они должны быть достаточно детальные, чтобы тебе было сразу понятно, чем занималась твоя программа, а во-вторых, в них должно быть удобно ориентироваться. Потому что искать 5 важных строчек по 10-мегабайтному логу может быть нелегко, а если тебе таких дюжину в день набросают, то жизни твоей не позавидуешь.
А потом уже, определившись с целью этого логирования, надо определяться с потребными для ее достижения средствами.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Zhendos, Вы писали:
Z>>Ну в состав systemd входит десятки утилит, Z>>каждая из которых решает довольно небольшую задачу, поэтому претензия к sysytemd непонятна.
Pzz>systemd — это аццкий монолитный кусок г-на. Разбит он при этом на несколько процессов или нет, не имеет значения. Друг от друга независимо они все равно не работают.
Это же отдельные процессы, что сложного запустить каждый по отдельности? Ну нужно будет какой-нибудь
файлы, сокеты и т.д., ничего сложного. И дистрибутивы которые не используют systemd это вполне доказывают,
пакуя некоторые программы из systemd в отдельные пакеты, а заменяя некоторые утилиты на их аналоги.
Pzz>С внедрением systemd процесс инициализации системы стал абсолютно непрозрачным, и отлаживать возникающие на этом этапе неисправности стало на два порядка тяжелее.
По мне так проще. Например раньше часть процесса старта системы не записывалась,
так как система журналирования еще не стартовала, теперь записывается все.
Pzz>UNIX way — это когда несколько независимых, полезных по-отдельности, програм можно объединить вместе, и получить из них нечто бОльшее.
Ну например udev из состава systemd вполне полезна отдельно из systemd,
и используется в системах не основанных на systemd довольно часто.
Здравствуйте, Pzz, Вы писали:
S>>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
Pzz>Скажи это авторам systemd
Нука расскажи мне, да.
Только теперь заметил новое шевеление в данной теме
Думал, что уже здесь обсудили всё — что можно и нельзя.
Pzz>Здравствуйте, AlexGin, Вы писали:
AG>Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм, AG>позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
Pzz>Ты подумай лучше, для начала, кому ты пишешь эти логи. Кто их будет читать? Кто их целевая аудитория?
Для начала — разрабы (я и моя команда).
Pzz>Потому что если ты пишешь их админу системы, который будет устанавливать и использовать твою программу, то писать надо в терминах, понятных ему, и внутренных подробностей жизни твоей программы не вываливать.
Да, поиск по тексту — выручит отца русской демократии
Pzz>А если ты их пишешь себе, с целью отладки по е-мейл, то во-первых, они должны быть достаточно детальные,
+100500
Это проработано. Логи вполне себе детализированные.
Но суть применения данного сервиса — скорее локальная автоматизация.
На объекте может и не быть соединения с интернет (скорее интранет),
так что отправка по e-mail — не актуальна.
Pzz>чтобы тебе было сразу понятно, чем занималась твоя программа, а во-вторых, в них должно быть удобно ориентироваться. Потому что искать 5 важных строчек по 10-мегабайтному логу может быть нелегко, а если тебе таких дюжину в день набросают, то жизни твоей не позавидуешь.
Ну 10 мегабайтным он точно не будет.
А в одномегабайтном (это если он ооооочччень сильно разрастётся) — искать уже легче.
Pzz>А потом уже, определившись с целью этого логирования, надо определяться с потребными для ее достижения средствами.
+100500
Посему я и выбрал spdlog — что там можно достаточно просто настраивать уровни логирования.
Здравствуйте, Pzz, Вы писали:
... Pzz>В каком-нибудь роутере может быть очень мало...
Приложение (сервис) пишу НЕ для роутера.
Pzz>Но конечно, если твоя программа не попадет в роутеры и FreeBSD, об этом можно и не беспокоиться.
+100500
Я именно об этом и писал.
