Elastic Stack 由 Elasticsearch、Kibana 和采集/处理组件组成。现代新部署通常优先使用 Elastic Agent 与 Integrations,Logstash 适合复杂解析、富化和多路输出。
## 数据链路
应用/主机日志 → Elastic Agent 或 Logstash → Elasticsearch data stream/index → Kibana Discover、Dashboard 与 Alert。
先定义日志字段和生命周期,再安装软件。至少统一 timestamp、service.name、environment、host、log.level、trace.id 和 message,避免每个团队创建不可查询的字段。
## 部署要点
同一 Stack 组件使用兼容版本。自建环境先部署 Elasticsearch,再 Kibana、Logstash、Elastic Agent/APM。生产 Elasticsearch 需要多节点、独立 master eligible 规划、磁盘水位、快照仓库、TLS、认证和容量模型。
不要关闭安全功能来解决连接问题。使用 CA 证书、Service Token/API Key 和最小权限。
## Logstash Pipeline
```ruby
input { beats { port => 5044 } }
filter {
grok { match => { "message" => "%{TIMESTAMP_ISO8601:app_time} %{LOGLEVEL:log.level} %{GREEDYDATA:message}" } }
date { match => ["app_time", "ISO8601"] }
}
output {
elasticsearch { hosts => ["https://es01:9200"] data_stream => "true" }
}
```
上线前用样本测试 grok,处理解析失败标签,限制队列与重试。复杂正则可能造成高 CPU,应优先结构化 JSON 日志。
## 索引与生命周期
使用 data streams 和 ILM 管理 rollover、保留和删除。分片不是越多越好;过多小分片会消耗 heap,过大分片又影响恢复。根据每日数据量、保留期、查询和节点容量压测。
## Kibana
用 Discover 验证原始数据和时间字段,再创建 Data View、Lens Dashboard 与告警。管理员、编辑者和只读用户分权;Kibana Saved Objects 也要备份或导出。
## 监控与排障
关注 cluster health、unassigned shards、heap、GC、磁盘水位、写入拒绝、查询延迟、ingest failure、Agent/Logstash 队列和端到端延迟。
排障顺序:采集端是否读取→网络/TLS/认证→Pipeline 是否解析→Elasticsearch 是否接受→索引/数据流是否存在→Kibana 时间范围和字段是否正确。
## 安全与备份
日志可能含密码、Token、身份证和业务数据,应在采集端脱敏,限制字段访问和保留期。Elasticsearch snapshot 必须存到独立仓库并恢复演练;复制副本不是备份。
参考:https://www.elastic.co/docs/get-started/the-stack