核心功能与定位
Checkly CLI 是 Checkly 官方提供的命令行工具，专为 Monitoring as Code (MaC) 工作流设计。它将合成监控（synthetic monitoring）定义为可版本控制的代码，让开发团队能够用熟悉的 TypeScript/JavaScript 语法编写 API 检查、浏览器检查（Playwright）和基础设施监控，并在本地测试后通过 CI/CD 管道部署到 Checkly 云端。
核心用法
快速启动：
npm create checkly@latest— 初始化新项目npx checkly login— 身份验证（需 CHECKLY_API_KEY 和 CHECKLY_ACCOUNT_ID）npx checkly test— 本地测试检查npx checkly deploy— 部署到生产环境
检查类型支持：
- API 检查：HTTP 请求 + 断言（状态码、响应时间、响应体）
- 浏览器检查：基于 Playwright 的单页测试（*.spec.ts）
- 多步骤检查：复杂用户流程（已逐步被浏览器检查取代）
- Playwright 测试套件：多项目并行执行
- 基础监控：心跳、TCP、DNS、URL 监控（无代码）
项目结构：
配置层级为 checkly.config.ts → CheckGroup → 单个 Check，支持自动发现（testMatch 模式）或显式构造定义。
显著优点
1. 代码化工作流：监控配置纳入 Git 版本控制，支持 PR 审查
2. 本地迭代效率：npx playwright test 快速调试，再经 npx checkly test 验证运行时兼容性
3. 原生 Playwright 支持：直接复用现有 @playwright/test 规范
4. CI/CD 原生集成：无缝对接 GitHub Actions、GitLab CI 等管道
5. Import 逆向迁移：npx checkly import 可将 Web UI 中已有检查转为代码
潜在局限与风险
- 学习曲线：需同时掌握 Checkly 构造语法（ApiCheck、AssertionBuilder）和 Playwright API
- 运行时差异：本地 Playwright 与 Checkly 云运行时（基于 AWS Lambda）存在环境差异，部分依赖可能不兼容
- 配置分散：项目级、组级、检查级配置层级较多，易覆盖规则混淆
- 浏览器检查冷启动：云端执行存在启动延迟，不适合亚秒级高频探测
- 凭证管理：API Key 需妥善保管，虽存储于 ~/.config/@checkly/cli/config.json，但在 CI 中需通过环境变量注入
适合人群
- 采用 "监控即代码" 实践的 DevOps/SRE 团队
- 已使用 Playwright 进行 E2E 测试的前端/全栈团队
- 需要大规模管理数十至数百个监控检查的中大型工程团队
- 追求监控配置与应用代码同仓库、同生命周期的组织
常规风险
- 误部署风险：
npx checkly deploy会直接覆盖云端配置，建议在 CI 中配合 dry-run 或手动审批 - 成本失控：高频检查 × 多地理位置 × 大量检查易产生意外账单
- Secret 泄露：Playwright 脚本中硬编码的测试账号、API Key 可能随检查定义暴露
- 网络依赖：检查执行依赖 Checkly 云端基础设施，私有部署需额外配置 Private Locations