2026/9/17 22:51:28
FEATURED · 精选文章 
OneUptime 仪表盘完全指南把指标、日志、事件与基础设施汇聚到同一屏【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文基于 OneUptime 官方文档《Dashboards – 概览》系统讲解仪表盘Dashboard的设计目标、可放置的组件类型、核心概念术语、在界面中的位置、从零搭建到公开分享的完整流程并结合仓库源码剖析其模式切换、组件类型枚举、变量机制与自动刷新配置等实现细节帮助读者掌握“一屏掌握系统健康状况”的实战能力。一、仪表盘解决什么问题OneUptime 的仪表盘Dashboard把平台已经收集到的各类数据——指标Metrics、日志Logs、链路追踪Traces、事件Incidents、监控器Monitors、Kubernetes 资源、主机Hosts——汇聚到同一个页面上让人用一眼就能看出系统当前发生了什么。典型的组合方式在页面上放置一个请求延迟图表旁边放一个未关闭事件列表再放一个 CPU 数值显示和一个带上下文说明的文本块保存后即可通过链接分享。具体来说仪表盘适合以下四类场景“一切正常吗”看板——面向值班轮岗Rufbereitschaft、每日站会或墙上的大屏电视发现关联——CPU 峰值、延迟升高、未关闭事件这三者同时出现在同一页面上比分散在三个标签页里更容易被察觉问题排查——分析故障时临时拼出来的一个仪表盘往往优于连续执行十条独立查询对外分享——面向客户的性能页、合作伙伴状态区或开源项目的公开仪表盘。二、仪表盘中可放置的组件文档列出的可放置组件分为五类它们与仓库源码中的组件类型枚举一一对应组件类别文档描述图表Chart展示时间序列趋势——延迟、错误、吞吐量单值字段与仪表盘Value / Gauge当前错误率、CPU、未关闭事件数表格Table按维度拆分的数据——最“吵”的 Top 10 主机、按服务统计的错误数文本块Text标题、上下文说明、指向 Runbook 的链接实时列表事件、告警通知、监控器、日志、Trace、Kubernetes 资源、Docker 资源、主机的实时列表从源码结构看Common/Types/Dashboard/DashboardComponentType.ts中的DashboardComponentType枚举定义了全部 50 余种组件类型覆盖基础可视化Chart、Value、Text、Clock、Table、Gauge外部数据源组件DataSourceChart、DataSourceValue、DataSourceGauge、DataSourceTable——源码注释明确说明这些组件读取的是外部数据源Prometheus、SQL、ClickHouse、Loki、Elasticsearch、REST而非 OneUptime 自身的遥测数据且在公开仪表盘中不可用日志与追踪LogStream、LogChart、TraceList、TraceChart、TraceTable运维实时列表IncidentList事件列表、AlertList告警列表、MonitorList监控器列表SLOSlo、SloList云原生与基础设施KubernetesPodList等 8 种 K8s 工作负载/节点列表、DockerHostList等 5 种 Docker 列表、PodmanHostList等 5 种 Podman 列表、ProxmoxNodeList、VMwareHostList、DockerSwarmNodeList、CephOsdList、CephPoolList、HostList其他NetworkMap网络地图、Html、安全事件流等。每种组件类型在Common/Types/Dashboard/DashboardComponents/目录下都有独立的接口定义文件如DashboardChartComponent.ts、DashboardIncidentListComponent.ts每种组件可携带的数据源、查询编辑器和渲染配置各不相同。完整的组件清单每个组件显示什么、何时选用见仓库文档 widgets.md。三、核心概念术语表文档给出了六个关键术语的定义这也是理解整个模块的骨架术语含义Dashboard仪表盘整个页面——一个名称、一个由组件组成的栅格、时间范围控件、一组变量Widget组件页面上的一块“磁贴”——图表、数值、列表、文本块Variable变量顶部下拉框同时过滤所有组件如 Cluster、Service、Customer、Environment时间范围Zeitbereich所有图表和数值共用的时间窗口在页面顶部统一设置刷新Aktualisieren组件重新拉取数据的频率——关闭、每几秒、每几分钟模式Modus要么是编辑可移动组件要么是查看只读访客视角这些术语在源码中都有精确对应模式编辑与查看Common/Types/Dashboard/DashboardMode.ts只定义了两个枚举值印证了文档的二分法enum DashboardMode { Edit Edit, View View, }变量五种类型Common/Types/Dashboard/DashboardVariable.ts中变量并非只是简单的下拉框而是支持五种类型export enum DashboardVariableType { CustomList Custom List, // 自定义列表逗号分隔的值 Query Query, // 通过 ClickHouse 查询动态填充选项 TextInput Text Input, // 文本输入 TelemetryAttribute Telemetry Attribute, // 绑定某个 OTel 属性键 ProjectLabel Project Labels, // 项目标签 }其中TelemetryAttribute类型最有特色变量绑定一个 OpenTelemetry 属性键例如k8s.cluster.name渲染时所选值会注入到任何针对该属性键的组件过滤条件中选项则从当前时间范围内该属性的去重值中获取。变量还支持多值选择isMultiSelect与默认值defaultValue。自动刷新七档间隔文档说“刷新频率是关闭、每几秒或每几分钟”源码Common/Types/Dashboard/DashboardViewConfig.ts给出了完整的七档配置export enum AutoRefreshInterval { OFF off, FIVE_SECONDS 5s, TEN_SECONDS 10s, THIRTY_SECONDS 30s, ONE_MINUTE 1m, FIVE_MINUTES 5m, FIFTEEN_MINUTES 15m, }getAutoRefreshIntervalInMs()将枚举转换为毫秒off返回null表示不刷新。该配置存储在仪表盘视图配置对象中export default interface DashboardViewConfig { _type: ObjectType.DashboardViewConfig; components: ArrayDashboardBaseComponent; // 页面上所有组件 heightInDashboardUnits: number; // 栅格高度以“仪表盘单位”计 refreshInterval?: AutoRefreshInterval | undefined; // 自动刷新间隔 variables?: ArrayDashboardVariable | undefined; // 页面级变量 }前端在App/FeatureSet/Dashboard/src/Components/Dashboard/DashboardView.tsx中消费该配置页面加载时若config.refreshInterval存在则写入本地状态随后以getAutoRefreshIntervalInMs(...)返回的毫秒值驱动周期性重新查询。也就是说刷新间隔是页面级配置作用于所有组件——这与术语表中“时间范围只设置一次、所有图表共用”的设计一致。四、在哪里找到仪表盘打开左侧导航中的Dashboards入口文档描述了六个页面及其用途页面在此做什么Dashboards列表仪表盘清单。新建、搜索、按标签过滤Dashboard → 查看工作区Workspace。在头部在编辑与查看之间切换Dashboard → 概述描述、所有者、标签Dashboard → 设置公开分享、密码、IP 访问白名单、自定义域名、品牌定制Dashboard → 所有者显式授予访问权限的用户与团队Dashboard → 删除删除该仪表盘五、搭建一个仪表盘六步流程文档给出的标准流程如下每步都结合源码补充了背景创建——起一个名称工作区以空白状态打开对应一个空的components数组添加组件——选择组件类型、配置其数据源、拖拽到期望位置每个组件的位置与尺寸由Common/Types/Dashboard/ComponentPosition.ts和ComponentSize.ts描述可选添加变量——例如添加一个service下拉框让同一个仪表盘适用于每个服务设置时间范围——预设值通常够用之后可微调可选公开分享——在设置中打开开关按需加密码或 IP 访问白名单可选自定义域名——把仪表盘托管到status.ihre-domain.de之类的自有域名上。关于公开分享从源码可以确认其安全边界Common/Server/Services/DashboardService.ts在读取仪表盘时会检查isPublicDashboard标志未公开则拒绝匿名访问Common/Server/API/DashboardAPI.ts对所有公开仪表盘接口统一套用了publicDashboardRateLimit限流中间件。这解释了 widgets 文档中的多处限制外部数据源组件和 Log 聚合图表在公开仪表盘中不可用SLO 组件仅对外发布当前数值而绝不泄露其定义监控的监控器、查询、评估周期。六、实战示例Checkout 服务的值班页文档给出了一个完整的小案例目标是给 Checkout 服务做一个值班页包含延迟、错误率、未关闭事件和一个实时日志流创建一个名为“Checkout 值班”的仪表盘添加变量service默认值checkout添加一个图表组件查询 P95 延迟过滤条件引用变量service旁边放一个数值组件展示错误率1% 触发黄色警告、5% 触发红色严重下方放一个事件列表组件过滤带checkout标签的事件再下方放一个日志流组件显示同一服务的日志保存。把顶部下拉框切换到payments——同一个仪表盘现在展示的就是 Payments 服务。这个示例完整演示了“变量驱动复用”的核心思想组件中的过滤条件不写死服务名而是引用页面级变量切换下拉框即整体刷新。结合DashboardVariable接口可以看到这类变量的attributeKey或名称会在渲染时注入各组件的过滤条件中且切换取值会触发重新渲染。七、仪表盘在 OneUptime 全局中的位置文档用四条边界说明仪表盘与其他模块的关系理解这些边界可以避免职责混淆监控器与遥测是数据源。你收集的每一条指标、每一行日志、每一个 Trace都可以在某个组件中被查询——这是所有Chart、Value、LogChart、TraceChart组件的数据基础事件与告警通知是只读的。IncidentList、AlertList组件只负责展示事件的创建与更新在其他地方完成。从源码结构看DashboardIncidentListComponent.ts等列表组件只定义过滤与展示字段不包含任何事件状态修改逻辑印证了“仪表盘只读”这一原则状态页与仪表盘互补而非替代。状态页StatusPage是面向客户的外部沟通“系统正常吗”仪表盘用于内部深入查看系统行为细节。仓库中App/FeatureSet/StatusPage/与App/FeatureSet/Dashboard/正是两个独立的功能模块工作流是行动的手段仪表盘是观察的手段。OneUptime 用工作流Workflow来执行处理动作用仪表盘来呈现正在发生什么。八、延伸阅读以下姊妹文档与本篇互为补充均位于App/FeatureSet/Docs/Content/de/dashboards/目录Dashboard 创建authoring——如何使用工作区、编辑组件组件清单widgets——全部组件的完整列表、每个组件的设置项与适用场景以及“该用哪个组件”的速查规则变量与过滤variables——让一个仪表盘复用于多个服务或客户分享与公开仪表盘sharing——公开 URL、密码、IP 白名单、自定义域名配置与权限configuration——所有者、标签、访问控制。此外前端工作区的实现入口在 Dashboard 视图组件 中可结合Common/Types/Dashboard/下的类型定义继续深入阅读。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 仪表盘完全指南：把指标、日志、事件与基础设施汇聚到同一屏
OneUptime 仪表盘完全指南把指标、日志、事件与基础设施汇聚到同一屏【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文基于 OneUptime 官方文档《Dashboards – 概览》系统讲解仪表盘Dashboard的设计目标、可放置的组件类型、核心概念术语、在界面中的位置、从零搭建到公开分享的完整流程并结合仓库源码剖析其模式切换、组件类型枚举、变量机制与自动刷新配置等实现细节帮助读者掌握“一屏掌握系统健康状况”的实战能力。一、仪表盘解决什么问题OneUptime 的仪表盘Dashboard把平台已经收集到的各类数据——指标Metrics、日志Logs、链路追踪Traces、事件Incidents、监控器Monitors、Kubernetes 资源、主机Hosts——汇聚到同一个页面上让人用一眼就能看出系统当前发生了什么。典型的组合方式在页面上放置一个请求延迟图表旁边放一个未关闭事件列表再放一个 CPU 数值显示和一个带上下文说明的文本块保存后即可通过链接分享。具体来说仪表盘适合以下四类场景“一切正常吗”看板——面向值班轮岗Rufbereitschaft、每日站会或墙上的大屏电视发现关联——CPU 峰值、延迟升高、未关闭事件这三者同时出现在同一页面上比分散在三个标签页里更容易被察觉问题排查——分析故障时临时拼出来的一个仪表盘往往优于连续执行十条独立查询对外分享——面向客户的性能页、合作伙伴状态区或开源项目的公开仪表盘。二、仪表盘中可放置的组件文档列出的可放置组件分为五类它们与仓库源码中的组件类型枚举一一对应组件类别文档描述图表Chart展示时间序列趋势——延迟、错误、吞吐量单值字段与仪表盘Value / Gauge当前错误率、CPU、未关闭事件数表格Table按维度拆分的数据——最“吵”的 Top 10 主机、按服务统计的错误数文本块Text标题、上下文说明、指向 Runbook 的链接实时列表事件、告警通知、监控器、日志、Trace、Kubernetes 资源、Docker 资源、主机的实时列表从源码结构看Common/Types/Dashboard/DashboardComponentType.ts中的DashboardComponentType枚举定义了全部 50 余种组件类型覆盖基础可视化Chart、Value、Text、Clock、Table、Gauge外部数据源组件DataSourceChart、DataSourceValue、DataSourceGauge、DataSourceTable——源码注释明确说明这些组件读取的是外部数据源Prometheus、SQL、ClickHouse、Loki、Elasticsearch、REST而非 OneUptime 自身的遥测数据且在公开仪表盘中不可用日志与追踪LogStream、LogChart、TraceList、TraceChart、TraceTable运维实时列表IncidentList事件列表、AlertList告警列表、MonitorList监控器列表SLOSlo、SloList云原生与基础设施KubernetesPodList等 8 种 K8s 工作负载/节点列表、DockerHostList等 5 种 Docker 列表、PodmanHostList等 5 种 Podman 列表、ProxmoxNodeList、VMwareHostList、DockerSwarmNodeList、CephOsdList、CephPoolList、HostList其他NetworkMap网络地图、Html、安全事件流等。每种组件类型在Common/Types/Dashboard/DashboardComponents/目录下都有独立的接口定义文件如DashboardChartComponent.ts、DashboardIncidentListComponent.ts每种组件可携带的数据源、查询编辑器和渲染配置各不相同。完整的组件清单每个组件显示什么、何时选用见仓库文档 widgets.md。三、核心概念术语表文档给出了六个关键术语的定义这也是理解整个模块的骨架术语含义Dashboard仪表盘整个页面——一个名称、一个由组件组成的栅格、时间范围控件、一组变量Widget组件页面上的一块“磁贴”——图表、数值、列表、文本块Variable变量顶部下拉框同时过滤所有组件如 Cluster、Service、Customer、Environment时间范围Zeitbereich所有图表和数值共用的时间窗口在页面顶部统一设置刷新Aktualisieren组件重新拉取数据的频率——关闭、每几秒、每几分钟模式Modus要么是编辑可移动组件要么是查看只读访客视角这些术语在源码中都有精确对应模式编辑与查看Common/Types/Dashboard/DashboardMode.ts只定义了两个枚举值印证了文档的二分法enum DashboardMode { Edit Edit, View View, }变量五种类型Common/Types/Dashboard/DashboardVariable.ts中变量并非只是简单的下拉框而是支持五种类型export enum DashboardVariableType { CustomList Custom List, // 自定义列表逗号分隔的值 Query Query, // 通过 ClickHouse 查询动态填充选项 TextInput Text Input, // 文本输入 TelemetryAttribute Telemetry Attribute, // 绑定某个 OTel 属性键 ProjectLabel Project Labels, // 项目标签 }其中TelemetryAttribute类型最有特色变量绑定一个 OpenTelemetry 属性键例如k8s.cluster.name渲染时所选值会注入到任何针对该属性键的组件过滤条件中选项则从当前时间范围内该属性的去重值中获取。变量还支持多值选择isMultiSelect与默认值defaultValue。自动刷新七档间隔文档说“刷新频率是关闭、每几秒或每几分钟”源码Common/Types/Dashboard/DashboardViewConfig.ts给出了完整的七档配置export enum AutoRefreshInterval { OFF off, FIVE_SECONDS 5s, TEN_SECONDS 10s, THIRTY_SECONDS 30s, ONE_MINUTE 1m, FIVE_MINUTES 5m, FIFTEEN_MINUTES 15m, }getAutoRefreshIntervalInMs()将枚举转换为毫秒off返回null表示不刷新。该配置存储在仪表盘视图配置对象中export default interface DashboardViewConfig { _type: ObjectType.DashboardViewConfig; components: ArrayDashboardBaseComponent; // 页面上所有组件 heightInDashboardUnits: number; // 栅格高度以“仪表盘单位”计 refreshInterval?: AutoRefreshInterval | undefined; // 自动刷新间隔 variables?: ArrayDashboardVariable | undefined; // 页面级变量 }前端在App/FeatureSet/Dashboard/src/Components/Dashboard/DashboardView.tsx中消费该配置页面加载时若config.refreshInterval存在则写入本地状态随后以getAutoRefreshIntervalInMs(...)返回的毫秒值驱动周期性重新查询。也就是说刷新间隔是页面级配置作用于所有组件——这与术语表中“时间范围只设置一次、所有图表共用”的设计一致。四、在哪里找到仪表盘打开左侧导航中的Dashboards入口文档描述了六个页面及其用途页面在此做什么Dashboards列表仪表盘清单。新建、搜索、按标签过滤Dashboard → 查看工作区Workspace。在头部在编辑与查看之间切换Dashboard → 概述描述、所有者、标签Dashboard → 设置公开分享、密码、IP 访问白名单、自定义域名、品牌定制Dashboard → 所有者显式授予访问权限的用户与团队Dashboard → 删除删除该仪表盘五、搭建一个仪表盘六步流程文档给出的标准流程如下每步都结合源码补充了背景创建——起一个名称工作区以空白状态打开对应一个空的components数组添加组件——选择组件类型、配置其数据源、拖拽到期望位置每个组件的位置与尺寸由Common/Types/Dashboard/ComponentPosition.ts和ComponentSize.ts描述可选添加变量——例如添加一个service下拉框让同一个仪表盘适用于每个服务设置时间范围——预设值通常够用之后可微调可选公开分享——在设置中打开开关按需加密码或 IP 访问白名单可选自定义域名——把仪表盘托管到status.ihre-domain.de之类的自有域名上。关于公开分享从源码可以确认其安全边界Common/Server/Services/DashboardService.ts在读取仪表盘时会检查isPublicDashboard标志未公开则拒绝匿名访问Common/Server/API/DashboardAPI.ts对所有公开仪表盘接口统一套用了publicDashboardRateLimit限流中间件。这解释了 widgets 文档中的多处限制外部数据源组件和 Log 聚合图表在公开仪表盘中不可用SLO 组件仅对外发布当前数值而绝不泄露其定义监控的监控器、查询、评估周期。六、实战示例Checkout 服务的值班页文档给出了一个完整的小案例目标是给 Checkout 服务做一个值班页包含延迟、错误率、未关闭事件和一个实时日志流创建一个名为“Checkout 值班”的仪表盘添加变量service默认值checkout添加一个图表组件查询 P95 延迟过滤条件引用变量service旁边放一个数值组件展示错误率1% 触发黄色警告、5% 触发红色严重下方放一个事件列表组件过滤带checkout标签的事件再下方放一个日志流组件显示同一服务的日志保存。把顶部下拉框切换到payments——同一个仪表盘现在展示的就是 Payments 服务。这个示例完整演示了“变量驱动复用”的核心思想组件中的过滤条件不写死服务名而是引用页面级变量切换下拉框即整体刷新。结合DashboardVariable接口可以看到这类变量的attributeKey或名称会在渲染时注入各组件的过滤条件中且切换取值会触发重新渲染。七、仪表盘在 OneUptime 全局中的位置文档用四条边界说明仪表盘与其他模块的关系理解这些边界可以避免职责混淆监控器与遥测是数据源。你收集的每一条指标、每一行日志、每一个 Trace都可以在某个组件中被查询——这是所有Chart、Value、LogChart、TraceChart组件的数据基础事件与告警通知是只读的。IncidentList、AlertList组件只负责展示事件的创建与更新在其他地方完成。从源码结构看DashboardIncidentListComponent.ts等列表组件只定义过滤与展示字段不包含任何事件状态修改逻辑印证了“仪表盘只读”这一原则状态页与仪表盘互补而非替代。状态页StatusPage是面向客户的外部沟通“系统正常吗”仪表盘用于内部深入查看系统行为细节。仓库中App/FeatureSet/StatusPage/与App/FeatureSet/Dashboard/正是两个独立的功能模块工作流是行动的手段仪表盘是观察的手段。OneUptime 用工作流Workflow来执行处理动作用仪表盘来呈现正在发生什么。八、延伸阅读以下姊妹文档与本篇互为补充均位于App/FeatureSet/Docs/Content/de/dashboards/目录Dashboard 创建authoring——如何使用工作区、编辑组件组件清单widgets——全部组件的完整列表、每个组件的设置项与适用场景以及“该用哪个组件”的速查规则变量与过滤variables——让一个仪表盘复用于多个服务或客户分享与公开仪表盘sharing——公开 URL、密码、IP 白名单、自定义域名配置与权限configuration——所有者、标签、访问控制。此外前端工作区的实现入口在 Dashboard 视图组件 中可结合Common/Types/Dashboard/下的类型定义继续深入阅读。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
` 构建带权限、审批、幂等与恢复保障的 Agent 工具)
