Nginx error_log 接入监控系统需确保日志级别覆盖ERROR及以上、结构化采集、精准告警与链路验证；默认error级别不涵盖alert/emerg级关键错误，须显式配置并避免局部覆盖，配合采集器解析字段、打标分类，关联access_log定位根因，保留7天日志并手动触发emerg级报错验证全链路。
要让 Nginx 的 error_log 真正接入监控系统并实时捕获 ERROR 级别日志，核心不是“把日志存下来”，而是“让关键错误可识别、可路由、可告警”。ERROR 级别本身是默认开启的，但直接依赖它容易漏掉真正要关注的问题——比如 upstream timed out 是 ERROR，而 Too many open files 默认却是 alert 级别，不调高日志等级就根本看不到。
确认 error_log 级别覆盖 ERROR 及以上
Nginx 默认 error_log /var/log/nginx/error.log error;，这会记录 error、crit、alert、emerg 四级。但要注意：
- 某些关键问题（如文件句柄耗尽）只在
alert或更高出现，若你手动改成了warn，反而会丢失 ERROR 级别之上的真实故障信号 - 全局配置可能被 server 块中的局部
error_log覆盖，务必检查具体出问题的虚拟主机是否单独设置了更低级别（如error_log ... warn;） - 推荐显式写为：
error_log /var/log/nginx/error.log error;，避免继承歧义
用结构化字段增强日志可采集性
原始 error_log 是纯文本，监控系统难以解析。需配合日志采集器做两件事：
- 在采集端（如 Filebeat 或 Vector）启用 Nginx error log 解析模块，自动提取时间、级别、PID、消息主体等字段
- 为 ERROR 级别日志打上固定标签，例如：
fields: { log_type: "nginx_error", severity: "error" } - 对高频 ERROR（如
upstream timed out）额外添加分类标签：error_category: "upstream_timeout"，便于后续按类聚合与告警
监控平台侧的关键配置
日志进到 Elasticsearch、Loki 或其他后端后，不能只靠关键词搜索，要建立可持续运行的检测逻辑：
- 设置告警规则：例如 “5 分钟内 ERROR 日志条数 > 10 条”，或更精准地匹配
upstream timed out+while connecting to upstream组合 - 关联 access_log：ERROR 日志只说“失败”，access_log 才有响应时间、状态码、URI；用 client IP + 时间戳 + URI 三字段交叉查询，快速定位是否某接口集中超时
- 保留至少 7 天的 error_log 历史，避免夜间突发错误因日志轮转被清空；建议用
logrotate配合dateext和maxage 7
生产环境必须做的验证动作
上线前务必手动触发一次典型 ERROR，确认整条链路生效：
- 临时在某个 server 块里加一行无效 SSL 指令（如
ssl_certificate /nonexistent.crt;），重载 Nginx，观察是否在 error_log 中生成emerg级报错 - 检查采集器日志，确认该条记录是否已发送、字段是否解析成功、是否有丢数据提示
- 在监控平台搜索该时间点的 error 日志，看是否能按 severity=error 精准筛选出来
