我正在使用用 C++ 编写的实时系统。我们希望使用 boost 或 pantheios 进行日志记录。该系统有一些标准的日志记录要求，我相信任何一个框架都可以满足这些要求，但除此之外，我们还希望能够记录该系统捕获的所有输入。此输入将被多个线程捕获，包括一些具有实时约束并且无法承受低效日志记录的显着延迟的线程。这应该会导致要记录的数据的高吞吐量。
我主要想知道是否可以信任任何一个框架来管理来自多个线程的如此高吞吐量的日志记录，而不会延迟我的时间关键线程。此外，我们可能需要进行一些数据清理，这将需要添加某种钩子，该钩子能够识别具有安全数据的捕获输入，运行我们的数据清理钩子，并维护一个包含已清理值映射的缓冲区。
我相信这两个日志平台都可以做到这一点，但是快速浏览一下它们的 API 并不清楚。任何使用过这两种日志工具的人都可以给我一些反馈，说明它们在这种情况下的效率如何，实现我所描述的内容有多容易，或者他们在两个日志框架之间的偏好？真的任何信息都会有用。
谢谢
我已经完成了大型多线程情况的登录。我的经验是：
日志记录仅用于开发人员的利益。没有其他人会阅读或理解日志文件。
解耦日志消息的生成以及它们如何被记录。
如果您想让日志消息的生成更高效，请首先使用快速的上下文，检查是否有任何内容正在记录此上下文，如果没有则不生成。否则生成消息。（这种技术最常见的用途是“级别”，可以是“调试”“信息”等，如果没有任何内容记录到该级别，我们不会创建消息）。
每个用例都应该生成一个特殊的 ID，该 ID 保留在该用例中，并且从它记录的所有内容都将显示该用例 ID。
还要记录生成消息的线程 ID。
使用单独的线程进行日志记录，而不是生成消息的线程。（boost 的日志库就是这样做的）
谨防“宏疯狂”，尽管自动添加诸如FILE和LINE之类的轻量宏是可以的。
我正在使用 Jon Torjo 编写的 Boost 日志库，这个库提供了从专用线程对日志文件的所有写入，因此在执行日志记录的线程上没有 I/O 延迟。这样做的缺点是，当系统崩溃时，可能不会记录一些日志语句，因为它使用了内部队列。
但总的来说，这个库的表现非常好，为您提供了很多不同的选择，如果您愿意牺牲消息，我认为这对您来说可能是一个不错的选择。
如果这不是一个选项，您将不得不从需要记录的线程执行 I/O，这在实时系统上确实不理想。
如果您在 Windows 上运行，您知道它不是 RT 操作系统，对吗？
您不妨考虑http://www.logog.org。听起来您正在处理我在编写它时正在处理的许多相同问题。我最初是为记录多线程音频 DSP 引擎而编写的，这当然是时间关键渲染的本质。
另请参阅https://stackoverflow.com/questions/696321/best-logging-framework-for-native-c