3、日志关联基础：日志采集架构（Fluentd/Loki）、日志标签与索引设计原则

在租户隔离的集群升级场景中，日志是关联 Prometheus 指标与异常样本的关键桥梁。本节将深入剖析以 Fluentd 为采集代理、Loki 为存储后端的日志采集架构，并讲解日志标签与索引的设计原则，确保在跨租户、跨集群的升级治理中实现高效的日志关联分析。

3.1 日志采集架构：Fluentd + Loki 管道

典型的日志采集管道分为三个核心阶段：采集（Agent）、传输（Buffer/Forwarder）、存储与查询（Backend）。Fluentd 作为轻量级数据采集器，负责从容器标准输出、文件或系统日志中读取数据，经过解析、过滤、标签注入后，通过 Loki 的 HTTP API 推送至对象存储。

3.2 日志标签与索引设计原则

Loki 的查询性能高度依赖标签设计。在租户隔离的升级治理中，标签不仅要满足快速检索，还要支持跨租户的隔离与聚合。以下是经过生产验证的设计原则：

3.3 Fluentd 配置示例：租户标签注入

以下配置展示了如何在 Fluentd 中为日志注入租户标签和升级上下文标签，并推送至 Loki：

<source>
  @type tail
  path /var/log/containers/*.log
  pos_file /var/log/fluentd-containers.log.pos
  tag kubernetes.*
  <parse>
    @type json
    time_key time
    time_format %Y-%m-%dT%H:%M:%S.%N%Z
  </parse>
</source>

<filter kubernetes.**>
  @type record_transformer
  <record>
    tenant_id ${record.dig("kubernetes", "labels", "tenant_id") || "unknown"}
    upgrade_batch ${record.dig("kubernetes", "labels", "upgrade_batch") || "none"}
    cluster_name ${ENV["CLUSTER_NAME"]}
  </record>
</filter>

<match kubernetes.**>
  @type loki
  url "http://loki-gateway.monitoring.svc:3100/loki/api/v1/push"
  <label>
    tenant_id
    upgrade_batch
    cluster_name
    container_name
  </label>
  <buffer>
    @type file
    path /var/log/fluentd-buffer
    flush_interval 5s
    chunk_limit_size 2MB
  </buffer>
</match>

3.4 索引设计：从标签到 LogQL 查询

合理的标签设计直接决定了 LogQL 查询的效率和准确性。在升级治理中，典型的关联查询模式如下：

• 按租户 + 升级批次过滤： {tenant_id="tenant-alpha", upgrade_batch="batch-3"} —— 秒级返回该批次所有日志。
• 按节点池 + 错误级别聚合： sum by (node_pool) (count_over_time({cluster_name="prod-cluster"} |= "error" [5m])) —— 快速定位异常节点池。
• 与 Prometheus 指标关联： 通过 upgrade_batch 标签关联 Prometheus 的 upgrade_duration_seconds 指标，实现日志与指标的交叉分析。

3.5 多租户隔离下的日志路由

Loki 支持基于 X-Scope-OrgID 头的多租户隔离。Fluentd 在推送日志时，需要根据租户标识动态设置该头。推荐两种实现方式：

1. Fluentd 配置中静态映射： 适用于租户数量固定且已知的场景，通过 tenant_id 标签直接映射。
2. Loki 代理层动态注入： 在 Fluentd 与 Loki 之间部署 Nginx 或 Envoy 代理，根据日志内容中的 tenant_id 字段动态设置 X-Scope-OrgID，实现租户路由的透明化。