Vercel、域名与 SSL 监控告警怎么设计？日志、指标与故障响应

为什么 Vercel 上的域名与 SSL 需要独立监控体系

依赖 Vercel 托管前端应用或 API 路由的项目，容易陷入一个认知误区：Vercel 作为平台方已经处理了证书自动续期和全球 CDN 分发，因此域名与 SSL 状态天然可靠。实际工程经验表明，Vercel 的自动化并不能覆盖所有故障场景。

证书自动续期依赖 DNS 验证记录（CNAME 或 TXT）的正确配置。如果域名托管在第三方 DNS 服务商，而 Vercel 的验证请求因权限或记录过期失败，证书会在到期前 7 天停止续期尝试，最终导致浏览器安全警告。域名解析本身也存在风险：Apex 域名（如 example.com）的 ALIAS 或 ANAME 记录在某些 DNS 服务商下行为不一致，可能返回过时的 IP 地址。此外，Vercel Edge Network 的局部节点故障、DNS 传播延迟或 DNSSEC 配置冲突，都会导致部分用户访问失败。

这些故障不会在 Vercel 控制台的“状态”页面体现，因为平台只承诺整体可用性，不担保单个自定义域名的解析正确性。因此，建立独立的监控体系是必要的。这套体系需要覆盖三个层面：日志记录请求链路中的异常、指标量化证书与域名的健康度、告警分级触发不同响应动作。

日志采集：从 Vercel 边缘到应用层的可观测数据

Vercel 提供了内置的 Logs 和 Observability 功能，但默认保留周期短（Pro 计划 7 天，Enterprise 可定制），且日志内容以请求级为主。对于域名和 SSL 相关的故障排查，需要额外捕获以下三类日志。

边缘日志中的 SSL 握手失败记录

当用户通过 HTTPS 访问时，Vercel Edge Network 会记录 TLS 握手阶段的状态码。常见的错误包括：

• `525`：SSL 握手失败，通常因为证书链不完整或私钥不匹配。
• `526`：无效的 SSL 证书，证书已过期或被吊销。
• `527`：域名与证书中的 CN/SAN 不匹配，多发生在新增子域名后未及时更新证书。

Vercel 的 Logs 面板支持按状态码过滤，但不会主动推送这些错误。建议通过 Log Drains 将日志实时导出到外部存储（如 Logtail、Datadog 或自建 Loki），然后设置查询告警：当 525/526/527 状态码在 5 分钟内出现超过 3 次时触发通知。

DNS 解析日志

域名解析失败很难从 Vercel 侧直接捕获，因为请求根本到不了边缘节点。解决办法是在 DNS 服务商侧启用解析日志（如 Cloudflare DNS Analytics、AWS Route 53 Query Logs），将 NXDOMAIN 或 SERVFAIL 记录导出到 S3 或 Kinesis。对于使用 Vercel 默认 DNS 的域名，可以通过 `dig` 命令定期检查权威解析结果，并将输出与预期记录对比，差异部分写入日志。

应用层日志中的证书验证事件

如果项目使用 Vercel Edge Functions 或 Serverless Functions 对外部 API 发起 HTTPS 请求，需要在函数代码中捕获 SSL 证书验证异常。Node.js 环境下，`tls.connect` 的 `cert` 事件或 `axios` 的 `ERR_TLS_CERT_ALTNAME_INVALID` 错误都应被记录。这些日志能帮助发现上游服务的证书问题，避免误判为 Vercel 域名故障。

指标定义：量化健康度的关键信号

日志是离散的事件记录，指标则提供连续的健康度视图。针对 Vercel 域名与 SSL，建议定义以下四个核心指标。

证书剩余有效期（Certificate Remaining Days）

这是一个基础但容易忽略的指标。Vercel 自动续期的证书通常有 90 天有效期，但手动上传的自定义证书需要自行管理。定期调用 Vercel API 的 `GET /v9/certs` 端点，解析每个证书的 `expiresAt` 字段，计算剩余天数。当剩余天数低于 30 天时标记为“注意”，低于 14 天时标记为“危险”。

DNS 解析成功率（DNS Resolution Rate）

使用分布在多个地理位置的探测节点（如 Checkly、Better Stack 或自建 Puppeteer 脚本），每 5 分钟对目标域名发起一次 DNS 查询。统计成功解析的比例，排除本地缓存干扰。如果连续 3 次探测失败，说明 DNS 配置可能存在全局性问题。

证书链验证结果（Chain Validation Status）

证书链的完整性直接影响浏览器信任。使用 `openssl s_client -showcerts -connect` 命令模拟 TLS 连接，检查返回的证书链是否包含中间证书。Vercel 自动生成的证书通常链完整，但自定义证书常见缺少中间证书的问题。建议每 24 小时执行一次验证，记录 Pass/Fail 状态。

边缘节点可达性（Edge Reachability）

从不同区域（至少覆盖北美、欧洲、亚太）对目标域名发起 HTTP HEAD 请求，记录响应时间与状态码。如果某个区域持续超时或返回 5xx，可能是 Vercel 边缘节点故障或 DNS 路由异常。这个指标需要与 Vercel 官方状态页交叉验证，排除平台全局故障。

链路追踪：定位故障的上下游依赖

单点指标只能告知“出了问题”，链路追踪才能回答“问题出在哪”。对于域名与 SSL 故障，典型的追踪链路包含三个跳转点。

用户请求到边缘节点

当用户报告无法访问时，首先确认 DNS 解析是否将请求指向了正确的 Vercel 边缘 IP。使用 `traceroute` 或 `mtr` 工具查看网络路径，如果请求中途被拦截或路由到错误节点，问题可能出在 DNS 服务商或 ISP 层面。Vercel 的 `x-vercel-id` 响应头可以标识处理请求的边缘节点 ID，结合 Vercel 的节点列表可以判断是否被路由到异常节点。

边缘节点到源站

Vercel 的 Serverless Functions 会回源到部署在 AWS Lambda 上的代码。如果函数返回 502，需要检查 Vercel 与后端 API 之间的 SSL 握手。在函数日志中搜索 `connect ECONNREFUSED` 或 `certificate has expired`，确认是 Vercel 自身证书问题还是上游服务证书问题。

证书续期流程

证书续期失败通常发生在 DNS 验证环节。Vercel 会在证书到期前 30 天开始自动续期，如果续期失败，会在项目设置的“Domains”页面显示红色警告。追踪续期状态需要调用 Vercel API 的 `GET /v9/certs/events` 端点，获取每次续期尝试的日志。常见的失败原因包括：DNS 验证记录未正确设置、TXT 记录被 DNSSEC 签名阻止、域名所有权验证过期。

告警分级：减少噪音，提升响应效率

告警设计的核心不是“覆盖所有异常”，而是“在正确的时间通知正确的人”。基于故障影响范围，将告警分为四个等级。

P0（灾难性故障）：域名完全不可解析

触发条件：连续 5 分钟 DNS 解析成功率为 0%，且至少两个探测区域同时报告失败。
通知方式：电话或短信直接联系运维负责人，同时推送至 PagerDuty 或 Opsgenie。
响应要求：立即检查 DNS 服务商控制台，确认域名是否被删除、暂停或 DNSSEC 签名错误。如果无法在 15 分钟内恢复，考虑临时切换域名到备用 CDN。

P1（严重故障）：证书过期或 HTTPS 不可用

触发条件：证书剩余有效期低于 7 天，或边缘节点返回 525/526 状态码的比例超过 5%。
通知方式：即时通讯工具（Slack、钉钉）的专用告警频道，@值班人员。
响应要求：如果证书由 Vercel 自动管理，手动触发续期（通过 Vercel CLI 执行 `vercel certs issue`）。如果是自定义证书，立即上传新证书并验证链完整性。

P2（警告状态）：证书即将到期或局部节点异常

触发条件：证书剩余有效期低于 30 天，或单个区域的边缘节点可达性低于 90%。
通知方式：邮件或告警平台的低优先级通知，汇总到每日运维报告。
响应要求：确认续期流程是否正常，检查 DNS 验证记录是否有效。对于局部节点异常，联系 Vercel 支持确认是否存在计划内维护。

P3（信息通知）：配置变更或状态恢复

触发条件：证书成功续期、DNS 记录变更、故障恢复后自动解除告警。
通知方式：写入日志系统或告警历史记录，无需主动推送。
响应要求：无需立即处理，但应作为后续根因分析的输入。

故障响应流程：从发现到根因分析的四个步骤

告警触发后，响应团队需要遵循标准流程，避免慌乱中做出错误决策。

第一步：确认故障范围

收到 P0 或 P1 告警后，首先验证告警是否真实。使用 `curl -I https://目标域名` 从本地和远程服务器分别测试，对比结果。同时查看 Vercel 官方状态页（status.vercel.com），排除平台全局故障。如果 Vercel 本身无异常，则故障大概率出在 DNS 服务商或证书配置。

第二步：快速恢复服务

对于 DNS 解析故障，最快恢复手段是修改 DNS 记录，将域名指向备用 CDN 或静态 IP。对于证书过期，如果 Vercel 自动续期失败，可以手动删除证书并重新签发，Vercel 会在几分钟内生成新证书。注意：手动删除证书会导致短暂的服务中断，建议在低峰期操作。

第三步：记录现场数据

恢复服务后，立即导出故障期间的日志和指标数据。重点关注：DNS 服务商的解析日志、Vercel 边缘节点的错误日志、证书续期事件的 API 响应。这些数据是根因分析的基础。

第四步：根因分析与改进

根据现场数据定位根本原因。常见根因包括：DNS 服务商 API 限流导致验证记录更新失败、TXT 记录被 DNSSEC 签名导致 Vercel 无法读取、自定义证书的私钥密码与 Vercel 不兼容。确定根因后，更新监控配置或修改流程。例如，如果 DNS 验证记录经常被 DNSSEC 拦截，可以在 Vercel 侧改用 HTTP 验证方式。

工具选型：自建还是托管方案

监控工具的选择取决于团队规模和运维能力。对于 10 人以下的小团队，直接使用托管服务可以节省部署成本。对于有专职运维的团队，自建方案提供更高的定制性。

托管方案推荐

• **Better Stack**：提供 Uptime 监控、SSL 证书检查、DNS 解析检查，支持多区域探测，免费额度覆盖 3 个域名。
• **Checkly**：专为 Serverless 架构设计，支持 Vercel 集成，可以编写 Playwright 脚本模拟用户访问，检测证书错误。
• **Datadog**：如果团队已经在使用 Datadog，可以通过其 Synthetic Monitoring 功能配置 API 测试和 SSL 检查，与现有告警体系整合。

自建方案参考

自建监控的核心组件包括：

• **探测节点**：在 AWS EC2、DigitalOcean 或阿里云上部署 3-5 个轻量级实例，分布在不同区域。
• **数据采集**：使用 Prometheus Blackbox Exporter 执行 HTTP、HTTPS、DNS 探测，暴露指标供 Prometheus 抓取。
• **告警引擎**：Prometheus Alertmanager 配置告警规则，通过 Webhook 发送到即时通讯工具。
• **可视化**：Grafana 仪表盘展示证书有效期、DNS 解析成功率、边缘节点响应时间。

自建方案的成本主要来自服务器和运维时间。3 个探测节点每月约 15-30 美元（以 AWS t4g.nano 实例计算），加上 Prometheus 和 Grafana 的维护，适合日 PV 超过 10 万的项目。

常见风险与应对策略

即使监控体系完善，仍有一些风险无法完全避免。

DNS 传播延迟

修改 DNS 记录后，全球生效需要 15 分钟到 48 小时。如果 Vercel 的证书续期请求在传播完成前到达，会因记录不一致而失败。应对策略：在修改 DNS 记录时，将 TTL 值临时降低到 60 秒，等待新记录生效后再恢复默认 TTL。

Vercel 平台限流

Vercel API 存在调用频率限制，Pro 计划为每分钟 100 次。如果监控脚本频繁查询证书状态，可能触发限流导致请求失败。应对策略：在监控脚本中实现指数退避重试，并将查询间隔设置为至少 60 秒。

自定义证书的管理复杂性

如果使用 Let's Encrypt 或其他 CA 签发的自定义证书，需要自行处理续期和链完整性。Vercel 不支持自动续期自定义证书，因此必须部署 cron job 定期检查并重新上传。建议使用 cert-manager（Kubernetes）或 acme.sh 脚本自动完成。

最佳实践：从 SystemDo 项目经验中提炼的检查清单

过去几年，SystemDo 在多个企业项目中部署了类似的监控体系，以下是从中总结的实用清单。

• **证书监控**：至少设置两个阈值——30 天警告和 7 天严重。不要只依赖 Vercel 的自动续期，手动验证续期日志。
• **DNS 监控**：使用至少两个不同地理位置的探测节点，避免单点误报。对于 Apex 域名，确认 DNS 服务商支持 ALIAS 记录，否则改用 CNAME 配合 www 子域名。
• **告警路由**：P0 告警必须直接通知到个人，不要仅依赖共享群组。P1 告警可以发送到群组，但需明确指定值班人员。
• **文档化**：将故障响应流程写成 Runbook，包含每个告警等级的处理步骤、API 调用示例、Vercel CLI 命令。在故障发生时，团队成员可以按文档操作，减少沟通成本。
• **定期演练**：每季度模拟一次证书过期或 DNS 故障，验证告警是否准确触发、响应流程是否顺畅。演练后更新文档，修正发现的问题。

这套监控体系的核心价值不在于“发现所有问题”，而在于“当问题发生时，团队能快速定位并恢复”。Vercel 的自动化降低了日常运维成本，但无法替代人工对关键基础设施的主动监控。建立日志、指标、告警和响应流程的闭环，才能确保域名与 SSL 的长期稳定运行。