📚 课程目录第3章日志系统架构

3、日志系统架构：集中式日志采集（Filebeat/Fluentd）、日志存储（Elasticsearch）、日志查询（Kibana）

在 Trace ID 联动变更门禁与回滚判断的场景中，日志系统是整个可观测性数据流的“骨架”。只有将分布式系统中散落的日志高效采集、可靠存储并快速查询，才能实现 Trace ID 的端到端串联。本章聚焦经典的 ELK/EFK 架构，剖析其核心组件与协作流程。

3.1 架构总览：三层职责分离

集中式日志系统通常划分为采集层、缓冲/存储层与查询分析层。每一层承担独立职责，并通过标准协议（如 HTTP、gRPC）或消息队列进行数据交换。

  核心原则：采集层无状态、存储层高可用、查询层低延迟。Trace ID 作为贯穿三层的唯一关联键。

3.2 采集层：Filebeat 与 Fluentd 对比

采集层负责从应用服务器、容器或云环境中读取日志文件或流式数据，并将其转发到存储层。Filebeat 和 Fluentd 是两种主流选择，它们在资源占用、插件生态与数据处理能力上存在差异。

特性	Filebeat	Fluentd
开发语言	Go	Ruby (核心) / C (插件)
资源占用	极低（约 10-20 MB 内存）	中等（约 50-100 MB 内存）
数据处理	轻量级过滤（如多行合并）	强大的 filter 与 transform 插件
输出目标	Elasticsearch、Logstash、Kafka	Elasticsearch、S3、MongoDB、Kafka 等 500+ 插件
配置复杂度	低（YAML 配置）	中（config 语法 + 插件管理）
适用场景	纯日志采集、与 ES 深度集成	复杂数据管道、多目标路由

选型建议：如果团队以 Elastic Stack 为核心，且日志格式相对统一，优先选择 Filebeat。如果需要对日志进行复杂的解析、过滤或路由到多个下游系统，Fluentd 的插件生态更具优势。

3.3 存储层：Elasticsearch 核心机制

Elasticsearch 作为分布式搜索与分析引擎，是日志存储的基石。它通过倒排索引实现全文搜索，通过分片（Shard）与副本（Replica）实现水平扩展与高可用。

3.3.1 索引与分片策略

索引（Index）：日志数据的逻辑容器，通常按时间（如 logs-2025-04）或业务模块命名。
分片（Primary Shard）：每个索引被拆分为多个分片，分布在集群的不同节点上，实现并行读写。
副本（Replica Shard）：每个主分片的冗余拷贝，用于故障转移与提升查询吞吐量。

# 创建日志索引示例（含分片与副本设置）
PUT /logs-trace-2025-04
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" },
      "trace_id": { "type": "keyword" },
      "service_name": { "type": "keyword" },
      "log_level": { "type": "keyword" },
      "message": { "type": "text" }
    }
  }
}

3.3.2 数据写入与查询流程

写入：采集层将日志发送到 ES 节点，节点根据 _id 或路由字段将文档路由到对应主分片，主分片写入后同步到副本分片。
查询：Kibana 或 API 发起搜索请求，协调节点将请求广播到所有相关分片，各分片返回匹配结果后合并返回。
聚合：支持 Terms、Date Histogram 等聚合操作，用于 Trace ID 分布、错误率统计等可观测性指标。

3.4 查询层：Kibana 可视化与 Trace ID 搜索

Kibana 提供基于 Web 的日志查询与可视化界面。在 Trace ID 联动场景中，Kibana 的 Discover 模块是快速定位日志的核心入口。

KQL 查询：使用 Kibana Query Language 直接搜索 trace_id: "abc123"，即可过滤出该 Trace 的所有日志。
仪表盘（Dashboard）：将多个可视化图表（如错误率趋势、服务调用拓扑）组合，用于变更门禁的实时监控。
时间范围选择：支持相对时间（如最近 15 分钟）与时间范围，便于回滚判断时回溯历史日志。

注意：Kibana 的查询性能依赖于 Elasticsearch 的索引设计。如果 trace_id 字段未设置为 keyword 类型，或索引分片数不合理，可能导致查询延迟过高，影响门禁判断的实时性。

3.5 数据流全景：从日志产生到 Trace ID 检索

下图展示了日志从应用实例产生，经过采集、缓冲、存储，最终在 Kibana 中通过 Trace ID 检索的完整数据流。

3.6 本章小结

集中式日志系统通过采集、存储、查询三层架构，为 Trace ID 联动提供了数据基础。Filebeat 与 Fluentd 各有侧重，Elasticsearch 的分片与索引设计直接影响查询性能，Kibana 则是 Trace ID 检索与可视化的前端工具。理解这三层的协作关系，是后续实现变更门禁与回滚判断的前提。