5xx与4xx告警区分设置

监控告警没配置好，要么半夜被“狼来了”吵醒，要么真出大事了手机却静悄悄。运维和开发最头疼的，就是告警阈值设得不对。把5xx服务端错误和4xx客户端错误混在一起用同一套逻辑处理，是典型的配置灾难。5xx意味着你的服务挂了，必须立即响应；4xx多数是对方的问题或者权限拦截，属于非紧急信息。如果你把404和502设成同样的紧急程度，不出三天，值班人员就会对告警产生疲劳，真正服务器宕机时反而没人理了。

区分设置5xx和4xx告警，本质上是在区分故障责任方和影响范围。5xx系列（如500、502、503、504）代表服务端在处理请求时发生了错误。这百分之百是你自己的问题，意味着用户无法正常访问，业务流程中断。4xx系列（如400、401、403、404）代表客户端请求有误。除了403和部分400错误可能暗示配置变动外，绝大多数4xx是爬虫扫描、用户输错URL、密码过期或者权限不足。这类错误不直接代表服务崩溃，但大量聚集时可能暗示有恶意攻击或前端代码写错了参数。

不要只盯着负载均衡器上的总状态码计数。如果你使用Nginx，要在日志格式中把状态码、上游响应时间、请求URI和域名拆开记录。在Nginx配置中，利用map指令将状态码分类，能让你在后续的日志分析中直接按类别聚合。比如把状态码按首位数字归类，这样在Prometheus或ELK里就能直接按类别设置不同的告警规则。

# Nginx log_format 增加独立状态码字段
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for" '
                'rt=$request_time uct="$upstream_connect_time" '
                'uht="$upstream_header_time" urt="$upstream_response_time"';

# 使用 map 分类状态码
map $status $status_type {
    ~^[2]     2xx;
    ~^[3]     3xx;
    ~^[4]     4xx;
    ~^[5]     5xx;
    default   other;
}

在应用层面，你需要在全局异常捕获器里区分异常类型。连接超时、数据库连接池耗尽这类底层错误要直接映射为5xx并记录详细堆栈。而对于参数校验失败、token过期这类业务异常，要显式抛出特定错误码，并在中间件层统一拦截，确保返回给网关的是正确的4xx状态码，而不是笼统的500。

5xx告警必须遵循“零容忍”或“极低阈值”原则。对于核心业务接口，5xx错误率不应超过0.1%，一旦超过这个比例，说明代码逻辑或基础设施有严重缺陷。更关键的是，5xx告警要基于错误率陡增来触发，而不是单纯靠绝对数量。比如设置五分钟内5xx错误数超过10个且环比增长超过100%才触发告警，这样能避免偶尔的网络抖动造成误报。对于502和504，要额外关联上游服务的健康检查状态，如果上游服务已经挂了，只发一条503告警就够了，不需要再发一堆502告警。

4xx告警则需要“去噪”处理。404告警是噪音重灾区，必须过滤掉已知的扫描器特征和静态资源请求。如果你的网站被扫目录，404数量会瞬间飙升，但这不代表服务有问题。对于401和403，要关注集中爆发。如果某个用户或IP在短时间内出现大量403错误，可能是权限越权攻击或token批量过期，这需要安全告警介入，而不是运维告警。400错误通常意味着客户端传参格式不对，如果某个接口的400比例突然升高，大概率是前端发版引入了bug，应该通知开发群而不是直接打电话。

告警级别至少分为三级：紧急、警告和通知。所有5xx告警默认都是紧急级别，必须立即通过电话、短信或即时通讯工具进行强提醒。如果五分钟内没有确认，要自动升级通知范围到上级主管。4xx告警通常属于警告或通知级别。普通404和405错误可以只发邮件或推送到专门的日志频道，不需要人立即处理。但403和大量400错误需要设为警告级别，通过即时通讯工具的非紧急通道推送，要求业务方在几小时内确认。

还有一种容易忽略的情况是状态码的伪装。很多应用在发生未捕获异常时，框架会默认返回500，但有些开发为了美观会把所有错误都捕获后返回200，然后在响应体里写错误码。这种“软错误”监控系统根本识别不了。你必须在网关层做响应体校验，如果发现业务码指示失败，即便HTTP状态码是200，也要按业务错误类型归类到4xx或5xx的告警逻辑里去处理。

单纯看状态码数量容易误判。一个504网关超时，可能是下游数据库慢查询导致，也可能是第三方支付接口挂了。如果你不做链路追踪，所有5xx告警都指向网关，排查起来效率极低。通过集成OpenTelemetry或SkyWalking，在告警信息里附带上traceId和发生故障的具体服务名。这样在告警通知里就能直接看到是哪个服务、哪个接口、甚至是哪条SQL引发的5xx。对于4xx，链路追踪能帮你快速区分是网关层限流触发的429，还是业务层密码错误触发的401。

区分设置不能只停留在技术层面，必须结合业务。对于电商系统，下单接口的5xx和查询接口的5xx影响完全不同。你需要给不同API路径设置不同的权重。下单、支付、登录等核心接口的5xx阈值要调到极低，哪怕只有一个错误也要立即告警。而历史订单查询、用户头像上传这类非核心接口，可以适当放宽阈值。同样，4xx也要区分业务场景。登录接口的401是正常现象，但重置密码接口的401大量出现可能意味着有撞库行为。

实现方式上，可以在Prometheus的告警规则里按接口路径分组。先定义核心接口列表，然后为这些接口单独设置Recording Rules，计算其错误率。告警规则只针对这些核心指标进行判断，其他接口的错误单独归入一个非紧急汇总告警，每小时推送一次即可。

# Prometheus 告警规则示例
groups:
- name: http_errors
  rules:
  # 5xx 紧急告警：核心接口错误率超过阈值
  - alert: Critical5xxOnCoreAPI
    expr: |
      (
        sum(rate(http_requests_total{status=~"5..",path=~"/api/pay|/api/login"}[5m]))
        /
        sum(rate(http_requests_total{path=~"/api/pay|/api/login"}[5m]))
      ) > 0.001
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "核心接口5xx错误率超过0.1%"

  # 4xx 警告告警：非404错误突增
  - alert: Warning4xxSpike
    expr: |
      sum(rate(http_requests_total{status=~"4..",status!="404"}[5m])) > 50
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "4xx错误（不含404）数量突增，请检查业务日志"

配置完告警后，必须进行混沌工程测试来验证区分设置是否生效。主动向测试环境注入故障，比如用tc命令模拟网络延迟触发504，用压力测试工具打爆线程池触发503，同时用脚本模拟大量404请求。观察告警系统是否只对5xx进行了紧急通知，而对4xx只发了摘要邮件。如果发现404触发了电话告警，说明你的告警规则里漏掉了对404的过滤条件。这种测试要定期做，因为随着业务迭代，接口路径和状态码分布会变化，旧的阈值可能不再适用。

每周要回顾一次告警触发情况。统计5xx告警的误报率和漏报率，如果某个5xx告警连续一周都在同一时间点触发，但业务无感知，说明是定时任务导致，应该调整阈值或加时间窗口静默。对于4xx，要分析趋势。如果4xx错误率每周递增，可能是某个客户端版本有bug在扩散，或者有新的扫描器在活动。把这些分析结果反哺到告警规则里，持续优化4xx的过滤列表和5xx的阈值基线。

区分5xx和4xx告警，本质上是建立一套信号与噪音的分离机制。5xx是火警，必须立即出警；4xx是交通违章，需要记录和分析，但不必每次都拉响警笛。把这两者分开，你的监控系统才能真正做到既不错过故障，也不干扰值班人员的正常休息。