日志记录器：生产环境诊断设计

# 日志器设计：生产环境中优先诊断与控制

在生产系统中，日志器的优劣不是看 API 速度，而是看它能在不增加额外负载的情况下，多快帮助诊断问题。日志记录会带来开销，因此正常运行时要尽量减少。但问题发生时，日志信息不足或杂乱无章，就会让排查变得不可能。一个优秀的日志器能在不牺牲性能的前提下，确保问题可诊断。

问题往往从日志结构开始：如果日志结构镜像代码结构，而不是业务流程。在多线程系统中，不同任务的消息会混杂在一起，难以追踪特定请求。

将上下文绑定到任务

解决方案是将日志与任务关联，而不是与调用点绑定。通过参数传递上下文会让函数签名变得臃肿。更好的方式是将其绑定到执行线程。

在 logme 中，通过线程通道实现这一点：

auto requestCh = Logme::Instance->CreateChannel(Logme::ID("req-42"));
LogmeThreadChannel(requestCh);
HandleRequest();

内部代码自动向通道记录日志：

void ParseHeaders() {
    LogmeW("invalid header");
}

日志现在按操作分组。在 spdlog 和 Quill 中，上下文围绕日志器，这更简单但不适合任务场景。

另一个问题是重复消息带来的噪音。重试错误会让日志充斥重复内容。事件级限频能解决这个问题：

LogmeW(LOGME_ONCE4THIS, "disk is full");

该消息在类实例中只出现一次，保持日志可读性。

灵活的消息路由

全局配置不够用。在 HTTP/2 中，需要分离连接日志和请求日志。请求通道链接到协议通道，但请求细节不应污染主日志。

Logme::Override ovr;
ovr.Add.DisableLink = true;
LogmeI(ovr, "request-specific detail");

这将消息隔离到本地通道。通用事件到处可见，私有事件仅本地可见。

子系统实现精准细节记录

单一维度（通道）不够用。任务有子系统：缓存、网络、解析等。选择性记录日志：

LOGME_SUBSYSTEM(cacheSid, "cache");
LOGME_SUBSYSTEM(parserSid, "parser");

LogmeD(cacheSid, "cache miss");
LogmeD(parserSid, "header parsed");

运行时，只启用需要的子系统，如缓存，其他保持静默，日志保持精简。

与库的集成

第三方库有自己的日志系统。我们拦截并集成：

void FfmpegLogCallback(void* ptr, int level, const char* fmt, va_list args) {
    char buffer[2048];
    vsnprintf(buffer, sizeof(buffer), fmt, args);

    Logme::Override ovr;
    ovr.Add.DisableLink = true;

    LogmeW(ovr, "[ffmpeg] %s", buffer);
}

消息遵循相同规则：通道、子系统、去重。

格式支持便于迁移：

LogmeI("value=%i", value);
fLogmeI("value={}", value);
LogmeI() << "value=" << value;

logme 融合 fmt 和流式风格，不像 spdlog（仅 fmt）和 Quill（异步 fmt）。

无需重启的生产控制

在常开系统中，日志正常时保持最小化。事件发生时：

• 怀疑缓存问题？启用缓存子系统。
• 通过通道隔离任务。
• 限制重复。

控制通过 logmectl 动态实现：级别、子系统，无需重启。

修复后，降低细节。否则，全局日志拉高会导致过载。

spdlog 强调速度，Quill 强调异步，logme 强调消息流控制，同时保持性能。

关键要点：

• 日志器应通过通道按任务分组，而非按日志器。
• 事件级去重减少噪音。
• 子系统支持运行时针对性细节记录。
• 库集成标准化输出。
• 生产环境需无需重启的动态控制。

— Editorial Team