直接监控 VSCode 服务的 HTTP/WS 端口即可，推荐用 hertzbeat「端口可用性」模板；需填宿主机 IP 或 ClusterIP，禁用 127.0.0.1；钉钉收不到通知主因是 Webhook 配置错误或网络不通；端口监控不足，应组合 HTTP 健康检查、进程内存、WebSocket 连接数；hertzbeat 与 Alertmanager 需明确分工，避免重复告警，并补全 severity 和 annotations.summary 字段。
VSCode插件服务暴露端口后，怎么加监控？
直接监控 code-server 或 vscode-remote-ssh 的 HTTP/WS 端口即可，不需要额外 Agent。hertzbeat 的「端口可用性」模版最轻量、最贴合——它只发 TCP SYN 包，不依赖服务返回内容，哪怕 VSCode 启动卡在登录页，只要端口监听着就判为正常。
常见错误现象：
- 填了
localhost:8080测试通，但部署到私有云后监控始终失败 → 实际是容器或宿主机防火墙没放开对应端口，telnet your-host-ip 8080在监控服务器上执行不通 - 用
127.0.0.1做监控地址 → hertzbeat 采集器运行在独立容器里，127.0.0.1指向的是它自己，不是你的 VSCode 服务
实操建议：
- VSCode 服务部署在 Docker 中时，确保
ports映射已发布（如-p 8080:8080），且宿主机 iptables/firewalld 允许该端口入站 - 监控地址填宿主机 IP 或 Kubernetes Service ClusterIP（若同 namespace）+ 端口，不要填容器内网 IP（如
172.18.0.x） - 间隔设为 30 秒足够，太密会增加连接压力；超时建议设 5 秒，避免因 VSCode 启动慢误报
告警通知为什么钉钉收不到？排查路径是什么
90% 是配置错在 Alertmanager 或 hertzbeat 的通知链路里，和钉钉本身无关。hertzbeat 自带钉钉 Webhook，但默认不校验 SSL 证书、不支持代理、不重试失败请求——这些细节一漏就静默失败。
实操建议：
- 先在 hertzbeat 界面测试钉钉 Webhook：
https://oapi.dingtalk.com/robot/send?access_token=xxx，确认返回{"errcode":0,"errmsg":"ok"} - 检查 hertzbeat 容器是否能访问公网（私有云常禁外网）：进容器执行
curl -v https://oapi.dingtalk.com，若超时需配宿主机 proxy 或改用内网钉钉群机器人（企业自建） - Webhook URL 中的
access_token和secret必须完整粘贴，少一个字符或多了空格都会返回400 - 别忽略 hertzbeat 日志：
docker logs hertzbeat | grep -i dingtalk，常见错误是java.net.UnknownHostException: oapi.dingtalk.com（DNS 不通）或Connection refused（代理未生效）
想监控 VSCode 插件实际负载，光看端口够吗？
不够。端口通 ≠ 可用。比如 code-server 进程僵死、内存爆满、WebSocket 连接数超限，端口仍监听但用户无法新建文件或保存代码。
推荐组合监控：
-
HTTP 接口健康检查：用 hertzbeat 的
http模版，GET/healthz（code-server 默认提供）或/api/health（部分定制版），检查响应码和 body 是否含"status":"ok" -
进程资源指标：在宿主机跑
node_exporter，通过 Prometheus 抓取process_resident_memory_bytes{job="code-server"}，设阈值 >1.5GB 告警 -
WebSocket 连接数：若用 Nginx 反代 code-server，加
ngx_http_stub_status_module，暴露/nginx_status，hertzbeat 用http模版解析Active connections:行
注意：hertzbeat 的 http 模版不支持 Basic Auth，若 code-server 加了登录页，得先关掉认证或换用 curl 自定义脚本采集。
Alertmanager 和 hertzbeat 告警规则怎么不冲突？
它们根本不在一个层级：hertzbeat 是独立告警源（类似 Prometheus 的 exporter + rules），Alertmanager 是告警中转器。如果你同时用两者，必须明确谁负责“发现问题”、谁负责“通知分发”。
典型踩坑：
- hertzbeat 已配置钉钉通知，又把它的告警推给 Alertmanager → 一条故障收到两遍钉钉消息
- Alertmanager 的路由规则匹配了 hertzbeat 发来的告警，但没配
continue: true，导致后续路由被跳过 - hertzbeat 告警的
labels缺少severity字段，Alertmanager 默认归到info组，而你的邮件通知策略只处理warning及以上
实操建议：
- 统一入口：让 hertzbeat 只做采集和原始告警生成，关闭其内置通知，全部走 Alertmanager（需开启 hertzbeat 的
prometheus-exporter模块，再配 Prometheusalert_rules） - 字段对齐：在 hertzbeat 的告警模板 YAML 里显式写
labels: { severity: "warning", service: "code-server" }，否则 Alertmanager 路由难匹配 - 测试路由：用
amtool alert list查看告警是否进来了，再用amtool config dump确认路由树是否命中你期望的 receiver
真正容易被忽略的点是：hertzbeat 默认告警没有 annotations.summary，而 Alertmanager 的模板渲染依赖这个字段，不填会导致钉钉消息体为空——看着告警触发了，点开却什么都没有。
