深色模式
集中式日志架构设计
当服务规模上千、日志量每天 TB 级时，采集端、缓冲层、存储层都要解耦设计。本文给出一套可水平扩展的分层拓扑与容量要点。
适用环境
bash
# 评估当前日志量
du -sh /var/log/nginx/
# 评估节点数
kubectl get nodes -o wide1
2
3
4
2
3
4
操作步骤
1. 分层拓扑（采集 → 缓冲 → 存储 → 查询）
[App/Pod] --(stdout/file)--> [Agent:DaemonSet] --(TCP)--> [Kafka/缓冲] --> [Transform:Vector/Fluentd] --> [ES/Loki]1
2. 采集层：节点级 Agent 统一收口
bash
# 每节点一个 Fluent Bit，负责解析与转发，不负责重逻辑
kubectl apply -f fluent-bit-ds.yaml1
2
2
3. 缓冲层：用消息队列削峰
yaml
# Vector 先把事件写入 Kafka，后端不可用时积压不丢
[sinks.kafka]
type = "kafka"
inputs = ["parse"]
bootstrap_servers = "kafka:9092"
topic = "logs-raw"1
2
3
4
5
6
2
3
4
5
6
4. 存储层：按量拆分索引/流
bash
# ES 按服务建不同索引模式，避免单索引过大
# Loki 按租户/服务打不同标签流1
2
2
WARNING
缓冲层（Kafka）是关键解耦点，但引入后会增加运维成本。日志量 < 100MB/s 时可直接 Agent→存储，不必上 Kafka。
验证
bash
# 端到端打通：造一条日志看是否最终入库
echo '{"level":"info","msg":"arch test"}' >> /var/log/app/app.log
curl -s 'http://es-host:9200/logs-app-*/_count?q=msg:arch%20test'1
2
3
2
3
常见坑
DANGER
不要每服务一个 Agent（Sidecar 海量）；也不要全集群只用一个中心 Agent（单点瓶颈）。节点级 DaemonSet 是大多数场景的甜点。