日志聚合

为什么

何时使用

如何做

1. 选聚合器并从所有服务发日志
   - Loki（Grafana 栈，便宜，结构化日志好）、Datadog（付费，全功能）、
     ELK（自托管，强但运维重）、CloudWatch（AWS 原生）
   - 经 agent（Promtail、Fluentd、Datadog agent）或直接从 app 发

2. 强保留策略
   - 7-30 天热（可查询、快）、90 天温（可查询、慢）、1-7 年冷（合规）
   - 热保留贵；别保 90 天热除非你常查那么远

3. 使日志按要紧字段可查询
   - 按以下索引或标签：service、level、trace_id、route、status_code
   - 别全索引（贵）；索引你查询的字段

4. 为常见事件模式建保存查询
   - "过去 5m checkout 错误"：{service="checkout", level="ERROR"} | last 5m
   - "慢请求"：{latency_ms > 1000} | last 1h
   - 事件中值班跑保存查询非自定义

5. 按日志模式告警，非仅指标
   - "ERROR 率 > 1/s 持续 5m" → page
   - "特定错误消息出现" → page（如"DB connection refused"）
   - 日志抓指标漏的失败（如不动错误率指标的罕见错误）

示例

# 日志聚合架构：
App → logger（JSON）→ Promtail → Loki → Grafana（查询/仪表盘/告警）
                       ↓
                       Datadog agent → Datadog（若两者都用）

# 保留策略（Loki）：
retention:
  hot:  30 天   # 快查询，贵存储
  warm: 90 天   # 慢查询，便宜
  cold: 7 年   # 合规，少查

# 保存查询（Grafana）：
- name: "checkout-errors-5m"
  query: '{service="checkout", level="ERROR"} |= "" | last 5m'
- name: "slow-requests-1h"
  query: '{latency_ms > 1000} | last 1h'
- name: "db-connection-refused"
  query: '{msg=~"DB connection refused"} | last 15m'

# 按日志模式告警（非仅指标）：
- alert: CheckoutDbConnectionRefused
  expr: count_over_time({service="checkout", msg=~"DB connection refused"}[5m]) > 0
  annotations:
    runbook_url: "https://rb/checkout-db-failover"
# 这抓特定失败即使错误率指标未破

常见问题

• ⚠仅本地盘日志 — pod 崩、日志没、事件以"日志在哪？"开始。
• ⚠无保留策略 — 日志 3 天过期，故一周后复盘看不到发生了什么。
• ⚠全字段索引 — 存储成本爆；仅索引你查询的字段（service、level、trace_id）。
• ⚠仅指标告警无日志告警 — 罕见错误（DB connection refused）不动错误率指标但仍是失败；也按日志模式告警。

最佳实践

• ✓实时从所有服务发日志到中央聚合器（Loki、Datadog、ELK）；日志活过 pod 死且可从单窗查询。
• ✓设分层保留策略（热 30d、温 90d、冷 7y 合规）；别全热 — 贵。
• ✓仅索引你查询的字段（service、level、trace_id、route）；为常见事件模式建保存查询使值班跑非写查询。
• ✓除指标外按日志模式（特定错误消息、按服务错误率）告警；日志抓指标漏的失败。