ELK 日志分析平台：Filebeat、Logstash、Elasticsearch 与 Kibana 实战

本文独立分析 ELK 日志平台，覆盖日志采集、解析、字段设计、索引生命周期、查询、告警、成本控制和常见故障。

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

单机部署时可以直接登录服务器查看日志，但当服务运行在多台主机、容器和多个集群中，人工登录无法快速关联请求、定位时间线和比较多个实例。

ELK 通常由 Elasticsearch、Logstash 和 Kibana 组成，实际采集侧经常使用 Filebeat 或其他 Agent。它把分散日志采集到统一平台，经过解析、脱敏和结构化后建立索引，再由 Kibana 进行查询、看板和告警。

二、日志平台的完整链路

text 复制代码

应用 / Nginx / 容器 -> Filebeat -> Logstash -> Elasticsearch -> Kibana

Filebeat 负责轻量采集和转发，Logstash 负责复杂解析、过滤、路由和脱敏，Elasticsearch 负责索引和检索，Kibana 负责查询、可视化和告警。

小规模环境可以减少中间层，但生产环境要根据吞吐、可靠性和处理复杂度决定是否引入 Logstash。

三、日志结构化设计

推荐输出 JSON 日志，而不是依赖复杂正则解析：

json 复制代码

{
  "@timestamp": "2026-10-20T10:00:00+08:00",
  "level": "ERROR",
  "service": "order-api",
  "env": "prod",
  "trace_id": "a81f2c7",
  "message": "payment timeout",
  "error_code": "PAYMENT_TIMEOUT"
}

核心字段通常包括时间、服务、环境、主机、容器、级别、Trace ID、请求路径、状态码、延迟和错误码。

不要把密码、Token、身份证号、银行卡号和完整 Cookie 写入日志。日志脱敏应尽量在应用输出或采集处理阶段完成。

四、Filebeat 采集配置示例

yaml 复制代码

filebeat.inputs:
  - type: filestream
    id: app-log
    paths:
      - /var/log/app/*.log
    parsers:
      - ndjson:
          target: ""
          overwrite_keys: true

output.logstash:
  hosts: ["logstash:5044"]

采集配置要考虑文件轮转、断点续传、权限、磁盘队列和网络中断。生产环境不应让 Agent 无限重试导致本地磁盘写满。

五、Logstash Pipeline

Logstash 可以执行解析、字段转换、过滤、脱敏和路由：

conf 复制代码

input {
  beats { port => 5044 }
}

filter {
  if [message] {
    json { source => "message" }
  }
  mutate {
    add_field => { "pipeline" => "app-log" }
  }
}

output {
  elasticsearch {
    hosts => ["https://elasticsearch:9200"]
    index => "app-%{[env]}-%{+YYYY.MM.dd}"
  }
}

解析失败时应保留原始字段并增加错误标记，不能静默丢弃日志。解析规则要有测试样例，避免日志格式变化后全量进入错误索引。

六、Elasticsearch 索引设计

索引设计影响查询性能和存储成本。需要考虑：

字段类型是否正确。
Text 和 Keyword 是否区分。
分片数量是否合理。
副本数量是否匹配可用性要求。
索引命名是否便于生命周期管理。
时间字段是否统一为 UTC 或明确时区。

日志通常按服务、环境和日期建立索引。不要为每个用户、请求或动态值创建索引，否则会产生索引数量爆炸。

七、索引生命周期与成本控制

日志数据应有保留策略，例如热数据保留 7 天，温数据保留 30 天，超过期限自动删除或转存对象存储。高价值审计日志和普通调试日志不应采用同样的保留时间。

成本控制方向：

降低无价值日志级别。
过滤重复健康检查日志。
统一字段并减少冗余内容。
使用生命周期策略自动迁移和删除。
限制查询时间范围。
监控磁盘水位、分片和查询耗时。

八、Kibana 查询与看板

看板建议按服务、环境和时间过滤，至少包含错误趋势、慢请求、状态码、主机、实例和 Trace ID。查询应优先使用结构化字段和精确过滤，避免长期执行全量通配查询。

典型排障流程：先按时间和服务定位错误，再按 Trace ID 关联入口日志、应用日志和依赖调用，最后查看发布记录和资源指标。

九、常见故障排查

1. 日志没有进入 Elasticsearch

逐层检查文件权限、Filebeat 状态、网络、Logstash 端口、解析错误、Elasticsearch 认证和索引写入权限。

2. 日志字段无法搜索

检查字段是否被解析为 Text、是否需要 Keyword、索引模板是否生效，以及 Kibana 数据视图是否刷新。

3. 日志时间不正确

统一应用、Agent、Logstash 和 Elasticsearch 的时间处理。不要只修改 Kibana 展示时区来掩盖源数据错误。

4. Elasticsearch 磁盘爆满

立即检查索引大小、分片、保留周期和异常日志量；必要时临时降低采集或删除可丢弃数据，但删除前要确认审计和合规要求。

5. 查询越来越慢

检查时间范围、字段类型、分片数量、节点资源、查询语句和高基数字段。避免在生产高峰执行大范围聚合。

6. 解析规则变更后日志丢失

查看 Logstash 错误标签和原始字段，先在测试数据上验证新规则，再灰度发布。解析失败不能直接丢弃原始日志。

十、日志安全与权限

日志平台拥有大量业务信息，应配置用户、角色、索引访问范围和审计。开发人员可以查询测试日志，不应默认读取全部生产日志和安全审计日志。

敏感字段应在应用、采集或处理层脱敏。已经写入 Elasticsearch 的敏感数据不能简单依靠 Kibana 隐藏，必要时要删除、重建索引并轮换相关凭据。

十一、与指标和链路追踪联动

日志本身适合记录具体事件，指标适合观察趋势，链路追踪适合跨服务关联。三者应共享服务名、环境、实例和 Trace ID，才能在看板上从错误率跳到日志，再从日志跳到具体请求链路。

十二、总结

ELK 的核心不是把所有文本集中起来，而是建立一套可检索、可关联、可保留、可删除、可审计的日志工程。采集要可靠，字段要结构化，敏感信息要脱敏，索引要有生命周期，查询要有边界，故障时还要能通过 Trace ID 还原请求链路。

CSDN 发布时先上传 elk-log-architecture.png，再替换图片路径。