17370845950

Python日志系统是涵盖采集、结构化、集中存储、查询分析与可视化的闭环，需规范JSON格式、集中收集（如Filebeat直传ES）、Kibana分析告警，并结合OpenTelemetry实现全链路追踪。

Python日志系统不只是写几行logging.info()，而是一整套从采集、结构化、集中存储到查询分析和可视化展示的闭环。核心在于：日志要可追溯、可过滤、可聚合、可告警。

一、规范日志格式，为后续分析打基础

默认的logging输出是纯文本，难解析。必须统一使用JSON格式，并包含关键字段（如服务名、追踪ID、模块、等级、时间戳）。

推荐用python-json-logger库，配合自定义Logger：

• 安装：pip install python-json-logger
• 配置示例中加入extra参数注入request_id或trace_id，便于链路追踪
• 避免在message里拼接敏感信息（如密码、token），应作为独立字段并标记is_sensitive=True，后续可在ES中做脱敏处理

二、集中收集：Filebeat + Logstash 或直接对接Elasticsearch

单机日志用RotatingFileHandler够用，但多服务/容器环境必须集中化。推荐轻量方案：Filebeat直传ES（跳过Logstash，降低延迟和运维成本）。

关键配置点：

• Filebeat中设置processors自动解析JSON日志（decode_json_fields）
• 为不同服务打tag（如service: user-api），方便Kibana按服务筛选
• 启用fields_under_root: true，让自定义字段（如user_id）直接出现在ES文档顶层，不用嵌套访问

三、分析与告警：用Kibana做实时看板 + Elastic Watcher设阈值告警

日志不是存完就结束，得“会说话”。例如：

• 建一个折线图，统计每分钟level: "ERROR"数量，叠加5分钟移动平均线，异常突增一眼可见
• 用Lens做散点图，横轴是响应时间duration_ms，纵轴是status_code，快速定位慢且失败的接口
• 用Watcher监听error_count > 10 in last 1m，触发企业微信/钉钉机器人通知

四、进阶技巧：结合OpenTelemetry实现全链路日志关联

当请求跨多个微服务时，仅靠request_id不够稳定。建议接入OpenTelemetry Python SDK：

• 自动注入trace_id和span_id到日志上下文
• 日志字段中同时存在trace_id和service.name，就能在Jaeger或Kibana APM中点击跳转查看完整调用链
• 用otel-python-instrumentation自动捕获Flask/FastAPI等框架的出入参、SQL慢查询，无需改业务代码

不复杂但容易忽略：日志时间必须用UTC，所有服务统一时区；保留原始日志文件至少7天，防止ES故障时数据断档。