Elasticsearch与Kibana集成：一个工程师的实战手记
去年冬天，我在一家中型互联网公司接手了一个“已上线但没人敢动”的日志平台。Dashboard上半数图表空白，时间筛选器像装饰品一样摆在那里，运维同事每次查问题都要手动curl ES API拼DSL——不是不会用Kibana，而是Kibana根本没真正连上ES的语义层。
后来发现，问题不在证书过期、也不在端口不通，而是在创建第一个logs-*索引时，没人告诉Filebeat：“别把@timestamp当字符串存。”结果ES自动映射成text，Kibana死活认不出这是时间字段。我们花了三天回溯数据流、重建索引、重配Index Pattern……最后在凌晨两点看着Dashboard终于按分钟滚动出曲线时，我意识到：Elastic Stack的“开箱即用”，只对理解它契约的人成立。
这不是一篇讲概念的文档，而是一份从踩坑现场打捞出来的工程笔记。它不罗列所有API参数，但会告诉你——
✅ 为什么dynamic: false必须写在模板里，而不是等报错再加；
✅ 为什么Kibana说“找不到字段”，其实ES里那个字段早就存在，只是类型错了；
✅ 为什么开了TLS之后Kibana启动失败，错误日志却只字不提证书路径错了；
✅ 以及，当你想让不同团队看到不同Dashboard时，真正的隔离点不在Kibana界面，而在ES的角色权限配置里。
索引不是表，Mapping才是契约的起点
很多团队把ES当成“带全文检索的MongoDB”来用：先写数据，再看Kibana能不能识别。这就像盖楼前不画结构图，等钢筋浇完才发现承重墙位置错了。
ES里最常被低估的，是索引模板（Index Template）的强制力。它不是建议，而是规则——只要索引名匹配logs-*，ES就会拒绝任何不符合模板Mapping的写入（前提是禁用动态映射）。
来看这个生产环境必须落地的模板：
PUT _index_template/logs_production { "index_patterns": ["logs-*"], "template": { "settings": { "number_of_shards": 1, "number_of_replicas": 1, "refresh_interval": "30s", "codec": "best_compression" }, "mappings": { "dynamic": false, "properties": { "@timestamp": { "type": "date", "format": "strict_date_optional_time||epoch_millis" }, "service.name": { "type": "keyword" }, "http.status_code": { "type": "short" }, "error.stack_trace": { "type": "text", "index": false }, "trace.id": { "type": "keyword", "doc_values": false } } } } }注意几个硬性设计点：
dynamic: false是安全阀。没有它，第一条日志里http.status_code: "500"会被映射为text，第二条http.status
