★ FEATURED ARTICLE Python后端中间件专题25“任务失败”如何找出是哪一张单——结构化日志与脱敏一条“Outbox publish failed”无法回答是谁提交、哪张工单、哪次事件也不能安全地把 broker URL 整串记下。同步请求、持久化 Outbox、异步 relay 和 Worker 分属不同执行环境排障需要一组可传递的标识而不是一份包含密码和请求体的巨大日志。目标、阅读条件与现场图本课目标是输出一行可解析 JSON、设计request_id → event_id → ticket_id的相关路径、在序列化前递归脱敏并能指出脱敏器保证不了什么。前置是 14 的 Outbox envelope、23 的代理生成X-Request-ID和 24 的边缘日志边界。只需安装项目依赖就能运行本地日志单测真实 API/relay/Worker 同时运行及跨容器日志关联是另一层验收。图里request_id是请求入口标识ticket_id是 PostgreSQL 业务实体event_id是 Outbox 事件身份重复投递仍保留同一 event ID。三者不应混成一个按请求查入口延迟、按 event 查 relay 重试与消费 receipt、按 ticket 查事实状态。traceparent是下一课要讲的跨进程因果上下文不能替代业务 ID。上一课练习答案答案 EX-24-01 [code]在project/保存为ex24_limit_audit.py静态检查与算术边界都可复现frompathlibimportPathimportre configPath(docker/nginx/nginx.conf).read_text(encodingutf-8)matchre.search(r\bclient_max_body_size\s(\d)m;,config)assertmatchisnotNoneassertre.search(r\bproxy_connect_timeout\s2s;,config)assertre.search(r\bproxy_read_timeout\s30s;,config)limitint(match.group(1))*1024*1024assertlimit1048576print(flimit{limit}over{limit1})运行命令python ex24_limit_audit.py。预期输出limit1048576 over1048577只读配置可能还不是已加载配置且 413 还依赖真实代理接收请求因此这不是 HTTP 413 的实际观测。答案 EX-24-02 [prose]413 先看 Nginx 的 body 限制、实际入口和 Nginx access/error504 看 upstream 地址、连接/读取超时与重试再查询 SQL 事实不能从代理超时推断 SQL rollback429 则看产生它的业务 Redis 预算或后来明确部署的边缘限流器当前 Nginx 快照没有limit_req。TLS overlay 静态测试只能检查监听、挂载与证书文件路径不能替浏览器验证可信 CA、SAN 和有效期。请求体可能含客户描述、凭据、Cookie 或个人信息错误原文也可能带 broker URL应记录事件类别与受控 ID/状态必要取证采用另有权限与保留期的隔离流程。一行 JSON 的安全范围JsonEventLogger.event先加入 UTC ISO 时间与事件名再将键值交给sanitize_fields递归处理最后json.dumps(..., ensure_asciiFalse)输出一行。键名含password/secret/token/authorization/cookie/credential大小写不敏感时值变[REDACTED]嵌套 dict/list 同样遍历超过 512 字符的字符串截断。保留error_typeTimeoutError避免把未审查的异常str(error)、完整请求头或 body 直接写进日志。最终项目已把埋点接到真实边界API 在事务提交并返回 Ticket 后写api_ticket_createdrequest_id/ticket_idrelay 对每个 envelope 写outbox_event_published或outbox_event_retryableWorker handler 写 handled/retryable/failed并带request_id/event_id/ticket_id。缓存失效和搜索投影的可重试失败走同一个受控日志与指标分支。API 的返回合同没有 event ID因此它不为日志额外查 Outbox也不伪造 event ID远端证据用ticket_id串三段并验证 relay 与 Worker 的event_id相同。日志不包含请求 title/body 或任意请求头Celery 首次发布和 Worker 每次task.retry()都显式固定argsrepr/kwargsrepr避免框架从实际 event args 再生成含客户字段的任务元数据。脱敏器仍是第二道防线。脱敏靠键不会在名为message的自由文本里识别Bearer ...str(unknown_object)也可能泄密。第一道防线是调用者不传敏感值第二道才是 sanitizer。公共访问日志只保留 Nginx 的安全$uri不含查询串两个 Uvicorn API 关闭自己的 access log避免框架默认日志重新打印带 query 的路径若把 Nginx 改成$request_uri或重新打开未经审查的框架 access log查询参数可能泄露。ID 在日志可查询但不应放进 Prometheus 标签。本地证据与具体排障从课程根运行正式本地命令python tools/verify_executable_revisions.py --lesson 25 --python python它独立安装 lesson-25 并验证历史合同但不启动三个真实进程。最终项目的远端命令是python scripts/run_remote_selector.py --checkpoint 25 --selector tests/integration/test_log_trace_remote.py::test_running_api_relay_worker_logs_correlate_without_credential_leak它在 POST 前分别保存api-a、api-b、relay、worker的日志 baseline经公共 Nginx 入口创建工单并从 201 响应取得由入口生成的X-Request-ID而不信任客户端提供的值。它还用同一 idempotency key 和不同 payload 触发受控 409 错误路径。等待 Worker 的持久化 effect 后它只审查 baseline 之后的新增切片要求两台 API 合计恰好一条目标 create、relay 恰好一条 confirmed、Worker 恰好一条 handled三段共享 request/ticket IDrelay 与 Worker 共享 event ID。互不相同的客户端 request ID、credential header、title、body、query 和 handled-error 哨兵必须在所有新增切片中完全缺席最后清理本次 SQL 行。未执行授权远端运行前状态仍是 PENDING这不等于已验证部署环境的真实凭据也不等于 PASS。若日志出现凭据停止扩散与访问、轮换相关测试凭据定位字段构造增加回归用例不要把原始泄露样本再贴入报告。本课练习练习 EX-25-01 [code]用JsonEventLogger写一条outbox_publish_failed包含request_id、ticket_id、broker_password和嵌套的authorization。断言业务 ID 可查询且两个秘密值都不在输出中打印 event、ticket ID 与脱敏后的 password。只运行内存lines.appendsink。练习 EX-25-02 [prose]列出排查“HTTP 201 后无通知”的相关顺序从哪个 ID 找到 Outbox再查 relay、Worker/receipt解释为什么可以把业务 ID 放在受控日志中却不能放进 Prometheus 的ticket_id/tenant_id标签指出“本地合同已通过”和“远端三进程证据仍 PENDING”的区别。结论与预告日志回答“一次事件发生了什么”但不能概括五分钟内有多少失败或长尾有多严重。26 用有界维度的 RED 指标把单个事故和服务面趋势接起来。完整核心模块结构化事件与递归脱敏from__future__importannotationsfromcollections.abcimportCallable,Mappingfromdatetimeimportdatetime,timezoneimportjson _SECRET_PARTS(password,secret,token,authorization,cookie,credential,)defsanitize_fields(value:object,*,max_string:int512)-object:Redact structured secret fields before serialization. Callers must still avoid passing secrets. This recursive policy is a second boundary that also handles a nested broker/client error context. ifisinstance(value,Mapping):cleaned:dict[str,object]{}forraw_key,childinvalue.items():keystr(raw_key)ifany(partinkey.casefold()forpartin_SECRET_PARTS):cleaned[key][REDACTED]else:cleaned[key]sanitize_fields(child,max_stringmax_string)returncleanedifisinstance(value,(list,tuple)):return[sanitize_fields(child,max_stringmax_string)forchildinvalue]ifisinstance(value,str)andlen(value)max_string:returnvalue[:max_string]…ifisinstance(value,(str,int,float,bool))orvalueisNone:returnvaluereturnstr(value)classJsonEventLogger:Emit one machine-readable event without coupling to a log vendor.def__init__(self,write_line:Callable[[str],object]print)-None:self._write_linewrite_linedefevent(self,event:str,**fields:object)-None:payloadsanitize_fields({timestamp:datetime.now(timezone.utc).isoformat(),event:event,**fields,})self._write_line(json.dumps(payload,ensure_asciiFalse,separators(,,:)))
阅读完成 · 觉得有帮助？
