如何用Nagios监控Nginx HTTP/2 Server Push日志并设置告警

HTTP/2 Server Push允许Nginx在客户端请求主资源时主动推送关联的CSS、JavaScript或图片，减少后续往返时间。不过这种机制也带来新的监控挑战：推送是否成功建立？推送资源是否被客户端拒绝？日志里哪些字段能反映这些问题？如果只能靠人工翻看访问日志，等发现问题时往往已经影响页面加载体验。Nagios作为成熟的监控平台，可以通过自定义插件解析Nginx日志文件，把推送失败率、推送耗时等指标纳入统一告警体系。

为Nginx日志增加HTTP/2 Push关键字段

Nginx默认的combined日志格式不会单独标记HTTP/2 Push相关请求，因此需要扩展log_format。常见的做法是利用http2_push_preload on自动推送，同时在响应头中添加一个自定义标识，例如X-HTTP2-Pushed，然后在访问日志中记录该响应头。这样后续的日志解析脚本就能准确识别哪条记录是推送请求，而不是普通的静态资源请求。

下面是一个Nginx配置示例，展示了如何定义专用的推送日志格式并应用在server块中。需要注意的是，Nginx本身没有直接暴露http2_push_count这样的内置变量，示例中通过响应头变量记录推送标识，实际生产环境可以配合map或njs模块动态写入推送资源数量。

http {
    log_format push_log '$remote_addr - $remote_user [$time_local] "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" "$http_x_http2_push"';

    server {
        listen 443 ssl http2;
        server_name ipipp.com;

        ssl_certificate     /etc/nginx/ssl/server.crt;
        ssl_certificate_key /etc/nginx/ssl/server.key;

        http2_push_preload on;

        location / {
            add_header X-HTTP2-Pushed pushed;
            access_log /var/log/nginx/push.log push_log;
            proxy_pass http://backend;
        }
    }
}

配置完成后，Nginx会为所有经过该location的HTTP/2请求写入带有pushed标识的访问日志。如果某个推送资源因为客户端不支持或者连接失效而失败，对应的状态码会记录在$status字段中，这为Nagios插件判断推送健康度提供了基础数据。另外建议对推送日志单独做轮转策略，避免时间窗口内文件过大影响解析效率。

在实际部署中，还需要关注日志文件的权限。Nagios插件通常以nagios用户运行，如果日志文件归Nginx的www-data或nginx用户所有，需要确保Nagios用户至少具备读取权限。可以通过将Nagios添加到对应组或使用logrotate的create参数调整权限。

编写Nagios自定义插件解析推送日志

Nagios插件的核心是退出码约定：返回0表示正常，1表示警告，2表示严重，3表示未知。插件还需要在标准输出中打印一行状态信息，并可选地输出性能数据。针对HTTP/2 Push日志，我们可以编写一个shell脚本，统计最近5分钟内推送请求总数、失败次数以及平均请求耗时，根据阈值返回对应的退出码。

脚本需要处理日志时间戳与当前时间的比较。由于Nginx日志时间格式为[14/Jan/2025:10:20:30 +0000]，而date命令在不同Linux发行版上对日期解析的兼容性略有差异，建议在脚本中先做一次格式转换。下面的示例使用date -d完成转换，并借助awk和bc进行数值计算。

#!/bin/bash
LOG=/var/log/nginx/push.log
WINDOW=300
NOW=$(date +%s)
FAIL_COUNT=0
TOTAL_COUNT=0
SUM_TIME=0

while read line; do
    ts=$(echo "$line" | awk '{print $4}' | sed 's/\[//; s/\/.*//')
    epoch=$(date -d "$ts" +%s 2>/dev/null)
    if [ $((NOW - epoch)) -le $WINDOW ]; then
        status=$(echo "$line" | awk '{print $9}')
        req_time=$(echo "$line" | awk '{print $10}')
        push_flag=$(echo "$line" | awk '{print $NF}')
        if [ "$push_flag" = "pushed" ]; then
            TOTAL_COUNT=$((TOTAL_COUNT+1))
            SUM_TIME=$(echo "$SUM_TIME + $req_time" | bc)
            if [ "$status" -ge 400 ]; then
                FAIL_COUNT=$((FAIL_COUNT+1))
            fi
        fi
    fi
done < "$LOG"

if [ $TOTAL_COUNT -eq 0 ]; then
    echo "UNKNOWN - 最近5分钟没有HTTP/2 Push记录"
    exit 3
fi

AVG_TIME=$(echo "scale=3; $SUM_TIME / $TOTAL_COUNT" | bc)
FAIL_RATE=$(echo "scale=2; $FAIL_COUNT * 100 / $TOTAL_COUNT" | bc)

if [ $(echo "$FAIL_RATE >= 20" | bc) -eq 1 ]; then
    echo "CRITICAL - 推送失败率 $FAIL_RATE% 总推送数 $TOTAL_COUNT 平均耗时 $AVG_TIME | fail_rate=$FAIL_RATE%;avg_time=$AVG_TIME"
    exit 2
elif [ $(echo "$FAIL_RATE >= 5" | bc) -eq 1 ]; then
    echo "WARNING - 推送失败率 $FAIL_RATE% 总推送数 $TOTAL_COUNT 平均耗时 $AVG_TIME | fail_rate=$FAIL_RATE%;avg_time=$AVG_TIME"
    exit 1
else
    echo "OK - 推送失败率 $FAIL_RATE% 总推送数 $TOTAL_COUNT 平均耗时 $AVG_TIME | fail_rate=$FAIL_RATE%;avg_time=$AVG_TIME"
    exit 0
fi

脚本中使用了>=进行数值比较，是因为在shell里直接写>会被当作重定向符号处理，而bc需要通过标准输入接收表达式。性能数据部分按照Nagios的label=value;warn;crit;min;max格式输出，这样Nagios可以通过性能数据采集机制将失败率和平均耗时保存下来，用于后续趋势分析。

需要特别提醒的是，日志解析脚本对push_flag的判断依赖于Nginx配置中响应头写入的值。如果响应头名称或值发生变化，脚本必须同步调整。此外，当日志文件被轮转后，脚本读取的是当前文件内容，旧日志不会被重复统计，因此建议将Nagios检查间隔控制在轮转周期以内，避免漏报。

配置Nagios服务与告警策略

有了插件之后，需要在Nagios的命令配置文件和服务定义文件中注册相关条目。命令定义中指定脚本路径和阈值参数，服务定义则绑定到具体主机，并设置检查间隔、重试次数和通知选项。下面是一个最简配置示例，实际使用时可以根据环境调整host_name和联系人组。

define command {
    command_name check_nginx_http2_push
    command_line /usr/local/nagios/libexec/check_http2_push.sh -f /var/log/nginx/push.log -w 5 -c 20
}

define service {
    use                     generic-service
    host_name               web-server
    service_description     HTTP/2 Push Log Monitor
    check_command           check_nginx_http2_push
    max_check_attempts      3
    check_interval          5
    retry_interval          1
    notification_options    w,u,c,r
    contact_groups          admins
}

告警阈值的设置需要结合业务流量模型。如果站点推送资源较少，失败率阈值可以设置得相对宽松，例如警告5%、严重20%；而对于高频推送的动态站点，短暂的网络抖动可能导致失败率瞬间升高，此时应当结合max_check_attempts和retry_interval避免一次瞬时波动就触发严重告警。建议先观察一周的日志数据，统计正常情况下的失败率分布，再确定合理的阈值边界。

另一个容易被忽略的点是通知风暴。如果多个虚拟主机共用同一个Nagios服务定义，一旦某台后端出现异常，可能同时收到大量告警。可以通过Nagios的依赖关系或服务组进行分组管理，也可以让插件返回更细粒度的状态信息，例如区分推送失败原因是客户端取消还是服务器主动关闭，从而帮助运维人员快速定位问题来源。同时，定期回顾性能数据趋势，能够判断HTTP/2 Push策略是否需要调整，例如减少推送资源数量或改为按需推送关键渲染路径资源。

Nginx HTTP/2 Server PushNagios监控插件日志解析告警修改时间：2026-09-21 01:29:40