日志

概述 在可观测性的三大支柱（Metrics、Logs、Traces）中，日志是最贴近应用层的数据。当线上服务出现异常，第一反应往往是"看日志"。ELK Stack（Elasticsearch + Logstash + Kibana）是日志分析领域的事实标准，在全文检索、日志解析、可视化分析方面功能强大。 随着 Loki 等"轻量级"日志方案兴起，ELK 面临着"存储成本高、运维复杂"的质疑。但 ELK 在全文检索、复杂文本分析、结构化日志聚合等方面的能力仍然无可替代。从架构原理到部署配置，详细梳理 ELK 日志分析平台的建设实践，并与 Loki 做对比分析，帮助你判断何时该选 ELK、何时该选 Loki。 参考来源：Elastic 官方文档 一、ELK Stack 架构 1.1 整体架构 ┌──────────────────────────────────────────────────────────────┐ │ ELK Stack 完整架构 │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ App/Node│ │ App/Node│ │ App/Node│ ← 日志源 │ │ │ log file│ │ log file│ │ log file│ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ │ │Filebeat │ │Filebeat │ │Filebeat │ ← 轻量采集器 │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ └────────────┼────────────┘ │ │ ▼ │ │ ┌────────────┐ │ │ │ Logstash │ ← 日志解析/过滤/转换 │ │ │ (可选) │ │ │ └──────┬─────┘ │ │ ▼ │ │ ┌──────────────────────────────────────┐ │ │ │ Elasticsearch 集群 │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ │ │Node1│ │Node2│ │Node3│ ← 存储 + 检索│ │ │ │ │(数据)│ │(数据)│ │(主从)│ │ │ │ │ └─────┘ └─────┘ └─────┘ │ │ │ └──────────────────┬───────────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────┐ │ │ │ Kibana │ ← 可视化 + 查询 │ │ └────────────┘ │ └──────────────────────────────────────────────────────────────┘ 1....

为什么选择 Loki 传统 ELK（Elasticsearch + Logstash + Kibana）方案虽然功能强大，但存在两个核心痛点： 存储成本高：Elasticsearch 将日志全文索引化，每条日志的索引膨胀可达原始数据的 3-5 倍 运维复杂：ES 集群扩缩容、分片再平衡、索引生命周期管理复杂，生产集群维护成本高 Loki 由 Grafana Labs 开源，设计理念是"像 Prometheus 那样做日志"。它只对日志的标签（Labels）做索引，不对日志正文建索引，通过 LogQL 进行全文检索。这种设计使存储成本降低 10 倍以上。 本文基于 Loki 3.x，参考 Loki 官方文档 Loki vs ELK 对比 维度 ELK (Elasticsearch) Loki 索引方式 全文倒排索引 仅索引标签，正文不索引 存储成本 高（索引膨胀 3-5x） 低（标签索引 + 压缩正文） 查询语言 Lucene Query / KQL LogQL（类 PromQL 语法） 扩展性 水平扩展，分片复杂 微服务模式，组件独立扩展 适用场景 全文检索、复杂分析 日志监控、指标化查询、与 Grafana 联动 资源消耗 高（JVM，内存大） 低（Go 编写，内存友好） Loki 并非要完全替代 ES。如果你的核心需求是全文检索和复杂文本分析，ES 仍是更好的选择。但对于 SRE 日志监控、指标告警、排障定位这类场景，Loki + Grafana 的组合在成本和效率上优势明显。...