ELK 日志分析实战：从集中采集到可视化排障的完整体系

当服务器从几台变成几十上百台，排查问题时"ssh 到每台机器 tail 日志"就彻底不可行了。ELK（Elasticsearch + Logstash + Kibana）为代表的日志集中平台，把分散的日志汇聚成可检索、可可视化的统一视图。本文完整讲解从采集到分析的落地路径。

一、日志平台的三大组件

| 组件 | 角色 | 职责 | |------|------|------| | Beats（Filebeat） | 采集器 | 轻量收集日志并转发，几乎零资源占用 | | Elasticsearch | 存储与检索 | 索引日志、全文检索、聚合分析 | | Kibana | 可视化 | 搜索界面、Dashboard、告警 |

现代实践常把 Logstash 换成轻量消息管道（Kafka 缓冲 + 自研消费），但核心链路不变：采集 → 传输 → 索引 → 检索可视化。

二、采集端：Filebeat 配置

# filebeat.yml
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/app/*.log
    fields:
      service: api-server
      env: production

output.elasticsearch:
  hosts: ["es-node-1:9200", "es-node-2:9200"]
  index: "app-logs-%{+yyyy.MM.dd}"

采集的纪律：应用日志只写 stdout/stderr 或固定目录，容器环境用 Docker log driver 或 sidecar 采集，避免采集器与应用耦合。

三、结构化日志：检索能力的分水岭

纯文本日志只能"模糊搜"，结构化 JSON 日志才能"精确过滤"。这是整个体系的基石：

{
  "time": "2026-10-20T14:03:22.112+08:00",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc-123",
  "user_id": "u_88",
  "msg": "订单支付超时",
  "order_id": "o_9999",
  "duration_ms": 3120
}

// Go 结构化日志
slog.Error("订单支付超时",
    "trace_id", ctx.TraceID(),
    "user_id", req.UserID,
    "order_id", order.ID,
    "duration_ms", elapsed.Milliseconds(),
)

价值：level:ERROR AND service:order-service AND duration_ms > 3000 这类组合查询，让排障从"翻日志"变成"查索引"。

四、日志清理与索引生命周期

日志无限增长会撑爆磁盘。ES 的 ILM（Index Lifecycle Management）自动管理：

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot":    { "actions": { "rollover": { "max_size": "50gb", "max_age": "1d" } } },
      "delete": { "min_age": "30d", "actions": { "delete": {} } }
    }
  }
}

按天滚动索引 + 30 天删除，磁盘占用可控，检索性能稳定。

五、Kibana 排障工作流

5.1 全链路串联

结构化日志带上 trace_id 后，一次用户请求跨越的十几个服务日志，都能通过一个 trace_id 串起来：

搜索: trace_id: "abc-123"
结果: gateway 日志 → order 日志 → payment 日志 → 最终错误点

这是分布式排障效率提升最大的单点实践。

5.2 Dashboard 与告警

• Dashboard：错误率趋势、Top 慢日志、接口错误分布、按服务聚合；
• 告警（Elastic Alerting）：level:ERROR 在 5 分钟内超过 N 条触发通知。

六、常见问题与排查

| 问题 | 排查方向 | |------|----------| | 日志不出现 | Filebeat 是否识别新文件（close_inactive）、输出到哪个 index | | 字段无法过滤 | 确认 mapping 是否被动态映射为 text 而非 keyword | | 索引增长过快 | 检查日志级别是否误调为 DEBUG、是否重复采集 | | 检索超时 | 分片过多、查询通配符过重，收敛检索范围 | | 时区错乱 | Kibana 与 ES 时区设置、日志时间格式统一 UTC/ISO8601 |

七、落地路线图

1. 第一阶段：Filebeat 采集 + ES 存储 + Kibana 检索，先解决"日志找得到"；
2. 第二阶段：应用全面结构化改造（JSON + trace_id），解决"日志查得准"；
3. 第三阶段：接入告警与 Dashboard，把日志从"排障工具"升级为"质量门禁"。

结语

ELK 体系的本质是把运维经验沉淀为可检索的数据。采集端轻、存储端稳、检索端快、告警端响，这四端的配合让每一次故障都能在分钟级定位到根因。切忌一步到位追求复杂架构——先用最简链路跑起来，再逐步加结构化、告警与全链路追踪，日志平台的价值会随着数据质量的提升而复利增长。