设置自定义收集器时，boost::log 不尊重关键字::max_size 吗？

Question

我正在使用 Boost 1.61，我最终想要的是：

1. 如果当前日志文件的大小达到FILE_ROTATION_SIZE，则旋转当前日志文件
2. 使用自定义收集器处理旋转文件以进一步压缩（这是压缩旋转文件的正确方法吗？）
3. 如果文件的总大小达到FILES_MAX_SIZE，则删除一些最旧的（希望压缩的）文件

现在，无需任何收集器，我只需使用以下 sn-p 即可达到第 1 点和第 3 点

sink = logging::add_file_log(
      keywords::file_name = fileName,
      keywords::rotation_size = FILE_ROTATION_SIZE,
      keywords::scan_method = sinks::file::scan_method::scan_matching,
      keywords::target = logDir.native(),
      keywords::max_size = FILES_MAX_SIZE,
      keywords::format =
      (
         expr::stream
            << expr::format_date_time< boost::posix_time::ptime >("TimeStamp", "%Y-%m-%d %H:%M:%S.%f")
            << " " << expr::attr< boost::log::attributes::current_thread_id::value_type >("ThreadID") << " "
            << "<" << expr::attr< Logger::SeverityLevel >("Severity") << "> "
            << expr::message
            << expr::attr< std::wstring >("Suffix")
      ),
      keywords::auto_flush = true

   );

但是，当设置一个带有sink->locked_backend()->set_file_collector(_fileCollector); 继承自的收集器时

boost::log::sinks::file::collector 现在基本上什么都不做文件仍然继续旋转，但旧文件不会被删除。

收集器的外观如下：

class FileCollector : public boost::log::sinks::file::collector
{
   virtual void store_file(boost::filesystem::path const& src_path) override;

   virtual uintmax_t scan_for_files(boost::log::sinks::file::scan_method method,
                                       boost::filesystem::path const& pattern = boost::filesystem::path(),
                                       unsigned int* counter = 0) override;
};

void FileCollector::store_file(boost::filesystem::path const& src_path)
{
   LOG << "src_path: " << src_path;
}

uintmax_t FileCollector::scan_for_files(boost::log::sinks::file::scan_method method,
                                                boost::filesystem::path const& pattern,
                                                unsigned int* counter)
{
   return 1;
}

scan_for_files() 根本没有被调用。

从the answer to this question，我可以看到作者说max_size 是一个收集器参数，所以我认为应该有某种方式在我的FileCollector 类中设置它。调用sinks::file::make_collector() 而不是继承自定义收集器似乎不是一种选择，因为它无法提供所需的store_file() 回调，我打算在其中放置压缩逻辑。

这是否意味着我应该继续跟踪总大小并在需要时自行处理删除？

谢谢！

Answer 1

这是压缩旋转文件的正确方法吗？

是的，如果您必须在您的应用程序中执行此操作。请注意，除非您使用异步日志记录，否则日志文件轮换是同步完成的。这意味着在压缩日志文件时，应用程序中的一些随机日志语句将需要相当长的时间才能完成。

更好的解决方案可能是使用单独的服务，例如 logrotate，它将处理日志轮换和压缩，而不会影响您的应用程序性能。

这是否意味着我应该继续跟踪总大小并在需要时自行处理删除？

是的，文件收集器完全负责管理旋转文件。每当调用 store_file 时，您的文件收集器必须执行必要的步骤来压缩文件并将其存储在目标存储中，并可能删除任何旧文件。

target 和 max_size 等参数由 Boost.Log 中实现的文件收集器解释，该文件收集器由 sinks::file::make_collector 创建。如果您实现自己的收集器，则必须以自己的方式对其进行初始化 - 可能通过将这些参数传递给收集器构造函数。