python日志采集需结构化输出、边缘采集与中心处理：用structlog或自定义formatter生成含service_name等字段的json日志；filebeat+redis实现高可用边缘采集；logstash消费redis并标准化入库es，小规模可异步直连es。
Python日志采集不是简单地把print换成logging，关键在于让日志可定位、可传输、可分析。核心要解决三个问题：怎么生成结构化日志、怎么从分散节点收上来、怎么进系统做后续处理。
Python端日志必须结构化输出
默认的logging输出是纯文本，下游工具很难解析。必须让每条日志自带字段，比如service_name、trace_id、level、timestamp这些基础键。
- 用structlog最省事：它自动把extra参数转成JSON字段，还能兼容OpenTelemetry上下文
- 自定义Formatter也行：继承logging.Formatter，在format()里手动拼字典再json.dumps
- 如果已接入OpenTelemetry，直接用opentelemetry-instrumentation-logging，trace_id和span_id会自动注入，不用额外写逻辑
边缘采集推荐Filebeat+Redis组合
单机跑Python服务时，直接读文件没问题；但微服务或K8s环境里，日志散在几十上百个Pod或实例上，必须靠专用采集器。
- Filebeat部署在每台机器或作为Sidecar容器，监听.log文件变化，轻量且稳定
- 配置processors.add_fields注入host、service、env等元信息，避免下游补全
- 发往Redis（list类型），用作缓冲：断网或ES抖动时，日志不丢，等恢复后继续消费
- 注意Redis高可用：生产环境别单点，至少配哨兵；吞吐特别大时可换Kafka
中心处理用Logstash标准化入库
Logstash不写代码，靠配置完成字段提取、格式转换、路由分发。
立即学习“Python免费学习笔记（深入）”；
- input插件连Redis：redis { data_type => "list" key => "filebeat" }
- filter里先json { source => "message" }解析原始JSON日志体，再用mutate重命名、删冗余字段
- output写Elasticsearch：按service_name动态建索引，比如logs-python-auth-2026.03，方便权限隔离与生命周期管理
小规模场景可直连ES，但要注意非阻塞
测试环境或单体应用，不想搭整套管道，也可以让Python自己把日志发ES，但得避开主线程阻塞。
- 用QueueHandler + QueueListener：日志先入队，后台线程异步发ES，不影响业务响应
- ES handler里加重试和降级：网络失败时写本地fallback文件，避免日志全丢
- 别在每个logger.info()里实时连ES——连接开销大，还容易拖慢接口
