分享大阪服务器 ELK 日志分析平台的搭建与优化实战。
ELK（Elasticsearch + Logstash + Kibana）是经典的日志分析方案。本文分享大阪服务器 ELK 搭建与优化实战。
架构设计 1) Filebeat：轻量级日志采集，部署在应用服务器 2) Kafka：消息队列，缓冲和削峰 3) Logstash：日志处理和转换 4) Elasticsearch：存储和搜索 5) Kibana：可视化和分析
规模评估 1) 日志量：每日日志量（GB） 2) 保留时间：日志保留天数 3) 节点数：根据日志量和保留时间计算 4) 示例：每日 100GB，保留 30 天，需 3TB 存储（副本后 6TB）
Elasticsearch 优化 1) 分片：每日一个索引，3-5 个主分片 2) 副本：1 副本 3) 刷新：refresh_interval 30s 4) 合并：定期 optimize 5) 冷热分离：热数据 SSD，冷数据 HDD
Logstash 优化 1) pipeline workers：CPU 核心数 2) batch size：500-1000 3) filter 优化：少用 ruby，用 mutate 4) 输出：bulk 批量写入 ES 5) 持久化队列：防止数据丢失
Filebeat 配置 1) input：指定日志路径 2) multiline：多行日志合并 3) processors：添加字段、过滤 4) output：到 Kafka 或 Logstash
Kibana 可视化 1) 索引模式：配置日志索引 2) 发现：搜索和过滤日志 3) 可视化：折线图、饼图、数据表 4) 仪表盘：组合多个可视化 5) 告警：基于查询的告警
索引生命周期管理 1) Hot：最近 7 天，SSD，高性能 2) Warm：7-30 天，HDD，查询为主 3) Cold：30-90 天，只读 4) Delete：90 天后自动删除
常见问题 问题一：ES 写入慢 排查：refresh 太频繁；bulk 太小；磁盘慢。 修复：refresh_interval 30s；bulk 5-15MB；升级 SSD。
问题二：查询慢 排查：分片过多；缺乏索引；深分页。 修复：合理分片数；用 search_after；定期 optimize。
问题三：日志丢失 排查：Kafka 积压；Logstash 处理慢；ES 不可用。 修复：增加 Kafka 分区；优化 Logstash；ES 扩容。
问题四：磁盘满 排查：日志量增长；保留时间过长。 修复：ILM 自动删除；冷热分层；压缩存储。
问题五：Kibana 加载慢 排查：索引太多；查询范围太大。 修复：限制索引；缩短查询范围；用 filter 而非 query。
监控告警 1) 集群健康状态 2) 节点和分片状态 3) 磁盘使用率 4) JVM 内存和 GC 5) 索引写入和查询速率 6) Kafka 消费延迟
成本优化 1) 冷热分层：冷数据用便宜存储 2) 压缩：ES 5.x+ 默认压缩 3) 合理保留：不需要的日志及时删除 4) 采样：部分日志采样存储 5) 聚合：历史数据聚合并存储
总结：ELK 搭建要根据日志量规划规模，关注 ES 写入和查询性能，合理设计索引生命周期，才能稳定运行。