4. 日志采集与集中化：ELK / Loki / Grafana Loki 架构、日志采集 Agent 配置、日志传输可靠性保障

在 MTTR 视角下，日志集中化是缩短诊断路径的第一步。如果日志采集丢失、传输延迟或存储不可查询，故障排查将退回到“逐台登录服务器”的原始状态。本章聚焦三大主流日志栈（ELK、Loki、Grafana Loki）的架构差异、Agent 配置要点以及传输可靠性保障机制。

4.1 三大日志栈架构对比

ELK（Elasticsearch + Logstash + Kibana）与 Loki（Grafana Loki）代表了两种不同的日志处理哲学：索引优先 vs. 标签优先。下表从 MTTR 关键维度进行对比：

4.2 日志采集 Agent 配置

无论选择哪种后端，Agent 都是日志管道的“第一公里”。以下以 Filebeat（ELK 生态）和 Promtail（Loki 生态）为例，展示核心配置要点。

4.2.1 Filebeat 配置示例

# filebeat.yml
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/nginx/access.log
    - /var/log/nginx/error.log
  fields:
    service: nginx
    env: production
  fields_under_root: true
  multiline:
    pattern: '^\d{4}-\d{2}-\d{2}'
    negate: true
    match: after

output.elasticsearch:
  hosts: ["https://es-cluster:9200"]
  username: "filebeat"
  password: "${ES_PWD}"
  ssl.verification_mode: certificate

# 可靠性保障：启用重试与背压
queue.mem:
  events: 4096
  flush.min_events: 512
  flush.timeout: 5s

4.2.2 Promtail 配置示例

# promtail.yml
scrape_configs:
- job_name: nginx
  static_configs:
  - targets: [localhost]
    labels:
      job: nginx
      env: production
      __path__: /var/log/nginx/*.log
  pipeline_stages:
  - multiline:
      firstline: '^\d{4}-\d{2}-\d{2}'
  - regex:
      expression: '^(?P<remote_addr>\S+) - - \[(?P<time>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) \S+" (?P<status>\d+)'
  - labels:
      status:
  - timestamp:
      source: time
      format: RFC3339

clients:
- url: http://loki-gateway:3100/loki/api/v1/push
  backoff_config:
    min_period: 100ms
    max_period: 10s
    max_retries: 10

4.3 日志传输可靠性保障

日志丢失是 MTTR 的隐形杀手。以下从生产者端、传输通道、消费者端三个层面给出保障措施。

4.3.1 生产者端（Agent）

• 本地缓冲队列： Filebeat 使用 queue.mem，Promtail 使用 client.batch-size 和 client.batch-wait，避免突发流量直接压垮后端。
• 磁盘持久化： 启用 queue.disk（Filebeat）或 positions.yaml（Promtail），确保 Agent 重启后不重复发送也不丢失偏移量。
• 背压机制： 当后端响应 429/503 时，Agent 应自动降速重试，而非丢弃日志。

4.3.2 传输通道

• Kafka 缓冲层： 在 Agent 与后端之间插入 Kafka，利用其持久化特性解耦生产与消费速率。
• TLS/mTLS： 加密传输防止日志内容泄露，同时避免中间人篡改。
• 压缩： 启用 gzip 压缩（如 Filebeat 的 compression_level: 5），减少带宽消耗。

4.3.3 消费者端（后端）

• 写入确认： Elasticsearch 应返回 201 Created 或 200 OK 才视为写入成功；Loki 应返回 204 No Content。
• 副本与冗余： Elasticsearch 设置 index.number_of_replicas: 1；Loki 使用 replication_factor: 3。
• 监控告警： 对 filebeat.messages_dropped、promtail_dropped_entries_total 等指标设置告警，第一时间发现丢日志。

4.4 日志集中化架构总览

下图展示了一个生产级日志集中化架构，涵盖 Agent、缓冲层、后端存储与查询入口：

4.5 日志传输可靠性保障架构

下图聚焦传输链路上的可靠性细节，展示从 Agent 到后端的完整保障链路：

4.6 日志采集 Agent 配置清单（MTTR 视角）

以下清单可作为 Agent 配置的验收标准，确保日志采集环节不成为 MTTR 的瓶颈：