日志过滤与检索：按级别过滤，按模块过滤，关键字检索

日志系统写好了，日志也刷刷地往外吐。但问题来了——日志太多，反而成了噪音。

我记得刚带第一个嵌入式项目时，系统一跑起来，终端里全是日志。有调试信息、有警告、有错误，还有各种模块的杂七杂八。我盯着屏幕看了半天，愣是没找到真正有用的那条错误日志。那时候我就意识到：日志系统不光要能写，还得能筛。

说白了，日志过滤与检索，就是帮你在海量信息里快速定位目标。今天咱们就聊聊这个。

为什么需要过滤与检索？

嵌入式系统里，日志量往往超出你的想象。一个跑着RTOS的设备，每秒可能产生几十条日志。如果全部打印出来，你根本看不过来。

我个人的习惯是：生产环境只保留ERROR和WARNING级别，调试时才打开INFO和DEBUG。但即便这样，一个模块的日志也可能刷屏。这时候就需要按模块过滤，或者按关键字检索。

你想想看，如果系统出了个bug，你只知道“大概在Wi-Fi模块里”，但日志里混着蓝牙、传感器、文件系统的信息。一条条翻？不现实。直接过滤出Wi-Fi模块的日志，再搜一下“timeout”关键字，问题可能就浮出水面了。

按级别过滤

级别过滤是最基础、最常用的。我一般把日志级别定义为：

typedef enum {
    LOG_LEVEL_NONE   = 0,
    LOG_LEVEL_ERROR  = 1,
    LOG_LEVEL_WARN   = 2,
    LOG_LEVEL_INFO   = 3,
    LOG_LEVEL_DEBUG  = 4,
    LOG_LEVEL_VERBOSE = 5
} log_level_t;

过滤时，只需要设置一个当前允许输出的最低级别。比如当前级别设为LOG_LEVEL_WARN，那么INFO和DEBUG级别的日志就不会输出。

代码实现很简单：

static log_level_t g_filter_level = LOG_LEVEL_DEBUG;

void log_set_filter_level(log_level_t level) {
    g_filter_level = level;
}

int log_should_output(log_level_t level) {
    return level <= g_filter_level;
}

这里有个小细节：级别数值越小，优先级越高。ERROR是1，VERBOSE是5。所以判断条件是 level <= g_filter_level。我见过有人搞反，结果ERROR被过滤掉了，调试时一脸懵。

按模块过滤

级别过滤能筛掉“不重要”的日志，但筛不掉“不相关”的日志。比如你只想看Wi-Fi模块的日志，但蓝牙模块的ERROR日志还是会输出。这时候就需要按模块过滤。

我习惯给每个模块分配一个ID：

typedef enum {
    MODULE_SYSTEM    = 0,
    MODULE_WIFI      = 1,
    MODULE_BLUETOOTH = 2,
    MODULE_SENSOR    = 3,
    MODULE_FILE      = 4,
    MODULE_NETWORK   = 5,
    MODULE_MAX
} module_id_t;

然后定义一个模块过滤掩码：

static uint32_t g_module_filter_mask = 0xFFFFFFFF; // 默认全部开启

void log_enable_module(module_id_t module) {
    g_module_filter_mask |= (1 << module);
}

void log_disable_module(module_id_t module) {
    g_module_filter_mask &= ~(1 << module);
}

int log_should_output_module(module_id_t module) {
    return (g_module_filter_mask & (1 << module)) != 0;
}

这样，你可以在运行时动态开启或关闭某个模块的日志。比如调试Wi-Fi时，只打开MODULE_WIFI，其他模块全部关掉。干净利落。

关键字检索

级别和模块过滤是“预过滤”，在日志输出前就决定要不要打印。关键字检索则是“后过滤”，在已经输出的日志里搜索特定内容。

关键字检索有两种实现方式：

1. 实时检索：在日志输出时，检查是否包含关键字，包含才打印。
2. 离线检索：先把日志存到缓冲区或文件里，然后用检索函数去查找。

实时检索适合调试场景，代码很简单：

static const char *g_keyword_filter = NULL;

void log_set_keyword_filter(const char *keyword) {
    g_keyword_filter = keyword;
}

int log_should_output_keyword(const char *message) {
    if (g_keyword_filter == NULL) {
        return 1; // 没有关键字过滤，全部输出
    }
    return strstr(message, g_keyword_filter) != NULL;
}

离线检索稍微复杂一点，但更实用。我一般会维护一个环形日志缓冲区，然后提供一个检索函数：

typedef struct {
    char     buffer[LOG_BUFFER_SIZE];
    uint32_t write_index;
    uint32_t read_index;
} log_buffer_t;

int log_search(log_buffer_t *buf, const char *keyword, 
               log_entry_t *results, int max_results) {
    int count = 0;
    // 遍历缓冲区，查找包含keyword的日志条目
    // 将匹配的条目存入results数组
    return count;
}

这个函数可以配合命令行或者调试工具使用。比如你在串口终端输入 search timeout，系统就会从日志缓冲区里找出所有包含“timeout”的日志，打印出来。

组合过滤：级别 + 模块 + 关键字

实际项目中，这三种过滤方式往往是组合使用的。我一般这样设计过滤逻辑：

int log_should_output(log_level_t level, module_id_t module, const char *message) {
    // 1. 级别过滤
    if (!log_should_output_level(level)) {
        return 0;
    }
    // 2. 模块过滤
    if (!log_should_output_module(module)) {
        return 0;
    }
    // 3. 关键字过滤
    if (!log_should_output_keyword(message)) {
        return 0;
    }
    return 1;
}

这个函数在每次日志输出前调用。三个条件都满足，才真正输出。这样你可以灵活组合：

• 只看Wi-Fi模块的ERROR日志
• 只看所有模块中包含“timeout”的WARNING日志
• 只看传感器模块的DEBUG日志，且包含“temperature”

嗯，就是这么灵活。

知识体系图

下面这张图总结了日志过滤与检索的核心逻辑：

实际项目中的避坑指南

聊了这么多实现，最后分享几个我踩过的坑：

• 别在中断里做关键字检索。 strstr 可能耗时较长，中断里调用会影响实时性。我一般只在任务级代码里做检索。
• 模块过滤掩码记得初始化。 默认应该是全部开启，而不是全部关闭。否则你调试时发现日志没了，排查半天才发现是掩码没设对。
• 关键字过滤不要用动态内存分配。 嵌入式环境里，malloc/free 容易产生碎片。我习惯用固定大小的数组存关键字，长度限制在64字节以内。
• 日志缓冲区要防溢出。 离线检索时，如果缓冲区满了，新日志会覆盖旧日志。我建议用环形缓冲区，并记录日志的时间戳，这样检索时能知道日志的新旧顺序。

我曾经在一个项目中，因为关键字过滤用了动态内存分配，结果系统运行几天后，日志功能突然失效了。查了半天，发现是内存碎片导致malloc失败。从那以后，我所有日志相关的内存都改用静态分配。

嗯，这些坑你提前知道，就能少走弯路。

日志过滤与检索，说白了就是给你的日志系统装上“瞄准镜”。级别过滤帮你排除杂音，模块过滤帮你锁定区域，关键字检索帮你精确命中目标。三者配合，调试效率能提升一个数量级。