Как сохранить последнее имя файла журнала в первом индексе (например, logtrail01.txt) с помощью библиотеки ведения журнала Boost V2 1.70?

Я представляю замену изначально написанной структуре ведения журнала моего приложения. Существующее ведение журнала записывается таким образом, чтобы генерировать файлы таким образом, что файл, в который записывается в данный момент, называется "logs.txt", а пролонгированные файлы называются < strong>"Logs.N.txt", где "Logs.1.txt" – последний после "logs.txt". Как добиться такого же поведения с помощью ведения журнала Boost V2?

Пытаюсь использовать ведение журнала Boost, потому что оно обеспечивает хорошую поддержку нескольких приемников, так как теперь мне нужно ориентировать свои журналы на 3 места: a) локальный файл журнала, b) драйвер стека в облаке и c) сервер системного журнала, размещенный в виде отдельного контейнера.

Причина, по которой я хочу, чтобы текущим файлом был "logs.txt", заключается в том, что, среди прочего, он позволяет просто tail -F logs.txt выполнять система.

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

auto strm = boost::log::add_file_log(
        boost::log::keywords::file_name = "Logs.%2N.txt",
        boost::log::keywords::open_mode = std::ios_base::app,
        boost::log::keywords::rotation_size = 5 * 1024, // Max filesize
        boost::log::keywords::auto_flush = true
    );

auto bkend = strm->locked_backend();                                                       
bkend->set_file_collector(boost::log::sinks::file::make_collector(                      
            boost::log::keywords::target = "./", // log file destination
            boost::log::keywords::max_size = 100 * 1024, //Max total size
            boost::log::keywords::min_free_space = 100000
            ));

bkend->scan_for_files(boost::log::sinks::file::scan_method::scan_matching, true);       

Поведение

Текущий шаблон генерации файлов:

Logs.01.txt     <--- Oldest file
Logs.02.txt
.
.
.
Logs.19.txt
Logs.20.txt     <--- File being written to

который по мере продолжения регистрации станет

Logs.41.txt     <--- Oldest file
Logs.42.txt
.
.
.
Logs.59.txt
Logs.60.txt     <--- File being written to

Индекс просто продолжает катиться (поэтому он выходит за рамки желаемого двухзначного индекса)

Logs.131.txt     <--- Oldest file
Logs.132.txt
.
.
.
Logs.149.txt
Logs.150.txt     <--- File being written to

Требуемый шаблон генерации файла:

logs.txt        <--- File being written to
Logs.01.txt     <--- Latest rolled over file
Logs.02.txt
.
.
.
Logs.12.txt
Logs.13.txt     <--- Oldest file

растет до

logs.txt        <--- File being written to
Logs.01.txt     <--- Latest rolled over file
Logs.02.txt
.
.
.
Logs.19.txt
Logs.20.txt     <--- Oldest file

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

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

Вопросы

  1. Существует ли конфигурация для серверной части ведения журнала файлов, которая может ее поддерживать?
  2. Если нет, как я могу настроить бэкэнд для этого?
  3. Кроме того, укажите мне любую документацию/руководство (кроме документации Boost.Log) по ведению журналов Boost, в котором рассказывается о структуре библиотеки и взаимодействиях на уровне классов, если известно.

person Ramakant    schedule 24.04.2019    source источник


Ответы (1)


Существует ли конфигурация для серверной части ведения журнала файлов, которая может ее поддерживать?

Нет, Boost.Log не поддерживает это. Основная причина заключается в том, что сохранение самого последнего файла журнала со значением счетчика, равным 0, требует N переименований файлов при каждой ротации, где N — количество ранее ротированных файлов. Помимо влияния на производительность, это увеличивает вероятность сбоя во время операций с файловой системой (например, в случае, если процесс открывает один из файлов во время ротации, что вызовет ошибку переименования в Windows).

Если нет, как я могу настроить бэкэнд для этого?

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

person Andrey Semashev    schedule 25.04.2019
comment
Спасибо. Есть ли какой-нибудь пример/учебник, на который вы могли бы мне указать, где это делается? Документация по повышению иногда бывает довольно загадочной. - person Ramakant; 26.04.2019
comment
У меня нет примера, но вы можете посмотреть исходники Boost.Log. Сборщик файлов реализован здесь: github.com/boostorg/log/ блоб/ - person Andrey Semashev; 27.04.2019
comment
Да, это трагедия этой версии библиотеки. Тем не менее, спасибо за ваш образец. Я все еще просматриваю его ... пытаясь понять, как решить мою проблему по линиям. Надеюсь, вы не будете возражать, если я достану вас вопросами по этому поводу, пока буду продолжать. :-) - person Ramakant; 01.05.2019