prometheus 无法直接抓取 nginx 错误日志，需通过 nginx-prometheus-exporter 等工具将 error.log 解析为结构化指标（如 nginx_exporter_error_count{level="error", message="connection refused"}），再由 prometheus 抓取 /metrics 端点，grafana 展示趋势并告警，以定位上游超时、ssl 握手失败等根因问题。
直接用 Prometheus 抓取 Nginx 错误日志频次不现实——它原生不解析文本日志。真正可行的路径是：把错误日志转成指标，再由 Prometheus 采集，Grafana 展示并告警。
让错误日志变成可采集的指标
Nginx 的 error.log 是纯文本，Prometheus 只认 /metrics 这类结构化指标端点。所以必须加一层转换：
- 用 nginx-prometheus-exporter（推荐）：它支持解析 error.log 文件，自动提取错误类型（如 “connect() failed”、“no live upstream”、“upstream timed out”）、频率、模块名等，并暴露为 Prometheus 格式指标，例如：
nginx_exporter_error_count{level="error", module="http_upstream", message="connection refused"} - 或用 Filebeat + Prometheus Exporter 模块：Filebeat 读 error.log，匹配预设正则提取字段，再通过其 prometheus 模块输出指标
- 避免手动写脚本轮询日志：易丢行、难对齐时间窗口、无重试机制
Prometheus 配置抓取错误指标
在 prometheus.yml 中新增 job，指向 exporter 的指标地址（默认 :9113/metrics）：
- 确保 exporter 启动时指定了 error log 路径，例如：
./nginx-prometheus-exporter --nginx.error-log-path /var/log/nginx/error.log - job 配置示例：
- - job_name: 'nginx-errors'
static_configs:
- targets: ['192.168.1.100:9113']
metrics_path: /metrics - 加 relabel_configs 区分不同 Nginx 实例，比如基于主机名打标：
relabel_configs:
- source_labels: [__address__]
target_label: instance
replacement: nginx-prod-01
Grafana 中看错误趋势与设告警
导入或新建面板，关键查询和告警逻辑如下：
- 查最近5分钟各错误类型的累计次数：
sum by (message, level) (rate(nginx_exporter_error_count[5m])) - 查每秒错误率突增（如 1 分钟内 error 级别错误超 3 次/秒）：
rate(nginx_exporter_error_count{level="error"}[1m]) > 3 - 重点监控高频致命错误：
• upstream connect timeout
• no live upstreams
• SSL_do_handshake() failed - 在 Grafana Alert Rule 中配置阈值，触发后推送到钉钉/企业微信/Alertmanager
补充：为什么不用 access log 做错误频次？
access.log 记录的是请求响应结果（$status），它反映的是“客户端看到的错误”，比如 502/503/504；而 error.log 记录的是 Nginx 自身运行期的底层失败原因，比如上游崩了、SSL 握手失败、磁盘满导致无法写缓存等——这才是定位根因的关键。两者互补，但监控错误根源必须依赖 error.log 解析。
