文本处理日志监控核心是建立“可定位、可追溯、可预警”的轻量闭环，关键在于统一JSON Lines格式日志、轻量采集路由（本地文件+脚本转发）、基于业务语义的精准告警及静态HTML聚合看板。
文本处理项目日志监控的核心，不在于堆砌工具，而在于建立“可定位、可追溯、可预警”的轻量闭环。关键在三件事：统一日志格式、集中采集路径、分级触发响应。
统一结构化日志输出
所有文本处理模块（如清洗、分词、NER、导出）必须输出标准字段，避免自由文本难以解析。推荐使用 JSON 行格式（JSON Lines），每行一条日志，含固定字段：
- timestamp：ISO8601 格式（如 2024-05-22T14:23:05.123Z），确保时序准确
- level：ERROR / WARN / INFO / DEBUG，用于后续过滤和告警分级
- module：标明来源（如 cleaner、spacy_ner），便于定位问题模块
- task_id：关联同一批文本处理的全链路（如 batch_20240522_001），支持跨模块追踪
- message：简明描述，避免堆砌堆栈；异常时附加 error_type 和 error_detail 字段
轻量采集与路由（不依赖重服务）
避免引入 Elasticsearch 或 Kafka 增加运维负担。用成熟小工具组合即可：
- Python 进程内用 logging.handlers.RotatingFileHandler 写入本地带日期前缀的日志文件（如 app_20240522.log）
- 部署 tail -F + awk 或轻量 Python 脚本（如 logstash-forwarder 替代品）实时读取新行，按 level/module 过滤后转发
- ERROR 日志直推企业微信/钉钉机器人（用 Webhook）；WARN 日志写入 SQLite 汇总表，供定时巡检；INFO 级别可暂存本地归档
基于规则的精准告警触发
不靠“日志量突增”这类模糊指标，聚焦业务语义异常：
- 连续 3 条 ERROR 含 "timeout" 或 "connection refused" → 触发下游服务不可达告警
- 单个 task_id 下出现 >5 条 WARN，且含 "encoding_mismatch" → 标记该批次文本编码风险，暂停后续处理并通知数据方
- 某 module 的 INFO 日志中 "processed_count" 字段 5 分钟无更新 → 判定模块卡死，自动重启子进程（需配合 supervisor 或 systemd）
人工可读的聚合看板（静态 HTML 即可）
每天凌晨用简单脚本生成一份 HTML 报告，放在内网静态服务下，包含：
- 昨日各 module 的 ERROR/WARN 数量柱状图（用 Chart.js 渲染）
- TOP 5 异常 task_id 列表，点击展开对应原始日志片段（截取前后 3 行上下文）
- 高频 error_type 统计（如 UnicodeDecodeError 占比 62%）→ 直接提示“请检查输入文件编码声明”
基本上就这些。不复杂但容易忽略的是 task_id 的全程透传和 error_type 的标准化命名——这两点决定了日志能不能真正服务于排障，而不是变成噪音池。
