SevOne 数据平台用例

关于

本手册旨在为 SevOne NMS 和 SevOne Data Insight 中提供的有价值的功能提供各种用例。

用例

警报


基线标准偏差
	问题	描述	解决方案	值
1	静态阈值会生成错误警报。	每天晚上 8:00 执行服务器备份。因此，服务器 CPU 使用率的百分比变得非常高。	根据基线 + 标准差启用警报 (建议使用两个标准差)。请参阅 https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule 了解更多详情。	警报现在会考虑晚上 8:00 时该指标的正常值。如果此时指示符 (例如， CPU) 在 80% 到 95% 之间，那么如果此时 CPU 在 95% ，那么不会触发任何警报。因此，不会触发错误警报，只会产生有意义的警报。


基线百分比
	问题	描述	解决方案	值
1	针对偏离正常值很多的度量值发出警报。	静态阈值不是选项，标准偏差相当大。因此，会创建显着分布的警报，因此很难捕获这些警报。	必须使用基线百分比来定义基线值的特定百分比阈值 (例如， 50%)。	必须使用基线来定义警报阈值。
2、	识别路由同级 (EIGRP ， OSPF ， BGP ， IS-IS 和 RIP) 数量的更改。	静态阈值不能用于具有不同数量的同级的不同 EIGRP 路由器。	当设备上的同级数量发生更改 (例如， 5% 差异) 时，必须使用基线百分比来发出警报。	将动态选取每个设备的对等数量上的任何更改。即，不必手动定义每个设备的阈值。否则，这将需要用户手动为每个设备创建警报，并在网络上每次发生更改时更新策略-这会导致大量维护开销。


基线变化量
	问题	描述	解决方案	值
1	当两个或多个同级关闭时发出警报。	边缘路由器具有不同数量的 BGP 同级，具有不同的 ISP (有些具有 10 个，有些具有 6 等)。当至少有两个同级已关闭时，必须发送警报。这是一个问题，因为每个设备都有不同数量的设备。即，另一个基线。在另一种情况下，两个设备可能相差 50% ，也可能相差 10%。因此，基线百分比不是选项。	每个设备具有不同数量的 BGP 同级。基线增量必须用于与基线相比上升小于 2 (BGP 同级) 的 BGP 同级数。	仅当 BGP 网络的弹性受到影响时，才会发送警报。


与平均值的斜率方差偏差 (DFA)
	问题	描述	解决方案	值
1	连接到 WiFi 网络的客户机显着减少。	方案: 无线提供商与机场签订服务级别协议 (SLA)。如果未通知机场 WiFi 存在问题 (即使问题可能与 WiFi 基础结构本身无关，但已影响 WiFi 导致有线网络出现问题) ，那么将对无线提供商进行处罚。为了监视 WiFi 网络的总体状态， WiFi 提供者会监视已连接的客户机数。对于警报， WiFi 提供者无法使用静态阈值 (在夜间，机场的人员少于白天)。并且，也不能使用基线警报 (银行假日，体育赛事等)。	必须使用斜坡警报来监视连接的客户机数突然减少的情况。	用于识别连接的客户机数量突然减少的斜坡警报。最后的 6 数据点允许 WiFi 提供程序识别问题，因此避免被客户 (在此示例中为机场) 处罚。
2、	接口速度更改。	某些类型的接口 (例如，端口通道， DSL 连接等) 当接口上出现一些问题时 (例如，端口通道的一个成员不工作， DSL 接口上的噪声增加等) ，接口速度可能会变化。	当接口速度更改时，必须使用斜率警报。	使用斜率警报，在接口上存在无法以任何其他方式检测到的问题时发送通知。在问题升级之前，将发送通知以执行操作并防止端口通道的更多接口关闭。
3。	磁盘利用率快速提高。	场景: 客户在某些磁盘上存在问题，其中空间利用率相当低，但在任何人实现之前，这些磁盘会突然快速增长并变满。	当磁盘利用率突然增加时，必须使用斜率警报来通知。	如果在达到任何阈值之前磁盘已满，那么会主动通知客户，并允许客户在磁盘利用率达到 100% 之前采取必要操作。
4.	气温快速升高。	场景: 当 A/C 在其中一个数据中心关闭时，温度会快速升高，并且在收到警报以执行任何操作时，温度已超过所需设置。	当温度显着升高时，必须使用斜坡警报。	在温度达到阈值之前，会主动通知客户。它还可避免在降低阈值时生成的错误警报。在大多数情况下，当温度快速上升时，是 A/C 问题。
5	UPS (不间断电源) 电池容量下降。	在一些旧的 UPS 设备中，在电池上运行时，仅持续几分钟。在修订阈值上发出警报不是解决方案，因为它会生成大量错误警报，有时可能为时已晚。	当电池容量显着下降时，必须使用斜坡警报。	在电池容量过低之前，会主动通知客户。这可避免由过高的静态阈值生成的错误警报，并且客户不需要猜测在每种情况下哪个静态阈值是最佳的。


斜率方差相对标准差 (RSD)
该方法计算最近 6 次民意调查的标准偏差 ( https://www.mathsisfun.com/data/standard-deviation-formulas.html ）与最近 6 次民意调查的平均值之间的差值。当指示符值大量传播时，将触发此类型的警报。即， 6 轮询的值离平均值很远。
	问题	描述	解决方案	值
1	正在切换接口。	因特网电路正在波动，并且正在上升和下降，但是，协议状态不断指示它已上升。检查电路是向上还是向下的唯一方法是检查流量利用率。	必须使用 RSD 警报来监视接口的流量 (HCOctets) 的标准偏差与平均值。	通过使用 RSD 警报，客户知道电路何时关闭，即使状态指示它已启动。


到最新数据点的时间
	问题	描述	解决方案	值
1	不适用	不适用	不适用	不适用


计数超过阈值
	问题	描述	解决方案	值
1	当因特网电路在过去 30 分钟内三次达到 90% 时发出警报。	场景: 作为一家金融服务公司，延迟和丢包非常重要。互联网电路一定不能饱和 -- 95% 的利用率很长一段时间是个大问题。必须在发生此情况之前发送警报，并且不能依赖基线。重要的是，互联网电路不打 90-95%。	当接口流量大于 90% 且 "计数超过阈值" 在过去 30 分钟内为 3 时，必须发送警报。	准时通知客户，以便他们可以在饱和之前主动升级互联网电路。


时间超过阈值
	问题	描述	解决方案	值
1	在过去一小时内，当因特网电路在 10 分钟内达到 90% 时发出警报。	场景: 作为一家金融服务公司，延迟和丢包非常重要。互联网电路一定不能饱和 -- 95% 的利用率很长一段时间是个大问题。必须在发生此情况之前发送警报，并且不能依赖基线。重要的是，因特网电路不会达到 90-95%.Count ，因为所有回路都具有不同的轮询时间间隔，并且某些回路已启用 HFP。	当接口流量在过去一小时内至少 10 分钟内超过 90% 时，必须发送警报。	准时通知客户，以便他们可以在饱和之前主动升级互联网电路。如果将轮询频率分配给对象，那么无关紧要。

数据收集


设备认证
	问题	描述	解决方案	值
1	无法从 F5 设备获取服务器，池，池成员等信息。	F5 设备受监视，但并非所有相关信息都由 SevOne获取。	打开设备认证案例并安装提供给客户的 .spk 文件。	使用 10 天的设备认证服务后，客户可以监控所有期望的指标以及他们不知道的更多指标。


高频轮询
	问题	描述	解决方案	值
1	存在问题的设备上的粒度有限。	对于日常监视， 5 分钟轮询已足够。但是，在设备上识别问题时，必须提高粒度以更好地了解设备/关注指示符的行为。	在发生问题的设备上启用高频轮询。可以手动完成此操作，也可以使用 REST API 自动完成此操作。	通过在存在问题的设备上启用高频轮询，客户可获取细粒度数据，以帮助更有效地对问题进行故障诊断，而不会影响由于设备上的连续高频轮询而可能产生的性能。


交叉对象计算/组轮询器/合成指示符
	问题	描述	解决方案	值
1	确定两个链路在其冗余站点上饱和的时间。	这两个站点在任何时候都在使用这些链接。这不是由于故障转移所致。	当两个链路的平均带宽超过 80% 利用率时， SevOne CoC 允许总带宽和警报的 AVG。	这意味着其中一个链路已完全饱和，另一个链路必须进行非常密切的监视。或者，这两个链接都接近 90% 的利用率过高。
2、	具有多个站点的受管服务提供者 (MSP) 可能不希望看到每个站点上的每个接口。	网络运营中心 (NOC) 团队不希望报告每个站点上的每个接口。	Group Poller 可用于使用 RegEx对站点上的所有接口进行分组。然后，可以在每个站点的所有链接中汇总利用率。	通过对所有接口进行分组，它允许客户创建一个具有堆积线条的报告，以轻松识别特定站点是否迂到其他站点未迂到的问题。
3。	大量虚拟机 (VM) 对所有系统上的 CPU 负载的可视性有限。	需要在具有最多 40 个以上 CPU 的系统上的高 CPU 负载时发出警报。在具有 40 个 CPU 的系统上，高负载下的单个 CPU 不值得发出警报。但是，客户没有单个指示符来表示此情况。	通过使用 REST API ，查询可以收集所有 HOST-MIB CPU 并自动创建 CoC 对象/计算。	所有 CPU 都不会聚集，并且能够获取更有意义的警报。此特定场景聚集了超过 19K 个 CPU。
4.	显示 0 到 1 之间的百分比而不是值。	客户希望查看以百分比表示的度量值。然而， SNMP 数据仅显示0到1之间的数值。	合成指标将 SNMP 值乘以100。	这将在整个 NOC 团队中生成更简单，更清晰且更一致的报告。
5	红色区域中的时间。	客户希望查看链接的利用率超过 80% 的时间。	可以创建合成指示符并在以下位置标记: 使用率低于 50%时为 0 1 表示 > 50% 和 < 80 2 表示> 80% 通过执行此操作，当值超过 50% 时，客户具有可视性，当值超过 80% 时，客户不会仅在值超过 80% 时获得可视性。	允许客户绘制和报告在每个专区中发生的时间量或发生的次数。这有助于获取更准确的信息或用于容量规划的信息。
6	Brocade 温度 OID 显示 (摄氏度 * 2)。即，如果温度为 25 摄氏度， OID 返回 50 摄氏度。	Brocade 具有一个 MIB 文件，其中包含显示机箱温度的 OID。但是，此温度不是以摄氏或华氏为单位，而是以 (摄氏 * 2) 为单位。这是一个问题，因为当 NOC 团队检查温度时，他们必须记住实际温度不是显示的值，而是该值除以 2。	创建用于将温度 OID 的值除以 2 的合成指示符。	创建的合成指示符 (将温度 OID 的值除以 2) 不再创建假警报。
7	需要度量以显示设备的总体运行状况。	为了减少噪音， NOC 团队需要一个指标来为他们提供一个设备的整体健康状况。此度量必须考虑诸如 "可用性" ， "CPU 使用率" ， "内存" 和 "错误" 等指标。	创建 CoC 以生成由以下度量组成的新指示符。可用性 CPU (如果超过 80%) 内存 (如果超过 80%) 接口流量 (如果超过 80%) 错误废弃温度可用风扇可用电源	创建的新指示符摆脱了所有指示符和警报产生的所有噪声，从而将焦点放在单个度量上。
8	查看 VPN 连接的总体数量，而不考虑 VPN 集中器。	方案: 一家公司有几个 VPN 集中器，它们在单个集中器上的连接低于特定阈值时发出警报。因此，会生成大量错误警报，指示当一个 VPN 集中器获取的连接数可能比另一个 VPN 集中器获取的连接数更多时， VPN 可能存在问题。	创建将所有 VPN 连接汇总为单个度量的组轮询器。	这允许客户仅在 VPN 连接总数低于阈值 (不取决于特定设备) 时创建警报。
9	仅在其中一个 CPU 核心上获取大量针对高 CPU 的警报。	有一个单一的 CPU 核心时不时会出现很高的情况，并生成警报。但是，其余 CPU 负载相当低。必须创建警报以仅在 CPU 平均值过高时触发。	使用设备的所有 CPU 核心的平均值创建 CoC 。	仅当所有 CPU 核心都处于高运行状态时，才会收到 CPU 警报。这将避免单个 CPU 核心高运行所产生的警报噪声。


通用收集器
	问题	描述	解决方案	值
1	获取特定文件夹的磁盘大小。	要度量应用程序的性能，必须监视服务器上特定文件夹的大小。执行此操作的一种方法是在服务器上执行 CLI 命令以获取结果。例如， df <enter path to folder>	Universal Collector 脚本可用于执行所需的命令并根据需要格式化结果。	已减少错误警报数。通过自动执行此任务，它减少了专用于监视应用程序性能的时间量。
2、	从 JSON 文件读取性能数据。	如果某类设备不兼容 SNMP ，则从该设备收集性能数据的唯一方式是读取JSON文件获取详细信息。	使用 Universal Collector 来解析 JSON 文件并收集性能数据。	可自动监视设备的性能。
3。	监控数千台不兼容 SNMP 的设备。	需要监控来自 5G 核心设备的性能指标，这些设备与 SNMP 不兼容。该信息可导出为 CSV 格式。	使用通用 xStats 适配器可监视每小时的百万个指示器。	针对 SevOne 功能提供不受支持的设备上的可视性，例如大规模速度，基线或高级警报。
4.	云提供者监视，例如 Amazon Web Services (AWS)。	云提供者依赖于 API 来共享性能数据。	将产品化的 xStats 适配器用于 AWS。	在云提供者上提供 SevOne 功能的可视性，例如大规模速度，基线或高级警报。
5	Arista SNMP 未能返回所有必需数据。但是，可以使用 Arista API 获取数据。	客户并未通过 SNMP 提交所有必需数据。有时，需要依赖 CLI 命令。 Arista 开发了一个 API ，允许客户从 API 接口从 CLI 命令获取数据。	使用延迟数据来查询 Arista API 并获取所需的数据。	该收集流程已实现自动化，用于获取无法从 SNMP 获取的数据。
6	轮询设备以获取特定度量时，返回的数据不干净-它与其他不相关的数据混合在一起，因此难以抽取所需信息。	有时从设备轮询数据时，无论是使用 SNMP 还是其他协议，结果都可能不符合预期格式。在将数据存储在平台上之前，需要对其进行转换/抽取。	将延迟数据与仅抽取和保存所需数据的定制脚本配合使用 (例如，使用正则表达式)。	现在可以监视之前无法执行的任何类型的数据，因为格式不正确或者它还包含不相关的数据。


遥测
	问题	描述	解决方案	值
1	需要以更高的频率从客户的网络设备收集和接收数据。	客户需要以更高的频率监控一些指标，以便对某些指标的性能保持更仔细的观察。使用 SNMP 并非可行方案，因为该设备无法处理大量 SNMP 请求。	使用遥测以更高频率监视某些关键指标。	通过使用遥测，客户现在可以按所需频率获取信息; 不会影响网络设备的性能。
2、	需要根据灵活的需求，监视不同频率的数据。	每个指标都有不同的要求，需要以不同的频率进行监测。例如，序列号的指示符不需要频繁监视，而某些接口错误需要以比正常 5 分钟轮询等更频繁的调度进行监视。	使用遥测来调整频率，以根据网络的当前情况将数据流式传输到遥测收集器。	通过使用遥测，可以按期望的频率获取度量。指标上的存储不会被浪费。需要更频繁地监测的指标获得了更多的可见性。

集成


Webhook
	问题	描述	解决方案	值
1	未针对 "警报" 检查电子邮件。	支持团队从他们使用的几个监视工具接收到太多包含警报的电子邮件。因此，将忽略电子邮件，导致缺少需要立即关注的关键警报。	警报必须与 Slack/团队集成。	当支持团队在 Slack 上接收到警报时，不会将其忽略，并允许他们对可以解决问题的个人进行标记。这使得它成为团队之间更协作的工作方法。
2、	很难同时通知所有相关个人有关一个问题的决议。	为了避免警报泛滥，客户决定将所有警报发送到集中位置，即 NOC 团队。某些警报需要上报/立即关注。但是，由于所有警报都集中在某个位置，因此导致了若干延迟，并且缺少了需要立即关注/将问题分配给正确的个人的警报。	警报必须与通知系统 (例如 PagerDuty) 集成。	发生严重警报时，将触发与 PagerDuty 的集成，并根据定义的业务规则 (具体取决于一天中的时间，涉及的设备，事件等) 进行集成。将触发特定通知方法，包括电子邮件， Slack 上的消息或电话会议，以与所有相关人员互动。
3。	NOC 团队花费了太多时间来解决诸如从完整磁盘中删除文件之类的小问题	NOC 团队花费了太多时间来执行可轻松实现自动化的手动任务。	警报必须与自动化工具 (例如， Ansible) 集成。	触发警报时，如果可以使用某些自动化运行手册来解决该问题，那么 SevOne 会将数据发送到自动化工具以自动修复问题。


SevOne 数据发布程序 (SDP)
	问题	描述	解决方案	值
1	实时应用网络更改。	为了更有效地在 VPN 集中器上应用更改，需要针对每个 VPN 集中器的连接数实时数据，以便在这些设备上应用规则更改。	将 SDP 与 ansible 集成，以实际方式流式采集数据，从而自动执行网络更改。	一旦 SDP 与 ansible (通过 Kafka 总线) 集成，就会实时更改 VPN 集中器的策略，从而避免拥塞问题和性能问题。
2、	其他团队使用 Grafana 或类似的内容进行分析。	团队不使用 SURF 或 SevOne Data Insight 来使用 SevOne 数据，因为他们喜欢使用自己的工具。当使用API从 SevOne, 收集数据时，性能无法令人接受。	使用 SDP 将数据实时流至 Grafana。	其他工具可以选择要获取的数据 (使用主题和过滤器) ，并且可以实时使用所需的所有数据，而不会出现性能问题。
3。	存储长时间的数据。	一些市场法规要求客户在很长一段时间 (5-6 年) 内保存数据。无需非常频繁地访问这些数据，将其保留在内部会给客户带来巨大的成本。	配置 SDP 以与云数据仓库集成。例如，支持 Kafka 总线的 Cloudera。	客户可以遵守部门法律，最大限度降低长时间保存数据的成本。


SevOne 应用程序接口
	问题	描述	解决方案	值
1	需要手动将元数据从配置管理数据库 (CMDB) 工具 (ServiceNow) 复制到 SevOne。	客户需要很长时间才能复制元数据属性 (例如 "区域" ， "国家或地区" ， "城市" ， "优先级" 和 "团队" 等)。从一个工具到另一个工具	使用 API 通过脚本每天将值从 CMDB 工具复制到 SevOne 以及从 SevOne 复制到 CMDB 工具。	现在， CMDB 工具具有与 SevOne同步的所有必需元数据。
2、	从 SevOne 警报手动在 ServiceNow 中引发突发事件。	客户从 SevOne 警报手动在 ServiceNow 中生成突发事件。这会导致问题，因为工程师有时会输入不正确的数据。此外，在 SevOne 中触发警报与在 SevOne中创建突发事件之间可能需要一些时间。	使用 API 直接引发 ServiceNow 突发事件。	使用 API 时，客户会实时创建 ServiceNow 中的所有突发事件，并且没有任何类型。
3。	使用准确的信息维护 CMDB 数据。	由于网络在不断变化的情况下运行的自然方式，要使 CMDB 保持最新状态具有挑战性。网络设备上的模块/卡上的更改，分配给虚拟机的 CPU 或 RAM ，序列号，拓扑等都是常见的，但很难跟踪和保持更新。	使用 API 从 SevOne 读取数据，并在 CMDB 工具中对其进行更新。	使用 API 时，自动化流程会填充部分资产详细信息。这既节省了时间，又避免了人为错误。


WDK
	问题	描述	解决方案	值
1	将 ServiceNow 事件与 SevOne 性能数据相关联。	支持团队难以将事件与性能数据相关联，以查找网络中问题的根本原因。	使用 WDK 在单个窗口小部件中显示来自 SevOne 和 ServiceNow 突发事件的性能数据。	使用 WDK 时，支持团队现在可以关联突发事件和性能数据，使其能够识别更快生成突发事件的性能问题。
2、	识别由网络更改生成的性能影响。	支持团队难以关联网络更改以及这些更改对网络性能的影响。	使用 WDK 在单个窗口小部件中显示来自 SevOne 的性能数据和来自 ServiceNow 变更请求的网络变更。	使用 WDK 时，支持团队现在可以识别网络更改对网络性能的影响。

报告


日历窗口小部件
	问题	描述	解决方案	值
1	同时发生性能问题。	有时，性能问题以特定频率发生。然而，发现这种复发情况并不总是容易的。	使用日历窗口小部件。	"日历" 窗口小部件提供了轻松可视化模式的功能，使用户能够快速识别性能问题。


图表设置
	问题	描述	解决方案	值
1	没有清晰可见的 Rx 和 Tx 流量。	当性能指标图表繁忙时，很难区分 Rx 和 Tx 流量。	对 Tx 流量使用负 y 轴。	将 Rx 流量显示为正 (获取的内容) ，将 Tx 流量显示为负 (获取的内容) ，可以更清晰更轻松地了解该接口的流量利用率。


基线
	问题	描述	解决方案	值
1	识别设备行为的更改。	在规划步骤以在网络上部署配置更改期间，非常常见的主要步骤之一是获取网络的基线，以了解在部署更改后网络上发生了哪些更改。	在设备上可用的所有指示符上启用基线。	SevOne 生成的基线为用户提供了在不同时间点了解指示符的正常值所需的信息。通过此功能，用户可以将指标的当前值与基线进行比较，以了解应用的网络更改的影响。
2、	用于度量的正常行为的故障诊断时间。	网络操作中心 (NOC) 团队花费大量时间对某些度量值 (例如， CPU 使用率或接口流量) 的利用率峰值进行故障诊断，这些度量值最终是该度量值的正常行为。	对报告启用基线。	通过启用基线， NOC 团队现在可以轻松地将度量标准的正常行为与当前值进行比较，从而使他们能够更快地对问题进行故障诊断。


标准偏差
	问题	描述	解决方案	值
1	不适用	不适用	不适用	不适用


时间与时间
	问题	描述	解决方案	值
1	检查指示符在最近更改后是否具有正常值。	客户希望确定当前值是否为 normal。基线是执行此操作的良好方法，但有时会滞后。因此，如果最近 (过去几天/几周) 进行了更改，有时无法使用基线。	使用一段时间 (上周的平均值) 将当前结果与上周的平均值进行比较。	用户可以将当前值与自更改完成以来的正常/期望值进行比较。
2、	密切关注指示器上的更改。	客户正在非常密切地监视度量值。为了识别重要的更改，客户需要考虑一天中的时间 (例如，下午的连接数比上午的连接数更多)。	使用一段时间 (前一天的平均值) 将当前结果与前一天的值进行比较。	用户可以将当前值与前一天的行为进行比较。这使用户能够了解指示符上的更改。


投影
	问题	描述	解决方案	值
1	无法查看何时将在容量上使用 WAN 电路。	客户希望了解 WAN 电路何时达到容量，以便在电路发生之前对其进行升级。	使用 TopN 时间到容量 (或 90% ， 80% 等) 针对该指标。	当使用 TopN 时间到容量时，客户知道他们在电路达到容量之前有多少时间，从而允许他们相应地规划升级。
2、	虚拟机容量规划。	不清楚客户何时需要增加虚拟基础架构的资源。	启用图表上的预测趋势。	通过启用图表上的预测趋势，可轻松可视化现有资源的未来利用率，使用户能够更好地预测未来需求。


百分位数
	问题	描述	解决方案	值
1	作为一家 MSP，我希望不按分配给客户的带宽收费，而是按第 95 百分位数收费。	很常见的情况是， ISP/MSP 会为他们注册的客户提供更多带宽，以便在流量激增时不限制他们。因此，为了不按峰值收费，而是按正常使用的最大带宽收费，ISP/MSP 使用了第 95 百分位数。	在报告中启用 95 百分位数。	现在，ISP/MSP 可以获得客户所消耗带宽的第 95 百分位值，从而轻松知道需要向客户收取多少费用。


报告链接
	问题	描述	解决方案	值
1	对步骤一致性进行故障诊断。	支持团队经理已经意识到，支持团队成员会感到困惑，因为在某些报告中，他们可以向下钻取到设备/对象/指示符以获取更详细的视图，而在某些其他报告中，此选项不可用。	为设备/对象/指示符创建全局报告链接。	由于支持团队熟悉该工具中提供的向下钻取工作流程，因此现在需要更少的时间对问题进行故障诊断。


报告链宁
	问题	描述	解决方案	值
1	在一天中的特定时间内持续延迟。	场景: 客户站点正在经历从中午 12:00 到下午 3:00 的一致延迟，很难深入到导致延迟的特定问题。	报告从该站点上最常用的接口 (使用动态过滤) 到流对话的链接。	确定生成导致站点上出现问题的流量的特定 IP。
2、	难以识别杂乱无章的报告上的峰值。	性能指标图表可能会变得非常混乱，因此很难发现问题或峰值。	使用从 TopN 到 "性能指标" 图表的报告链接。	通过将窗口小部件链接在一起，当需要突出显示一个设备并在 "性能指标" 图表上查看性能时，用户可以提高效率。


变量
	问题	描述	解决方案	值
1	客户有一个按地理位置分布的团队，他们希望有自己位置的报告。	方案: 因为有 100 个不同的站点，并且每个站点上的团队都希望有一个专门的报告供他们使用，这意味着客户必须创建 100 个具有相同数据但具有特定位置的过滤器的不同报告。这是很有问题的，因为他们每次需要向报告添加新的指标或 KPI 时，都需要更新 100 个报告。此外，小组经理和区域小组组长希望为他们自己的区域编写一份报告，这意味着还需要进一步的报告。	每个站点创建一个设备组，并在报告上使用设备组变量。	创建每个站点一个设备组时，会有一个报告满足所有团队的需求，将 100 多个报告合并为一个报告，并大幅缩短每个报告类型的维护时间。