日志分析不是“配完就能跑”，而是设计出来的可观测性基础设施
你有没有遇到过这样的场景：
- Kibana里查不到刚写入的日志，刷新三遍才出现；
- 用level: ERROR做筛选，结果返回一堆WARN甚至INFO；
- Dashboard加载要等8秒，点开一个折线图就卡住；
- 大促期间磁盘告警疯狂刷屏，运维半夜爬起来删索引……
这些都不是 Elasticsearch “坏了”，而是日志分析架构在设计阶段就埋下了隐患。它不像部署一个Nginx那样“改完配置 reload 就行”，而是一套需要前置思考、权衡取舍、持续演进的可观测性基础设施。
今天不讲命令行速成，也不堆砌术语，我们从真实工程现场出发，拆解三个最常出问题、也最影响交付质量的关键环节：索引怎么建才不翻车？Logstash 怎么写才不丢日志？Kibana 怎么配才不卡顿？每一步都附带你在文档里找不到的实战经验。
索引不是“建个名字就完事”，它是日志生命周期的第一道闸门
很多人把索引当成数据库里的“表名”——起个logs-prod就开始往里灌数据。但 Elasticsearch 的索引，本质是 Lucene 分段（Segment）的物理容器，它的结构直接决定你未来三个月能不能睡安稳觉。
时间命名不是为了好看，是为了可控滚动
别再用logs-prod这种永久索引了。生产环境必须用时间戳后缀，比如：
logs-app-2024.04.01 logs-app-2024.04.02 ...为什么？因为 ES 的 ILM（Index Lifecycle Management）策略只认这种格式。没有它，你就得手动写脚本每天rollover，或者眼睁睁看着单个索引涨到 200GB+，查询变慢、恢复变难、备份失败。
更关键的是：ILM 不只是自动删旧数据，更是冷热分离的执行器。你可以让最近7天的索引留在 SSD 节点（hot），30天前的迁移到 SATA 节点（warm），90天后自动归档或删除——这一切，全靠索引名里那个2024.04.01触发。
字段类型错了，等于给查询埋雷
这是新手踩坑最多的地方：
-@timestamp字段被识别成text，导致range查询完全失效；
-level字段默认成了text，你搜level: ERROR，ES 却去分词匹配E,R,R,O,R；
-service_name本该聚合统计，却因没开doc_values，Kibana 直接报错Fielddata is disabled on text fields。
