为速度关键系统设计跟踪/日志答案

【问题标题】：Design traces/logs for speed critical system为速度关键系统设计跟踪/日志
【发布时间】：2013-03-08 02:03:31
【问题描述】：

假设我们有对速度至关重要的系统（例如统计/分析、套接字编程等），我们如何设计跟踪和日志。

更具体地说，日志和跟踪通常会降低性能（即使我们有关闭机制或冗长的扩展机制）。在这种情况下，是否有任何关于如何“放置”日志/跟踪的参考指南，以便在问题发生时（特别是在生产站点）开发人员/后期制作团队能够查明实际问题。

PS：我来自使用 C/C++（在 Linux 上运行）开发此类应用程序的背景

【问题讨论】：

如果你能承受丢失一些条目，我猜是异步日志；或者像 lmax 的破坏者，如果你绝对需要一致性
如果您的意思是使用另一个线程进行日志记录，我知道该过程。然而，有时，即使这些也会成为拖累。想知道是否有任何其他“更好”的机制来处理日志记录/跟踪。
您是否正在寻找一种在没有任何记录的情况下增加尽可能少开销的系统？或者您是否正在寻找一种方法来最大限度地减少实际写入日志的开销？如果是后者，消息是否倾向于聚集在一起，中间有很长的间隙，还是存在更严重的总吞吐量问题？
让我反过来说。我已经在生产环境中拥有支持 X 速度的系统（没有模块间跟踪、日志）。现在我正试图找到一种方法来添加日志（整个系统）和跟踪，并试图最大限度地减少 X 的退化。

标签： c++ design-patterns logging architecture

【解决方案1】：

您可以在缓冲区中累积日志，您可以使用Google Protocol Buffers 来描述和实施该缓冲区。您可以让不同的线程定期（每 5 分钟）将此缓冲区清空到磁盘，或通过UNIX domain socket（或其他Linux IPC mechanisms）将其发送到一个守护进程，该守护进程侦听并将它们写入持久数据库或简单地将它们写入磁盘。

如果您不想访问产生日志的机器上的磁盘，您可以通过regular socket 将它们发送到另一台机器并将它们写入该机器上的磁盘。

如果您要聚合来自多台机器的日志，请考虑使用0MQ 或CrossRoads 作为消息队列，通过网络将您的日志传递到永久存储它们的机器。你可以找到一些关于using 0MQ in conjuction with Google Protocol Buffers here的信息。

【讨论】：