监控服务存活需先验证端口监听状态，再探测http/https健康接口，最后通过脚本或prometheus等工具实现自动化轮询与告警。
监控应用服务的存活状态，不能只看进程是否在运行，关键要验证“服务是否真正对外可用”。进程存在 ≠ 服务可用，这是运维中常见的误判点。
端口监听是第一道硬门槛
服务必须在指定端口上成功监听，才具备对外响应能力。比如 Web 服务监听 80/443、MySQL 监听 3306、Redis 监听 6379。仅靠 ps 查到进程，无法确认端口是否 bind 成功或被其他程序抢占。
- 用
ss -tuln | grep :端口号或netstat -tuln | grep :端口号检查监听状态 - 注意区分监听地址：
0.0.0.0:80表示可被外部访问，127.0.0.1:80则仅本机能连，对外不可用 - 若端口未监听，需排查服务配置（如 Nginx 的
listen设置）、权限（非 root 绑定 1024 以下端口失败）、端口冲突等问题
HTTP/HTTPS 接口探测更贴近真实可用性
端口通了，不代表业务接口正常。例如后端服务启动但数据库连接失败，返回 500 错误；或健康检查接口（如 /health、/actuator/health）返回非 200 状态码。
- 用
curl -I -s -o /dev/null -w "%{http_code}" http://localhost:8080/health获取 HTTP 状态码 - 对 HTTPS 服务加
-k跳过证书校验（测试环境），生产环境建议配合证书验证 - 可进一步解析响应体，比如检查 JSON 中
"status":"UP"字段，避免仅依赖状态码
结合轻量脚本实现自动化轮询
把端口和接口检查封装成可定时执行的脚本，比人工登录检查更可靠。例如 Shell 脚本每分钟检测一次，异常时发邮件或写日志：
- 定义服务列表：IP、端口、健康检查 URL、超时阈值（如 5 秒）
- 用
timeout 5 curl -fsS --head http://... > /dev/null实现带超时的探测 - 根据返回值（0=成功，非0=失败）记录结果，并触发告警（如调用企业微信 webhook）
- 搭配
crontab每 30 秒或 1 分钟执行一次（高频检测注意避免压测自身服务）
用专业工具做长期可观测性
单台服务器可手动脚本，多服务、多节点场景建议引入标准化监控体系：
- Prometheus + Blackbox Exporter：通过 ICMP、TCP、HTTP 主动探针采集存活指标，自动打标、存储、告警
-
Zabbix：内置 agent 或主动检查模板，支持自定义键值（如
web.page.get[http://x.x/x,200]）判断页面状态 - 自建 PHP/Python 健康页：统一聚合各服务的探测结果，生成 HTML 页面供人工快速巡检（类似 shell 脚本生成的 status 页面）
