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