OneUptime Terraform Provider 实战示例库从标签到监控、状态页与值班策略的即用配置【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本指南以 OneUptime 开源仓库中 Terraform 示例文档 为骨架系统整理了一整套可直接复制粘贴的 HCL 配置覆盖标签、多类型监控器、自定义域名状态页、团队、值班策略、计划维护、事故分类与探针等核心资源。每一个示例都源自仓库内真实运行的 E2E 测试套件E2E/Terraform/e2e-tests/tests因此文中的属性与语义均为真实有效。读完本文你将能够用 Terraform 把 OneUptime 的监控、状态页与告警体系完整落地为声明式基础设施。前置准备Provider 声明与认证约定所有示例都假设你已经完成了下述 Provider 设置。完整的 API Key 创建与十分钟上手流程参见 Quick Start。terraform { required_providers { oneuptime { source oneuptime/oneuptime version ~ 11.0 } } } provider oneuptime { # api_key 从 ONEUPTIME_API_KEY 环境变量读取 # oneuptime_url 仅在自托管时设置例如 oneuptime_url https://oneuptime.example.com }关于这段配置有两个要点值得注意版本约束Provider 版本与 OneUptime 平台版本保持同步。云托管环境使用~ 11.0自托管环境应选择小于或等于你的平台版本的最新已发布 Provider 版本且不要锁定到精确的 patch 版本——并非每个平台补丁都会发布到 Registry。详见 Self-Hosted Setup 与 Registry Usage。密钥边界必须是项目级 API Key在控制台Ajustes del proyecto Claves API中创建并授予计划管理的所有资源类型的 Create / Read / Update / Delete 权限。用户级 Key 或自托管主 Key 会导致ProjectId required错误。从源码看Provider 本身是由仓库内 Scripts/TerraformProvider 目录下的 TypeScript 生成器依据 OneUptime OpenAPI 规范动态生成的 Go 代码参见 Scripts/TerraformProvider/README.mdCRUD 映射规则为 POST→Create、GET→Read、PUT/PATCH→Update、DELETE→Delete。因此下面的资源名oneuptime_snake_case_resource与 API 端点一一对应理论上会自动跟上 API 的演进。Labels最轻量的积木先建后用标签Label是 OneUptime 中成本最低的基础组件——建议最先创建随后通过labels [...]一个无序的标签 ID 集合挂载到几乎任何资源上。正因为是无序集合调整顺序不会产生 diff。resource oneuptime_label production { name production description Production infrastructure color #FF5733 }color使用十六进制色值如#FF5733。E2E 测试目录 tests/01-label 与 tests/37-label-order-idempotency 分别验证了标签 CRUD 与无序集合幂等性——后一个测试专门确保重排 label ID 不会触发无意义的变更。Monitors监控器的三种写法HTTP 监控器显式检查步骤一个Website监控器对“检查什么、何时判定 up/down”拥有完全控制权。monitor_steps的 JSON 结构逐行详解见 Monitor Steps。resource oneuptime_monitor_status operational { name Operational description Monitor is operational color #2ecc71 priority 1 is_operational_state true } resource oneuptime_monitor_status offline { name Offline description Monitor is offline color #e74c3c priority 3 is_operational_state false } resource oneuptime_monitor website { name Website description Homepage availability and status code check monitor_type Website monitor_steps jsonencode({ _type MonitorSteps value { monitorStepsInstanceArray [ { _type MonitorStep value { id step-website-1 monitorDestination { _type URL value https://example.com } requestType GET monitorCriteria { _type MonitorCriteria value { monitorCriteriaInstanceArray [ { _type MonitorCriteriaInstance value { id criteria-online name Online description Website responds with 200 filterCondition All changeMonitorStatus true createIncidents false createAlerts false monitorStatusId oneuptime_monitor_status.operational.id filters [ { _type CriteriaFilter value { checkOn Is Online filterType True } }, { _type CriteriaFilter value { checkOn Response Status Code filterType Equal To value 200 } } ] incidents [] alerts [] } }, { _type MonitorCriteriaInstance value { id criteria-offline name Offline description Website is unreachable filterCondition Any changeMonitorStatus true createIncidents false createAlerts false monitorStatusId oneuptime_monitor_status.offline.id filters [ { _type CriteriaFilter value { checkOn Is Online filterType False } } ] incidents [] alerts [] } } ] } } } } ] } }) }(改编自 E2E 测试35-monitor-with-steps。)这段配置展示了monitor_steps的线上信封格式wire envelope外层_type/value逐层嵌套MonitorSteps → MonitorStep → MonitorCriteria → MonitorCriteriaInstance → CriteriaFilter。有两个关键语义优先级priority在服务端是INSERT 插槽语义——新建一个状态会把所有priority P的既有状态顺移一位且创建后不可更新。因此 E2E 测试tests/35-monitor-with-steps/main.tf刻意使用101/102/103 的高位、带间隔、升序优先级并用depends_on串行创建避免与项目默认状态竞争。filterConditionAll表示所有过滤器必须同时命中Any表示任一命中即可。上例中“Online”判定同时要求“在线”与“状态码等于 200”“Offline”判定只需“不在线”即可。Ping 监控器Ping 监控器的目的地是Hostname或IP而非 URLresource oneuptime_monitor ping { name Gateway Ping description ICMP reachability of the gateway host monitor_type Ping monitor_steps jsonencode({ _type MonitorSteps value { monitorStepsInstanceArray [ { _type MonitorStep value { id step-ping-1 monitorDestination { _type Hostname value gateway.example.com } requestType GET monitorCriteria { _type MonitorCriteria value { monitorCriteriaInstanceArray [ { _type MonitorCriteriaInstance value { id criteria-ping-online name Reachable description Host responds to ping filterCondition All changeMonitorStatus true createIncidents false createAlerts false monitorStatusId oneuptime_monitor_status.operational.id filters [ { _type CriteriaFilter value { checkOn Is Online filterType True } } ] incidents [] alerts [] } } ] } } } } ] } }) }(改编自 E2E 测试35-monitor-with-steps。)注意monitorDestination._type从URL换成了Hostname。从 Provider 静态源码 Scripts/TerraformProvider/StaticFiles/monitorsteps.go 的枚举定义看目的地类型仅接受URL、IP、Hostname三种取值monitorStepsDestinationTypeValues这与监控器类型存在对应关系Website / API / SSL Certificate 监控器使用URLPing / Port 监控器使用Hostname或IP。同一份源码还维护了完整的checkOn枚举覆盖响应时间、丢包、抖动、状态码、请求/响应头、证书有效性、磁盘/CPU/内存、DNS、SQL、SNMP 等数十种检查维度与filterType枚举Equal To、Greater Than、Contains、Is Empty、Anomalously High等所有枚举均在 plan 阶段由stringvalidator.OneOf(...)校验写错取值会得到即时报错而不是 apply 时的 API 400。手动监控器手动监控器不做主动检查——状态由人工或自动化系统设定因此完全不需要monitor_stepsresource oneuptime_monitor third_party { name Payment Provider (manual) description Tracked manually during vendor incidents monitor_type Manual monitoring_interval Every 5 minutes }(改编自 E2E 测试26-monitor-steps-basic。)monitoring_interval的取值示例为Every 5 minutes。E2E 测试 tests/26-monitor-steps-basic/main.tf 还展示了其它基础场景disable_active_monitoring true可禁用主动探测测试中为避免探针在销毁阶段回写状态而使用不带monitor_steps的 Website 监控器由服务端自动生成默认步骤且 Provider 不会把这些默认值报告为 drift。其他同样写法的合法monitor_type取值包括API、Port、IP、SSL Certificate、Incoming Request、Server。其中Server 与 Incoming Request监控器会暴露计算型密钥属性server_monitor_secret_key、incoming_request_secret_key供对应的探针 Agent 使用只读由服务端生成。关于monitor_steps还值得补充一点虽然示例文档使用jsonencode()信封格式仓库内 E2E 测试的较新写法tests/35-monitor-with-steps/main.tf 顶部注释说明 Provider 也支持类型化嵌套 HCL 语法monitor_steps [{ monitor_destination ... criteria [...] }]无需jsonencode、无需手写 id、id 由服务端生成。两种格式由 monitorsteps.go 中的MonitorStepsToAPI/MonitorStepsFromAPI转换函数双向翻译并保证“用户配置 → API → 回读”的往返一致性。状态页与自定义域名三个资源协同状态页自定义域名由三个资源协同完成已验证的项目级domain、status_page本身、以及将两者关联的status_page_domain。其中full_domain与cname_verification_token由服务端计算——不要手工设置。resource oneuptime_domain company { domain example.com } resource oneuptime_status_page public { name Public Status description Customer-facing status page page_title System Status page_description Check our system status and incident history is_public_status_page true enable_email_subscribers true enable_sms_subscribers false } resource oneuptime_status_page_domain status { domain_id oneuptime_domain.company.id status_page_id oneuptime_status_page.public.id subdomain status } output status_domain { # 由服务端计算subdomain domain例如 status.example.com value oneuptime_status_page_domain.status.full_domain }(改编自 E2E 测试25-status-page-with-domain和12-status-page-domain。新域名必须先通过 DNS 验证状态页域名才会生效。)在真实 E2E 场景中tests/25-status-page-with-domain/main.tf 还演示了更复杂的关系多个域名挂到同一状态页不同subdomain、同一域名服务于多个状态页以及is_verified true的域名声明方式。该测试同时验证了 Issue #2236 的修复——fullDomain与cnameVerificationToken作为计算字段被正确回填且不产生 driftIssue #2232 的修复则保证服务端注入的downtimeMonitorStatuses等默认值不会破坏幂等性。团队与成员resource oneuptime_team sre { name SRE description Site reliability engineering } resource oneuptime_team_member alice { team_id oneuptime_team.sre.id user_id 5f8a1b2c3d4e5f6a7b8c9d0e # 用户 id — 在仪表盘其个人主页的 URL 中可见 }(团队部分改编自 E2E 测试33-team-crud。被引用的用户必须已属于该项目成员关系在用户接受邀请后才确认。)oneuptime_team_member通过team_iduser_id建立成员关系其中user_id是一个普通字符串可在仪表盘用户个人主页 URL 中获取。值班策略与升级规则一个值班策略on-call policy加一条升级规则5 分钟内无人确认即升级resource oneuptime_on_call_policy primary { name Primary On-Call description First line for production incidents repeat_policy_if_no_one_acknowledges true } resource oneuptime_escalation_rule first_line { on_call_duty_policy_id oneuptime_on_call_policy.primary.id name First line description Page the on-call engineer immediately order 1 escalate_after_in_minutes 5 }(策略部分改编自 E2E 测试31-on-call-duty-policy-crud。)repeat_policy_if_no_one_acknowledges控制“无人确认时是否重复执行整个策略”escalate_after_in_minutes 5定义了升级触发阈值。升级规则的专项测试见 tests/39-escalation-rule值班排班on-call schedule见 tests/40-on-call-schedule。计划维护resource oneuptime_scheduled_maintenance_event db_upgrade { title Database maintenance description Planned PostgreSQL upgrade — writes paused briefly starts_at 2026-08-01T02:00:00Z ends_at 2026-08-01T04:00:00Z is_visible_on_status_page true }(改编自 E2E 测试30-scheduled-maintenance-crud。时间戳使用 RFC3339 格式不同记法表示的同一时刻不会产生 drift。)时间戳的“同一时刻不产生 drift”并非口头承诺而是有专门的源码实现Provider 静态代码 Scripts/TerraformProvider/StaticFiles/rfc3339.go 定义了自定义的RFC3339Type/RFC3339Value其StringSemanticEquals先把两个字符串解析为time.Time再按时刻相等比较因此服务端把2026-08-01T02:00:00Z回写成2026-08-01T02:00:00.000Z或把时区偏移改写为 UTC都不会被误报为变更。该文件注释明确指出这是此前expires_at/starts_at出现 “inconsistent result after apply” 类错误的根因修复。事故Incident等级与状态定制你的事故分类体系——incident_severity用于衡量影响等级incident_state用于建模生命周期。order控制显示顺序。resource oneuptime_incident_severity sev1 { name SEV-1 description Full outage, all hands color #e74c3c order 1 } resource oneuptime_incident_state mitigated { name Mitigated description Impact contained, fix in progress color #f39c12 order 3 }(改编自 E2E 测试03-incident-severity与04-incident-state。oneuptime_alert_severity与oneuptime_alert_state对告警采用完全相同的写法。)从 Terraform 声明事故事故通常由监控器自动创建但它们本身也是普通资源——非常适合游戏日演练game daysresource oneuptime_incident drill { title DR drill description Disaster recovery exercise incident_severity_id oneuptime_incident_severity.sev1.id current_incident_state_id oneuptime_incident_state.mitigated.id }(改编自 E2E 测试28-incident-crud。)incident_severity_id与current_incident_state_id是典型的实体引用属性——以 ID 字符串形式引用其它资源。同类引用还有monitor_id、on_call_policy_ids等数组型引用如labels是无序 ID 集合重排不会产生 diff参见 Scripts/TerraformProvider/README.md 中“Entity references”的建模说明。自定义探针自定义探针Probe让你从自己的基础设施发起监控检查resource oneuptime_probe eu_west { key probe-eu-west-1 name EU West Probe description Probe running in eu-west-1 probe_version 1.0.0 should_auto_enable_probe_on_new_monitors true }(改编自 E2E 测试23-probe-crud。)key是探针的唯一标识should_auto_enable_probe_on_new_monitors控制新建监控器时是否自动启用该探针执行检查。探针版本相关的幂等性专项测试见 tests/20-probe-version-idempotency。更多资源与延伸阅读示例文档还给出了三个延伸入口Monitor Steps —— 完整的monitor_steps结构、判定过滤器与常见误区Importing Resources —— 把已在仪表盘中创建的资源纳入 Terraform 管理各资源的逐属性参考Terraform Registry 的 oneuptime Provider 文档页registry.terraform.io/providers/oneuptime/oneuptime/latest/docs。如果你想把本文的示例直接跑起来可结合 Quick Start 完成 API Key 创建、terraform init、terraform plan与terraform apply的完整流程想了解 Provider 的生成机制与认证细节可阅读 Scripts/TerraformProvider/README.md。上述所有示例的运行时验证均可在仓库的 E2E 套件 E2E/Terraform/e2e-tests 中找到对应测试目录与verify.sh校验脚本它们是这些配置真实有效的最佳佐证。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime Terraform Provider 实战示例库：从标签到监控、状态页与值班策略的即用配置
OneUptime Terraform Provider 实战示例库从标签到监控、状态页与值班策略的即用配置【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本指南以 OneUptime 开源仓库中 Terraform 示例文档 为骨架系统整理了一整套可直接复制粘贴的 HCL 配置覆盖标签、多类型监控器、自定义域名状态页、团队、值班策略、计划维护、事故分类与探针等核心资源。每一个示例都源自仓库内真实运行的 E2E 测试套件E2E/Terraform/e2e-tests/tests因此文中的属性与语义均为真实有效。读完本文你将能够用 Terraform 把 OneUptime 的监控、状态页与告警体系完整落地为声明式基础设施。前置准备Provider 声明与认证约定所有示例都假设你已经完成了下述 Provider 设置。完整的 API Key 创建与十分钟上手流程参见 Quick Start。terraform { required_providers { oneuptime { source oneuptime/oneuptime version ~ 11.0 } } } provider oneuptime { # api_key 从 ONEUPTIME_API_KEY 环境变量读取 # oneuptime_url 仅在自托管时设置例如 oneuptime_url https://oneuptime.example.com }关于这段配置有两个要点值得注意版本约束Provider 版本与 OneUptime 平台版本保持同步。云托管环境使用~ 11.0自托管环境应选择小于或等于你的平台版本的最新已发布 Provider 版本且不要锁定到精确的 patch 版本——并非每个平台补丁都会发布到 Registry。详见 Self-Hosted Setup 与 Registry Usage。密钥边界必须是项目级 API Key在控制台Ajustes del proyecto Claves API中创建并授予计划管理的所有资源类型的 Create / Read / Update / Delete 权限。用户级 Key 或自托管主 Key 会导致ProjectId required错误。从源码看Provider 本身是由仓库内 Scripts/TerraformProvider 目录下的 TypeScript 生成器依据 OneUptime OpenAPI 规范动态生成的 Go 代码参见 Scripts/TerraformProvider/README.mdCRUD 映射规则为 POST→Create、GET→Read、PUT/PATCH→Update、DELETE→Delete。因此下面的资源名oneuptime_snake_case_resource与 API 端点一一对应理论上会自动跟上 API 的演进。Labels最轻量的积木先建后用标签Label是 OneUptime 中成本最低的基础组件——建议最先创建随后通过labels [...]一个无序的标签 ID 集合挂载到几乎任何资源上。正因为是无序集合调整顺序不会产生 diff。resource oneuptime_label production { name production description Production infrastructure color #FF5733 }color使用十六进制色值如#FF5733。E2E 测试目录 tests/01-label 与 tests/37-label-order-idempotency 分别验证了标签 CRUD 与无序集合幂等性——后一个测试专门确保重排 label ID 不会触发无意义的变更。Monitors监控器的三种写法HTTP 监控器显式检查步骤一个Website监控器对“检查什么、何时判定 up/down”拥有完全控制权。monitor_steps的 JSON 结构逐行详解见 Monitor Steps。resource oneuptime_monitor_status operational { name Operational description Monitor is operational color #2ecc71 priority 1 is_operational_state true } resource oneuptime_monitor_status offline { name Offline description Monitor is offline color #e74c3c priority 3 is_operational_state false } resource oneuptime_monitor website { name Website description Homepage availability and status code check monitor_type Website monitor_steps jsonencode({ _type MonitorSteps value { monitorStepsInstanceArray [ { _type MonitorStep value { id step-website-1 monitorDestination { _type URL value https://example.com } requestType GET monitorCriteria { _type MonitorCriteria value { monitorCriteriaInstanceArray [ { _type MonitorCriteriaInstance value { id criteria-online name Online description Website responds with 200 filterCondition All changeMonitorStatus true createIncidents false createAlerts false monitorStatusId oneuptime_monitor_status.operational.id filters [ { _type CriteriaFilter value { checkOn Is Online filterType True } }, { _type CriteriaFilter value { checkOn Response Status Code filterType Equal To value 200 } } ] incidents [] alerts [] } }, { _type MonitorCriteriaInstance value { id criteria-offline name Offline description Website is unreachable filterCondition Any changeMonitorStatus true createIncidents false createAlerts false monitorStatusId oneuptime_monitor_status.offline.id filters [ { _type CriteriaFilter value { checkOn Is Online filterType False } } ] incidents [] alerts [] } } ] } } } } ] } }) }(改编自 E2E 测试35-monitor-with-steps。)这段配置展示了monitor_steps的线上信封格式wire envelope外层_type/value逐层嵌套MonitorSteps → MonitorStep → MonitorCriteria → MonitorCriteriaInstance → CriteriaFilter。有两个关键语义优先级priority在服务端是INSERT 插槽语义——新建一个状态会把所有priority P的既有状态顺移一位且创建后不可更新。因此 E2E 测试tests/35-monitor-with-steps/main.tf刻意使用101/102/103 的高位、带间隔、升序优先级并用depends_on串行创建避免与项目默认状态竞争。filterConditionAll表示所有过滤器必须同时命中Any表示任一命中即可。上例中“Online”判定同时要求“在线”与“状态码等于 200”“Offline”判定只需“不在线”即可。Ping 监控器Ping 监控器的目的地是Hostname或IP而非 URLresource oneuptime_monitor ping { name Gateway Ping description ICMP reachability of the gateway host monitor_type Ping monitor_steps jsonencode({ _type MonitorSteps value { monitorStepsInstanceArray [ { _type MonitorStep value { id step-ping-1 monitorDestination { _type Hostname value gateway.example.com } requestType GET monitorCriteria { _type MonitorCriteria value { monitorCriteriaInstanceArray [ { _type MonitorCriteriaInstance value { id criteria-ping-online name Reachable description Host responds to ping filterCondition All changeMonitorStatus true createIncidents false createAlerts false monitorStatusId oneuptime_monitor_status.operational.id filters [ { _type CriteriaFilter value { checkOn Is Online filterType True } } ] incidents [] alerts [] } } ] } } } } ] } }) }(改编自 E2E 测试35-monitor-with-steps。)注意monitorDestination._type从URL换成了Hostname。从 Provider 静态源码 Scripts/TerraformProvider/StaticFiles/monitorsteps.go 的枚举定义看目的地类型仅接受URL、IP、Hostname三种取值monitorStepsDestinationTypeValues这与监控器类型存在对应关系Website / API / SSL Certificate 监控器使用URLPing / Port 监控器使用Hostname或IP。同一份源码还维护了完整的checkOn枚举覆盖响应时间、丢包、抖动、状态码、请求/响应头、证书有效性、磁盘/CPU/内存、DNS、SQL、SNMP 等数十种检查维度与filterType枚举Equal To、Greater Than、Contains、Is Empty、Anomalously High等所有枚举均在 plan 阶段由stringvalidator.OneOf(...)校验写错取值会得到即时报错而不是 apply 时的 API 400。手动监控器手动监控器不做主动检查——状态由人工或自动化系统设定因此完全不需要monitor_stepsresource oneuptime_monitor third_party { name Payment Provider (manual) description Tracked manually during vendor incidents monitor_type Manual monitoring_interval Every 5 minutes }(改编自 E2E 测试26-monitor-steps-basic。)monitoring_interval的取值示例为Every 5 minutes。E2E 测试 tests/26-monitor-steps-basic/main.tf 还展示了其它基础场景disable_active_monitoring true可禁用主动探测测试中为避免探针在销毁阶段回写状态而使用不带monitor_steps的 Website 监控器由服务端自动生成默认步骤且 Provider 不会把这些默认值报告为 drift。其他同样写法的合法monitor_type取值包括API、Port、IP、SSL Certificate、Incoming Request、Server。其中Server 与 Incoming Request监控器会暴露计算型密钥属性server_monitor_secret_key、incoming_request_secret_key供对应的探针 Agent 使用只读由服务端生成。关于monitor_steps还值得补充一点虽然示例文档使用jsonencode()信封格式仓库内 E2E 测试的较新写法tests/35-monitor-with-steps/main.tf 顶部注释说明 Provider 也支持类型化嵌套 HCL 语法monitor_steps [{ monitor_destination ... criteria [...] }]无需jsonencode、无需手写 id、id 由服务端生成。两种格式由 monitorsteps.go 中的MonitorStepsToAPI/MonitorStepsFromAPI转换函数双向翻译并保证“用户配置 → API → 回读”的往返一致性。状态页与自定义域名三个资源协同状态页自定义域名由三个资源协同完成已验证的项目级domain、status_page本身、以及将两者关联的status_page_domain。其中full_domain与cname_verification_token由服务端计算——不要手工设置。resource oneuptime_domain company { domain example.com } resource oneuptime_status_page public { name Public Status description Customer-facing status page page_title System Status page_description Check our system status and incident history is_public_status_page true enable_email_subscribers true enable_sms_subscribers false } resource oneuptime_status_page_domain status { domain_id oneuptime_domain.company.id status_page_id oneuptime_status_page.public.id subdomain status } output status_domain { # 由服务端计算subdomain domain例如 status.example.com value oneuptime_status_page_domain.status.full_domain }(改编自 E2E 测试25-status-page-with-domain和12-status-page-domain。新域名必须先通过 DNS 验证状态页域名才会生效。)在真实 E2E 场景中tests/25-status-page-with-domain/main.tf 还演示了更复杂的关系多个域名挂到同一状态页不同subdomain、同一域名服务于多个状态页以及is_verified true的域名声明方式。该测试同时验证了 Issue #2236 的修复——fullDomain与cnameVerificationToken作为计算字段被正确回填且不产生 driftIssue #2232 的修复则保证服务端注入的downtimeMonitorStatuses等默认值不会破坏幂等性。团队与成员resource oneuptime_team sre { name SRE description Site reliability engineering } resource oneuptime_team_member alice { team_id oneuptime_team.sre.id user_id 5f8a1b2c3d4e5f6a7b8c9d0e # 用户 id — 在仪表盘其个人主页的 URL 中可见 }(团队部分改编自 E2E 测试33-team-crud。被引用的用户必须已属于该项目成员关系在用户接受邀请后才确认。)oneuptime_team_member通过team_iduser_id建立成员关系其中user_id是一个普通字符串可在仪表盘用户个人主页 URL 中获取。值班策略与升级规则一个值班策略on-call policy加一条升级规则5 分钟内无人确认即升级resource oneuptime_on_call_policy primary { name Primary On-Call description First line for production incidents repeat_policy_if_no_one_acknowledges true } resource oneuptime_escalation_rule first_line { on_call_duty_policy_id oneuptime_on_call_policy.primary.id name First line description Page the on-call engineer immediately order 1 escalate_after_in_minutes 5 }(策略部分改编自 E2E 测试31-on-call-duty-policy-crud。)repeat_policy_if_no_one_acknowledges控制“无人确认时是否重复执行整个策略”escalate_after_in_minutes 5定义了升级触发阈值。升级规则的专项测试见 tests/39-escalation-rule值班排班on-call schedule见 tests/40-on-call-schedule。计划维护resource oneuptime_scheduled_maintenance_event db_upgrade { title Database maintenance description Planned PostgreSQL upgrade — writes paused briefly starts_at 2026-08-01T02:00:00Z ends_at 2026-08-01T04:00:00Z is_visible_on_status_page true }(改编自 E2E 测试30-scheduled-maintenance-crud。时间戳使用 RFC3339 格式不同记法表示的同一时刻不会产生 drift。)时间戳的“同一时刻不产生 drift”并非口头承诺而是有专门的源码实现Provider 静态代码 Scripts/TerraformProvider/StaticFiles/rfc3339.go 定义了自定义的RFC3339Type/RFC3339Value其StringSemanticEquals先把两个字符串解析为time.Time再按时刻相等比较因此服务端把2026-08-01T02:00:00Z回写成2026-08-01T02:00:00.000Z或把时区偏移改写为 UTC都不会被误报为变更。该文件注释明确指出这是此前expires_at/starts_at出现 “inconsistent result after apply” 类错误的根因修复。事故Incident等级与状态定制你的事故分类体系——incident_severity用于衡量影响等级incident_state用于建模生命周期。order控制显示顺序。resource oneuptime_incident_severity sev1 { name SEV-1 description Full outage, all hands color #e74c3c order 1 } resource oneuptime_incident_state mitigated { name Mitigated description Impact contained, fix in progress color #f39c12 order 3 }(改编自 E2E 测试03-incident-severity与04-incident-state。oneuptime_alert_severity与oneuptime_alert_state对告警采用完全相同的写法。)从 Terraform 声明事故事故通常由监控器自动创建但它们本身也是普通资源——非常适合游戏日演练game daysresource oneuptime_incident drill { title DR drill description Disaster recovery exercise incident_severity_id oneuptime_incident_severity.sev1.id current_incident_state_id oneuptime_incident_state.mitigated.id }(改编自 E2E 测试28-incident-crud。)incident_severity_id与current_incident_state_id是典型的实体引用属性——以 ID 字符串形式引用其它资源。同类引用还有monitor_id、on_call_policy_ids等数组型引用如labels是无序 ID 集合重排不会产生 diff参见 Scripts/TerraformProvider/README.md 中“Entity references”的建模说明。自定义探针自定义探针Probe让你从自己的基础设施发起监控检查resource oneuptime_probe eu_west { key probe-eu-west-1 name EU West Probe description Probe running in eu-west-1 probe_version 1.0.0 should_auto_enable_probe_on_new_monitors true }(改编自 E2E 测试23-probe-crud。)key是探针的唯一标识should_auto_enable_probe_on_new_monitors控制新建监控器时是否自动启用该探针执行检查。探针版本相关的幂等性专项测试见 tests/20-probe-version-idempotency。更多资源与延伸阅读示例文档还给出了三个延伸入口Monitor Steps —— 完整的monitor_steps结构、判定过滤器与常见误区Importing Resources —— 把已在仪表盘中创建的资源纳入 Terraform 管理各资源的逐属性参考Terraform Registry 的 oneuptime Provider 文档页registry.terraform.io/providers/oneuptime/oneuptime/latest/docs。如果你想把本文的示例直接跑起来可结合 Quick Start 完成 API Key 创建、terraform init、terraform plan与terraform apply的完整流程想了解 Provider 的生成机制与认证细节可阅读 Scripts/TerraformProvider/README.md。上述所有示例的运行时验证均可在仓库的 E2E 套件 E2E/Terraform/e2e-tests 中找到对应测试目录与verify.sh校验脚本它们是这些配置真实有效的最佳佐证。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考