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、布局配置dashboardViewConfigJSON 类型以及一套品牌与公共访问字段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仪表盘 → 总览。文档给出的常见命名模式具有很强的实操指导性维度示例标签按团队team:platform、team:checkout、team:growth按环境env:prod、env:staging按用途purpose:oncall、purpose:exec、purpose:investigation当项目积累了数十上百块面板时Paneles仪表盘列表页面支持按标签过滤这是最快速的定位方式。在数据模型上Dashboard.labels是EntityArray类型、通过DashboardLabel联接表与Label多对多关联见 Dashboard.ts。与所有者规则对称仓库还提供了自动打标签的规则模型 DashboardLabelRule同样支持按面板名称/描述正则与已有标签匹配命中后自动将labelsToAdd中指定的标签附加到面板上已存在的标签不会重复附加。这意味着平台组新建的面板自动打上team:platform这类运营约定可以通过规则固化而非依赖人工记忆。四、权限Permisos基于项目角色的访问控制仪表盘权限建立在项目级 RBAC 之上。文档给出的四个核心权限如下权限允许的操作创建面板Crear Panel创建新的仪表盘读取面板Leer Panel查看面板在私有模式下编辑面板Editar Panel修改组件、变量与配置删除面板Eliminar Panel删除仪表盘这些权限在源码中有精确对应。在 Permission.ts 中定义了CreateDashboard、ReadDashboard、EditDashboard、DeleteDashboard等权限常量在 Dashboard.ts 的TableAccessControl与各列的ColumnAccessControl中这四类操作分别与ProjectOwner、ProjectAdmin以及上述细粒度权限组合校验。例如create要求ProjectOwner/ProjectAdmin/CreateDashboard三者之一read开放给ProjectMember、Viewer、SettingsAdmin、SettingsMember、SettingsViewer以及ReadDashboardupdate要求ProjectOwner/ProjectAdmin/EditDashboarddelete要求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三个设置共同决定谁能看到面板公开开关Panel Público——关闭时公共 URL 直接返回 404主密码Contraseña maestra——配置后访客必须先输入密码才能看到面板内容IP 白名单Lista blanca de IPScale 计划——配置后来自其他 IP 的请求一律被拒绝。三者可以任意组合。文档给出的最严格组合是公开开启 配置主密码 启用 IP 白名单——典型场景是合作伙伴门户Portal de socios希望在公开、保密、来源限定三个维度上同时加锁。5.1 源码中的字段落点在 Dashboard.ts 中这层访问控制与字段一一对应isPublicDashboardBoolean默认false公共开关本体并带有ColumnBillingAccessControl更新受计划约束enableMasterPasswordBoolean默认false与masterPassword密码开关与密码本体。masterPassword以HashedString类型存储hashed: true并配套masterPasswordSalt字段——模型注释明确指出每个面板有一个独立随机盐混入哈希盐在每次写密码时生成、永不通过 API 暴露给调用方同时允许校验旧的未加盐哈希并在成功解锁后升级ipWhitelistVeryLongTextIP 白名单文档描述为每个 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
