日志

概述 线上炸了，你打开 Kibana 搜日志，发现关键 Pod 3 分钟前被 OOM Kill 重启了，旧日志跟着容器一起灰飞烟灭。这种事在 K8s 环境里太常见了——Pod 是短命的，日志不能跟着 Pod 一起消失。 K8s 的日志采集和传统虚拟机完全不是一回事。传统环境日志躺在 /var/log/ 下，SSH 上去就能看。K8s 里 Pod 随时可能被调度到任何节点，随时可能被销毁重建，日志分散在整个集群。如果不做集中采集，故障排查时你根本找不到日志在哪。 这篇文章把 K8s 日志采集的几种方案拆开讲清楚：DaemonSet 模式、Sidecar 模式、以及基于节点 Agent 的方案。每种方案什么场景用、怎么配置、踩什么坑，全部覆盖。最后给出一套生产可用的选型决策框架。 K8s 日志的三种类型 在讲采集方案之前，先搞清楚 K8s 里有哪些日志。不同类型的日志采集策略完全不同。 1. 容器标准输出日志 这是最常见的一类。应用把日志写到 stdout/stderr，容器运行时（containerd 或 Docker）负责把这些日志落盘到节点的 /var/log/containers/ 目录。 # 查看某节点的容器日志文件 ls /var/log/containers/ # 输出示例 # nginx-xxx_default_app-abc123.log # redis-yyy_default_app-def456.log # 这些文件实际是指向 /var/log/pods/ 下的符号链接 ls -l /var/log/containers/nginx-xxx_default_app-abc123.log # lrwxrwxrwx 1 root root 99 ... nginx-xxx_default_app-abc123.log -> /var/log/pods/default_nginx-xxx_abc123/app/0.log 这类日志的好处是采集简单——DaemonSet 模式直接读 /var/log/containers/*....

概述 在可观测性的三大支柱（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 的组合在成本和效率上优势明显。...