企业官网建设流程全解析

OneUptime 仪表盘配置与权限管理完全指南：所有者、标签、RBAC 与公共访问控制

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

本篇指南围绕 OneUptime 官方文档中"仪表盘配置与权限"（configuration.md）展开，系统讲解一个仪表盘在投入使用后需要掌握的访问控制与运维设置：如何通过所有者与标签精细控制可见范围，如何理解并分配基于项目的 RBAC 权限，如何组合"公共开关 + 主密码 + IP 白名单"三层防线，以及数据保留、复制、删除与备份的完整运维路径。读完本文，你将能独立为团队搭建一套"按需最小可见"的仪表盘治理方案，并能在源码层面定位每一项配置的落点。

一、仪表盘配置与权限的核心定位

在 OneUptime 中，仪表盘是把指标、日志、链路、事件、监控项等已有数据聚合到单一页面的载体（参见 仪表盘总览）。默认情况下，仪表盘仅对登录的项目成员可见，是项目的私有资源。因此"配置与权限"章节解决的核心问题是：当仪表盘需要长期维护时，如何回答三个问题——谁能看、谁能改、谁能删。

从数据模型看，仪表盘本体由 Dashboard 模型 承载。它归属于项目（projectId），拥有名称、slug、描述、标签数组（labels，多对多关联Label）、布局配置（dashboardViewConfig，JSON 类型）以及一套品牌与公共访问字段（pageTitle、pageDescription、logoFile、faviconFile、isPublicDashboard、masterPassword、ipWhitelist等）。理解这些字段，就能理解后续每一节配置在数据库中的真实落点。

二、所有者（Propietarios）：细粒度的显式访问

2.1 什么是一块仪表盘的"所有者"

所有者是你在项目级角色之外，显式授予某块仪表盘访问权的用户与团队。它解决的是"项目级只读角色过宽"的典型问题——例如某块面板包含客户级别的敏感细节，只应让客户成功团队可见，而不应让所有具备项目只读权限的成员都能打开。

配置入口在Panel → Propietarios（仪表盘 → 所有者）：

• 添加所有者用户：为单个成员追加该面板的访问权限；
• 添加所有者团队：为该团队内每一名成员批量授予同样的访问权限。

在源码层面，这两类关系分别由两张独立的关联表实现：

• DashboardOwnerUser：记录"用户—仪表盘"的所有者关系。模型上声明了dashboardId + userId + projectId的唯一索引与唯一约束，避免同一用户被重复添加为所有者；同时带有isOwnerNotified标记字段，用于记录该用户是否已收到被设为所有者的通知。
• DashboardOwnerTeam：记录"团队—仪表盘"的所有者关系，同样有dashboardId + teamId + projectId的唯一约束。

2.2 所有者的自动化分配

除了手工在Panel → Propietarios中添加，OneUptime 还提供了规则驱动的自动分配机制：DashboardOwnerRule。该模型允许你定义"当新仪表盘满足匹配条件时，自动把指定用户/团队设为所有者"。匹配条件包括：

• dashboardNamePattern/dashboardDescriptionPattern：对面板名称、描述做不区分大小写的正则匹配，留空则匹配任意；
• dashboardLabels：仅当面板已带有至少一个指定标签时触发，留空则忽略标签；
• isEnabled：规则总开关，默认开启；
• notifyOwners：命中规则后是否通知被添加的所有者，默认开启。

动作字段ownerUsers/ownerTeams指定命中后要添加的所有者。这套规则与下文"标签规则"（DashboardLabelRule）配合，可以实现"按命名/标签自动治理所有权"的规模化运营。

三、标签（Etiquetas）：组织与检索仪表盘的第一手段

标签是给面板打上的分类 tag，应用位置在Panel → Vista General（仪表盘 → 总览）。文档给出的常见命名模式具有很强的实操指导性：

当项目积累了数十上百块面板时，Paneles（仪表盘列表）页面支持按标签过滤，这是最快速的定位方式。

在数据模型上，Dashboard.labels是EntityArray类型、通过DashboardLabel联接表与Label多对多关联（见 Dashboard.ts）。与所有者规则对称，仓库还提供了自动打标签的规则模型 DashboardLabelRule：同样支持按面板名称/描述正则与已有标签匹配，命中后自动将labelsToAdd中指定的标签附加到面板上（已存在的标签不会重复附加）。这意味着"平台组新建的面板自动打上team:platform"这类运营约定可以通过规则固化，而非依赖人工记忆。

四、权限（Permisos）：基于项目角色的访问控制

仪表盘权限建立在项目级 RBAC 之上。文档给出的四个核心权限如下：

这些权限在源码中有精确对应。在 Permission.ts 中定义了CreateDashboard、ReadDashboard、EditDashboard、DeleteDashboard等权限常量；在 Dashboard.ts 的@TableAccessControl与各列的@ColumnAccessControl中，这四类操作分别与ProjectOwner、ProjectAdmin以及上述细粒度权限组合校验。例如：

• create要求ProjectOwner/ProjectAdmin/CreateDashboard三者之一；
• read开放给ProjectMember、Viewer、SettingsAdmin、SettingsMember、SettingsViewer以及ReadDashboard；
• update要求ProjectOwner/ProjectAdmin/EditDashboard；
• delete要求ProjectOwner/ProjectAdmin/DeleteDashboard。

4.1 所有者与自定义域名的"独立权限位"

文档特别强调：所有者与自定义域名都有各自独立的权限组，从而可以在不授予"编辑面板"权限的前提下，单独授予"管理所有者"或"管理自定义域名"的能力。从 Permission.ts 可以清楚看到这一设计：

• 面板所有者相关：ReadDashboardOwnerUser/EditDashboardOwnerUser/DeleteDashboardOwnerUser、ReadDashboardOwnerTeam/EditDashboardOwnerTeam/DeleteDashboardOwnerTeam，以及规则层的ReadDashboardOwnerRule/EditDashboardOwnerRule/DeleteDashboardOwnerRule；
• 自定义域名相关：ReadDashboardDomain/EditDashboardDomain/DeleteDashboardDomain；
• 标签规则相关：ReadDashboardLabelRule/EditDashboardLabelRule/DeleteDashboardLabelRule。

这些权限同样出现在权限目录（Permission.ts 中ReadDashboardDomain等常量附近），并可被挂到项目角色下批量授予。

4.2 在哪里分配

在Productos → Equipos → Permisos（产品 → 团队 → 权限）中，为各团队的角色勾选上述权限即可完成分配。建议遵循最小权限原则：把"只读"与"仅管理所有者"拆开授予，避免为了某个管理动作而被迫放开整块面板的编辑权。

五、公共面板的访问控制：三层可叠加的安全开关

当你通过 分享与公共面板 将面板公开后（入口为Panel → Ajustes → Panel Público），三个设置共同决定"谁能看到"：

1. 面板公开开关（Panel Público）——关闭时，公共 URL 直接返回 404；
2. 主密码（Contraseña maestra）——配置后，访客必须先输入密码才能看到面板内容；
3. IP 白名单（Lista blanca de IP，Scale 计划）——配置后，来自其他 IP 的请求一律被拒绝。

三者可以任意组合。文档给出的最严格组合是：公开开启 + 配置主密码 + 启用 IP 白名单——典型场景是合作伙伴门户（Portal de socios），希望在公开、保密、来源限定三个维度上同时加锁。

5.1 源码中的字段落点

在 Dashboard.ts 中，这层访问控制与字段一一对应：

• isPublicDashboard（Boolean，默认false）：公共开关本体，并带有@ColumnBillingAccessControl（更新受计划约束）；
• enableMasterPassword（Boolean，默认false）与masterPassword：密码开关与密码本体。masterPassword以HashedString类型存储（hashed: true），并配套masterPasswordSalt字段——模型注释明确指出：每个面板有一个独立随机盐混入哈希，盐在每次写密码时生成、永不通过 API 暴露给调用方，同时允许校验旧的未加盐哈希并在成功解锁后升级；
• ipWhitelist（VeryLongText）：IP 白名单，文档描述为"每个 IP 一行，仅在面板公开时生效"，并通过@ColumnBillingAccessControl将更新限制在Scale 计划（与文档中"plan Scale"的表述一致）。

5.2 主密码的使用建议

文档建议在以下场景启用主密码：

• 要与合作伙伴/客户共享，但不想让泄露的 URL 直接可用；
• 面板属于"半公开"性质——不想逐个邀请观众成为团队成员，又不宜直接放到开放的互联网上。

若需要更严格的管控（按观众建独立账号、审计"谁看过什么"），则应当保持面板私有，改为把观众以只读团队成员身份邀请进来。

六、数据保留（Retención de datos）：面板不失效，数据有期限

面板本身不会过期。其展示的数据则遵循项目的保留策略：指标、日志、链路在计划所保有的时间范围内可查询。一个指向"最近 90 天"的组件，在只保留 30 天数据的计划下，将只显示仍被存储的部分——也就是说，面板的"时间窗口"是期望值，实际可见范围受底层数据保留期约束。

这与 OneUptime 的遥测数据管道设计一致：面板是读取层，指标/日志/链路是数据层，数据层按计划执行保留与清理，面板只是查询这些数据的视图。

七、复制面板（Duplicar）：模板化的最佳实践

在面板列表中选中Duplicar（复制）即可复制现有面板。复制品包含：

• 每一个组件（widget）；
• 每一个变量；
• 全部配置。

唯一例外：公共共享设置。复制品总是以"未公开"状态起步，需要你自行决定是否重新打开公开开关。

文档给出的典型用法是"把模板做成分叉"：比如把"我们的值班面板（nuestro panel de guardia）"复制成某特定服务专用的副本。结合 变量与过滤器 中"一个面板 + 一个service变量 = 对所有服务复用"的思路，复制 + 变量改造是批量产出定制面板的最快路径。

八、删除面板（Eliminar）：不可逆操作

删除入口在Panel → Eliminar（仪表盘 → 删除）。需要注意：

• 不可撤销：面板的布局设计以及与之关联的自定义域名会被一并删除；
• 遥测数据不受影响：删除面板不会删除底层指标、日志、链路数据；
• 若面板在自定义域名上公开，删除后该 URL 立即停止解析——若想保持 URL 持续可用，应先把域名迁移到另一块面板，再执行删除。

在数据模型上，Dashboard与DashboardDomain、DashboardOwnerUser、DashboardOwnerTeam等关联表通过外键（onDelete: "CASCADE"）级联清理，因此"删除即清关联"是数据库层面的既定行为。

九、备份：自托管与云托管的不同姿势

• 自托管 OneUptime：定期备份数据库即可。面板配置与项目其他数据一同存储在数据库中，无需单独备份面板；
• OneUptime Cloud：备份由平台托管。若你需要自己的副本，可通过OneUptime API读取面板数据（对应仓库中的 APIReference 功能集 与面板的 CRUD 端点/dashboard，见 Dashboard.ts 中的@CrudApiEndpoint），将配置序列化导出保存。

十、延伸阅读

• 分享与公共面板：公开模式下的密码、IP 白名单、自定义域名与品牌配置；
• 变量与过滤器：用变量把一块面板变成面向多服务/多客户的模板；
• 创建面板：画布与组件编辑；
• 组件目录：各类组件的完整清单与展示内容；
• 仪表盘总览：面板在整个产品体系中的定位与快速上手。

实操建议：将"所有者 + 标签 + 独立权限位"三者配合使用——用标签组织目录、用所有者收敛可见性、用细粒度权限分离"看、改、管"职责，再对任何外发场景叠加公共访问三层开关，即可形成一套完整、可审计的仪表盘治理闭环。

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