🔗 新的日志记录功能

🔗 这是什么？

Squid 的日志记录功能不够

• 快 - stdio，与 Squid 在同一个执行线程
• 灵活 - 只能写入文件；无法通过网络、写入 MySQL 等。

其目标是为 Squid 枚举一个替代的日志记录机制，它将是快速且灵活的。

🔗 之前的尝试

• 我记得是一些废弃的 sourceforge 项目？通过 TCP 进行日志记录；消息被“丢失”，因此从未完成。
• s26_logfile sourceforge 分支 - Adrian 最初尝试将日志记录分离到外部进程；没有丢失消息，并显示出巨大的潜力，但未完成。

🔗 进行 s26_logfile 时学到的东西

• 日志需要在用户运行“squid -k rotate”时进行轮转；这意味着轮转命令必须与其余的日志消息数据保持同步。最初实现为信号，效果很好，但错过了那些在进程之间的内核套接字缓冲区中“传输中”的消息，或者仍然在 Squid 中缓冲等待发送到辅助进程的消息。
• 默认情况下，stdio 在某些情况下会逐个字符地读取 - 确保适当使用 setvbuf()，否则性能会很差（即，大量的单字节 read() 系统调用）。

🔗 新的日志文件应该做什么？

• 可以采用 varnish 风格实现 - 共享内存环形缓冲区 - 快速高效
• UNIX 流套接字 / 管道 / 回环 TCP：几乎在所有地方都可移植，语义清晰。需要小心构建消息，以便操作系统有机会通过 VM 技巧封装消息，而不是复制数据。确保这一点的方法是：让消息成为页面大小的固定倍数，并希望应用程序 malloc() 不要太快地回收这些页面。真烦人！
• 尽管如此，即使每秒 10,000 个请求，平均日志行长度为 160 个字符，数据复制量也只是每秒 1.52 MB；对于现代机器来说，这不算什么。
• 在第一阶段，它不应该试图枚举日志条目。只在 Squid 中格式化它们并通过行发送。如果它们是 TLV 编码的（这会使接收者的工作更容易，如果它想进行任何类型的处理 - 例如导入到 MySQL），那就更好了，但这可以是第二个版本。
• .. 对消息进行版本化。
• 对消息进行排序 - 这样，实现通过 UDP 传输数据的日志记录过程的人将拥有一个漂亮的、单调递增的序列号，他们可以使用该序列号，而无需手动处理数据包。
• 包含某些“控制”序列： - “立即轮转日志文件” - “立即将您拥有的数据刷新到磁盘” - “刷新并关闭” - 还有什么？
• s26_logfile 将单个日志行视为命令 - 命令就是一行，其中大部分将是日志行。最有效的方法是将日志行打包成一个大块，可以一次性写入磁盘或 UDP 套接字，但说实话，人们可能会喜欢每行单独枚举。

🔗 实现细节

• 使用 Squid 辅助框架来实现这一点是可以的。
• 但是您希望将大量数据排队写入，而不是逐行写入日志管道；这毫无意义。
• 稍微改变 Squid 的 logfile*() 例程语义；例如： - “行开始” - “追加数据” - “行结束” - 同样，这有点过度，但我认为当前代码假定它可以部分写入日志行，并在最后正确组装。真是的。
• 将日志框架分解为一个 API，可以由不同的实现提供，例如： - “同步日志” - 即，就像现在一样 - “syslog 日志” - 目前在各处通过 #ifdef 实现，但可能不应该如此 - “日志文件辅助程序” - 本文档讨论的内容

🔗 初始日志记录辅助程序？

• “请将此写入磁盘”
• 找一个志愿者来编写一个“将此写入磁盘 *并* 同时写入 MySQL”的程序。
• 再找一个志愿者编写一个“将此写入磁盘和/或 TCP 套接字”的程序。
• 获取 Wikipedia 的补丁，该补丁通过 UDP 进行日志记录，并将其整合到此框架中。
• 还有什么？

🔗 第二个版本？

• 对日志行进行 TLV 编码（这对于自定义日志文件格式应该很容易）。
• 共享内存环形缓冲区？
• 还有什么？

分类: WantedFeature

导航：站点搜索，站点页面，类别，🔼 向上