Linux怎么监控HTTP接口响应耗时如果超过3秒自动告警-LINUX-PHP中文网

curl -w 可提取各阶段耗时，关键指标是 time_starttransfer（ttfb），反映服务端真实响应起点；需配合 --connect-timeout 和 -m 超时控制、bc 浮点判断、告警冷却及业务状态校验，避免误报。

linux怎么监控http接口响应耗时如果超过3秒自动告警

直接用 curl 配合超时参数 + 状态判断就能实现，不需要上 Zabbix 或 Prometheus 这类重型工具——但必须加业务校验和冷却机制，否则一抖就告警。

用 `curl -w` 提取真实响应耗时

curl 的 -w 参数能输出各阶段耗时，关键不是总时间，而是 time_starttransfer（TTFB），它反映服务端真正开始响应的时间，比 time_total 更准。

只测 TTFB： curl -s --connect-timeout 2 -m 5 -w "%{time_starttransfer}" -o /dev/null http://localhost:8080/health
--connect-timeout 2 控制 DNS + TCP 连接阶段最多 2 秒，防卡在握手
-m 5 是整个请求最大耗时（含传输），超时返回非零退出码，可直接用于 if 判断
注意：如果后端用了 CDN 或反向代理，time_starttransfer 可能包含其缓存逻辑，需结合日志交叉验证

判断超时并触发告警的 Shell 逻辑

不能一测出 >3 秒就发邮件，得连续失败、有状态记忆、还要防恢复静默。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

用 bc 做浮点比较：$(echo "$ttfb > 3" | bc -l)，避免 Bash 不支持小数
记录上次告警时间到 /tmp/http_alert_last_sent，两次告警间隔至少 15 分钟
检查前先确认服务进程和端口是否正常，避免因 nginx worker 崩了但 master 还在导致误判

示例片段：

ttfb=$(curl -s --connect-timeout 2 -m 5 -w "%{time_starttransfer}" -o /dev/null http://localhost:8080/health 2>/dev/null)
if [ -z "$ttfb" ] || [ "$(echo "$ttfb > 3" | bc -l)" = "1" ]; then
  if [ ! -f /tmp/http_alert_last_sent ] || [ $(($(date +%s) - $(cat /tmp/http_alert_last_sent))) -gt 900 ]; then
    echo $(date +%s) > /tmp/http_alert_last_sent
    echo "HTTP TTFB $ttfb s on $(date)" | mail -s "⚠️ Slow API" admin@example.com
  fi
fi

为什么不用 `systemctl show -p SubState` 替代？

因为 SubState 只反映 systemd 对服务“启动意图”的理解，不等于接口真能响应。比如：

nginx master 进程在，但所有 worker 都卡死 —— SubState=running，但 curl 超时
Java 应用已启动，但 Spring Boot Actuator 的 /health 返回 {"status":"DOWN"} —— systemctl 显示 active，实际不可用
所以必须走真实 HTTP 探测，systemd 只能作为兜底（比如配合 ExecStartPost 健康检查）

真正难的不是测出耗时，而是区分“瞬时抖动”和“持续劣化”；一次超时可能是 GC 或磁盘 I/O 尖峰，连续三次才值得人看——这个阈值和冷却窗口，得根据你的业务容忍度调，别抄别人家的 3 秒或 15 分钟。