2026/9/20 3:55:14
FEATURED · 精选文章 
可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载Network Site网络站点是 OneUptime 中用来描述一个物理或地理场所的模型——它可以是一个大区Region、一个市场Market、一个加盟商、一个配送中心也可以是一家门店。站点之间可以互相嵌套形成树形结构网络设备Network Device挂载到站点上OneUptime 把设备的健康状态沿树向上汇总Rollup最终让某张大区卡片上的一个数字就能回答外面是不是有什么东西坏了。本文以官方文档为骨架结合仓库源码完整讲解站点层级、监控默认值、父级健康度计算策略、可用性口径以及计划维护Scheduled Maintenance对二者的影响帮助你为多门店/多分支网络资产设计出一套可落地的监控分层方案。站点入口位于Network → Sites本文涉及的源码模型为 NetworkSite.ts汇总引擎位于 NetworkSiteService.ts。层级结构The Hierarchy站点构成一棵树。每个站点都有一个站点类型Site Type——Region、Market、Unit、Data Center 等——类型列表是按项目隔离的可在Network → Settings → Site Types下维护。每个站点还有一个可选的父站点Parent Site。某类站点类型可以被标记为unit-level单元级用来标注资产树的叶子层级也就是单独的门店或分支机构。设备恰好挂载到一个站点。一个站点的子树subtree等于它自己加上它下面的所有站点子树内设备的健康状态正是该站点汇总的来源。因此一个自身没有任何设备的 Region 依然会有状态——因为它下面的 Units 有。在数据库模型中这些关系被显式建模见 NetworkSite.tsparentSiteId/parentSite指向父站点的自引用关系materializedPath以/分隔的祖先 ID 路径例如/rootId/childId/由服务端在父级变更时维护用于子树查询与汇总depth该站点之上的祖先数量根站点为 0networkSiteTypeId关联到按项目的类型表NetworkSiteType。需要留意的是模型中还保留了一个siteType字符串字段但它在代码注释中已被明确标记为DEPRECATED已废弃旧版本把站点类型作为内联字符串枚举存储现在改为按项目的NetworkSiteType查找表旧字段仅用于BackfillNetworkSiteTypes数据迁移回填新代码不应读写它。如果你在项目里看到这个字段请忽略。汇总何时重算官方文档给出的触发点是设备监控状态变化时、设备更换站点时、树被重新挂接父级时以及一个每五分钟一次的清扫sweep任务——它专门捕获那些只有时间流逝才会改变答案的状态。源码中的 NetworkSiteService.ts 也印证了这一点站点策略/阈值变更后会立即调用recomputeRollupForSite触发重算同时把五分钟清扫作为兜底backstop站点移动re-parent时调用recomputeRollupForSiteAndAncestors重算新旧祖先链站点删除后也会重算幸存祖先链的汇总。监控默认值Monitoring Defaults站点也是一次性声明其内部设备如何被监控的地方。Site → Settings → Monitoring Defaults包含两个字段设置项效果Default Probe默认探针负责 ping 该站点设备、并在设备持有凭证时通过 SNMP 采集设备的探针。设备在本站点创建且自身未指定探针时继承它无探针设备移入本站点时同样继承。Default SNMP Credential Profile默认 SNMP 凭证配置文件当设备自身和它自己的配置文件都没有携带凭证时用于对该站点设备进行 SNMP 采集的凭证配置文件。在站点上同时设置这两个值后一台新设备只需填写名称和地址即可完成注册从第一次轮询起它就会被 ping从第一次轮询起它就会走 SNMP 采集。模型层面对应着probeId与snmpCredentialProfileId两个外键字段见 NetworkSite.ts。源码注释特别强调默认探针通常应当是部署在该站点网络内的自定义探针custom probe因为只有它能真正触达站点的网络。两者在编辑时的行为差异刻意设计探针是拷贝到设备上的设备在站点内创建或移入时默认探针会被复制到设备上。之后即使修改站点的默认探针也不会重新指向那些已经持有探针的设备——哪个探针能触达设备是网络层面的事实而不是应该从站点表单批量覆写的偏好。凭证配置是实时读取的每次轮询都会现场读取。在站点上设置一个凭证配置文件后站点内每台无凭证设备都会从下一次轮询开始被采集无需逐台编辑清空它这些设备立即退回仅 ping。两者在树上的作用范围也不同探针沿整棵树继承落在无探针站点的设备会取最近祖先的探针。因此在一个 Region 上设置一个探针即可覆盖其下所有 Market 与 Unit而某个 Market 若自己指定了探针则为其子树覆写该设置。凭证配置文件只从设备所在站点本身读取Unit 中的设备不会拾取设置在 Region 上的配置文件——请把凭证配置文件设置在设备实际挂载的那些站点上。父级健康度如何计算How Parent Health Is Calculated每个站点在Site → Settings → Health Rollup下选择两种汇总策略之一。策略枚举定义在 SiteHealthRollupPolicy.ts其中WorstStatus默认——子树内任意设备的最差状态即为站点状态PercentThreshold——由子树内非 Operational 设备的占比决定站点状态。默认策略是WorstStatus这是刻意选择让升级upgrade不会改变任何既有站点的汇总行为。parseSiteHealthRollupPolicy会把任意存储字符串收敛为合法策略遇到旧数据或非法值时回退到默认值确保一次坏配置字符串绝不能导致汇总失败。最差状态Worst status of any device默认子树内任意设备报告的最差状态成为站点状态。状态严重度就是 MonitorStatus 的priority——种子数据中的阶梯是 Operational1、Degraded2、Offline3数字越大越严重。一个设备离线站点即离线无论旁边有多少健康设备。对Unit而言这是正确答案一栋建筑里的四台交换机加一台防火墙并不是相互独立的——其中一台熄灭就是该地址的问题取平均只会掩盖一次真实故障。对拥有四百多家门店的 Region而言这通常是错误答案第 12,000 家门店里的一台交换机熄灭会把整个大区刷成 Offline——在最狭窄的意义上正确却在任何实际意义上无用大区卡片永远无法变绿也就失去了承载信息的能力。离线设备百分比Percentage of devices down站点状态由子树内报告状态非 Operational 的设备占比决定离线设备占比站点状态0%Operational大于 0%、低于阈值Degraded项目中使用的那种既非 Operational 也非 Offline 的状态若项目没有该状态则回退到 Offline达到或超过阈值Offline阈值为每个站点独立设置Offline Threshold (%)默认 50。默认值 50 定义于 SiteHealthRollupPolicy.tsDefaultSiteOfflineThresholdPercent注释称其为刻意不预设立场的起点它是该大区大部分宕机与该大区大部分存活互换位置的唯一取值。注意第一行只要没有设备离线站点就是 Operational无论阈值被设得多低。阈值为 0 的含义是任何一台设备离线都使本站点离线而不是健康的大区是离线的。哪些设备有投票权两种策略在这一点上完全一致而它的影响比听上去更大已归档archived设备永不投票它们已退役虽然保留着自己的siteId但被排除在外。从未报告过任何内容的设备永不投票正在等待首次轮询的设备不能作为故障证据。它同时被排除在分子和分母之外因此一个处于接入中段的大区会基于已经应答的那一半来评分。探针轮询probe-polled设备普通类型以最近一次轮询的结果投票只要通过 ping 或 SNMP 可达即可而不看最后一次成功距今多久。一台能响应 ping 但 SNMP 采集失败的设备被视为可达并按可达投票站点卡片显示站点正常而设备行会显示 SNMP failing提示有人去修复凭证。监控器背书monitor-backed设备——即在自身设置中被切换到绑定监控器覆写bound-monitor override的设备——以其绑定的监控器状态投票因为没有任何东西在轮询它。若没有绑定任何监控器它从未报告过因而根本不投票。注意最后一对的不对称性附加到探针轮询设备上的网络设备监控器不会改变它的投票方式。一个配置了接口 down → Offline判据的监控器会给一台对每次 ping 都有响应的交换机盖上 Offline 章若允许一个暗掉的端口把整个站点刷红——而下面每一行设备都读作 Up——站点卡片就会与它所汇总的列表自相矛盾。轮询是轮询设备的健康来源监控器的作用是触发事件incident。如何选择策略面向加盟连锁资产的一个合理默认层级策略原因Unit / 门店最差状态一台设备离线就是一个站点出问题。Market百分比阈值约 50%一半门店离线的市场就是离线的。Region百分比阈值约 25–50%卡片应在单店故障时保持绿色在发生系统性事件时才变红。策略是按站点设置的所以你可以在 Region 行上应用百分比策略而让其下所有站点保持默认值。可用性Uptime每个站点都有一条状态时间线status timeline——每次汇总状态变化生成一行状态变化时开启、下一次变化时关闭。可用性由它计算而来时间线模型见 NetworkSiteStatusTimeline.ts其Starts At/Ends At字段记录每次状态变更的起止时间处于未被标记为 Operational状态的时间计为宕机时间重叠行会被合并因此没有任何一秒被重复计数任何行都没有覆盖的时间计为正常时间线只有在汇总真正运行后才会产生行没有证据不等于故障仍处于打开状态的行延伸到测量窗口结束。一个完全没有时间线行的站点显示—而非 100%从未被汇总过的站点是未监控不是完美。每日可用性Daily uptime在 30 天数字之外每个站点还显示Uptime (24h)Status Timeline页面则为最近 30 天每天绘制一条柱。它的存在是因为 30 天平均值无法表现糟糕的一天30 天窗口内的全天宕机只值 3.3 个百分点——于是某个整周二的黑暗站点月度报告仍是 96.7%一个读起来像四舍五入误差的数字。每日条带把同一份数据放到一个坏日子 一根坏柱子的坐标轴上。天数是滚动 24 小时切片、截止于当前时刻而非本地日历日设备、查看者与服务器可能身处不同时区不存在一个它们能达成一致的统一天。父级可用性不是子级可用性的平均值父级可用性来自父级自己的时间线即由上面的汇总策略生成的那条时间线而不是其子级百分比的算术平均。这一区分是刻意的对子级取平均会把两台设备的门店与两百台设备的配送中心等权处理也无法表达大区整体没问题因为只有一家门店离线。在百分比策略下父级可用性可以一句话说清该大区处于其降级阈值之上的时间占比。在最差状态策略下它变成该大区内完全没有任何东西离线的时间占比——一种严苛的读数这正是大区通常需要另一种策略的原因。网络站点的计划维护Scheduled Maintenance在**计划维护Scheduled Maintenance**事件的Resources Affected选择器中挂载站点方式与挂载监控器或主机完全一致。站点自身的Scheduled Maintenance标签页会列出所有挂载到它的维护事件。挂载父级即可覆盖其下所有内容。一个覆盖 Region 的维护窗口会覆盖其中的每个 Market 与 Unit包括在窗口排期之后才创建的站点。因此区域性运营商割接carrier cutover不必枚举四百家门店。覆盖是仅向下继承的覆盖某个 Unit 的窗口不会让它的 Region 进入维护中状态——Region 仍被期望保持在线同一时段内另一 Unit 发生的真实故障仍然必须计入 Region 的账上。维护窗口改变了什么窗口期间被维护站点的实时状态不变。因计划工作而关机的 Unit 在地图与树中仍读作 Offline只是旁边多一个 In maintenance 徽标。查看它的人需要知道它是关着的。被维护站点的可用性 %窗口从宕机时间和测量周期两者中同时扣除。两小时维护使这一天变为 22 小时长这两小时内的时间双向都不计入。其祖先的健康汇总被维护子树下的设备停止投票。大区不会因为一次早已在日历上的割接而变红。其祖先的可用性 %不受影响也无需修正——因为计划内宕机从一开始就没有进入它们的时间线。最后一行解释了为什么祖先通过抑制投票suppressing votes来处理而不是把区间从可用性中减去。若从大区的分母中减去窗口会连同把同一时段内该大区其他任何地方的真实故障一并抹除。在源码中这一机制被独立封装为 NetworkSiteMaintenanceSuppression.ts站点是唯一一类健康汇总会在维护中被静默、但自身实时状态仍如实上报的可维护资源——维护期间站点继续报告关于自身的真相改变的是谁在投票。按项目的进行中维护查找还会有几秒缓存。扣除使用的是事件声明的 Starts At / Ends At而不是工作人员碰巧在状态间切换它的时间——因此可用性数字可以手工与日历对账。如果一整天都落在窗口内它在每日条带中的柱会绘制为维护而非完美的一天且不向平均值贡献任何内容。与监控器的交互把监控器挂载到同一事件仍然做它一直做的事该监控器的主动监控在窗口期间被暂停。二者相互独立——挂载站点是为了把它从站点汇总及其可用性中排除挂载监控器是为了让它们停止告警。站点告警Alerting on a SiteSite → Settings → Alerting在站点汇总迁移transition到非 Operational 状态时打开一条告警并在站点恢复时自动解决。它刻意只关注迁移在已不健康的站点上启用告警武装的是下一次迁移而不是对过去补发告警。因为告警依附于汇总上文策略决定了它何时触发。百分比策略下的大区在大区越过其阈值时告警而不是在第一家门店变暗时告警。模型层面对应shouldAlertWhenUnhealthy布尔开关默认 false与alertSeverityId未设置时默认取项目最严重级别字段服务端通过currentActiveAlertId记录当前打开的站点不健康告警供恢复逻辑自动解决见 NetworkSite.ts 与 NetworkSiteService.ts 中的告警同步逻辑。相关阅读网络设备监控Network Device Monitor——挂载到这些站点的设备的注册、轮询与告警库存总览Inventory——网络设备在更大资产目录中的呈现位置。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime Network Sites 完全指南层次结构、健康汇总策略与可用性计算OneUptime Network Sites 完全指南层次结构、健康汇总策略与可用性计算 本指南基于 OneUptime 官方文档与仓库源码系统讲解 Ne可观测性后端运维前端云原生微服务AI AgentAdvisor vs Optuna两大超参数调优工具全方位对比测评Advisor vs Optuna两大超参数调优工具全方位对比测评 在机器学习模型开发过程中超参数调优是一个至关重要的环节它直接影响模型的性能和泛化能力。Kronos金融大模型解码市场语言的开源预测引擎Kronos金融大模型解码市场语言的开源预测引擎 在瞬息万变的金融市场中传统技术分析方法正面临前所未有的挑战。想象一下一位量化分析师面对海量的K线数据试人工智能大模型基础模型预训练金融科技创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 网络站点（Network Site）深度指南：层级健康汇总、可用性与计划维护
可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载Network Site网络站点是 OneUptime 中用来描述一个物理或地理场所的模型——它可以是一个大区Region、一个市场Market、一个加盟商、一个配送中心也可以是一家门店。站点之间可以互相嵌套形成树形结构网络设备Network Device挂载到站点上OneUptime 把设备的健康状态沿树向上汇总Rollup最终让某张大区卡片上的一个数字就能回答外面是不是有什么东西坏了。本文以官方文档为骨架结合仓库源码完整讲解站点层级、监控默认值、父级健康度计算策略、可用性口径以及计划维护Scheduled Maintenance对二者的影响帮助你为多门店/多分支网络资产设计出一套可落地的监控分层方案。站点入口位于Network → Sites本文涉及的源码模型为 NetworkSite.ts汇总引擎位于 NetworkSiteService.ts。层级结构The Hierarchy站点构成一棵树。每个站点都有一个站点类型Site Type——Region、Market、Unit、Data Center 等——类型列表是按项目隔离的可在Network → Settings → Site Types下维护。每个站点还有一个可选的父站点Parent Site。某类站点类型可以被标记为unit-level单元级用来标注资产树的叶子层级也就是单独的门店或分支机构。设备恰好挂载到一个站点。一个站点的子树subtree等于它自己加上它下面的所有站点子树内设备的健康状态正是该站点汇总的来源。因此一个自身没有任何设备的 Region 依然会有状态——因为它下面的 Units 有。在数据库模型中这些关系被显式建模见 NetworkSite.tsparentSiteId/parentSite指向父站点的自引用关系materializedPath以/分隔的祖先 ID 路径例如/rootId/childId/由服务端在父级变更时维护用于子树查询与汇总depth该站点之上的祖先数量根站点为 0networkSiteTypeId关联到按项目的类型表NetworkSiteType。需要留意的是模型中还保留了一个siteType字符串字段但它在代码注释中已被明确标记为DEPRECATED已废弃旧版本把站点类型作为内联字符串枚举存储现在改为按项目的NetworkSiteType查找表旧字段仅用于BackfillNetworkSiteTypes数据迁移回填新代码不应读写它。如果你在项目里看到这个字段请忽略。汇总何时重算官方文档给出的触发点是设备监控状态变化时、设备更换站点时、树被重新挂接父级时以及一个每五分钟一次的清扫sweep任务——它专门捕获那些只有时间流逝才会改变答案的状态。源码中的 NetworkSiteService.ts 也印证了这一点站点策略/阈值变更后会立即调用recomputeRollupForSite触发重算同时把五分钟清扫作为兜底backstop站点移动re-parent时调用recomputeRollupForSiteAndAncestors重算新旧祖先链站点删除后也会重算幸存祖先链的汇总。监控默认值Monitoring Defaults站点也是一次性声明其内部设备如何被监控的地方。Site → Settings → Monitoring Defaults包含两个字段设置项效果Default Probe默认探针负责 ping 该站点设备、并在设备持有凭证时通过 SNMP 采集设备的探针。设备在本站点创建且自身未指定探针时继承它无探针设备移入本站点时同样继承。Default SNMP Credential Profile默认 SNMP 凭证配置文件当设备自身和它自己的配置文件都没有携带凭证时用于对该站点设备进行 SNMP 采集的凭证配置文件。在站点上同时设置这两个值后一台新设备只需填写名称和地址即可完成注册从第一次轮询起它就会被 ping从第一次轮询起它就会走 SNMP 采集。模型层面对应着probeId与snmpCredentialProfileId两个外键字段见 NetworkSite.ts。源码注释特别强调默认探针通常应当是部署在该站点网络内的自定义探针custom probe因为只有它能真正触达站点的网络。两者在编辑时的行为差异刻意设计探针是拷贝到设备上的设备在站点内创建或移入时默认探针会被复制到设备上。之后即使修改站点的默认探针也不会重新指向那些已经持有探针的设备——哪个探针能触达设备是网络层面的事实而不是应该从站点表单批量覆写的偏好。凭证配置是实时读取的每次轮询都会现场读取。在站点上设置一个凭证配置文件后站点内每台无凭证设备都会从下一次轮询开始被采集无需逐台编辑清空它这些设备立即退回仅 ping。两者在树上的作用范围也不同探针沿整棵树继承落在无探针站点的设备会取最近祖先的探针。因此在一个 Region 上设置一个探针即可覆盖其下所有 Market 与 Unit而某个 Market 若自己指定了探针则为其子树覆写该设置。凭证配置文件只从设备所在站点本身读取Unit 中的设备不会拾取设置在 Region 上的配置文件——请把凭证配置文件设置在设备实际挂载的那些站点上。父级健康度如何计算How Parent Health Is Calculated每个站点在Site → Settings → Health Rollup下选择两种汇总策略之一。策略枚举定义在 SiteHealthRollupPolicy.ts其中WorstStatus默认——子树内任意设备的最差状态即为站点状态PercentThreshold——由子树内非 Operational 设备的占比决定站点状态。默认策略是WorstStatus这是刻意选择让升级upgrade不会改变任何既有站点的汇总行为。parseSiteHealthRollupPolicy会把任意存储字符串收敛为合法策略遇到旧数据或非法值时回退到默认值确保一次坏配置字符串绝不能导致汇总失败。最差状态Worst status of any device默认子树内任意设备报告的最差状态成为站点状态。状态严重度就是 MonitorStatus 的priority——种子数据中的阶梯是 Operational1、Degraded2、Offline3数字越大越严重。一个设备离线站点即离线无论旁边有多少健康设备。对Unit而言这是正确答案一栋建筑里的四台交换机加一台防火墙并不是相互独立的——其中一台熄灭就是该地址的问题取平均只会掩盖一次真实故障。对拥有四百多家门店的 Region而言这通常是错误答案第 12,000 家门店里的一台交换机熄灭会把整个大区刷成 Offline——在最狭窄的意义上正确却在任何实际意义上无用大区卡片永远无法变绿也就失去了承载信息的能力。离线设备百分比Percentage of devices down站点状态由子树内报告状态非 Operational 的设备占比决定离线设备占比站点状态0%Operational大于 0%、低于阈值Degraded项目中使用的那种既非 Operational 也非 Offline 的状态若项目没有该状态则回退到 Offline达到或超过阈值Offline阈值为每个站点独立设置Offline Threshold (%)默认 50。默认值 50 定义于 SiteHealthRollupPolicy.tsDefaultSiteOfflineThresholdPercent注释称其为刻意不预设立场的起点它是该大区大部分宕机与该大区大部分存活互换位置的唯一取值。注意第一行只要没有设备离线站点就是 Operational无论阈值被设得多低。阈值为 0 的含义是任何一台设备离线都使本站点离线而不是健康的大区是离线的。哪些设备有投票权两种策略在这一点上完全一致而它的影响比听上去更大已归档archived设备永不投票它们已退役虽然保留着自己的siteId但被排除在外。从未报告过任何内容的设备永不投票正在等待首次轮询的设备不能作为故障证据。它同时被排除在分子和分母之外因此一个处于接入中段的大区会基于已经应答的那一半来评分。探针轮询probe-polled设备普通类型以最近一次轮询的结果投票只要通过 ping 或 SNMP 可达即可而不看最后一次成功距今多久。一台能响应 ping 但 SNMP 采集失败的设备被视为可达并按可达投票站点卡片显示站点正常而设备行会显示 SNMP failing提示有人去修复凭证。监控器背书monitor-backed设备——即在自身设置中被切换到绑定监控器覆写bound-monitor override的设备——以其绑定的监控器状态投票因为没有任何东西在轮询它。若没有绑定任何监控器它从未报告过因而根本不投票。注意最后一对的不对称性附加到探针轮询设备上的网络设备监控器不会改变它的投票方式。一个配置了接口 down → Offline判据的监控器会给一台对每次 ping 都有响应的交换机盖上 Offline 章若允许一个暗掉的端口把整个站点刷红——而下面每一行设备都读作 Up——站点卡片就会与它所汇总的列表自相矛盾。轮询是轮询设备的健康来源监控器的作用是触发事件incident。如何选择策略面向加盟连锁资产的一个合理默认层级策略原因Unit / 门店最差状态一台设备离线就是一个站点出问题。Market百分比阈值约 50%一半门店离线的市场就是离线的。Region百分比阈值约 25–50%卡片应在单店故障时保持绿色在发生系统性事件时才变红。策略是按站点设置的所以你可以在 Region 行上应用百分比策略而让其下所有站点保持默认值。可用性Uptime每个站点都有一条状态时间线status timeline——每次汇总状态变化生成一行状态变化时开启、下一次变化时关闭。可用性由它计算而来时间线模型见 NetworkSiteStatusTimeline.ts其Starts At/Ends At字段记录每次状态变更的起止时间处于未被标记为 Operational状态的时间计为宕机时间重叠行会被合并因此没有任何一秒被重复计数任何行都没有覆盖的时间计为正常时间线只有在汇总真正运行后才会产生行没有证据不等于故障仍处于打开状态的行延伸到测量窗口结束。一个完全没有时间线行的站点显示—而非 100%从未被汇总过的站点是未监控不是完美。每日可用性Daily uptime在 30 天数字之外每个站点还显示Uptime (24h)Status Timeline页面则为最近 30 天每天绘制一条柱。它的存在是因为 30 天平均值无法表现糟糕的一天30 天窗口内的全天宕机只值 3.3 个百分点——于是某个整周二的黑暗站点月度报告仍是 96.7%一个读起来像四舍五入误差的数字。每日条带把同一份数据放到一个坏日子 一根坏柱子的坐标轴上。天数是滚动 24 小时切片、截止于当前时刻而非本地日历日设备、查看者与服务器可能身处不同时区不存在一个它们能达成一致的统一天。父级可用性不是子级可用性的平均值父级可用性来自父级自己的时间线即由上面的汇总策略生成的那条时间线而不是其子级百分比的算术平均。这一区分是刻意的对子级取平均会把两台设备的门店与两百台设备的配送中心等权处理也无法表达大区整体没问题因为只有一家门店离线。在百分比策略下父级可用性可以一句话说清该大区处于其降级阈值之上的时间占比。在最差状态策略下它变成该大区内完全没有任何东西离线的时间占比——一种严苛的读数这正是大区通常需要另一种策略的原因。网络站点的计划维护Scheduled Maintenance在**计划维护Scheduled Maintenance**事件的Resources Affected选择器中挂载站点方式与挂载监控器或主机完全一致。站点自身的Scheduled Maintenance标签页会列出所有挂载到它的维护事件。挂载父级即可覆盖其下所有内容。一个覆盖 Region 的维护窗口会覆盖其中的每个 Market 与 Unit包括在窗口排期之后才创建的站点。因此区域性运营商割接carrier cutover不必枚举四百家门店。覆盖是仅向下继承的覆盖某个 Unit 的窗口不会让它的 Region 进入维护中状态——Region 仍被期望保持在线同一时段内另一 Unit 发生的真实故障仍然必须计入 Region 的账上。维护窗口改变了什么窗口期间被维护站点的实时状态不变。因计划工作而关机的 Unit 在地图与树中仍读作 Offline只是旁边多一个 In maintenance 徽标。查看它的人需要知道它是关着的。被维护站点的可用性 %窗口从宕机时间和测量周期两者中同时扣除。两小时维护使这一天变为 22 小时长这两小时内的时间双向都不计入。其祖先的健康汇总被维护子树下的设备停止投票。大区不会因为一次早已在日历上的割接而变红。其祖先的可用性 %不受影响也无需修正——因为计划内宕机从一开始就没有进入它们的时间线。最后一行解释了为什么祖先通过抑制投票suppressing votes来处理而不是把区间从可用性中减去。若从大区的分母中减去窗口会连同把同一时段内该大区其他任何地方的真实故障一并抹除。在源码中这一机制被独立封装为 NetworkSiteMaintenanceSuppression.ts站点是唯一一类健康汇总会在维护中被静默、但自身实时状态仍如实上报的可维护资源——维护期间站点继续报告关于自身的真相改变的是谁在投票。按项目的进行中维护查找还会有几秒缓存。扣除使用的是事件声明的 Starts At / Ends At而不是工作人员碰巧在状态间切换它的时间——因此可用性数字可以手工与日历对账。如果一整天都落在窗口内它在每日条带中的柱会绘制为维护而非完美的一天且不向平均值贡献任何内容。与监控器的交互把监控器挂载到同一事件仍然做它一直做的事该监控器的主动监控在窗口期间被暂停。二者相互独立——挂载站点是为了把它从站点汇总及其可用性中排除挂载监控器是为了让它们停止告警。站点告警Alerting on a SiteSite → Settings → Alerting在站点汇总迁移transition到非 Operational 状态时打开一条告警并在站点恢复时自动解决。它刻意只关注迁移在已不健康的站点上启用告警武装的是下一次迁移而不是对过去补发告警。因为告警依附于汇总上文策略决定了它何时触发。百分比策略下的大区在大区越过其阈值时告警而不是在第一家门店变暗时告警。模型层面对应shouldAlertWhenUnhealthy布尔开关默认 false与alertSeverityId未设置时默认取项目最严重级别字段服务端通过currentActiveAlertId记录当前打开的站点不健康告警供恢复逻辑自动解决见 NetworkSite.ts 与 NetworkSiteService.ts 中的告警同步逻辑。相关阅读网络设备监控Network Device Monitor——挂载到这些站点的设备的注册、轮询与告警库存总览Inventory——网络设备在更大资产目录中的呈现位置。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime Network Sites 完全指南层次结构、健康汇总策略与可用性计算OneUptime Network Sites 完全指南层次结构、健康汇总策略与可用性计算 本指南基于 OneUptime 官方文档与仓库源码系统讲解 Ne可观测性后端运维前端云原生微服务AI AgentAdvisor vs Optuna两大超参数调优工具全方位对比测评Advisor vs Optuna两大超参数调优工具全方位对比测评 在机器学习模型开发过程中超参数调优是一个至关重要的环节它直接影响模型的性能和泛化能力。Kronos金融大模型解码市场语言的开源预测引擎Kronos金融大模型解码市场语言的开源预测引擎 在瞬息万变的金融市场中传统技术分析方法正面临前所未有的挑战。想象一下一位量化分析师面对海量的K线数据试人工智能大模型基础模型预训练金融科技创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
