SRE生产实践：日志聚合与分析
文档日期：2026-03-25
适用场景：中大型分布式系统运维
难度等级：中级 ⭐⭐⭐
一、概述与背景
1.1 问题背景
在微服务架构下，一个用户请求可能跨越数十个服务节点。当系统出现故障时，工程师需要在海量日志中快速定位问题根源。传统的单机日志查看方式已无法满足需求：
- 日志分散：每个服务实例都有独立日志文件
- 数据量巨大：日均数TB级别的日志数据
- 查询困难：无法快速关联多个服务的日志链路
- 成本高昂：存储和计算成本不断上升
- 可观测性缺失：无法实时了解系统运行状态
1.2 日志聚合的价值
- 快速故障定位：秒级查询，毫秒级响应
- 链路追踪：通过TraceID关联完整请求链路
- 趋势分析：发现系统潜在问题
- 合规审计：满足安全审计和数据合规要求
- 成本优化：集中存储和管理，降低总体成本
二、核心原理
2.1 日志聚合架构
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Service A │ │ Service B │ │ Service C │
│ (Logs) │ │ (Logs) │ │ (Logs) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────────────┼────────────────┘
│
┌────▼─────┐
│ Collector │ (Filebeat/Fluentd)
│ (Agent) │
└────┬─────┘
│
┌───────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌─────▼──────┐ ┌────▼────┐
│ Kafka │ │ Message Q │ │ Direct │
│ (Buffer)│ │ (Optional) │ │ (Fast) │
└────┬────┘ └─────┬──────┘ └────┬────┘
│ │ │
└───────────────┼──────────────┘
│
┌────▼──────────┐
│ Elasticsearch │
│ (Storage) │
└────┬──────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌─────▼──────┐ ┌────▼────┐
│ Kibana │ │ Grafana │ │ Custom │
│ (UI) │ │ (Dashboard)│ │ Apps │
└─────────┘ └────────────┘ └─────────┘
2.2 核心组件
2.2.1 日志收集层（Collection）
Filebeat（推荐用于容器环境）
- 轻量级Agent，内存占用<50MB
- 支持多行日志、JSON解析
- 内置背压处理，不丢日志
Fluentd（推荐用于复杂场景）
- 灵活的插件生态
- 支持复杂的日志处理规则
- 可作为中央日志处理器
Logstash（推荐用于复杂转换）
- 强大的日志处理能力
- 支持Grok正则表达式
- 但资源消耗较大
2.2.2 消息队列层（Optional）
使用Kafka/RabbitMQ的优势：
- 解耦：收集端和存储端独立扩展
- 缓冲：应对存储端突发流量
- 重放：支持日志重新处理
- 多消费：支持多个下游系统
2.2.3 存储层（Storage）
Elasticsearch（业界标准）
- 倒排索引，查询性能优异
- 支持复杂的聚合分析
- 自动分片和副本机制
- 生态完善（Kibana、Beats等）
其他选择：
- Loki（Prometheus生态，成本低）
- ClickHouse（OLAP分析，成本低）
- S3+Athena（云原生，成本最低）
2.2.4 查询展示层（Visualization）
- Kibana：Elasticsearch官方UI，功能最全
- Grafana：通用可视化平台，支持多数据源
- 自建系统：满足特定业务需求
2.3 关键技术点
2.3.1 日志结构化
{
"timestamp": "2026-03-25T09:20:15.123Z",
"level": "ERROR",
"service": "payment-service",
"instance": "payment-service-pod-123",
"trace_id": "550e8400-e29b-41d4-a716-446655440000",
"span_id": "f7461d1186919d51",
"user_id": "user_12345",
"request_id": "req_98765",
"message": "Payment processing failed",
"error": "timeout",
"duration_ms": 5000,
"tags": {
"env": "production",
"region": "cn-east-1",
"version": "v2.1.0"
}
}
结构化的好处：
- 支持精确字段查询
- 便于聚合统计
- 易于告警规则配置
- 提高查询性能
2.3.2 采样策略
在高流量场景下，采样可显著降低成本：
采样率 = min(1, 10 / QPS)
例如：
- QPS = 100,000 → 采样率 = 0.0001（1/10000）
- QPS = 1,000 → 采样率 = 0.01（1/100）
- QPS = 100 → 采样率 = 0.1（1/10）
采样原则：
- 错误日志100%采样
- 慢查询日志100%采样
- 正常日志按比例采样
- 关键业务链路100%采样
2.3.3 日志保留策略
日志级别 保留时间 存储位置
ERROR 30天 热存储(ES)
WARN 14天 热存储(ES)
INFO 7天 热存储(ES)
DEBUG 3天 热存储(ES)
TRACE 1天 本地/不存储
冷存储：
- 超过30天的日志归档到S3/OSS
- 保留1年用于审计
三、主要功能与应用场景
3.1 故障诊断
场景：用户反馈支付失败
1. 通过request_id快速定位请求
2. 查看trace_id关联的完整链路
3. 发现payment-service超时
4. 查看该服务的错误日志
5. 发现数据库连接池耗尽
6. 定位根本原因：某个查询性能下降
3.2 性能分析
查询：service:payment-service AND duration_ms:[1000 TO *]
结果：找出所有耗时>1秒的请求
分析：
- 哪些接口最慢？
- 慢查询的特征是什么？
- 是否与特定用户/数据量相关？
3.3 安全审计
查询：action:delete AND user_id:* AND timestamp:[now-7d TO now]
结果：过去7天所有删除操作
用途：
- 审计谁删除了什么
- 何时删除
- 是否有异常操作
3.4 容量规划
聚合查询：
- 日均日志量趋势
- 存储增长率
- 查询QPS分布
- 峰值流量预测
决策：
- 何时需要扩容
- 是否需要调整采样率
- 是否需要优化存储
3.5 告警规则
规则1：错误率告警
条件：error_count / total_count > 1% in 5min
动作：发送告警到On-Call
规则2：慢查询告警
条件：duration_ms > 5000 AND count > 100 in 5min
动作：发送告警到开发团队
规则3：异常模式检测
条件：同一user_id在1分钟内出现>10次错误
动作：可能是攻击，发送安全告警
四、部署与安装步骤
4.1 前置要求
# 检查系统环境
- Linux内核 >= 4.15
- Docker >= 20.10
- Docker Compose >= 1.29
- 磁盘空间 >= 100GB（日志存储）
- 内存 >= 16GB（ES集群）
4.2 快速部署（Docker Compose）
步骤1：创建目录结构
mkdir -p /opt/log-stack/{elasticsearch,filebeat,kibana}
cd /opt/log-stack
步骤2：创建docker-compose.yml
version: '3.8'
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
container_name: elasticsearch
environment:
- discovery.type=single-node
- xpack.security.enabled=false
- "ES_JAVA_OPTS=-Xms4g -Xmx4g"
ports:
- "9200:9200"
volumes:
- es_data:/usr/share/elasticsearch/data
networks:
- log-stack
healthcheck:
test: curl -s http://localhost:9200 >/dev/null || exit 1
interval: 10s
timeout: 5s
retries: 5
kibana:
image: docker.elastic.co/kibana/kibana:8.11.0
container_name: kibana
environment:
- ELASTICSEARCH_HOSTS=http://elasticsearch:9200
ports:
- "5601:5601"
depends_on:
elasticsearch:
condition: service_healthy
networks:
- log-stack
filebeat:
image: docker.elastic.co/beats/filebeat:8.11.0
container_name: filebeat
user: root
volumes:
- ./filebeat.yml:/usr/share/filebeat/filebeat.yml:ro
- /var/lib/docker/containers:/var/lib/docker/containers:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
command: filebeat -e -strict.perms=false
depends_on:
elasticsearch:
condition: service_healthy
networks:
- log-stack
volumes:
es_data:
networks:
log-stack:
driver: bridge
步骤3：创建filebeat.yml配置
filebeat.inputs:
- type: container
enabled: true
paths:
- '/var/lib/docker/containers/*/*.log'
processors:
- add_docker_metadata:
host: "unix:///var/run/docker.sock"
- add_kubernetes_metadata:
in_cluster: true
processors:
- add_host_metadata:
- add_process_metadata:
output.elasticsearch:
hosts: ["elasticsearch:9200"]
index: "logs-%{+yyyy.MM.dd}"
logging.level: info
logging.to_files: true
logging.files:
path: /var/log/filebeat
name: filebeat
keepfiles: 7
permissions: 0644
步骤4：启动服务
# 启动所有服务
docker-compose up -d
# 检查服务状态
docker-compose ps
# 查看日志
docker-compose logs -f elasticsearch
# 验证Elasticsearch
curl http://localhost:9200/_cluster/health
# 访问Kibana
# 浏览器打开：http://localhost:5601
4.3 Kubernetes部署
步骤1：创建Namespace
kubectl create namespace logging
步骤2：部署Elasticsearch
# elasticsearch-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: elasticsearch
namespace: logging
spec:
serviceName: elasticsearch
replicas: 3
selector:
matchLabels:
app: elasticsearch
template:
metadata:
labels:
app: elasticsearch
spec:
containers:
- name: elasticsearch
image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
ports:
- containerPort: 9200
name: http
- containerPort: 9300
name: transport
env:
- name: cluster.name
value: "k8s-logs"
- name: node.name
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: discovery.seed_hosts
value: "elasticsearch-0.elasticsearch,elasticsearch-1.elasticsearch,elasticsearch-2.elasticsearch"
- name: cluster.initial_master_nodes
value: "elasticsearch-0,elasticsearch-1,elasticsearch-2"
- name: ES_JAVA_OPTS
value: "-Xms2g -Xmx2g"
- name: xpack.security.enabled
value: "false"
resources:
requests:
memory: "2Gi"
cpu: "500m"
limits:
memory: "4Gi"
cpu: "2000m"
volumeMounts:
- name: data
mountPath: /usr/share/elasticsearch/data
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 50Gi
---
apiVersion: v1
kind: Service
metadata:
name: elasticsearch
namespace: logging
spec:
clusterIP: None
selector:
app: elasticsearch
ports:
- port: 9200
name: http
- port: 9300
name: transport
步骤3：部署Filebeat DaemonSet
# filebeat-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: filebeat
namespace: logging
spec:
selector:
matchLabels:
app: filebeat
template:
metadata:
labels:
app: filebeat
spec:
serviceAccountName: filebeat
terminationGracePeriodSeconds: 30
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
containers:
- name: filebeat
image: docker.elastic.co/beats/filebeat:8.11.0
args: ["-c", "/etc/filebeat.yml", "-e"]
env:
- name: ELASTICSEARCH_HOST
value: elasticsearch.logging.svc.cluster.local
- name: ELASTICSEARCH_PORT
value: "9200"
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
securityContext:
runAsUser: 0
resources:
requests:
memory: "100Mi"
cpu: "100m"
limits:
memory: "200Mi"
cpu: "500m"
volumeMounts:
- name: config
mountPath: /etc/filebeat.yml
readOnly: true
subPath: filebeat.yml
- name: varlog
mountPath: /var/log
readOnly: true
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
- name: dockersock
mountPath: /var/run/docker.sock
volumes:
- name: config
configMap:
name: filebeat-config
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: dockersock
hostPath:
path: /var/run/docker.sock
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: filebeat
namespace: logging
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: filebeat
rules:
- apiGroups: [""]
resources:
- namespaces
- pods
- nodes
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: filebeat
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: filebeat
subjects:
- kind: ServiceAccount
name: filebeat
namespace: logging
步骤4：部署Kibana
# kibana-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: kibana
namespace: logging
spec:
replicas: 1
selector:
matchLabels:
app: kibana
template:
metadata:
labels:
app: kibana
spec:
containers:
- name: kibana
image: docker.elastic.co/kibana/kibana:8.11.0
ports:
- containerPort: 5601
env:
- name: ELASTICSEARCH_HOSTS
value: http://elasticsearch.logging.svc.cluster.local:9200
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "1000m"
---
apiVersion: v1
kind: Service
metadata:
name: kibana
namespace: logging
spec:
type: LoadBalancer
selector:
app: kibana
ports:
- port: 5601
targetPort: 5601
步骤5：部署
# 创建ConfigMap
kubectl create configmap filebeat-config \
--from-file=filebeat.yml \
-n logging
# 部署所有组件
kubectl apply -f elasticsearch-statefulset.yaml
kubectl apply -f filebeat-daemonset.yaml
kubectl apply -f kibana-deployment.yaml
# 检查部署状态
kubectl get pods -n logging
kubectl get svc -n logging
# 查看日志
kubectl logs -n logging -l app=elasticsearch -f
4.4 生产级配置建议
4.4.1 Elasticsearch集群配置
# elasticsearch.yml
cluster.name: production-logs
node.name: ${HOSTNAME}
# 内存配置（重要！）
# 设置为物理内存的50%，但不超过31GB
-Xms16g
-Xmx16g
# 磁盘配置
path.data: /data/elasticsearch
path.logs: /var/log/elasticsearch
# 网络配置
network.host: 0.0.0.0
http.port: 9200
transport.port: 9300
# 集群配置
discovery.seed_hosts: ["es-node1", "es-node2", "es-node3"]
cluster.initial_master_nodes: ["es-node1", "es-node2", "es-node3"]
# 性能优化
indices.memory.index_buffer_size: 40%
thread_pool.write.queue_size: 1000
thread_pool.search.queue_size: 1000
# 索引配置
index.number_of_shards: 5
index.number_of_replicas: 1
index.refresh_interval: 30s
4.4.2 索引生命周期管理（ILM）
# 自动删除30天前的日志
PUT _ilm/policy/logs-policy
{
"policy": "logs-policy",
"phases": {
"hot": {
"min_age": "0d",
"actions": {
"rollover": {
"max_primary_shard_size": "50GB",
"max_age": "1d"
}
}
},
"warm": {
"min_age": "7d",
"actions": {
"set_priority": {
"priority": 50
}
}
},
"cold": {
"min_age": "14d",
"actions": {
"set_priority": {
"priority": 0
}
}
},
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
五、常见问题与排查
5.1 安装部署问题
问题1：Elasticsearch启动失败 - "max virtual memory areas vm.max_map_count too low"
原因：Linux系统限制
解决方案：
# 临时修改
sysctl -w vm.max_map_count=262144
# 永久修改
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -p
问题2：Filebeat无法连接Elasticsearch
排查步骤：
# 1. 检查网络连接
telnet elasticsearch 9200
# 2. 查看Filebeat日志
docker logs filebeat | grep -i error
# 3. 检查Elasticsearch状态
curl http://elasticsearch:9200/_cluster/health
# 4. 验证配置文件
docker exec filebeat filebeat test config
问题3：磁盘空间不足导致Elasticsearch只读
症状：
"reason":"[FORBIDDEN/12/index read-only / allow delete (api)]"
解决方案：
# 1. 清理旧索引
curl -X DELETE "localhost:9200/logs-2026-03-01"
# 2. 解除只读状态
curl -X PUT "localhost:9200/_all/_settings" -H 'Content-Type: application/json' -d'
{
"index.blocks.read_only_allow_delete": null
}
'
# 3. 扩容磁盘或调整保留策略
5.2 性能问题
问题4：查询响应缓慢
排查步骤：
# 1. 检查集群状态
curl http://localhost:9200/_cluster/stats
# 2. 检查索引大小
curl http://localhost:9200/_cat/indices?v
# 3. 查看慢查询日志
curl http://localhost:9200/_search/slow
# 4. 优化查询
# 使用filter而不是query（filter会被缓存）
# 避免通配符查询
# 使用时间范围限制
优化建议：
// 不好的查询
{
"query": {
"match": {
"message": "*error*"
}
}
}
// 好的查询
{
"query": {
"bool": {
"filter": [
{ "range": { "timestamp": { "gte": "now-1h" } } },
{ "term": { "level": "ERROR" } },
{ "match": { "message": "error" } }
]
}
}
}
问题5：内存溢出（OOM）
原因：
- Elasticsearch JVM堆内存设置过小
- 查询返回结果过多
- 聚合操作消耗内存过大
解决方案：
# 1. 增加JVM堆内存
# 修改 -Xms 和 -Xmx，设置为物理内存的50%
# 2. 限制查询结果
# 使用 size 参数限制返回数量
# 使用 scroll API 处理大结果集
# 3. 优化聚合
# 避免深层嵌套聚合
# 使用 composite aggregation 处理大量聚合
5.3 数据问题
问题6：日志丢失
可能原因：
- Filebeat缓冲区满
- Elasticsearch写入失败
- 网络中断
预防措施：
# filebeat.yml
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/*.log
# 启用本地队列
queue.mem:
events: 4096
flush.min_events: 512
flush.timeout: 1s
# 启用持久化队列（防止丢失）
queue.disk:
path: "${path.data}/queue"
max_size: 10GB
segment_size: 100MB
write_timeout: 30s
output.elasticsearch:
hosts: ["localhost:9200"]
# 重试配置
max_retries: 3
backoff.init: 1s
backoff.max: 60s
问题7：日志重复
原因：
- Filebeat重启导致重新读取
- 多个Filebeat实例读取同一文件
解决方案：
# 启用registry文件持久化
filebeat.registry.path: /var/lib/filebeat/registry
# 使用唯一的source标识
processors:
- add_fields:
target: ''
fields:
source_host: ${HOSTNAME}
source_file: %{[log.file.path]}
5.4 告警规则问题
问题8：告警频繁误触发
原因：
- 阈值设置过低
- 没有考虑业务波动
解决方案：
// 使用动态阈值
{
"trigger": {
"schedule": {
"interval": "5m"
}
},
"input": {
"search": {
"request": {
"indices": ["logs-*"],
"body": {
"query": {
"range": {
"timestamp": {
"gte": "now-5m"
}
}
},
"aggs": {
"error_rate": {
"avg": {
"script": "doc['is_error'].value ? 1 : 0"
}
}
}
}
}
}
},
"condition": {
"compare": {
"ctx.payload.aggregations.error_rate.value": {
"gt": 0.01 // 错误率>1%
}
}
}
}
六、生产实践建议
6.1 架构设计
6.1.1 高可用部署
┌─────────────────────────────────────────┐
│ Kubernetes Cluster │
├─────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Filebeat Pod │ │ Filebeat Pod │ │
│ │ (DaemonSet) │ │ (DaemonSet) │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ └────────┬────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Kafka Cluster │ │
│ │ (3 replicas) │ │
│ └────────┬────────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ │ │ │ │
│ ┌──▼──┐ ┌──────▼──┐ ┌──────▼──┐ │
│ │ ES │ │ ES │ │ ES │ │
│ │Node1│ │ Node2 │ │ Node3 │ │
│ └──┬──┘ └──────┬──┘ └──────┬──┘ │
│ │ │ │ │
│ └────────────┼────────────┘ │
│ │ │
│ ┌───────▼────────┐ │
│ │ Kibana (HA) │ │
│ └────────────────┘ │
│ │
└──────────────────────────────────────┘
6.1.2 容量规划
假设：
- 日均请求量：1亿
- 平均日志大小：1KB
- 日均日志量：100GB
- 副本数：1（总存储：200GB）
- 保留时间：30天
所需存储：200GB × 30 = 6TB
Elasticsearch节点配置：
- 节点数：3（高可用）
- 每个节点磁盘：2TB
- 总磁盘：6TB
- 内存：每个节点16GB（总48GB）
- CPU：每个节点8核（总24核）
6.2 运维最佳实践
6.2.1 监控指标
关键指标：
1. 集群健康状态
- cluster.status (green/yellow/red)
- active_shards / total_shards
2. 索引性能
- indexing.index_total (索引速率)
- search.query_total (查询速率)
- search.query_time_in_millis (查询延迟)
3. 资源使用
- jvm.mem.heap_used_percent
- fs.total_in_bytes / fs.available_in_bytes
- cpu.percent
4. 日志收集
- filebeat.harvester.open_files
- filebeat.harvester.running
- filebeat.input.log.files.truncated
6.2.2 备份策略
# 创建快照仓库
curl -X PUT "localhost:9200/_snapshot/backup" -H 'Content-Type: application/json' -d'
{
"type": "fs",
"settings": {
"location": "/mnt/backup/elasticsearch"
}
}
'
# 创建快照
curl -X PUT "localhost:9200/_snapshot/backup/snapshot-2026-03-25" -H 'Content-Type: application/json' -d'
{
"indices": "logs-*",
"ignore_unavailable": true,
"include_global_state": false
}
'
# 恢复快照
curl -X POST "localhost:9200/_snapshot/backup/snapshot-2026-03-25/_restore"
6.2.3 定期维护
# 每周任务
1. 检查集群健康状态
curl http://localhost:9200/_cluster/health
2. 检查磁盘使用率
curl http://localhost:9200/_cat/nodes?v
3. 验证备份完整性
curl http://localhost:9200/_snapshot/backup/_all
# 每月任务
1. 优化索引
curl -X POST "localhost:9200/logs-*/_forcemerge?max_num_segments=1"
2. 清理过期索引
curl -X DELETE "localhost:9200/logs-2026-02-*"
3. 更新ILM策略
# 根据实际情况调整保留时间
6.3 成本优化
6.3.1 存储优化
优化方向：
1. 调整采样率
- 错误日志：100%
- 关键业务：100%
- 普通日志：10-50%
- 调试日志：1-5%
2. 压缩
- 启用Elasticsearch压缩
- 使用更高效的日志格式
3. 分层存储
- 热数据：SSD（7天）
- 温数据：HDD（14天）
- 冷数据：对象存储（30天+）
预期成本降低：50-70%
6.3.2 查询优化
优化技巧：
1. 使用filter而不是query
- filter会被缓存
- 性能提升10倍
2. 避免通配符查询
- 使用term查询
- 使用match查询
3. 限制返回字段
- 只返回需要的字段
- 减少网络传输
4. 使用聚合而不是脚本
- 聚合性能更好
- 支持缓存
七、参考资料
7.1 官方文档
7.2 相关技术
- 分布式追踪：Jaeger、Zipkin
- 指标监控：Prometheus、Grafana
- 告警管理：AlertManager、PagerDuty
- 日志处理：Fluentd、Logstash
7.3 推荐阅读
- 《Elasticsearch权威指南》
- 《可观测性工程》（Observability Engineering）
- Google SRE Book - Monitoring Distributed Systems
7.4 开源项目
八、总结
日志聚合与分析是现代SRE体系的基础设施。通过建立完善的日志系统，我们可以：
✅ 快速定位故障：从数TB日志中秒级找到问题
✅ 深入理解系统：通过数据驱动的决策优化系统
✅ 提升可靠性：及时发现和处理潜在问题
✅ 降低成本：通过采样和分层存储优化成本
✅ 满足合规：完整的审计日志和追踪能力
关键成功因素：
- 从一开始就设计结构化日志
- 建立清晰的采样和保留策略
- 投入足够的资源进行运维
- 持续优化和改进
文档版本：v1.0
最后更新：2026-03-25
维护者：SRE Team