以Nginx日志为统一源头，通过扩展log_format、map标记服务名、透传X-Request-ID实现上下文注入；Filebeat采集后经Kafka分topic传输；Python Consumer结构化解析并关联应用日志；应用侧用structlog输出结构化补充日志，共同构建端到端可观测闭环。
核心思路不是让 Python 写日志给大数据，而是以 Nginx 日志为统一源头，注入关键上下文，再通过轻量采集 + 结构化解析 + 侧边补充，形成端到端可观测闭环。
扩展 Nginx 日志格式，注入业务与性能字段
默认日志缺少后端服务标识、真实响应耗时、请求追踪 ID 等关键信息，需主动增强：
- 在
http块中定义增强型log_format，至少包含：$remote_addr $upstream_response_time $upstream_status $http_x_request_id $request_time "$request" $status $body_bytes_sent - 用
map指令按路径标记服务名，例如：map $request_uri $app_name { ~^/api/users/ "user-svc"; ~^/pay/ "payment-svc"; default "unknown"; }，再把$app_name加入日志格式 - 确保 Python 应用在入口处生成并透传
X-Request-ID（如用uuid4()），Nginx 会自动捕获为$http_x_request_id
部署 Filebeat 实现稳定日志采集
避免轮询、文件锁、权限异常等问题，用 Filebeat 直接对接 Nginx 日志文件：
Python 编程规范
下载
Python 编程规范与最佳实践。强制 PEP 8 代码风格、语法校验、单元测试执行，适用于代码编写、审查和重构。触发词：Python、代码规范、py_compile、单元测试。
- 每台 Nginx 服务器安装 Filebeat，配置监控
/var/log/nginx/access.log和error.log - 启用
json.keys_under_root: true（若日志已为 JSON 格式），否则用dissect或grok解析文本日志，推荐预编译 grok 模式：%{IP:remote_addr} - - \[%{HTTPDATE:time_local}\] "%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}" %{NUMBER:status} %{NUMBER:body_bytes_sent} "%{URI:referer}" "%{DATA:user_agent}" %{NUMBER:upstream_response_time} - 输出到 Kafka 时按类型分 topic：
nginx-access-raw、nginx-error-raw，保障顺序性与吞吐
Python Consumer 清洗与关联结构化数据
用 Python 编写 Kafka Consumer 完成字段 enrichment 和跨系统关联：
立即学习“Python免费学习笔记（深入）”；
- 解析原始日志后，补全地理信息（IP 归属）、设备类型（UA 解析）、错误分类（如 502→“上游不可达”）
- 提取
request_id字段，与 Python 应用侧输出的app.log（同样含该 ID）做 join，实现 Nginx 接入层 + Python 业务层日志对齐 - 清洗后的数据写入数仓目标：高频指标进 Doris（如每分钟 5xx 数），明细日志进 Hive 分区表（按日期+app_name），供批流一体分析
Python 应用侧输出结构化日志作为必要补充
Nginx 日志无法覆盖业务逻辑细节，必须由 Python 主动输出可对齐的补充日志：
- 使用
structlog或python-json-logger，强制输出 JSON，字段含：request_id、trace_id、event、level、duration_ms、error_type - 日志写入本地文件（如
/var/log/myapp/app.log），由另一组 Filebeat 采集，发往python-app-logstopic - 避免记录敏感参数（如密码、token），可在日志中间件中统一过滤或脱敏
