日志监控需结构化记录、分级告警、可追溯回放：记录含URL、状态码等上下文；ERROR/WARNING/INFO三级分类；接入ELK+告警；上线前做健康检查。
日志监控不是加几行 print 就完事，而是让爬虫“会说话”——出问题时能说清在哪、为什么、怎么修。核心是：结构化记录 + 分级告警 + 可追溯回放。
日志内容必须带上下文，不能只记“失败”
光写“请求失败”没用，得包含 URL、状态码、重试次数、代理 IP、时间戳、异常类型（ConnectionError？Timeout？403？）。建议用字典格式统一输出，例如：
- 用 logging.Logger 配合 extra 参数注入 request_id、spider_name、proxy 等字段
- 对关键步骤（如登录、翻页、解析）单独打点，标记 success/fail + 耗时
- 解析失败时，除了报错，顺手把原始 HTML 片段（截前500字符）也记进日志，方便复现
按严重程度分级，该报警的别沉默，该忽略的别刷屏
INFO 级别别塞太多，重点保留下列三类：
- ERROR：请求超时、解析字段缺失、反爬拦截（如检测到验证码跳转）、数据库写入失败
- WARNING：HTTP 状态码非 200 但未抛异常（如 429 被限流）、字段为空但有默认值兜底、重试达上限仍失败
- INFO：单个任务启停、成功抓取条数、关键中间状态（如“已切换 User-Agent”）
日志要能查、能聚合、能联动
本地文件日志只是起点，生产环境需接入可观测体系：
- 用 RotatingFileHandler 控制单文件大小和保留天数，避免磁盘爆满
- 通过 Logstash / Filebeat 实时采集，发往 Elasticsearch；用 Kibana 做关键词筛选（如 status_code:403）、错误趋势图、高频失败 URL 排行榜
- 对 ERROR 级别日志配置 Webhook（如飞书/钉钉机器人），附上 request_id 和最近 3 条相关日志，点击直达 Kibana 查询链接
每次上线前跑一次“日志健康检查”
新版本发布不等于日志就可靠，建议上线前验证：
- 模拟一个被封 IP 场景，确认是否打出 WARNING + 切换代理动作 + 记录旧 IP
- 故意改错 XPath，看解析失败日志是否含原始 HTML 片段和报错堆栈
- 批量触发 10 次请求，检查日志中 request_id 是否唯一、时间戳是否有序、耗时字段是否非空
基本上就这些。日志监控不是越详细越好，而是让每条日志都承担明确角色：定位问题、辅助决策、沉淀经验。不复杂但容易忽略——真正救你命的，往往是那条写着“当前代理已被目标站封禁”的 WARNING。
