ELK日志平台 ELK 是什么：集中式日志平台的定位与取舍
ELK 是什么：集中式日志平台的定位与取舍
ELK 是 Elasticsearch、Logstash、Kibana 三个组件的首字母缩写。实际生产里通常还会加上跑在业务机上的采集器 Filebeat，四个组件串成一条完整链路：应用写日志文件 → Filebeat 读文件并结构化 → Logstash 解析与富化 → Elasticsearch 建索引存储 → Kibana 检索与出图。它解决的核心问题是：当服务从一台机器拆成几十个容器之后，登录每台机器 tail -f 已经不可能，必须把所有日志收拢到一处，做到「一个关键字搜全站、一个时间轴串起整条调用链」。
日志属于典型的「写多读少、写进去基本不会再改、但出故障时要求秒级全文检索」的数据。Elasticsearch 底层的倒排索引正好吃这一口：它把日志正文按分词结果建成索引，所以「在一亿行日志里搜一个订单号并看到上下二十行上下文」能在亚秒级返回，这是纯靠 grep 或者只存标签的时序库做不到的。代价是写入放大明显：原始日志一行，进倒排索引后占用可能翻倍，机器磁盘和内存开销都大。
选型时不要只看「能不能查」，要先算清楚「每天多少 GB、保留多少天、要查多快的窗口」。ELK 适合日志量大、检索维度不固定、需要全文搜关键字与异常堆栈的场景；如果只是看几个固定指标的曲线，用别的东西更省。
| 方案 | 索引方式 | 优势 | 劣势与适用边界 |
|---|---|---|---|
| ELK / Elastic Stack | 全文倒排索引，每个字段都可检索 | 全文检索强、Kibana 生态成熟、聚合分析能力完整 | 资源开销大、JVM 调优有门槛、运维成本高 |
| Loki + Grafana | 只索引标签（label），日志正文压缩成块 | 存储便宜、与 Prometheus 标签体系一致、部署轻 | 正文不做索引，复杂全文检索慢，适合「按标签捞日志」 |
| ClickHouse | 列式存储 + 跳数索引 | 聚合扫描极快、单位成本低、SQL 门槛低 | 需要自己写采集与查询层，缺乏开箱即用的日志 UI |
| Splunk | 商业倒排索引 | 功能最全、SPL 查询语言强、企业级支持好 | 按数据量计费，成本高，适合预算充足的大企业 |
| 阿里云 SLS | 托管式日志服务 | 免运维、弹性、与云产品打通 | 按量付费、数据在云上、深度定制受限 |
一句话取舍：要全文检索 + 复杂聚合 → ELK；要便宜 + 只看标签 → Loki；要极快聚合 + 自己有开发能力 → ClickHouse；不想运维也不差钱 → Splunk 或云上 SLS。
核心术语表
| 术语 | 含义 |
|---|---|
| index（索引） | 一类文档的集合，类似数据库的表。日志场景通常按服务或按日期切分 |
| mapping（映射） | 索引的字段结构定义，规定每个字段是 text、keyword、long、date 还是 ip 等 |
| analyzer（分析器） | 决定文本怎么切词、怎么归一化，由 character filter + tokenizer + token filter 组成 |
| shard（分片） | 索引的水平切分单位，每个分片就是一个完整的 Lucene 索引 |
| replica（副本） | 分片的拷贝，用于容错与分担读流量 |
| ILM（索引生命周期） | Index Lifecycle Management，按时间自动把索引在 hot/warm/cold/delete 之间搬动 |
| data stream（数据流） | 面向时序数据的写入抽象，背后是一串自动 rollover 的隐藏索引 |
| template（模板） | 新建索引时自动套用的 settings 与 mappings，避免手工建每个索引 |
| ingest pipeline | 写入前在 ES 侧做的一串处理器，比如 grok、date、gsub，替代一部分 Logstash 工作 |
| Grok | 基于正则的日志解析语法，用 %{TIMESTAMP_ISO8601:ts} 这种模式把文本拆成字段 |
| KQL / Lucene | Kibana 的两种查询语法，KQL 更贴近自然表达，Lucene 语法支持通配与字段分组 |
| Beats | 轻量采集器家族，Filebeat 收文件、Metricbeat 收指标、Winlogbeat 收 Windows 事件 |
合规提醒：日志里经常混着手机号、身份证、邮箱、Cookie、Authorization 头、数据库连接串。采集前先在应用侧做脱敏与最小化，别把全量请求体直接打进去；日志平台的访问权限要按角色授权，生产日志不能人人可见。
