【阅读论文】-- LiveRAC：系统管理时序数据的交互式可视化探索

本文主要是介绍【阅读论文】-- LiveRAC：系统管理时序数据的交互式可视化探索，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

zotero截图

LiveRAC：系统管理时序数据的交互式可视化探索

- 摘要
- 引言
- 相关工作
- 系统管理
- - 角色和活动
  - 当前工具的局限性
- 迭代设计
- - 方法
  - 参加者
  - 设计阶段
- 设计要求
- 可视化解决方案
- - 设计原则
  - LiveRAC 接口
  - 执行
- 纵向评价
- - 非正式纵向研究方法
  - 对设计的影响
  - 使用场景
- 结论
- 致谢
- 参考文献

标题头图截图

摘要

我们介绍了LiveRAC，这是一个支持大规模系统管理时间序列数据分析的可视化系统，该系统涵盖了数千个网络设备上的数百个参数。LiveRAC通过可重新排序的图表矩阵提供了高信息密度，其中语义缩放功能使每个图表的视觉表现能适应当前的空间大小。LiveRAC允许用户并排比较任意组合的设备和参数，且可在多个细节层级上进行视觉对比。经过一系列设计和开发阶段，LiveRAC最终在生产环境中成功部署。我们对LiveRAC进行了非正式的纵向评估，目的是更好地理解在目标环境中哪些提出的可视化技术最为有用。

关键词：可视化、时间序列数据、纵向研究

引言

时间序列数据在科学、工程和商业中普遍存在。可视化通过利用人类感知来减少认知负荷，帮助人们解释数据。统计图形，尤其是时间值对的折线图，大量用于检查单个或小组时间序列。然而，理解大量时间序列数据仍然很困难。我们选择大规模系统管理作为一个领域，人们需要在多个细节级别上理解大量时间序列数据，并考虑到经常变化的分组。

用于托管服务的数据仓库可以存储有关数万台物理和虚拟服务器的详细信息。对于每个系统，CPU 负载和内存使用等参数都会定期记录。该数据可能会存档多年。系统管理人员必须能够查询详细数据来满足各个客户的需求，同时保持对托管环境全局状态的了解。

不幸的是，收集和存储此类数据的工具的功能与帮助系统管理员理解数据并采取行动的工具的功能之间存在差距。一种广泛使用的分析方法是检查显示一台服务器上一个参数状态的图表。一次检查一个这样的图表只能产生一个支离破碎的、低级的环境视图。人类工作记忆的局限性使得很难对整个集合进行有用的概述。

许多商业系统管理工具提供带有摘要统计信息的高级仪表板，但这些隐藏了系统状态的真正复杂性。例如，大多数使用阈值，如果一定比例的系统可用并响应，则将受监视的状态评级为健康。然而，如果只有一个关键系统发生故障，数据中心可能不健康，或者如果许多系统因日常维护而发生故障，数据中心也可能仍然健康。此外，这些工具不允许进行足够的深入探索来发展和确认有关根本原因及其补救措施的假设。为了超越这一点，可视化工具应该帮助系统管理员快速分析单个低级图表和高级摘要仪表板之间的记录数据。

我们的主要贡献是 LiveRAC 的设计方法和实现，这是一个用于浏览和关联具有高信息密度的时间序列数据的可视化系统。它可以扩展到数千个设备上的数十个参数通道。 LiveRAC 使用可重新排序的图表矩阵，允许对设备和参数分组进行多个详细级别的并排视觉比较。这些图表支持语义缩放，提供适合可用空间的视觉表示。为大型公司的运营人员设计和部署研究可视化系统，他们必须提供可靠的生产服务，是一项有趣且雄心勃勃的方法挑战。我们在分阶段模型中采用了标准的以用户为中心的设计流程，每个阶段都进行需求收集和原型开发。我们通过越来越高保真的原型展示了我们的想法的实用性，获得了组织内控制生产数据和最终用户访问权限的个人的认可。我们讨论了从可视化技术的概念验证实施转向大型组织中高度专有数据的部署系统所带来的随之而来的挑战和见解。

我们描述了两个次要贡献。第一个是新颖的时间序列可视化系统，可以呈现数百万个数据点的视觉表示。第二个是与操作系统管理人员一起在生产环境中对 LiveRAC 进行非正式的现场研究，以确定我们的设计选择是否在生产环境中提供了预期的功能。

系统管理

我们描述了系统管理专业角色和活动，以及支持该用户群体的现有工具的局限性。

角色和活动

系统管理专业人员在托管服务中的作用是满足托管提供商与其客户之间建立的服务级别协议。这些协议规定了要提供的服务的所有重要方面，包括：将提供哪些服务、如何提供服务、如何衡量服务提供以及不满足服务协议的后果。履行这些协议是系统管理专业人员的主要任务。提供可靠的生产服务需要业务、分析和系统管理技能的结合。

为了管理复杂性，系统管理专业人员被分为多个响应层。较低层的工作期限非常紧迫（在某些情况下，只有几分钟）并且在高度结构化的环境中工作。他们使用的工具在功能和流程上受到严格限制。相比之下，我们的目标用户生命周期工程师 (LCE) 是最顶层的高级运营人员，负责多个客户帐户。与较低层相比，LCE 具有更具分析性、更少反应性的角色，并且它们似乎更需要 LiveRAC 等可视化工具的探索功能。

解读网络环境状态是基本的系统管理活动。它涉及了解各个设备的状态，以及这些状态如何影响整体端到端服务。 LCE 检查时间序列数据，例如警报记录、统计数据和日志文件。我们研究中的 LCE 使用 SWIFT 来开展这项活动。更普遍的是，系统管理专业人员使用各种网络管理系统 (NMS) 工具，例如 OpenNMS 1、HP OpenView 2 和 BMC Patrol 3。大多数 NMS 工具将来自多个托管系统的警报、统计数据和日志集成到中央数据库中，并提供视图该数据。

报告生成需要创建显示相关时间序列值的可共享文档。我们研究的 LCE 通过制作感兴趣图表的屏幕截图或复制各个时间序列的 HTML 表来从 SWIFT 获取这些报告。大多数 NMS 工具都可以运行预构建的查询，例如过去一周负载最重的前十个系统的报告。它们还可能支持自定义查询语言或基于表单的查询生成器。

容量规划涉及预测未来的系统和基础设施需求。一位 LCE 参与者这样总结其三个阶段：“第 1 阶段记录 [客户] 今天拥有的内容，第 2 阶段提供短期建议（一到三个月），例如添加内存、改变 [客户] 进行备份的方式、等等，第三阶段是长期的，我们提供一些建议，例如更换硬件、将应用程序版本更改为经过认证的版本，可能会使用刀片服务器以减少占用空间，以便在现有空间中容纳更多服务器。 ”容量规划取决于对 NMS 捕获的网络环境状态以及有关客户活动和项目的外部知识的准确、完整的了解。例如，知道即将发生的重大事件将增加服务器负载，生命周期工程师将决定是否需要升级，或者当前系统是否足够。

事件调查涉及特定事件，例如服务中断或网络安全漏洞。已升级至 LCE 审查级别的事件通常会产生重大业务影响。事件调查分为三个不同的阶段。第一个是事件通知，通常通过自动生成的警报或客户提交的票证来通知。在第二阶段，LCE 使用 NMS 研究相关设备的时间序列数据参数，并可能查看其他设备是否出现类似情况。在第三阶段，LCE 指导响应，通常部署进一步的取证工具，例如网络嗅探器或 Rootkit 检测器。

客户、工程和运营之间的协调涉及沟通调查结果、变更请求和建议。一位 LCE 参与者将其描述为“充当渠道”，以促进服务交付和事件响应。

当前工具的局限性

用于系统管理专业人员的现有 NMS 工具在分析记录的时间序列数据方面存在很大的局限性。最关键的限制是缺乏中层对环境状况的看法。数字摘要，例如各组中启动或关闭的设备计数、整体网络利用率以及高优先级警报，确实为管理员和管理者提供了有用的信息。然而，这些视图并不完整，并且隐藏了许多重要的细节，例如这些系统与特定阈值的接近程度、哪些特定系统处于离线状态，或者哪些系统遇到问题。要查找诸如离线系统的身份之类的详细信息，需要向下钻取到另一页面，或者在一个非常大的页面内向下滚动。这些工具对需要在多个系统之间进行直接比较的任务提供的支持很差，例如，确定负载峰值或警报等行为事件是否同时影响多个系统。

许多 NMS 工具使用基于规则和机器学习的方法来推断是否存在问题并发送警报通知。实际上，这些方法会产生大量不可操作的警报。例如，在我们研究的环境中，监控系统每天生成大约 10,000 个警报，其中每天只有一到两个警报代表可操作的事件。全面抑制规则用于自动删除大量告警。这些抑制规则表明系统管理员对单个警报或指标的信心较低，而是依赖于自己对记录数据的分析。

当前使用来自 NMS 的预构建或自定义查询的报告生成工具也有局限性。预构建和自定义报告的结果通常位于表格或可滚动的图表页面中，没有摘要或聚合，因此很难进行比较或获取环境状态的完整视图。预构建的查询，例如“显示过去 6 天内 CPU 最高的 10 个系统”可能不符合任务要求。即使是定制的查询也要求用户提前知道他们正在寻找什么，因此对于发现意外的模式是无效的。

LiveRAC 旨在解决交互式可视化系统中的这三个限制。它为系统管理员提供了多个级别的数据视图，使他们能够从复杂的数据现实中得出推论，并将他们的解释传达给其他人。

迭代设计

我们描述了我们的设计方法、我们招募的参与者以及我们设计过程的四个阶段。

方法

我们的项目遵循以用户为中心的标准设计流程的许多方面。我们收集需求，然后构建一系列原型并获得反馈。我们从纸质原型开始，继续使用合成数据进行概念验证交互式软件原型，然后是在真实数据上运行的高保真原型，最后是可部署的系统。我们发现，在企业环境中，招募具有运营职责的高级系统管理参与者是一项挑战，因为参与研究项目需要更高的批准，而且日常工作量非常大。我们修改了传统协议，随着项目的发展分阶段增加参与者池，通过中期结果产生兴趣。每个工作原型都增加了项目的可信度，从而获得组织内更接近生产数据和真实用户的下一个团队的支持。在随后的每个阶段中，我们都能够与更多更接近目标用户组的参与者合作，最终与系统管理从业者（LCE）直接接触。我们在每个阶段收集了额外的要求。我们的分阶段设计过程有四个独立的阶段：需求收集和原型细化。

我们通过与高级系统管理专业人员进行访谈、参加管理层会议、记录用户通过桌面共享工具与 LiveRAC 交互的会话以及收集日志和调查来收集有关目标用户的数据。我们的会议和采访重点关注系统管理专业人员的角色和活动、票务和问题解决流程如何工作、容量规划如何完成、当前系统支持哪些类型的见解以及他们如何传达这些见解。

参加者

我们的设计过程涉及三组 14 名参与者。外部小组由目标组织外部的一名参与者组成，该参与者具有担任小公司 CTO 的高级系统管理经验 (C1)。

内部团队由目标组织的高级技术人员组成：一名工具工程团队成员（T1）、一名执行董事（E1）和四名高级技术总监（D1、D2、D3、D4）。所有人都非常熟悉我们的目标用户；董事管理他们，工程师为他们开发工具。该小组参加了设计会议并对原型提供了反馈。除了E1之外，该组的所有成员都使用了LiveRAC系统，但由于他们不是我们的目标用户群体，因此我们没有对他们进行单独采访。

LCE 小组由七名生命周期工程师（L1 至 L7）组成，是我们的目标用户组。他们参加设计会议、回复调查并在记录的会话中测试已部署的 LiveRAC 系统。 L1 至 L4 的四名参与者参加了额外的培训、采访和电子邮件沟通。

许多参与者在不同的地理位置工作，因此通过屏幕共享和电话会议来促进会议。

设计阶段

我们从收集初始需求开始了第一阶段。我们采访了 C1，以收集有关系统管理挑战和常用工具的信息。此外，我们还使用免费提供的企业系统管理平台 OpenNMS 监控我们自己的本地网络，以获得使用此类工具和数据的直接经验。我们能够借鉴自己在该领域的经验：一位作者在系统管理和架构方面拥有多年的专业经验，另外两位作者与系统管理从业者密切合作构建和部署了数据集成和可视化系统[7]。
在这里插入图片描述
我们根据这些初始要求设计了一个原型，选择了多种可视化原理支持的技术组合。在用纸质原型完善我们的想法后，我们构建了一个在合成数据集上运行的概念验证软件原型。该原型被提交给 T1，这是我们的目标 LCE 人群日常使用的软件工具的设计者。 T1 确认原型是合适的，并且对其交互式视觉查询的潜力感到充分鼓舞，同意参与下一设计阶段。

第二阶段，我们通过与T1的会议细化了需求。我们开发了一个在生产数据库上运行的高保真原型，并通过迭代开发过程定期收集 T1 的反馈。第二个原型被提交给 E1 和 D1，他们对能够以以前不可能的详细程度查看系统管理环境的能力充满热情，并成为下一阶段的参与者。

在第三阶段，除了T1之外，我们还通过E1和D1的会议收集了需求。我们开发了第三个高保真原型，目标是实现供 LCE 使用的灵活且强大的可部署系统。除了 T1、E1 和 D1 之外，我们还向 D2、D3 和 D4 展示了最终的系统。他们的批准使我们能够在研究的最后阶段直接接触目标用户（LCE L1 到 L7）。

第四阶段，我们通过会议和调查收集L1-L7的需求，并进一步完善我们的系统以纳入他们的需求和反馈。然后，我们将该系统部署在生产环境中，并继续收集所有 14 名参与者的反馈。我们进行了为期三个月的非正式纵向评估。尽管经理 E1 和 D1 鼓励员工尝试该系统，但参与并不是强制性的。我们收集了总共 13 个 LiveRAC 系统用户的 38 个会话日志。其中，四人是主管，其他人担任技术职务。 LCE L1-L4 是我们最活跃的用户，四人之间总共记录了 24 个会话。

设计要求

我们通过迭代设计过程在不同阶段确定并验证了设计要求。

在第一阶段，对于概念验证原型，我们根据与 C1 的讨论以及使用 OpenNMS 软件的经验，提炼出了一个总体的高级要求：用户需要浏览和关联参数、设备、和时间值。该数据集包含数千台设备的数十个参数，这些参数在几年内以 5 分钟的间隔收集。数据将在多个级别的时间窗口中查看：小时、天、周、月和年。需要调查的具体设备组和参数变化很大。在某些情况下，调查是从某些设备分组开始的；在其他情况下，通过查找一个或多个参数的临界值。一个特殊的挑战是帮助用户将警报与其他参数关联起来。

在第二阶段，对于高保真原型，我们确定并解决了这些要求：

按名称或元数据搜索特定设备
提供可在企业标准桌面硬件上运行的客户端，通过使用管理多年数据收集和存储的后端服务器来处理大数据量
动态更改时间窗口
在启动时从参数和设备映射到视觉表示
提供用于调整标准和动态可更改分组大小的快捷方式，以简化导航

在最后阶段，对于可部署系统，额外的要求是：

将设备参数动态映射到可视化表示，例如 CPU 使用情况：彩色框、迷你图、低细节折线图、高细节折线图
按参数对设备进行排序
显式过滤到设备子集，支持基于现有选择分层组织结构
动态自定义阈值，以视觉方式区分感兴趣的值
通过以电子表格格式导出有关所选参数和设备的详细信息，将结果集成到工作流程中
支持拖动单行以电子表格样式调整大小的熟悉交互

可视化解决方案

我们展示了设计背后的激励性可视化原则，描述了 LiveRAC 的界面和功能，并讨论了其实现。

设计原则

LiveRAC 界面综合了多种技术来满足上述要求。在许多情况下，技术的选择是由特定的可视化原则指导的，我们在下面引用其来源。我们做出一个断言：同时显示多个细节级别可以在上下文中提供有用的高信息密度。下面的列表反映了我们的最终设计，经过几个阶段的需求收集、迭代开发和研究参与者的验证。

我们在图 3 中显示了 LiveRAC 界面，其中包含来自生产服务器的数据，通过将客户设备 ID 随机映射到字典中的名词来进行匿名化。随附的视频显示了交互界面的外观和感觉。

在这里插入图片描述

LiveRAC 接口

原则：在适当的时候应该保留熟悉的视觉表现形式。这种方法利用用户的直觉和经验来加快学习速度。 LiveRAC 中的基本可视化数据表示是熟悉的折线图和条形图。这些图表显示为类似电子表格的矩阵中的单元格。默认情况下，LiveRAC 使用与 LCE 使用的其他内部软件工具相同的颜色编码约定，如图 2 所示，并且可以根据需要重新分配调色板。尽管默认颜色不能最大限度地区分，但它们已经足够了，因此我们保留它们以供熟悉。我们还提供类似 VCR 的控件，以可变速度播放数据。实时数据是实时查看的，而存档数据通常是在加速播放下查看的。
在这里插入图片描述
原理：并排比较多个小视图比记住以前看过的视图更容易。小倍数原理 [23]，其中不同数据集的许多小实例以相同的表示形式显示，允许对数十个项目进行快速并排视觉比较。一次检查一个图表并将其与以前见过的图表进行比较的替代方法的效率要低得多，并且不能很好地扩展。在一组轴上过度绘制许多曲线的替代方案只能扩展到几十条曲线，否则视觉混乱就会变得难以承受。 LiveRAC 主框架如图 3 所示，呈现一个矩阵，其中每个单元格都包含一个区域感知图表，水平轴上显示时间，垂直轴上显示设备参数。所有图表显示相同的时间段。可以使用双刃滑块或在屏幕底部的文本字段中输入明确的开始和结束时间来更改时间段。

原理：空间位置是最强的感知线索。信息可视化的核心原则是，通过空间排序进行的编码关系比颜色、大小或方向等其他编码更能准确地感知[9]。这一原理是可重新排序矩阵技术的基础 [2, 20]，该技术允许在探索性数据分析过程中直观地检测细胞之间的关系。在LiveRAC中，每个矩阵行代表一个受监控的网络设备，每个矩阵列代表一组一个或多个受监控的参数，并且可以根据其值进行排序。例如，按负载排序按负载平均值对设备行进行排序，最高的位于顶部。可以根据参数值对列进行排序，例如时间序列的最小值、最大值或平均值。可以按设备名称或元数据（例如位置、客户或其他分组）对行进行排序。用户也可以对列重新排序。

原则：通过显式链接协调多个视图是最有效的。链接视图[15]的原则是视图之间的明确协调可以增强它们的价值。在 LiveRAC 中，当用户在图表内移动光标时，所有图表中都会用垂直线标记相同的时间点。同样，在一个图表中选择一个时间段会在所有图表中显示一个标记。该技术允许在不同图表上同时直接比较参数值。此外，人们可以轻松地将带有详细轴标签的大型图表与更小、更简洁的图表之间的时间关联起来。

断言：同时显示多个细节级别可以在上下文中提供有用的高信息密度。多种技术选择都是基于这一断言。首先，LiveRAC 使用拉伸和挤压导航，其中扩展一个或多个区域会压缩视图的其余部分 [11, 17]。随附的视频展示了这种导航技术的外观和感觉。拉伸和压缩在矩形区域上进行，因此展开单个图表也会放大它所代表的设备的整行以及它显示的参数的整列。

显示器的边缘是固定的，因此所有单元格都保留在可见区域内，这与传统缩放（其中某些区域被推离屏幕）相反。有快速导航快捷方式可以缩放单个单元格、列、聚合的设备组、搜索结果或缩小到概览。用户还可以直接拖动网格线或调整屏幕上自由绘制的矩形的大小。还可以为任何任意分组创建导航快捷方式，其单元格不需要是连续的。这种交互机制提供了多个焦点区域，支持多个细节级别。

其次，LiveRAC 中的图表会动态适应，以显示每个单元格中适应可用屏幕空间的视觉表示。这种技术称为语义缩放[13]，允许一组设备参数时间序列的表示层次结构。在图 3 中，最大的图表具有多条重叠曲线以及详细的轴和图例标签。较小的图表显示较少的曲线和较少的标签，并且在较小的尺寸下，只有一条曲线显示为迷你图 [24]。在每条曲线上，显示时间段内的最大值用红点表示，最小值用蓝点表示，当前值用绿点表示。所有表示级别根据当前时间窗口内参数的最小、最大或平均值的动态可变阈值对背景矩形进行颜色编码。最小的视图是一个简单的块，其中颜色编码是唯一显示的信息。

第三，聚合技术通过确保密集区域显示有意义的视觉表示来实现视觉可扩展性。考虑到我们的目标规模是数十个参数和数千个设备，矩阵的大小很容易超过 100,000 个单元。拉伸和挤压导航允许用户快速创建包含许多不同大小的单元格的马赛克，其中许多区域的单元格数量大于所需的可用像素数，甚至可以为每个单元格绘制一个单像素块。在这些区域中，绘制了一个聚合块，代表屏幕空间区域内的所有单元。一种幼稚的方法可能是过度绘制单元格，以便用户看到颜色的混合或最后绘制的单元格。这种方法效率低下，并且不太可能显示最相关的信息。相反，LiveRAC 使用四种可能的聚合函数之一来计算给定块的显示，该聚合函数针对其表示的单元格中的时间序列值：最小值、最大值、平均值和基数。

我们增加聚合块的颜色饱和度以显示密度，与所代表的单元格数量成比例，从非聚合块的 25% 基本饱和度水平开始。相反，随着显示更多细节，图表背景颜色的饱和度会降低，遵循 Ware [26] 和 Tufte [23] 的指南，即大面积应使用去饱和颜色，并且前景和背景之间的高对比度可提高可读性。

考虑到数千台设备的目标规模，通常没有足够的空间来为水平行绘制清晰的标签。当设备按共享描述性参数（例如逻辑分组）排序时，会为此更高级别的结构绘制单个标签，并以指示其代表的聚合设备数量的数字结尾。

第四，保证可见性的技术[11]确保重要信息始终可见，即使在高度压缩和聚合的区域也是如此。虽然概念很简单，但挑战在于实现一种渲染架构，在单元数量巨大时提供交互式帧速率。 LiveRAC 构建于 PRISAD 基础设施 [21] 之上，该基础设施支持拉伸和挤压导航框架内保证可见的标记。 LiveRAC 使用保证可见的标记来显示设备名称和元数据的渐进式搜索过程中的结果。 LiveRAC 还以保证可见性的方式标记关键项目，包括关键类别的警报以及多个参数高于关键阈值的警报。这些参数根据用户要求进行调整：高级系统管理人员检查的事件大大高于日常操作水平。

原则：概览优先，缩放过滤，按需细节。 Shneiderman [18] 阐述的这一广泛遵循的原则已被认为对于应对规模和复杂性是有效的。上述技术的组合允许在同一视觉隐喻中从多个细节层次的概述中进行交互式探索。我们提供过滤功能，动态控制矩阵中显示的参数。尽管我们通过将警报视为基于时间的事件来将警报集成到时间序列框架中，但在矩阵单元内绘制警报的全文会很尴尬。相反，我们提供一个按需弹出的传统对话框。用户可以以电子表格格式导出任何选定设备组的时间序列数据和警报的详细信息，以将 LiveRAC 支持的可视化查询集成到 LCE 的工作流程中。直到最终设计阶段，我们才能直接接触 LCE 目标受众时，才认识到导出这些详细信息的要求。

原则：应避免视觉突然变化。这一原理源于物体恒常性[16]和变化盲目性[14]的知觉理论。在 LiveRAC 中，所有转换都是动画的，例如，使用导航快捷方式扩大或缩小区域。当用户更改时间窗口或首先将单元格从块展开为图表时，服务器查询以获取更多数据可能需要很多秒。在此期间，我们继续显示旧的视觉表示，但在单元格的右上角有一个黄点，表示更新正在进行中。当新数据可用时，我们将其表示直接绘制在旧数据上，避免闪烁，从而增加变化盲目性的风险。

原则：用户的操作应该得到即时的视觉反馈。最终的设计原则被采用以实现高交互数据探索[16]。通过构建 PRISAD 基础设施 [21]，即使使用大型数据集，我们也能实现有保证的帧速率渲染。此外，LiveRAC 在与服务器更新不同的线程中执行渲染，以确保即使在长时间运行的数据库查询期间也能实现一致的交互式响应。

执行

LiveRAC 是连接到后端数据库（在本例中为 SWIFT 服务器）的客户端。 LiveRAC 是在 PRISAD 库 [21] 上编写的，它为有保证的帧速率手风琴绘图提供通用、高效的渲染基础设施，提供拉伸和挤压导航，并保证标记项目的可见性。如上所述，渲染和服务器更新发生在单独的线程中。

LiveRAC 已被证明可以在 4000 个网络设备和 20 个输入通道的数据集上保持交互式帧速率，显示以 5 分钟间隔收集的六个月数据。原始数据集总共包含数十亿个原始数据点。渲染和拾取节点的核心结构支持 O(n log n) 插入、删除和搜索操作。截至第二阶段，LiveRAC 实施的技术细节可在论文 [10] 中找到。为了演示与 LiveRAC 可视化系统的交互，提供了一个简短的视频。

纵向评价

我们讨论了非正式纵向研究的方法，总结了设计的含义并提出了 LCE 使用场景。

非正式纵向研究方法

我们纵向研究的目的是更好地了解生产环境中设计中使用的可视化技术的优点和缺点。

我们的纵向研究收集的数据包括：笔记、音频、交互式会话的桌面共享屏幕截图电影以及来自 LiveRAC 的日志数据。由于我们的目标人群在多个偏远地区工作，因此许多采访和会议都是通过电话进行的。我们尽可能录制对参与者的采访，在一些大型会议上，我们依靠手写的笔记，而出于保密考虑，我们无法进行录音。

我们的参与者有严格的时间限制，并且位于不同的物理地点，这给有效培训带来了挑战。事实证明对于采用至关重要的两种培训策略是使用桌面共享软件进行实时演示来描述和演示 LiveRAC 的功能，以及分发一个五分钟的 Flash 培训视频来演示其基本功能。两名 LCE 表示，他们已多次观看该视频，以充分吸收信息。我们还提供了书面文档和交互快捷方式表。用户的问题和疑虑均通过电子邮件得到解答。

我们通过审查所有注释、音频和视频日志并构建一个内部 wiki 来分析数据，该 wiki 可以识别参与者请求的功能、错误以及有关观察到的用户行为的注释。

对设计的影响

我们总结了非正式研究的主要发现。

视觉、交互式排序具有显着的优势。 LCE 最感兴趣的是他们认为在某些类别中最严重的系统。他们当前的报告工具只能在固定时间段内提供此功能，并且无法在单个屏幕上显示每个设备的所有受监控参数的值。我们使用 LiveRAC 作为可视化查询工具来观察 LCE。通过对每列进行排序，他们不仅能够看到与该列关联的参数中最严重的违规者，还可以看到相应列中的值。在以这种方式使用该工具并发现两个 Web 服务器的行为异常时，一位参与者评论道：“拥有数据固然很棒，但如果您无法直观地看到它，那么它几乎毫无价值！ …我可以整天查看 Excel 电子表格，但永远看不到我在这里可以看到的内容…您知道，其中的可视化部分是天壤之别。”我们的研究结果表明，数据重新排序是已部署的可视化系统的一个关键功能。

并排查看大量图表对于偶然发现模式至关重要。例如，参与者发现一个设备中的 CPU 负载出现异常，向下扫描该行，发现在第一个设备恢复正常后，另一个设备立即出现相同的行为。该参与者评论道：“持续了一周半、两周……[已编辑]又下降了……负载均衡器[正在]将流量发送到一个而不是另一个。哇，这很有趣。”这种模式可以通过自动化方法检测到，但前提是用户知道会发生这种情况。我们显示器的高信息密度支持参与者识别新的、有趣的模式的能力。我们的研究结果表明，视觉并排比较对于偶然发现很重要，并且应该在未来部署的可视化系统中得到支持。

操纵时间窗口并查看长时间段内的数据概览是新颖且令人兴奋的。 LCE 在预测未来负载需求时使用长期趋势信息。当参与者 A 向他的同事参与者 B 介绍该工具并演示他可以从查看几个小时的数据转变为查看六个月的数据时，后者的反应是惊讶和兴奋。我们的研究结果表明，提供支持大时间范围的动态可变时间窗口是时间序列可视化设计的关键组成部分。

链接视图有助于关联。例如，参与者 L1 和 L2 在采访中发现了几种相关模式，我们通过桌面共享软件观察了他们的互动。在许多情况下，并排系统中不会出现相关性。在一个实例中，L1 观察到负载均衡组中的一台 Web 服务器停止接受流量，但仍保持在线状态。 L2 指出，几乎在恢复后立即，池中的另一个系统也出现了相同的行为。此类问题恰恰是自动化方法可能无法检测到的类型，因为两个设备都没有离线或对 ping 测试没有响应。 L3 提到，“我喜欢 [LiveRAC] 的一点是，如果出现特定警报，您可以放置垂直线并查看所有其他参数，如果 CPU 出现峰值，您可以查看所有其他参数并查看哪些参数确实如此，或者我们发现 ping 测试存在严重警报，但当您查看 CPU 利用率极低时，您可以了解资产的运行状况。”我们的发现表明紧密链接和高信息密度支持这种类型的模式发现。

拉伸和压缩导航并不是采用的障碍。尽管之前的实验室研究发现拉伸和挤压导航的性能受到影响[12]，但我们发现这种交互机制并没有像我们预期的那样给我们的参与者带来太大的挑战，尽管它很新颖且训练有限。这种差异可能是由于 LiveRAC 中广泛使用基于结构的导航，用户经常使用快捷方式来放大光标下的单元格或列。我们推测，与在屏幕上拖出任意矩形并自由调整其大小相比，这种导航可能需要更少的认知负荷。

添加报告生成功能对于 LCE 接受度至关重要。我们的发现与 Gonz ́ alez 和 Kobsa [4] 的观点相呼应，他们提出将可视化系统紧密集成到用户的标准分析工具链中可以促进采用。我们的 LCE 参与者要求能够从可视化工具中提取排序的、用户选择的数据，以将探索过程中获取的信息传输到下游工作流程中。在获得 LCE 的访问权限后，我们在设计过程的第四阶段确定了这一要求。我们的参与者表示，如果我们没有添加此功能，他们就会失去使用该系统的兴趣。 LCE 对以前的系统管理工具的一个主要抱怨是无法生成他们可以操作和共享的定制报告。

即使在项目构思时目标用户群体无法充分参与，迭代设计也可以取得成功。从项目一开始就无法直接访问整个参与者库是一个重大挑战。更传统的以用户为中心的设计流程将使我们能够更快地迭代我们的设计。例如，我们根据对需求的初步评估，投入了大量的开发时间来进行警报处理，却发现 LCE 在很长一段时间内发现警报不再那么有趣。尽管在可视化研究文献中尚未明确讨论在大型组织的政治约束下获得参与者的挑战，但许多人已经注意到将研究人员提出的可视化技术转移到现实世界环境中的困难。我们建议我们的分阶段方法，即软件原型向管理链中可能持怀疑态度的个人展示可视化方法的价值，可以在其他研究环境中效仿。

使用场景

我们提出了三个场景，展示了 LCE 参与者在我们的非正式纵向研究中使用 LiveRAC 的情况，并记录了桌面共享会话的记录。（桌面共享应用程序将图像减少到 256 色，并引入了其他压缩伪影。）图像已被裁剪以突出显示关键数据。

图 4a 显示了场景 1。LCE 首先以最低语义缩放级别概述 50 个设备，其中彩色块显示每个设备的每个参数的最大值。使用以前软件工具的表格和图表视图获取相同的信息需要手动扫描 50 个图表才能确定最高值出现的位置。将一个参数对其他参数的影响关联起来将是一项乏味的活动。参与者最感兴趣的是按 CPU 负载对系统进行排序；内存使用情况、平均负载和网络流量利用率也令人感兴趣。我们观察到 LCE 对多达 4000 个设备使用概览和排序技术，如随附视频和图 3 所示。
在这里插入图片描述
LCE 继续使用排序、拉伸和挤压导航以及时间导航来探索相同的数据集。执行排序操作后，LCE 拉伸 CPU 负载最高的系统的单元格以查看趋势，如图 4b 所示。 LCE 立即对 CPU 使用率最高的违规者的利用率异常飙升感兴趣，并表示这是一个令人感兴趣的功能。为了检查这是否是可能影响容量规划的频繁出现的趋势，还是不太重要的孤立事件，他单击并拖动时间滑块以放大时间窗口。使用现有可视化工具发现具有负载峰值的设备需要一次查看一台设备，或者查看仅显示 CPU 参数的未排序视图。在LiveRAC中，所有其他参数都可以同时进行比较。

图 4c 显示了场景 2，其中 LCE 显示同事在几个月内排序的趋势信息。当他拉伸显示 CPU 使用率最高的设备的单元格时，他发现系统在达到 100% 后不久就停止报告数据。两个 LCE 都认为这种行为表明存在问题。

图 4d 显示了场景 3。LCE 正在检查同一负载平衡池中的一组 Web 服务器。这些服务器旨在具有类似的行为。扩展这些单元后，他发现在某些设备上，负载意外地在数周内几乎降至 0，但它们并没有崩溃，并继续报告所有监控参数。 LCE 表示，他将联系负责该系统的同事进行跟进。

我们在随附的视频中提供了另外三个使用场景，这些场景是通过直接视频捕获 LiveRAC 交互式会话而不是从桌面共享日志制作的。

结论

我们提出了 LiveRAC，这是一种新颖的可视化系统，支持浏览和关联记录的时间序列数据以进行系统管理。我们采用了分阶段的设计流程，在该流程中我们展示了工作原型，以便在后续阶段接触到更多参与者。我们实现了在完整生产环境中部署 LiveRAC 的挑战性目标。我们进行了一项非正式的纵向实地研究，我们的研究结果表明，最终设计的许多方面都有助于实现预期任务。

LiveRAC 提供高信息密度界面，比仪表板方法传达更多信息，并支持按需提供详细信息。对于我们研究中的用户来说，可以交互式监控和探索的大量设备和参数是令人惊讶和兴奋的。积极的研究参与者以及主要参与设计评审的管理者都对从系统中获得的见解充满热情。 LiveRAC 得到了用户的持续支持，并有望在其他网络管理和规划应用程序中得到更广泛的部署。