分布式日志收集需统一采集、标准化格式、可靠传输，推荐Filebeat+Kafka+Logstash/Elasticsearch组合；Python日志须注入trace_id/span_id实现链路追踪打通；实时监控聚焦高频错误、慢请求关联异常及业务指标提取；存储采用热/温/冷分层策略并配合采样与过滤控本。
分布式日志收集：从本地到中心化
单机日志在微服务或容器化环境中很快会失效——日志散落在不同节点、命名不统一、轮转策略不一致，查问题像大海捞针。核心思路是：统一采集、标准化格式、可靠传输。
推荐用 Filebeat + Kafka + Logstash/Elasticsearch 组合（轻量级且成熟）：
- Filebeat 部署在每台应用服务器上，监控 Python 的 logging 输出文件（如
app.log），自动识别多行异常栈（需配置multiline.pattern） - 日志内容必须含结构化字段：
service_name、host、trace_id（配合 OpenTelemetry 或自定义上下文注入）、level、timestamp - Kafka 作为缓冲队列，避免瞬时峰值压垮下游；Logstash 做清洗（比如提取 JSON 字段、过滤 DEBUG 日志）、丰富（添加地理信息、服务版本）
Python 日志与链路追踪打通
光有日志不够，得知道这条日志属于哪个请求、经过哪些服务。关键是在 logging 的 LogRecord 中注入追踪上下文。
以 OpenTelemetry Python SDK 为例：
立即学习“Python免费学习笔记（深入）”；
- 初始化时设置全局 tracer 和 propagator（如
TraceContextTextMapPropagator） - 自定义
logging.Filter，在filter(record)中读取当前 span 的 trace_id、span_id，并写入record.trace_id、record.span_id - Formatter 中直接引用：
%(trace_id)s %(span_id)s %(levelname)s %(message)s - HTTP 中间件（如 Flask/Bottle 的 before_request）自动创建 entry span，并将 trace_id 注入 logging context
这样一条错误日志就能在 Kibana 里点击 trace_id，跳转到 Jaeger/Zipkin 查完整调用链。
实时监控与智能告警
日志不是攒着看的，要变成监控信号。重点盯三类模式：
- 高频错误突增：例如 5 分钟内 ERROR 日志超 100 条（用 Elasticsearch 的 date histogram + terms 聚合实现）
-
慢请求关联异常：把 access log（含耗时）和 app log（含报错）按
request_id关联，筛选 “耗时 >2s 且含 Exception” 的组合 -
业务指标提取：用正则从日志中抽字段，如
"order_created: id=(\w+), amount=(\d+)"→ 计算每分钟下单量、平均金额
告警建议用 ElastAlert 或 OpenSearch Alerting，避免直接脚本轮询——支持静默期、告警合并、通知渠道（企业微信/钉钉/Webhook）。
日志存储与成本控制
全量日志存一年不现实。分层策略更实用：
- 热数据（7 天）：SSD 存 ES，支持全文检索、聚合分析
- 温数据（90 天）：转存对象存储（S3/OSS），用 Presto/Trino 查询（需提前按日期建分区）
- 冷数据（1 年+）：归档压缩后离线保存，仅用于合规审计
同时在 Filebeat 或 Logstash 层做采样：对 INFO 级别日志按 10% 采样，ERROR/WARNING 全量保留。用 drop_event_if 过滤无意义日志（如健康检查 ping、静态资源访问）。
