企业官网建设流程全解析

OneUptime 平台能力全景：开源可观测性平台的八大核心模块详解

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime

OneUptime是一款完整的开源（Apache 2.0）监控与可观测性平台，将在线时间监控、状态页、事件管理、值班告警、日志管理、工作流自动化、应用性能监控（APM）与错误跟踪整合为一个可自托管的统一系统。本文以仓库内 丹麦语版快速上手文档（与 英文版 内容一致）为骨架，结合仓库源码与各功能模块的官方文档，逐模块解析每个能力的实际作用、适用场景与对应实现位置，帮助你判断用 OneUptime 替代现有工具栈后如何落地使用。

平台定位：用一个集成平台取代多个工具

OneUptime 面向"需要检查网站、Dashboard、API 或任何在线资源可用性"的团队：当宕机发生时向团队告警，用状态页让客户保持知情，并进一步覆盖事件处理、值班轮换、测试运行、服务加固、日志分析、性能追踪与错误调试。核心价值在于把原本分散在多个 SaaS 工具中的能力收敛到一个自托管平台，让数据与流程在一个闭环内流转——监控检测到异常，自动升级给值班人员，同步更新状态页，并在日志、链路与指标中定位根因。

下表整理了原文档中"以 OneUptime 替换多工具"的核心对应关系：

在线时间监控（Uptime Monitoring）

从全球多个位置持续监控在线服务的可用性与响应时间，一旦异常通过电子邮件、短信、Slack 或其他渠道通知团队。这对应原文档中可替代Pingdom的能力。

从仓库看，该能力由监控模型与分布式探针协同实现：

• 监控的核心数据模型为 Monitor.ts，支撑网站、API、Ping、端口、SSL、DNS 等各类监控类型，仓库文档目录 monitor/ 下即包含 website-monitor.md、api-monitor、ping-monitor、port-monitor、ssl-certificate-monitor、dns-monitor、synthetic-monitor 等专项指南。
• 全球多点检测由探针（Probe）执行，探针模型见 Probe.ts，探针服务实现位于 Probe/ 目录，监控与探针的绑定关系由 MonitorProbe.ts 记录。

以网站监控为例（详见 website-monitor.md）：OneUptime 周期性向目标 URL 发送 HTTP 请求并校验响应，支持以 HTTP 状态码、响应时间、响应体内容、响应头作为在线/降级/离线判定条件；还支持{{timestamp}}与{{random}}动态占位符以绕开 CDN 缓存、mTLS 客户端证书、忽略重定向与自签名证书等高级选项。下面的截图展示了探针在检测到 Checkout API 响应时间超过 5 秒阈值时触发 HTTP 超时告警的过程——来自 Frankfurt、Virginia 等多个区域的探针共同确认了降级：

状态页（Status Pages）

在宕机或计划维护期间向客户与利益相关者传达信息，创建带自定义品牌的页面，展示服务的当前状态与历史记录，对应可替代StatusPage.io的能力。状态页的完整使用指南见 status-pages/index.md。

状态页是"被监控内容的对外门面"：页面上每一行是一个Status Page Resource（某个监控器或监控组），可分组、可嵌套；支持电子邮件、短信、Slack、Microsoft Teams、Webhook 五类订阅者并自动通知；提供自定义域名（CNAME + SSL）、HTML/CSS/JavaScript 定制、RSS 订阅流与可嵌入的状态徽章。可见性方面支持三种私有化方式：私有用户、主密码、SAML SSO/OIDC，外加 IP 白名单。相关数据模型包括 StatusPage.ts、StatusPageResource.ts、StatusPageGroup.ts、StatusPageSubscriber.ts 与 StatusPageDomain.ts。

事件管理（Incident Management）

以协作式工作流从头到尾管理事件：创建事件报告、分配任务、向利益相关者更新进度、记录解决方案，对应可替代Incident.io的能力。入门指南见 incidents/index.md，事件状态与严重级别的定义见 states-and-severities.md。

从模型层看，事件体系非常完整：Incident.ts 是事件主模型，配套 IncidentState.ts（状态）、IncidentSeverity.ts（严重级别）、IncidentStateTimeline.ts（状态时间线）、IncidentPublicNote.ts（公开备注）、IncidentInternalNote.ts（内部备注）、IncidentMember.ts（成员）、IncidentPostmortemTemplate.ts（复盘模板）等模型，覆盖从声明、分诊、沟通到复盘的全流程。仓库还定义了"事件剧集（Episode）"体系（如 IncidentEpisode.ts），用于把同类事件聚合管理。

值班与告警（On-Call & Alerts）

为团队排定值班班次、定义升级策略，确保事件发生时正确的人在正确的时间被通知，对应可替代PagerDuty的能力。相关入门文档位于 on-call/ 目录（如电话白名单、来电策略、日历订阅等）。

值班体系的核心模型是 OnCallDutyPolicy.ts 及其配套模型：OnCallDutyPolicySchedule.ts（排班）、OnCallDutyPolicyScheduleLayer.ts（排班层级）、OnCallDutyPolicyEscalationRule.ts（升级规则）、OnCallDutyPolicyExecutionLog.ts（执行日志）。告警通知渠道覆盖短信、电话、推送、邮件、Slack 等，仓库中对应 UserSMS.ts、UserCall.ts、UserPush.ts、UserNotificationRule.ts 等模型，另设 IncomingCallPolicy.ts 支持来电式告警确认。

日志管理（Logs Management）

收集、存储并分析在线服务的日志，支持搜索、过滤与可视化，从而洞察问题并排查故障，对应可替代Loggly的能力。日志数据通过 OpenTelemetry 接入，相关模型包括 LogSavedView.ts（保存视图）、LogPipeline.ts 与 LogPipelineProcessor.ts（管道处理）、LogScrubRule.ts（脱敏规则）、LogDropFilter.ts（丢弃过滤）。遥测接入与采集的详细指南见 telemetry/ 目录。

工作流（Workflows）

将 OneUptime 与现有工具集成并自动化工作流，可与 Slack、Jira、GitHub 等5000+工具联动，这是原文档强调的集成规模能力。仓库中 Workflow.ts 为工作流主模型，配套 WorkflowLog.ts、WorkflowVariable.ts 等，集成入口文档见 integrations/index.md 与 workflows/ 目录。

工作流不只是"通知"层面的拼接，而是可编排端到端的自动化。下图展示了一个"事件升级"自动化画布：以"事件创建"为触发条件，判断严重级别后依次执行呼叫值班策略、发布 Slack、创建 Jira 工单、更新状态页等动作——这正是原文档所述"与现有工具集成并自动化工作流"的典型落地形态：

应用性能监控（APM）

衡量并优化在线应用与服务的性能，追踪链路（traces）、响应时间、吞吐量、错误率与用户满意度等关键指标，对应可替代NewRelic与DataDog的能力。仓库中的核心支撑包括 TraceSavedView.ts（追踪视图）、MetricSavedView.ts（指标视图）、MetricType.ts（指标类型）等模型，并结合 dashboards/ 目录提供的自定义仪表盘能力（支持 authoring、widgets、variables、sharing，入口见 dashboards/index.md），把链路、指标与仪表盘串成完整的性能观测链路。

错误跟踪（Error Tracking）

检测并诊断在线服务中的错误，输出带堆栈跟踪（stack traces）、上下文与用户反馈的详细错误报告，对应可替代Sentry的能力。核心模型为 TelemetryException.ts，并配套 TelemetrySourceMap.ts（Source Map，用于还原混淆堆栈）、TelemetryIngestionKey.ts（遥测接入密钥）等模型。错误数据同样经由 OpenTelemetry 管道进入平台，实现异常的统一采集、聚合与排查。

快速开始：如何把平台跑起来

仓库根 README.md 与 docker-compose.md 提供了两条上手路径：

• 自托管（Docker Compose，单机）：适用于 Debian / Ubuntu / RHEL 与 Docker Compose 环境。克隆仓库后复制配置、填写随机密钥并启动：

git clone --depth 1 --single-branch --branch release https://gitcode.com/GitHub_Trending/on/oneuptime.git cd oneuptime cp config.example.env config.env # 务必编辑 config.env，设置强随机密钥 npm start

启动后访问http://localhost注册账号即可开始使用。未安装 npm 时也可改用(export $(grep -v '^#' config.env | xargs) && docker compose up --remove-orphans -d)直接拉起容器。系统需求可参考 sizing.md：推荐 16GB 内存 / 8 核 / 400GB 磁盘，家庭实验环境最低 8GB 内存 / 4 核 / 20GB 磁盘。升级使用npm run update，卸载使用npm run down。

• Kubernetes（Helm）：生产环境推荐方案，仓库提供了完整 Helm Chart（见 HelmChart/ 目录与 upgrading.md 升级指南）；本地开发环境的搭建步骤见 local-development.md。

继续阅读

本文对应原文档的入门总览。接下来可按需深入对应模块的官方指南：

• 监控：从 website-monitor.md 开始，浏览 monitor/ 目录下的全部监控类型文档；
• 状态页：status-pages/index.md 及其同目录下的资源分组、品牌域名、订阅者文档；
• 事件：incidents/index.md 与事件状态/严重级别文档；
• 值班：on-call/ 目录；
• 集成与自动化：integrations/index.md 与 workflows/ 目录；
• 遥测接入：telemetry/ 目录。

通过以上模块的组合使用，即可把"监控发现异常 → 告警升级值班 → 状态页同步 → 日志/链路/指标定位根因 → 工作流联动其他工具"的完整闭环，统一运行在一个自托管、数据自主可控的开源平台上。

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime