1. 课程导入与日志平台全景

在分布式系统里，日志是最廉价、最真实、也最容易被忽视的可观测数据。一次线上故障往往同时涉及网关、应用、数据库、缓存、消息队列和容器编排平台，如果每个组件的日志都散落在各自机器的 /var/log 或容器标准输出里，排障就变成了"逐台登录、逐条 grep"的体力活。Elastic 日志分析与集中运维平台要解决的核心问题，就是把分散的日志变成可检索、可聚合、可告警、可追溯的集中数据资产。

本课程围绕"采集—传输—存储—检索—可视化—告警—运维"这条主线展开，最终目标是让学员能够独立搭建并维护一套可用的日志平台。下面先建立全景认知，再明确学习路径与实战目标。

一、为什么需要集中式日志平台

传统排障方式有三个典型痛点。第一是定位慢：一个请求经过 6 个服务，报错只出现在其中一环，运维需要依次登录多台机器，用 grep 加时间范围过滤，平均定位时间可能超过 30 分钟。第二是无法关联：应用日志、Nginx 访问日志、MySQL 慢查询日志格式不同、时间基准不同，很难拼出一次完整调用链。第三是不可回溯：机器重启或日志轮转后，历史记录丢失，事后复盘缺少证据。

集中式日志平台把上述问题转化为工程问题：所有日志统一采集、统一传输、统一存储，用结构化字段描述来源与语义，再通过查询语言和可视化面板快速定位。以一次典型的"下单接口 500"为例，平台可以在几秒内返回：错误发生在 order-service 的 createOrder 方法，异常类型为 NullPointerException，同一 traceId 下上游网关返回 502，下游库存服务超时 3 秒。这种关联能力是单机 grep 无法提供的。

二、典型架构与数据流

Elastic 日志平台的经典架构由四层组成，数据自左向右流动，最终在 Kibana 呈现给使用者。下图展示了从日志产生到可视化告警的完整链路，以及各层的关键组件与职责。

理解这张图的关键在于：每一层都有明确的输入输出契约。数据源层输出的是原始文本行；采集传输层负责把非结构化文本解析为带字段的 JSON 文档，并保证不丢不重；存储检索层负责持久化与高效查询；可视化告警层负责把查询结果转化为人类可读的图表和可触发的通知。任何一层出问题，都会表现为"日志查不到"或"告警不准确"，因此后续章节会逐层拆解。

三、核心组件与职责边界

Filebeat 是轻量级采集器，部署在每台产生日志的机器上，负责读取文件、跟踪偏移量、做基础的多行合并，然后推送到下游。它的资源占用低，适合大规模铺开。Logstash 承担更重的解析与转换工作，通过 input/filter/output 三段式管道，用 Grok 正则把一行 Nginx 日志拆成 client_ip、method、status、request_time 等字段。Kafka 作为缓冲层，在日志峰值时削峰填谷，避免 Elasticsearch 被突发写入压垮。Elasticsearch 是存储与检索引擎，用倒排索引支撑全文搜索和聚合分析。Kibana 是交互入口，提供 Discover 检索、Dashboard 可视化、告警规则配置。

需要特别强调的是字段标准化。如果应用日志里时间字段叫 timestamp，Nginx 日志里叫 time_local，数据库日志里叫 ts，那么跨服务关联查询就会非常困难。实践中通常约定统一使用 @timestamp 作为事件时间，用 service.name 标识服务，用 trace.id 串联调用链。这个约定越早建立，后期维护成本越低。

四、学习路径与实战目标

本课程按"先跑通、再调优、后运维"的节奏推进。第一阶段完成单机环境搭建：安装 Elasticsearch、Kibana、Filebeat，采集一个 Spring Boot 应用的日志并在 Kibana 中检索到。第二阶段引入 Logstash 做结构化解析，配置索引模板和 ILM 策略，让日志按天滚动、到期自动删除。第三阶段接入 Kafka 缓冲，配置告警规则，实现"错误日志 5 分钟内超过 10 条即通知"。第四阶段做性能调优与故障排查，包括分片规划、JVM 堆内存调整、慢查询分析。

实战目标可以量化为四条：能独立部署一套三节点 Elasticsearch 集群；能把至少三种来源的日志采集并结构化入库；能写出按服务、按状态码、按耗时区间的聚合查询；能配置一条有效的错误告警规则并验证通知到达。达成这四条，就具备了集中运维平台的基本开发与维护能力。

接下来从环境搭建开始，先让第一条日志出现在 Kibana 的 Discover 页面里。只要这条链路跑通，后面的解析、聚合、告警都是在这条链路上逐步增强。