📚 课程目录第4章标签规则基础

4. 标签规则基础：通配符匹配、精确匹配、多标签匹配策略

在 Fluent Bit 多租户日志路由体系中，标签（Tag）是数据流的核心标识符。每个日志记录从输入插件进入管道时都会被赋予一个标签，后续的过滤器（Filter）和输出（Output）插件依赖标签规则来决定如何处理和转发数据。掌握标签匹配规则，是构建灵活、可维护的多租户路由策略的前提。

4.1 标签的生成与结构

标签通常由输入插件自动生成或由用户显式指定。常见的标签格式如下：

输入插件	默认标签格式	示例
Tail	`tail.0` 或自定义	`tail.nginx.access`
Syslog	`syslog.<transport>`	`syslog.tcp`
Forward	由发送端携带	`tenant-a.app1`
HTTP	请求路径或自定义	`http.api.orders`

在多租户场景中，推荐使用层级标签（以点号分隔）来编码租户、应用和环境信息，例如：tenant-alpha.production.web、tenant-beta.staging.api。

4.2 三种核心匹配策略

Fluent Bit 的 tag 和 match 配置项支持三种匹配模式，每种模式适用于不同的路由粒度需求。

4.2.1 精确匹配（Exact Match）

精确匹配要求标签与配置字符串完全一致，不包含任何通配符。这是最高效的匹配方式，适用于已知固定标签的场景。

[OUTPUT]
    Name    elasticsearch
    Match   tenant-alpha.production.web
    Host    es-cluster-1.internal

上述配置仅匹配标签为 tenant-alpha.production.web 的日志，其他标签（如 tenant-alpha.production.api）不会被路由到此输出。

4.2.2 通配符匹配（Wildcard Match）

通配符 * 可以匹配零个或多个字符，但不能跨层级（即不能匹配点号）。这是最常用的多租户路由模式。

匹配模式	匹配示例	不匹配示例
`tenant-alpha.*`	`tenant-alpha.web`, `tenant-alpha.api`	`tenant-beta.web`
`.production.`	`web.production.nginx`	`web.staging.nginx`
`tenant-*`	`tenant-alpha`, `tenant-beta`	`tenant-alpha.web`（跨层级）

⚠️ 常见误区：通配符 * 不能跨越标签层级中的点号。例如模式 tenant-* 无法匹配 tenant-alpha.web，因为点号被视为层级分隔符。如需匹配多层级，应使用 tenant-*.* 或更具体的模式。

4.2.3 多标签匹配策略（Multi-Tag Match）

Fluent Bit 允许在 Match 配置中使用空格分隔的多个模式，实现“或”逻辑的匹配。这对于将多个不同来源的日志路由到同一个输出目标非常有用。

[OUTPUT]
    Name    s3
    Match   tenant-alpha.* tenant-beta.* tenant-gamma.*
    Bucket  my-company-logs
    Region  us-east-1

上述配置将三个租户的所有日志（无论应用层级）统一写入 S3 存储。多标签匹配策略在以下场景中尤为高效：

统一归档：将多个租户的冷数据写入同一低成本存储。
共享告警通道：将多个关键服务的错误日志发送到同一个告警系统。
集中审计：将不同租户的安全日志聚合到审计集群。

4.3 标签匹配优先级与路由决策流程

当一个日志记录进入管道时，Fluent Bit 会按以下顺序进行路由决策：

标签生成：输入插件为日志记录分配标签。
过滤器匹配：过滤器插件按配置顺序检查 Match 规则，匹配则处理。
输出匹配：输出插件按配置顺序检查 Match 规则，匹配则发送。
默认行为：若没有任何输出匹配，日志默认被丢弃（除非配置了 @INCLUDE 或 storage 持久化）。

  💡 最佳实践：在配置文件中，将精确匹配的输出放在前面，通配符匹配的输出放在后面，最后放置多标签匹配的兜底输出。这样可以减少不必要的匹配尝试，提升路由性能。

4.4 标签匹配策略对比

策略	语法	匹配粒度	性能	适用场景
精确匹配	`Match tenant-alpha.web`	单一标签	最高	特定服务、调试、关键链路
通配符匹配	`Match tenant-alpha.*`	标签前缀/后缀	高	租户级路由、环境隔离
多标签匹配	`Match a.* b.* c.*`	多个标签集合	中	聚合路由、统一输出

4.5 标签匹配流程图

下图展示了 Fluent Bit 内部标签匹配与路由决策的完整流程：

4.6 实战案例：多租户日志路由配置

假设我们有三个租户（Alpha、Beta、Gamma），每个租户有 Web 和 API 两个服务。我们希望实现以下路由策略：

Alpha 租户的所有日志发送到 Elasticsearch 集群 A。
Beta 和 Gamma 租户的 Web 服务日志发送到 Elasticsearch 集群 B。
所有租户的 API 服务日志发送到 S3 归档。

[INPUT]
    Name    tail
    Path    /var/log/tenant-alpha/*.log
    Tag     tenant-alpha.${filename}

[INPUT]
    Name    tail
    Path    /var/log/tenant-beta/*.log
    Tag     tenant-beta.${filename}

[INPUT]
    Name    tail
    Path    /var/log/tenant-gamma/*.log
    Tag     tenant-gamma.${filename}

# Alpha 租户全量路由
[OUTPUT]
    Name    elasticsearch
    Match   tenant-alpha.*
    Host    es-cluster-a.internal

# Beta 和 Gamma 的 Web 服务
[OUTPUT]
    Name    elasticsearch
    Match   tenant-beta.web tenant-gamma.web
    Host    es-cluster-b.internal

# 所有 API 服务归档
[OUTPUT]
    Name    s3
    Match   *.api
    Bucket  api-logs-archive
    Region  us-west-2

🔑 关键要点：

使用 ${filename} 变量动态生成标签，使标签与日志文件关联。
通配符 tenant-alpha.* 匹配该租户下所有服务，实现全量路由。
多标签匹配 tenant-beta.web tenant-gamma.web 将两个租户的 Web 日志聚合到同一输出。
模式 *.api 匹配所有租户的 API 服务，实现跨租户的集中归档。

4.7 标签匹配性能优化建议

优化方向	建议	原因
匹配顺序	精确匹配在前，通配符在后	减少通配符字符串比较次数
标签层级	控制标签层级不超过 4 层	过深的层级增加解析开销
通配符位置	优先使用后缀通配符（如 `tenant-*`）	前缀匹配比后缀匹配更快
多标签数量	单个 Match 中模式不超过 10 个	过多模式导致线性扫描性能下降