边缘计算中自适应应用的监控挑战

corn8

426人浏览 · 2025-10-07 03:11:23

corn8 · 2025-10-07 03:11:23 发布

边缘计算框架中自适应应用的监控：前沿综述

1. 引言

近年来，出现了大量基于云的系统软件解决方案，例如物联网（IoT）应用程序。因此，数十亿用户或设备连接到互联网上的应用程序，导致在云数据中心生成并处理数万亿千兆字节的数据。然而，由终端用户或设备产生并传输至集中式云数据中心的海量数据带来了通信带宽和计算资源的低效利用问题。由于数据处理所需的全部资源容量和计算智能主要集中在以云为中心的数据中心，当前云解决方案（例如亚马逊 AWS IoT 和谷歌云 Dataflow）的数据分析仍然是一个开放的研究问题。

为了解决上述问题，现代云框架如边缘计算（Shi和Dustdar，2016）、雾计算（Bonomi等人，2014）和渗透计算（Villari等人，2016）旨在通过将服务部署在终端用户或设备附近，并采用新的数据传输协议以增强与数据中心服务的交互，从而提升网络边缘资源的能力和责任，相较于传统的集中式云架构，这还能为应用提供较低的延迟响应时间。

沿着这一思路，SWITCH项目的主要目标是引入一种新颖的软件设计模型，以便将服务质量/用户体验质量目标纳入现代云框架（包括边缘计算）中运行的应用程序的完整生命周期。基于这一概念模型，SWITCH解决方案提供了一个用于开发软件系统并监控其执行的环境，以及一个用于自适应调整系统行为的自主平台。本文的重点是监控此类自适应应用，以确保在边缘计算框架中有效利用集中式云设施、边缘设备以及整个基础设施。

作为一个启发性示例，图1提供了一种现代计算框架架构——边缘计算架构——该架构包含不同的层级：（I）集中式云计算，（II）SDN/NFV技术，（III）边缘计算，以及（IV）物联网对象、传感器或用户。

示意图0

如图1所示的先驱云计算框架示例中的多层架构，描述如下：

第一层集中式云计算层

第一层包括可属于不同服务提供商的云数据中心。该层可用于长期存储以及通常对时间不敏感的应用级数据处理操作。换句话说，该层的能力是利用集中式云基础设施来运行大数据分析并处理时间敏感性较低的数据。在该层中，应用程序可能由不同的模块化服务组成，每个服务根据用户需求执行不同目的的高级数据处理。

例如，一个物联网灾害预警应用在此层中可能包含两项服务：“预警触发器”服务和“呼叫运营商”服务。“预警触发器”可以是一种监控服务，用于处理传感器采集的输入数据，并在发生异常事件时通知其他服务（如“呼叫运营商”）。而“呼叫运营商”服务则可决定是否向应急系统或公共机构发送警报。

第二层 SDN/NFV技术层

软件定义网络（SDN）（阿斯图托等人，2014）和网络功能虚拟化（NFV）（Jesus‐Gil和Botero，2016）正成为设计、构建和运营网络的新方式。这两种互补的技术能够支持边缘节点与云数据中心之间的数据传输。引入这些技术可以轻松提高网络的动态性和管理能力。例如，如果当前网络质量不理想，则可以更改数据在集中式云计算层（第一层）与边缘计算层（第三层）之间流动的路径。

结合使用，SDN和NFV有可能指定网络流、提升网络性能，并提供独立于底层网络设备的网络管理抽象。因此，SDN和NFV可被视为推动网络环境以及新型基于云的应用架构（如边缘计算框架）演进的使能解决方案。

第三层边缘计算层

在边缘计算层，边缘节点代表网关和数据采集服务，能够对原始数据进行处理，例如实时聚合、过滤、加密和编码本地数据流。该层是将云资源分布并移近终端用户和终端设备的地方。这正是边缘计算也被称为普适计算的主要原因。采用边缘节点的目的是在数据流采集位置附近分析时间敏感数据，从而减轻集中式云计算层（第一层）资源的计算负载，并在某些情况下也减少SDN/NFV技术层（第二层）的网络负载（萨蒂亚纳拉亚南，2017）。边缘节点还可以具备其他功能，具体取决于各个用例的需求。在预警系统中，这些节点包含通过直连链路从传感器接收数据的服务，对输入数据流进行过滤，聚合测量值，并将数据发送至“预警触发器”，而预警触发器是运行在集中式云计算层的另一项服务。因此，边缘计算层可以显著减轻核心网络和数据中心的流量负担。正因如此，这一作为集中式云扩展的新范式，为时间关键型甚至实时应用在满足服务质量要求的前提下提供了低延迟、位置感知能力，并优化了用户体验。

第IV层物联网对象/传感器/用户层

在此层中，连接设备在互联网中普遍存在。对象（例如智能家居模块）可被远程控制；传感器能够测量不同的参数（例如温度、大气压力、湿度及其他环境变量）；用户也能够通过手机等连接设备使用在线软件解决方案。

图1所示的多层边缘计算架构相较于传统云计算模型具有以下改进：

减少网络流量 ：位于边缘计算层（第三层）的边缘节点能够过滤不必要的数据，并显著聚合仅需传输到集中式云计算层（第一层）的关键信息，然后进行接收、存储和处理。
提升应用性能 ：在靠近终端用户或终端设备的边缘计算层（第三层）的边缘节点上本地进行数据处理，而不是在集中式云计算层（第一层）进行，可被用作降低延迟、减少响应时间并从而提升应用QoS的解决方案。
促进新的负载均衡方法 ：边缘计算范式引入了新的服务迁移功能，例如在集中式云计算层（第一层）和边缘计算层（第三层）之间按需迁移正在运行的服务，以支持按需负载均衡（Sharma等，2017）。或者，与传统的集中式计算相比，通过在边缘节点本地扩展计算能力，可显著改善负载均衡行为。
提供位置、网络和上下文信息的感知 ：由于边缘计算架构，现在可以跟踪终端用户的信息，例如其位置、移动性、网络状况、行为和环境，以高效地提供定制化服务。这将确保考虑到终端用户对用户体验质量（QoE）的需求和偏好（作为用户满意度的直接测量）。
降低能耗 ：连接到互联网的设备和用户数量的快速增长始终伴随着对提高能效的需求。任务可以从终端设备卸载到距离较近的边缘节点，例如集中式云数据中心。这一事实有助于减少终端设备、集中式计算基础设施以及边缘计算层与集中式云计算层之间网络节点的能耗。

边缘计算应用的性能会因运行条件的运行时变化而显著不同，例如需要处理的到达请求数量、虚拟化资源的可用性、分布在互联网上的不同应用组件之间的网络连接质量等。因此，跟踪运行环境的动态变化对于识别和修复系统健康状况的任何恶化至关重要。为此，在边缘计算框架的每一层使用监控能力有助于基于云的应用提供商识别性能瓶颈所在位置。此外，它还允许系统预测潜在问题，并提升应用性能，以避免用户遭遇用户体验质量下降。

此类先进的基于云的框架可提供高度分布式、异构甚至联邦环境，能够利用轻量级容器相关虚拟化技术（例如 CoreOS, Kubernetes, OpenShift Origin 和 Docker Swarm）来实现不同服务的自动部署，这些服务通过明确定义且高效的机制相互通信。因此，在使用边缘计算平台时，存在针对云基础设施、容器虚拟化、通信网络以及应用特定条件的各种监控需求。

针对应用自适应目标而完全配置的监控系统的重要性已在多种云环境中的经验研究中进行了讨论。这些研究展示了在实践中具有多样化适用性的各种监控技术与方法论。迄今为止，已有多种研究工作分析了云应用所需的监控工具和方法（Aceto等，2012；Aceto等，2013；Fatema等，2014；Garcia‐Valls等，2014；Mohamaddiah等，2014；Ward和 Barker，2014；Hazarika和 Singh，2015；Alcaraz‐Calero和 Aguado，2015；Sugapriya和 Jeya，2015；Alhamazani等，2015）。然而，这些监控研究尚未涉及边缘计算框架内的自适应应用领域，而该领域代表了云计算的新时代。这是一个重要的研究方向，因为如果未能正确分析并确定此类应用所需监控需求的完整范围，则可能导致严重的软件工程失败。

本文的主要目标是探讨在边缘计算上下文中监控的演进所面临的一些根本性挑战，这些挑战在学术文献和工业界尚未得到充分解决。为了理解当前如何应对这些挑战，我们重点对现有的云监控技术的特性进行比较与分析，以准确确定它们在此领域中的优势与劣势。

更具体地说，本文的主要贡献可以总结如下：（I）对边缘计算框架内的不同监控概念进行系统化分析；（II）识别此类现代监控中的主要开放性挑战和重大技术问题；（III）提供支持边缘计算框架内应用程序动态适应的监控需求分类；以及（IV）提出边缘计算应用自适应中监控技术的未来研究方向。

本文的其余部分组织如下。第2节介绍了边缘计算框架内监控层级的需求分析，并在本节最后概述了相关挑战。第3节针对边缘计算应用建立了监控需求分类法。第4节讨论了现有广泛使用的监控技术，以及这些技术在何种程度上满足了从边缘计算视角识别出的需求。结论见第5节。

2. 监控层级

为了使边缘计算应用能够适应不断变化的执行环境，并确保应用 QoS需求持续得到满足，有必要采用一种综合监控系统，该系统能够应对涉及不同级别的各种需求，包括：（1）底层基础设施（如虚拟机的计算资源等），（2）边缘计算平台（如Docker容器等），（3）各个应用组件之间的网络连接，以及（4）应用特定的测量指标（如服务响应时间等）。

本节从边缘计算的角度，对基于云的应用程序此前提到的四个监控层级进行需求分析。现代软件工程学科提供了一种设计方法，此类应用基于一组不同的松散耦合的独立组件构建，这些组件运行在虚拟机（VMs）或容器中。因此，为保证完整性，我们同时考虑了虚拟机和容器级别的虚拟化。第2节重点强调了从边缘计算视角来看，自适应应用的监控需求的重要性，以便在第3节中提出针对此类应用的监控需求分类法。

2.1. 虚拟机层级监控

包括中央处理器、内存、磁盘和网络在内的所有物理资源都可以被虚拟化。多个虚拟机可以部署在单个物理机器上，从而彼此共享物理资源。根据边缘计算的理念，必须能够控制可配置的虚拟化资源池，这些资源应用于集中式云计算层（如图1所示的第一层）和边缘计算层（如图1所示的第三层）。这些资源应能够自主分配与释放，尽可能减少甚至无需应用服务提供商的干预。为了实现高效的资源利用并防止虚拟化资源中出现任何问题，对云数据中心和边缘节点中使用的虚拟机进行监控至关重要。通过高效监控这些虚拟化资源的使用情况，可以实现最佳的性能优化。用于监控此类资源的能力包括主要用于监控中央处理器、内存、存储和网络使用情况的工具：

CPU使用率 显示虚拟机中正在使用的中央处理器占总可用中央处理器的百分比。如果处理器利用率达到100%且CPU运行队列开始积压，则表示系统已耗尽可用处理能力，此时必须采取适应性操作——或者更理想的是提前预测并采取措施。
内存使用情况 表示所选机器上已使用的内存百分比。
磁盘使用率 指虚拟机读取或写入的数据量，也可以表示已用驱动器空间的百分比。通过向虚拟机添加额外存储并将其分配给适当的分区，通常可以解决磁盘空间问题。
网络使用情况 是虚拟机特定网络接口上的流量体积，包括外部和内部数据流量。

该领域已发表的相关论文包含在表1中。我们将在下文提供更多细节。

Al‐Hazmi等人 (2012) 采用了一种云监控系统，以向基于云的应用提供商和客户同时提供监控即服务 (MaaS)，二者在多租户环境中可能对监控数据有不同的视图。他们的监控解决方案可在联邦云中运行；然而其受限于数据中心的监控工具。该方法要求所有基础设施都使用相同的监控系统；而边缘计算框架的一个重要需求是监控解决方案不依赖特定云环境，并能够在联邦测试平台之间运行。

表1 不同虚拟机级别监控系统的研究概述

论文	Goal	测量指标（虚拟机级别）
(Al‐Hazmi等人, 2012)	监控联邦云	中央处理器、内存、磁盘，网络使用情况等。
(Wood等人, 2008)	资源利用率建模云应用	中央处理器、磁盘、网络使用情况
（权和诺，2013）	IaaS云监控	中央处理器、内存、磁盘
(米瓦拉米和纳坦，2013)	IaaS云监控	中央处理器，内存
(克莱曼等人，2010a)	监控联邦云	中央处理器，内存，网络使用情况
(Caglar和Gokhale，2014)	智能资源供应	中央处理器，内存

Wood等人 (2008) 提出了一种数学模型，用于估算虚拟机的资源开销。该模型可用于近似计算在特定平台上任何应用程序的虚拟化资源需求（尤其是中央处理器）。此外，该模型还可用于估算共置于同一主机上的虚拟机的聚合资源需求。他们的方案定义了虚拟机避免因资源匮乏而导致性能下降所需的最少资源量。然而，该方法无法直接测量应用性能（例如通过响应时间衡量）的变化情况。这项工作中的另一个显著问题是，对虚拟化应用的资源使用情况进行分析是离线进行的，且发生在月度或季节性时间尺度上。因此，在边缘计算场景的动态环境中，该模型的实用性受到限制。

Kwon和Noh (2013) 提出了一种监控系统架构，该系统包含一个仪表板，用于显示服务器和虚拟机的实时资源利用率。文中提到，如果中央处理器、内存和存储过载，则虚拟服务器将无法执行其正常功能。然而，该文章并未说明实验如何在实践中实施，因此尚不完全清楚所提出的解决方案是否能够如作者所声称的那样改善虚拟机的性能。需要注意的是，所提出的监控架构仅适用于特定类型的虚拟化（Xen 虚拟机管理程序）。

Meera和Swamynathan (2013) 提出了一种基于代理的资源监控系统，该系统向基于云的应用提供商提供虚拟机相关信息（中央处理器和内存利用率），以实现高效资源优化。通过增加一个告警功能来改进所提出的监控架构，当某个值超过阈值时触发该功能，可用于故障预测或服务级别协议(SLA)评估等多种用途。该架构受限于对集中式协调的依赖。相比之下，针对自适应边缘计算解决方案的需求，报告资源可用性的监控代理应具备自主性。

Clayman等人 (2010a) 描述了一种名为 Lattice 的监控框架，该框架能够实时测量和报告虚拟基础设施的系统参数，用于基于云服务的管理。该监控框架提供了必要的库以及应用程序编程接口（API），可用于实现定制化监控系统，其更像一个工具包而非即用型工具。Lattice 监控框架的主要功能是通过 UDP 或组播协议进行测量数据的收集与分发。因此，他们提出的解决方案不包含可视化功能。

Caglar和Gokhale（2014）提出了一种可在异构和虚拟化环境中使用的自主、智能资源管理工具，称为 iOverbook。该工具通过前馈神经网络模型，结合历史资源使用情况，预测未来一小时的平均CPU和内存使用率，从而实现在线超额预订策略。然而，他们的工作可以通过有效过滤潜在异常值来改进，以减少在大规模边缘计算环境中的边缘节点上产生的高数据传输开销。此外，为了使所提出的解决方案能够在高度动态环境中以高采样频率运行，可以进一步考虑采用不同时间间隔，而非固定每小时速率。

2.2. 容器级别监控

与虚拟机相比，容器作为一种服务器虚拟化形式，无需启动操作系统（OS）的受欢迎程度正在迅速上升。其中一个特别的原因是，容器镜像的大小明显小于完整的虚拟机镜像。基于这一趋势，已经提供了诸如亚马逊EC2容器服务（ECS）和谷歌容器引擎（GKE）等不同的基于容器的虚拟化平台，作为基于管理程序技术的替代方案。由于容器具有轻量级特性，因此与使用虚拟机相比，可以在不同的托管环境中更快、更高效地部署基于容器的服务（例如微服务（Kratzke和 Quint，2017））。此外，在云中的计算节点之间拉取容器镜像或迁移应用组件的容器实例也更加容易；而传统的基于虚拟机的技术过于笨重，难以实现边缘计算框架所需的这种敏捷性。这种敏捷性是必需的，因为迁移过程是实现负载均衡、应对硬件故障、扩展系统或重新分配资源等多种目的的有效工具。迁移机制必须能够自动运行，以便在特定情况下（例如，在图1所示的多层边缘计算框架的每一层发生基础设施故障时）也能实现近乎零停机。

根据云环境变得越来越动态且工作负载随时间变化的边缘计算趋势，使用这种轻量级云技术可以支持整个系统的自适应，以满足应用提供商和用户的需求。这种支持还得益于该技术所提供的特别可互操作的服务打包与编排能力，使我们能够绑定各种软件组件来构建完整的应用。这意味着将计算和数据管理从数据中心转移到网络边缘的去中心化的边缘云，需要对可移植的应用组件（如容器化）进行轻量级分发和编排。

如果系统在集中式云计算层（图1中所示的第一层）和边缘计算层（图1中所示的第三层）均使用容器来运行应用服务，则必须进行容器级别监控。

根据文献（Stankovski等，2016；Preeth等，2015；Beserra等，2016；Vangeepuram，2016；Dusia等人，2015年），在应用自适应背景下需要监控且有用的容器级别指标如表2所示。

表2 容器级别参数的通用集合

容器级别指标	Type	描述
rx_bytes	B/s	容器接收的字节数
接收_数据包	分组/秒	容器接收的分组
tx_字节	B/s	容器发送的字节数
tx_数据包	分组/秒	容器发送的分组
cpu_使用情况	浮点数	容器CPU使用率
内存_使用情况	KB	容器内存使用量
io_服务_字节_读取	B/s	容器从块设备读取的字节数
io_服务_字节_写入	B/s	容器写入块设备的字节数

此外，还有一些工具专门用于监控容器，并显示给定容器的关键属性的运行时值，如表3所列。

表3 容器专用监控工具概述

监控工具	许可证	REST API	Scalable	Alerting	Time Series Database (TSDB)	GUI
Docker内置工具	Apache 2	Yes	No	No	No	No
cAdvisor	Apache 2	Yes	No	No	No	Yes
cAdvisor + InfluxDB + Grafana	cAdvisor: Apache 2, InfluxDB: MIT, Grafana: Apache 2	Yes	Yes	No	Yes	Yes
Prometheus	Apache 2	Yes	No	Yes	Yes	Yes
DUCP	商业版	Yes	Yes	No	Yes
Scout	商业版	Yes	No	Yes	Yes	Yes

表3中比较的所有容器专用监控工具均提供REST API，用于公开有关特定容器的统计信息，并且该远程API可由其他实体外部调用。

Docker提供了一个名为 docker stats 的内置命令，用于报告指定容器的运行时指标和资源使用情况。此外，通过向 Docker远程API 发送 GET请求，也可以获取更详细的指标集。

容器顾问（cAdvisor）是一个开源系统，用于测量、聚合、处理和显示有关运行中容器的监控数据。这些监控信息可用于了解运行中容器的运行时资源使用情况和性能特征。cAdvisor 仅显示最近 60 秒的数据。然而，它支持将监控信息轻松存储到外部数据库（如 InfluxDB），从而实现长期存储、检索和分析。InfluxDB 是一个开源的时序数据库（TSDB），能够进行实时和历史分析。此外，Grafana 是一个基于 Web 的开源用户界面，用于可视化大规模监控信息。它能够对数据库执行查询，并以合适的图表形式展示结果。结合 cAdvisor 使用 Grafana 和 InfluxDB，可以有效地将 cAdvisor 收集的被监控参数以简洁的图表形式在任意时间段内进行可视化。

Prometheus 是一种开源监控工具，同时也是一种时序数据库（TSDB）。它以指定的时间间隔从预定义的资源中收集监控参数，展示结果，检查规则表达式，并在系统开始出现异常行为时触发告警。Prometheus使用LevelDB作为其本地存储实现，用于索引以及存储实际的样本值和时间戳。尽管与Prometheus相比，cAdvisor被认为更容易使用，但在检测到需要关注的特定事件发生时，其告警功能存在局限性。然而，这两种工具自身可能都无法很好地提供开箱即用的可扩展性，以处理大量被监控的容器。

Docker通用控制平面（DUCP）是一种用于管理、部署、配置和监控基于 Docker容器构建的分布式应用的工具。该容器管理解决方案支持所有Docker 开发工具，例如Docker Compose，可在集群中部署多容器应用。作为 Docker原生商业解决方案，DUCP具备高可扩展性和基于Web的界面等关键特性。

Scout 是另一个具有基于Web的图形化管理环境的容器监控工具，最多可存储30天的测量指标。它包含一个逻辑推理引擎，能够根据指标及其关联的预定义阈值进行告警。与Scout类似，市场上还有许多具有相同特性的商业解决方案可用于监控容器。

容器级别监控目前是一个热门的研究课题，相较于云基础设施监控等相关领域。该领域已发表的相关论文包含在表4中。

表4 不同容器级别监控系统的研究概述

论文	Goal	测量指标（容器级别）
（Stankovski等，2016 )	云应用的适应（用于时间关键型应用）	中央处理器、内存、磁盘、网络使用
（Preeth等，2015）	虚拟化技术的性能评估技术	中央处理器、内存、磁盘，网络使用等情况。
（Beserra等，2016）	虚拟化技术的性能评估技术（针对 I/O密集型应用）	Disk
( Vangeepuram， 2016 )	虚拟化技术的性能评估（针对Cassandra服务器）	中央处理器和磁盘
( Dusia等人，2015年 )	支持应用QoS（用于带宽密集型应用程序）	网络使用

斯塔诺夫斯基等人（2016）提出了一种分布式自适应架构，该架构应用边缘计算概念以及Docker和Kubernetes等基于容器的技术，以确保时间关键型应用的服务质量。他们的思路是将容器化应用（文件上传用例）部署在不同的地理位置，使得针对每个文件上传请求，服务都被创建、提供并销毁。对于每个容器，可根据终端用户、应用程序开发者和/或管理员定义的监控数据和操作策略，分配主机所需的资源特征。

普里特等人（2015）基于系统资源利用率评估了Docker容器性能。根据他们的基准测试，作者发现就内存、中央处理器和磁盘使用情况而言，基于容器的虚拟化可与在裸机上运行的操作系统相媲美。在这三项指标上，Docker的性能接近原生环境的性能。但是，根据网络利用率来看，主机操作系统的网络带宽明显低于Docker容器。然而，在这项工作中，为了简化实验，每个主机仅分配给一个容器。此外，将容器性能与其他虚拟化技术进行对比评估，可作为对本工作的进一步补充。

贝塞拉等人（2016）分析了容器虚拟化与基于虚拟机的虚拟化在高性能计算磁盘I/O密集型任务中的性能表现。评估结果表明，对于磁盘I/O和数据密集型应用，容器化环境通常比虚拟机更高效。此外，如果每台物理服务器仅有一个抽象层，则这两种虚拟化技术可达到相同的性能水平。

万吉普拉姆（2016）对Apache Cassandra时序数据库在Linux容器与裸机环境下的性能进行了实验性对比。他们考虑了三种不同的工作负载场景：写入、读取以及混合（读写）负载。研究结果表明，在写入和混合负载场景下，运行在裸机上的Cassandra集群的CPU利用率低于容器化环境；但在读取场景中，两者之间没有显著差异。在所有场景中，裸机上的Cassandra集群相比容器具有更低的延迟。此外，关于磁盘吞吐量，无法从研究结果中得出明确结论。然而，该研究未考虑内存利用率。如果监控内存消耗情况，将能提供更真实的结果，因为当系统内存不足时，Cassandra的性能会变差，最终会频繁进行垃圾回收。

杜西亚等人（2015）提出了一种机制，利用Docker为时间关键型应用提供网络服务质量保障。他们的实现能够对主机上运行的所有容器的网络访问进行优先级排序，使高优先级的容器获得更多总可用网络带宽的份额。因此，通过这种方式，网络带宽密集型的容器化应用不会因与其他应用共享Docker主机而导致执行效果不佳或不可接受。然而，作者在静态环境中进行了实验，未考虑当前的数据流需求或正在进行的缓冲区状态。

2.3. 端到端链路质量监控

基于云的应用程序（如预警系统）具有时间关键性需求，例如最小延迟和抖动容忍度，并需要适当的支持以实现有保障的基于网络的 QoS。这是一个挑战，因为如果网络基础设施的条件持续变化，性能将难以保持。

一些应用服务部署在网络边缘的节点上，而另一些则部署在集中式数据中心，这一想法引发了人们对边缘计算框架中这些服务之间链路网络质量的严重关注。这是一个具有挑战性的研究领域，因为它不仅涉及边缘节点与数据中心之间的服务实时迁移，还涉及边缘计算框架中同一层不同节点之间的迁移。

通过边缘计算框架的所有通信的网络性能必须通过端到端链路质量监控来测量。无论使用何种网络技术，边缘计算范式中都包含四种需要考虑的应用组件之间的网络连接类型：

云数据中心与边缘节点之间的通信 ：SDN和NFV等新兴使能技术为应用关于网络如何被适当管理的先进原则提供了基础，在云数据中心与边缘计算框架中的边缘节点之间进行开发、实现、部署和运行。近年来，软件定义网络（SDN）和网络功能虚拟化（NFV）开辟了新的机遇，提供了一种基于端到端连接质量按需虚拟化网络的方法。通过NFV可以对网络组件（例如路由器、网桥、交换机等）进行虚拟化，从而能够高效地动态实例化、迁移以及扩展或缩减路由、数据包转发和防火墙服务等网络功能。与此同时，SDN提供了一系列应用程序编程接口（API）和控制协议（如简单网络管理协议（SNMP）和 OpenFlow），使网络具备可编程性、可管理和自动化能力。
边缘节点之间的通信 ：位于不同地理位置的边缘节点在本地管理一组虚拟化资源。通过同级边缘节点之间的协同供应和内容分发，应用服务提供商能够提升完整应用性能。这些节点之间的数据传输可以通过集中式方法（如软件定义网络（SDN））实现，也可以通过传统路由协议（如开放最短路径优先（OSPF））采用完全分布式方法进行（Verma等，2016）。
云数据中心之间/内部的通信 ：随着基于云的应用程序显著增长，部署在云数据中心不同层级上的软件组件之间交换的数据量正在迅速增加。由于不同云数据中心之间/内部复制和分布式的应用组件连接所固有的网络条件运行时变化，确保此类应用程序能够提供良好的服务质量一直是一个具有挑战性的问题。
物联网对象/用户与边缘节点之间的通信 ：自适应应用提供商必须根据物联网设备和客户网络环境动态调整其服务，以提供高性能和无缝体验。

根据文献（Lampe等，2013；陈等，2014；Samimi等，2007；Mohit，2010；Hsu和 Lo，2014；Taherizadeh等，2016a年；Cervino等，2011），网络测量中需要分析的最重要指标包括：

网络吞吐量 ，即通过网络连接成功传输数据的平均速率。
网络延迟 ，指数据包从一个端点或节点经链路传输到另一个端点所需的时间。该指标也可表示往返时间（RTT），即消息从源点发送至远程位置并返回源点所经历的时间。
丢包，指在通过网络传输的一个或多个数据包未能到达其目的地的情况。
抖动，指连续接收的数据包端到端延迟的变化。该网络指标对于实时应用（例如石油勘探或车联网应用）极为重要，因为抖动会影响相关数据流缓冲区的大小。

如表5所示，一些研究工作致力于构建监控系统，以针对云环境的端到-end链路质量测量进行研究。

表5 不同链路质量监控系统的研究概述

论文	Goal	测量指标（网络级别）
（Lampe等，2013 )	支持应用QoS（用于音视频流媒体服务）	延迟
(陈等，2014)	支持应用QoS（用于云游戏系统）	吞吐量、延迟，丢包
(Samimi等，2007年 )	支持应用QoS（用于通信服务）	延迟、丢包，抖动等。
( Mohit，2010 )	支持应用QoS（用于通信服务）	吞吐量、延迟，丢包
( Hsu和Lo，2014 )	确保为用户（对于多媒体服务）提供用户体验质量	吞吐量、延迟，丢包，抖动
(塔赫里扎德等人，2016a年)	确保为用户（数据流媒体服务)提供良好的用户体验质量	吞吐量，延迟丢包，抖动
(Cervino等，2011 )	支持应用QoS（用于实时流媒体服务）	吞吐量，延迟，丢包，抖动

兰佩等人（2013）解释说，网络基础设施的限制（例如高延迟）可能会影响面向用户的计算机游戏。作者在研究中重点关注网络延迟测量，若能增加端到-end链路质量指标将更有助益；例如，网络扰动的影响，如增加的丢包或波动的吞吐量，这些是边缘计算框架内网络性能的明显指标。

陈等人（2014）对两种商业版游戏系统（StreamMyGame和 OnLive）进行了广泛的流量分析。结果表明，带宽和丢包的限制会对云游戏系统的图像质量和帧率产生负面影响。相比之下，由于缓冲的存在，网络延迟对游戏服务的图像质量影响不大。该研究主要关注用户视角下的基于云的游戏系统，而从服务提供商视角评估游戏服务的性能则可作为另一项研究方向。

萨米米等人（2007）提出了一种模型，该模型包含一个基于网络的监控系统，并支持在覆盖网络上对服务进行动态实例化、配置和服务组合。结果表明，为了简化和加速通信服务的部署与原型开发，可以设计和使用分布式云基础设施，以根据服务提供商需要大量资源的工作负载动态调整服务质量。然而，在涉及覆盖网络时，封装技术并非没有缺点，包括带来开销、给负载均衡带来复杂性，以及与防火墙等设备存在互操作性问题。

莫希特（2010）提到，基于计算的基础设施测量对于云服务的最优实现是不够的。云服务的网络级评估也非常重要。该作者提出了一种方法，包含使用不同技术，但未涉及实现和详细信息。此外，他们的解决方案依赖于高容量边缘路由器，这类设备价格昂贵，因此并非所有应用场景都能承受。

许和罗（2014）提出了一种从服务质量（QoS）到用户体验质量（QoE）的映射方法，从而建立了一个自适应模型，将端到-end链路质量指标（包括延迟、丢包率、抖动和吞吐量）转化为在云上运行的多媒体服务中终端用户的用户体验质量。为此，他们提出了一种函数，用于评估用户观看流媒体视频后的用户体验质量评分。结果表明，网络服务质量与用户的用户体验质量具有一致性和关联性。因此，服务提供商能够应用所提出的自主函数来计算用户的用户体验质量感知，并对用户体验质量下降做出快速响应。该方法未考虑网络成本优化与质量之间的权衡，而这一因素在边缘计算场景的自适应过程中是一个需要重点考虑的关键因素（艾哈迈德和雷赫马尼，2017）。然而，需要注意的是不同的用户有不同的目标，例如价格与质量之间的冲突目标。

塔赫里扎德等人（2016a）提出了一种非侵入式网络边缘监控方法，能够测量关键服务质量指标，包括延迟、丢包、吞吐量和抖动，从而针对在边缘计算平台上运行的实时数据流应用，调整用户所体验到的服务质量。作者声称，特定于网络边缘的监控知识有助于应用提供商更有效地根据用户状况（例如网络状态）进行自适应调整。在该研究中，主要的适应可能性包括将用户动态重新连接到一组提供完全合格网络性能的最佳可靠服务器。

切维诺等人（2011）进行了实验，以评估在云中部署虚拟机对点对点流媒体的优势。作者将网络流量分发节点战略性地部署到亚马逊在全球拥有的云基础设施中。主要目标是通过在亚马逊的云数据中心之间建立网络连接，利用其数据中心之间存在的低延迟和减少的数据包丢失，从而改善实时流媒体甚至点对点视频会议服务的服务质量。作者评估了位于不同区域的亚马逊数据中心之间连接的多种网络服务质量指标，这些连接提供的网络质量优于平均互联网连接。他们的实现涉及跨大陆通信，因此未解决流量本地化问题，例如仅在一个区域内邻近对等节点之间的数据交换。因为在某些情况下，如精灵宝可梦GO（2016年的一款成功游戏），分布在一个国家（例如澳大利亚）周围的边缘节点偶尔需要将部分数据（仅为计分信息的一个子集）发送至中心数据中心，而该游戏要求用户与近距离的边缘节点之间进行持续的来回交互。

2.4. 应用级监控

边缘计算框架本身是与应用无关的，因为它并不专用于某一种类型的软件系统或用途。然而，每个基于云的应用都需要扩展以包含应用级监控能力，以测量反映服务状态及其性能的指标。尽管大量研究工作考虑了底层云基础设施的可靠性，但仍然缺乏高效的应用级监控技术来检测和衡量服务质量下降。在表6中，总结了不同监测应用级指标的研究工作。

表6 应用级监控系统研究概述

论文	Goal	测量的指标（应用级）
（莱特纳等人，2012）	云应用的适应（例如推特）	响应时间（每项数据的时间），应用吞吐量（数据每秒项目数等）
（埃文斯等人，2015）	云应用的适应（例如推特）	每秒总入站推文，运行中的频道数量 pipeline等。
（Emeakaroha等，2012）	云应用SLA违规检测	响应时间、应用吞吐
## 2.4. 应用级监控

表6 应用级监控系统研究概述

论文	Goal	测量的指标（应用级）
（莱特纳等人，2012）	云应用的适应（例如推特）	响应时间（每项数据的时间），应用吞吐量（数据每秒项目数等）
（埃文斯等人，2015）	云应用的适应（例如推特）	每秒总入站推文，运行中的频道数量 pipeline等。
（Emeakaroha等，2012）	云应用SLA违规检测	响应时间、应用吞吐量等。
（Farokhi等，2015）	云应用的适应（例如Web应用）	响应时间
（Xiong等，2013）	云应用性能建模（例如Web应用）	响应时间和应用吞吐量
（Mastelic等，2012）	云应用性能建模（例如音视频服务）	响应时间（每帧渲染时间）
（邵和王，2011）	云应用性能建模	响应时间、应用可用性等。
（Wamser等，2017）	确保用户体验质量（例如实时视频流服务）	应用吞吐量（每秒帧数）、丢帧和视频质量
(Rossi等，2015)	云应用性能建模	响应时间
(Jamshidi等，2015)	云应用的适应	响应时间和应用吞吐量
（Rao等，2011）	智能资源供应	响应时间和应用吞吐量
（Islam等，2012）	智能资源供应	响应时间

Leitner等（2012）提出了一种名为 CloudScale 的监控系统，该系统在运行时测量分布式应用的性能，并采用用户指定的扩展策略来配置和取消配置虚拟资源。他们提出的基于事件的方法对工作负载行为进行建模，支持多维分析，并定义了适应性操作。然而，该方法仅考虑了弹性，通常表现为增加或减少资源池中计算节点的总数，而未考虑应用拓扑或重新配置。

Evans等（2015）使用基于容器的虚拟化来运行一个名为 Sentinel 的 Twitter 分析应用。该应用由分布在云中的多个容器化组件组成，能够按需对 Docker 容器进行重新配置，并提供实时服务监控，以通知重新配置模块根据变化的情况（如负载等）重构应用。所提出的系统具有可扩展性，能够动态复制运行的组件，以分担工作负载。

埃米卡拉哈等人（2012）实现了名为 CASViD 的监控框架，该框架为通用型，支持测量低级别系统指标（例如中央处理器和内存利用率）以及高级别应用指标（这些指标取决于应用类型和性能）。结果表明，基于非侵入式设计的 CASViD 可以定义有效测量间隔来监控不同的指标。它能够为不同工作负载提供测量不同指标的有效间隔。下一步有可能改进该框架以支持多层应用。这具有挑战性，因为当今边缘计算应用具有分布式特性，每个应用都有不同类型的组件和不同的应用级指标。

法罗基等人（2015）提出了一种模糊自主资源控制器，通过针对内存和中央处理器的垂直扩展，在避免资源过度和不足配置的同时满足服务响应时间约束。该控制模块能够自主调整所需的最优内存和中央处理器数量，以实现交互式服务（如网络服务器）的性能目标。由于最大内存或中央处理器容量有限，所提出的系统可进一步扩展，以同时考虑垂直扩展和水平扩展，从而能够应对大规模边缘计算场景中可能产生的无限工作负载。

熊等人（2013）提出了一种名为vPerfGuard的模型驱动框架，以实现自动化自适应应用性能。该方法能够识别性能瓶颈，包含三个模块：（1）传感器元件，用于收集运行时系统指标以及应用级别指标，例如响应时间和应用吞吐量；（2）建模元件，支持创建定制化性能模型，展示系统指标与应用性能之间的相关性；（3）模型更新元件，可自动检测性能模型何时需要更改。该方法的一个潜在缺点是，如果性能分析师缺乏足够的知识或经验来定义合适的性能指标以构建模型，则其机制可能无法使用。此外，在某些情况下，异常值可能对回归分析产生巨大影响，从而限制了所获得指标在自适应中的可靠性。

马斯泰利克等人（2012）讨论了中央处理器或内存使用率如何影响响应时间，在他们的情况下，响应时间即为每帧渲染时间。他们的监控系统包括属于该应用的所有进程的资源消耗。这些进程具有相同的父进程，因此通过列出被监控应用程序的进程ID（PID）列表，可以汇总该应用程序所属所有进程的资源消耗，并计算出某一时刻的总资源消耗。该模型若能扩展以包含其他类型的指标将更具优势；例如网络级参数，因为对包括音视频流媒体服务在内的各种实时数据流应用的监控与管理是一个大数据挑战。

邵和王（2011）提出了一种基于云监控运行时模型（RMCM）的性能保证方法。在这项工作中，利用线性回归算法基于运行时监控数据构建性能模型。这些相关指标包括分配给应用程序所在虚拟机的资源、在同一虚拟机上共存的应用程序数量、应用程序的实际资源占用、工作负载等。结果表明，该性能模型可有效用于控制资源供给方法，以实现指定的性能目标。由于该项工作中监控代理需要手动安装和配置，因此监控的非功能性需求（如可扩展性和迁移）可能无法满足。另一个值得进一步研究的方向是如何确定有效的测量间隔。

瓦姆泽等人（2017）专注于基于HTTP的视频流服务实例的实时迁移，以应对用户移动性带来的影响。他们使用边缘计算环境，在用户感知到视频质量较差时，实现跨不同边缘节点的云服务快速替换。在本研究中，依托 INPUT项目，采用了一种深度包检测（DPI）监控工具来测量三个应用级指标，包括每秒帧数、丢帧和视频质量，因为这些指标与用户体验质量（QoE）具有正相关性。当这些指标中的任何一个在特定时间段内超过预定义阈值时，服务必须从当前边缘节点迁移到另一个边缘节点。

罗西等人（2015）提出了一种根据Linux操作系统计数器来估算云应用响应时间的模型，例如 LoadAVG。基于低级指标（例如CPU负载）来估算应用级指标的最重要原因之一是，监控应用级指标（如响应时间）可能会在网络通道和计算资源方面带来开销。此外，监控高级指标可能对用户产生隐私影响。结果表明，LoadAVG提供的负载值与应用响应时间的行为相伴随，从而导致两者行为之间存在强烈的正相关性。他们的工作仅考虑了 LoadAVG，因此通过探索其他计数器（如iostat和netstat），该模型可以得到更全面的发展。

贾姆希迪等人（2015）提出了一种名为FQL4KE的自学习适应技术，该技术是一种基于强化学习（RL）算法的模糊控制方法，用于学习最优弹性策略。该方法旨在在不依赖任何关于运行中云应用的先验知识的情况下，实现伸缩过程的自动化。所提出的架构包含一个学习模块，该模块通过学习适用于系统的适应规则，持续更新控制器的知识库。然而，该方法无法处理时变目标。如果系统目标发生变化，控制器必须从头开始重新学习所有内容。在现实环境中一个更根本的问题是，场景数量可能极为庞大，因此由于新型计算范式中的时间约束，学习过程可能会变得不切实际。

饶等人（2011）使用了一种称为iBalloon的分布式强化学习机制，用于自适应虚拟机资源供应，其中监控对于自主编排和适应至关重要。

如今，云基础设施通过横向或纵向扩展方案提供弹性资源，以使应用性能适应不断变化的工作负载。然而，当前这些仅利用与基础设施相关的监控数据的扩展方法，在运行时工作负载变化期间可能导致严重的性能下降。作者指出，如果仅监控内存和带宽等基础设施级指标，而不考虑应用性能在运行时的行为（即应用级监控），则由于缺乏详细测量，会使资源供应问题复杂化。在他们的研究中，根据所提出的纵向扩展方法，每个虚拟机都能够调整其在中央处理器、内存和带宽方面的资源分配。iBalloon架构包含三个基本元素：（1）主机代理，负责向虚拟机分配资源；（2）应用代理，包含iBalloon的监控部分，并报告有关应用性能的运行时信息；（3）决策器，其上部署了位于每个虚拟机中的强化学习代理，以执行自动资源容量调整。然而，iBalloon存在局限性，因为它未考虑其他虚拟化资源（例如存储），也不支持其他适应性操作（例如迁移）以提升应用性能。这是一个问题，因为在管理部署于边缘计算框架上的应用时，有必要考虑应用组件在异构基础设施之间的迁移（Desertot等人，2005）。

Islam等人（2012）提出了一种主动式云资源管理方法，该方法应用线性回归和神经网络来预测并满足未来资源需求。本研究的实际问题是分析时间序列监控数据，以提取预测模型及监控数据的其他特性。所提出的性能预测模型能够在运行时估计即将发生的资源利用率（例如所有正在运行的虚拟机实例的CPU使用率的聚合百分比），并能够启动额外的虚拟机以最大化应用性能。作者基于响应时间方面的应用性能考虑了预测准确性。该方法支持分布式扩展，还可进一步增强以处理单个虚拟机的资源分配问题。目前，仅使用CPU利用率来训练预测模型，而他们的方法未来可进一步包含其他类型的资源，例如内存、磁盘和带宽。

2.5. 边缘计算上下文中监控的演进所面临的挑战

根据我们的分析，边缘计算框架中监控自适应应用面临的最重要当前挑战如下：

移动性管理 ：当客户端设备移动时，由于终端用户与边缘节点之间的链路网络参数（如抖动、延迟、带宽等）发生变化，应用QoS可能会迅速上升或下降，且这种变化可能难以预测（Ahmed 和 Ahmed，2016）。由于用户或终端设备的位置可能随时间变化，动态服务迁移已受到越来越多的关注，在边缘计算范式的背景下提供全天候服务。
网络边缘的可扩展性和资源可用性 ：轻量级任务很可能在网络边缘进行处理，因此边缘节点可能存在硬件容量限制。同时，应确保这些节点能够满足不断增长的服务需求和不断增长的网络流量。无论边缘网络中终端用户的客户端设备数量如何，边缘节点都应确保服务的可用性（Ahmed 和 Ahmed，2016）。
先验知识 ：支持服务质量约束需要预先了解执行环境，例如底层基础设施以及应用组件在网络中的配置（Xiao 等，2016）。如果一种适应技术不需要依赖先前经验提供的知识，则该技术具有完全优势。
数据管理 ：在大规模环境中，监控探针正在产生海量采集数据，需要进行聚合、处理和存储。因此，这带来了其他挑战，例如利用具有更高带宽（Zhao 等，2015）和灵活集成能力（Esposito 等，2015）的分布式数据中心。
协调式去中心化 ：构建去中心化系统的挑战在于确保所有不同的应用组件共同推动整个系统朝着一个共同目标前进。
节约成本、时间和能源 ：按需资源分配应具备足够的灵活性，以便根据现代自适应云应用的需求动态分配基础设施，而此类系统的一个重要属性是降低其成本。然而，成本优化不应导致服务质量/用户体验下降。需要注意的是，应用提供商需要考虑适应逻辑的插入位置：是单独插入，还是与监控组件集成在一起。例如，应用程序的监控模块是否负责考虑网络成本优化，或者这是自适应引擎的任务。
互操作性与避免供应商锁定 ：供应商锁定通常被认为是云计算中的一个劣势（Toosi 等，2014）。近年来，为应对这一挑战，推动边缘计算标准化的工作已取得显著进展。例如，由 Linux 基金会支持并于 2017 年启动的开源 EdgeX Foundry 项目，旨在为物联网边缘计算开发一个厂商中立的框架。类似地，OpenFog联盟由戴尔、思科、英特尔、微软和 ARM 等科技巨头联合普林斯顿大学共同成立，致力于推动雾计算的标准化。该联盟旨在利用云、边缘和雾架构来实现物联网场景。
边缘节点间的最优资源调度 ：调度机制必须具备足够的智能性，以在运行时环境的不确定性（Lee 和 Lee，2015）下保证响应，例如变化的工作负载、用户信道多样性、不稳定的网络状况、用户移动性等。
容错性 ：应用应在存在故障（张等人，2014）的情况下继续运行，例如失去对边缘节点的控制或延迟不确定。这需要具备去中心化控制或离线检测与恢复的机制。由于实时系统具有安全关键性，其容错性已受到广泛关注。
主动计算 ：这一新范式通过预测未来状态来自主地触发决策和行动。为实现这一愿景，必须考虑时间约束，并且通常需要处理大量历史与流式数据（富尼耶等人，2015）。
服务复制 ：在边缘计算背景下，服务可以复制并在多个地理上分布的云基础设施上运行（法里斯等人，2017）。服务器复制存在自身的技术问题，例如需要考虑的临时不一致性。此外，不同企业对使用（或不使用）新技术有不同的规定，例如关于数据存储位置的内部法规。
容器安全 ：使用基于容器的虚拟化无疑支持边缘计算范式，但也带来了新的安全威胁。例如，容器能够直接与主机内核通信，这可能导致系统中的安全漏洞。
非特定边缘节点 ：在图1所示的多层边缘计算框架中，边缘节点指的是一组异构计算平台，其性能可能不如云数据中心。然而，当前工业界很少提出用于提供通用型边缘节点以支持计算和数据分析的解决方案。在这方面，LightKone项目于2017年开始实施，旨在将计算从数据中心直接转移到网络边缘。作为另一个例子，名为开放边缘计算（OEC）的项目的主要愿景是，所有附近的组件（如Wi‐Fi接入点、DSL盒、基站）都能够通过标准化、开放机制向各种应用程序提供资源，以在边缘执行计算。实际上，这些边缘节点通常并不适合处理通用计算工作负载。因此，与这些节点类似，其监控机制通常受限于特定技术的专有使用，因而无法满足多用途需求。

2.6. 总结

为了简化边缘计算环境中的自适应决策机制，监控解决方案会从不同级别收集信息。为此，除了监控虚拟化资源（例如中央处理器、内存、磁盘等）外，还需考虑其他监控级别，包括容器、端到-end网络质量和应用。在本节中，所选论文的综述方式涵盖了边缘计算框架内自适应应用程序的所有重要功能性和非功能性监控需求。本节还指出了该领域需要探索的最新挑战和未来研究方向。通过对本节文献的分析，我们提出了一种新的需求分类体系，用于指导边缘计算框架内相关监控技术的开发与部署，该分类法将在第3节中进行阐述。

3. 边缘计算场景中监控需求分类

借鉴引用文献中第2节的讨论，表7提出了支持在边缘计算框架上编排的应用程序进行动态适应所需的监控需求分类法。该表中还列出了10项常见的功能需求，这些需求对于所有类型的边缘计算场景中的监控系统都至关重要。基于此分类法，我们在第4节中分析了监控工具，以明确其面临的挑战和优势。

在边缘计算框架中用于基本监控的功能需求，因在所有监控层级中均普遍存在，故总结于表7并描述如下：

在多租户云环境中供服务提供商和客户使用 ：此需求意味着能够为具有不同权限的各类用户定义多种角色和视图，以访问监控数据。特别是在多租户供应平台（何等人，2012）中，多个租户可能共享相同的基础设施和应用实例，并具有不同的服务质量值，各租户应仅能测量与其相关的参数并访问相应信息。
提供可视化功能 ：可视化是分析动态变化环境（如边缘计算场景）中事件的关键功能。它在时序数据库中存储的监控数据与人脑之间提供了强大的接口。
能够过滤测量值以减少数据交换 ：在被监控节点上提供基于阈值的过滤能力，对于降低监控数据传输和存储过程中的运行时通信开销显得尤为重要。
可调节至任意所需的监控时间间隔 ：可在指定的秒、分钟、小时、天或周范围内设置任意自定义时间间隔。监控间隔的长度需确保可靠性，避免开销，并防止在执行适应性操作期间失去对运行环境的控制。
包含测量值的长期存储功能 ：该功能是构建监控方法的核心能力之一，旨在优化监控数据的存储与检索，以便（例如）利用这些数据为未来的适应策略提供依据。
支持大规模动态环境的扩展适应策略 ：边缘计算框架内服务的弹性管理需要能够在大规模环境中支持扩展策略的可扩展监控解决方案，而这一问题目前仍是一个开放性难题，现有的许多监控系统尚未有效解决。监控解决方案的不同特性，如数据存储机制、用于数据收集的通信协议、执行监控活动所消耗的资源以及随时间自动自配置以调整监控系统的能力，都可能影响在大规模动态环境中应用程序的可扩展性。
能够设置自动告警 ：在边缘计算场景中，通常需要能够创建满足特定条件的自定义告警规则。例如，当某个虚拟机或容器实例开始出现异常行为，或某个指标达到其关联阈值时，监控解决方案应能够触发告警。
支持不同的适应性操作，例如服务迁移等 ：在边缘计算框架中，监控系统应应对由于适应性操作（如虚拟机或容器实时迁移）导致的应用重新上下文化（例如动态IP地址管理）所带来的不确定性。
监控系统的自动安装和配置 ：由于弹性扩展操作而创建新的虚拟机、容器或应用实例时，监控系统必须能够自动检测到这些新创建的资源。自动发现可被视为一种自动安装的方法，指的是在云环境中检测新设备，并在无需人工干预的情况下对这些设备进行持续监控的过程。类似地，由于弹性缩减操作，正在运行的虚拟机、容器或应用实例可能会被终止。在大规模边缘计算环境中，任何监控系统的自动安装和配置都是支持扩展适应策略的必要条件。
可根据监控需求进行定制 ：必须支持监控解决方案的可定制性，例如指标扩展（纳入并开始测量任何新的特定指标），这使得能够涵盖特定环境下的特殊情况，从而为监控方法提供执行环境的全面视图。

边缘计算框架中监控系统在虚拟机和容器级别的功能需求如下：

独立于底层云基础设施提供商 ：在边缘计算场景中，联邦云环境的管理需要通过互操作监控在异构框架之间共享信息。虽然设计特定于云的监控平台较为容易，但实现能够与多个云基础设施提供商协同工作的通用监控解决方案仍然是一个具有挑战性的问题。
快速响应随时间变化的动态资源管理 ：这一功能需求是一个过程，特别是针对时间敏感的边缘计算应用，监控解决方案需快速检测并收集有关环境变化的信息。与集中式云数据中心方法相比，边缘计算需要更加敏捷的监控系统，尤其是因为网络边缘是一个高度动态的环境，终端设备可能频繁地可用或不可用、设备在移动，或边缘节点随时间改变状态。
支持所有类型的硬件虚拟化监控 ：边缘计算框架中的云监控解决方案应涵盖联邦云中各种硬件虚拟化及操作系统。
提供一个API以暴露监控数据 ：所有在虚拟机、容器、网络链路或应用上运行的监控工具必须能够提供一个API，用于暴露被监控实体的运行时统计信息，并且该远程API应可被其他实体从外部访问。

边缘计算框架内监控系统在网络链路质量级别方面的功能需求解释如下：

监控端到-end网络QoS特性的全范围 ：在端到-end链路质量级别测量方面，服务质量属性不断变化，因此需要在边缘计算环境中密切监控网络层参数（主要是网络吞吐量、延迟、丢包和抖动）。
支持按需网络配置 ：边缘计算框架内的监控解决方案必须能够支持可编程网络有助于动态管理和控制虚拟网络资源。
尽管存在过滤器和防火墙仍能到达设备 ：由于各种安全问题，在私有管理域中通常会过滤特定类型的流量，例如ICMP或SNMP数据包。在这种情况下，监控解决方案应通过不同的通信协议自动改变其操作模式，以确定用户位置、到达用户设备，并测量到用户的端到-end链路质量指标。为此，第一个要求是网络监控解决方案应能够访问用户设备的IP地址（需考虑任何网络地址转换）。
考虑用户的链路状况（例如，网络质量） ：在边缘计算框架内，通过利用网络边缘特定的监控信息，可以实现针对用户网络条件的有益动态适应。监控并识别终端用户与应用服务器之间连接的网络质量，使得决策或控制任务成为可能，从而持续调整部署的服务以实现最优性能。例如，在网络边缘存在多个服务器可提供服务的场景中，监控解决方案有助于根据客户端的网络边缘条件（如通过更稳定的连接获得更高分辨率的流媒体应用）选择最佳的应用实例进行连接。

边缘计算环境中云监控系统在应用层的其他功能需求如下所列：

能够处理应用拓扑和重新配置 ：在边缘计算框架内执行期间，由于适应性操作导致基于云的应用程序发生拓扑变化或重新配置，监控系统若能感知这些变化，将更有利于支持指标收集和各种分析。例如，监控系统可以了解作为整体应用的分布式服务运行位置以及它们之间的连接方式。
根据应用性能定义有效测量间隔 ：应根据应用程序的运行时性能，优化确定不同类型的应用程序的监控测量间隔。过短的测量间隔可能对监控工具的侵入性产生负面影响，而过慢的采样率可能会降低监控信息的准确性。
支持多层应用 ：在边缘计算框架中，与传统的集中式云架构不同，终端用户发送的单个请求会导致位于不同位置的不同应用层之间发生多次交互。在边缘计算环境中，将多层应用的响应时间区分为各个组成部分的持续时间，对于应用性能诊断至关重要。因此，任何边缘计算框架中的监控解决方案都应能够从应用程序的多个层级收集监控参数。此外，未来的监控系统还可能考虑应用的多层特性（例如，每层上不同动态供应策略的监控信息）以及各层之间的交互。
能够适应时变应用适应目标 ：如果应用自适应的目标随时间变化，监控解决方案可能需要在监控升级期间动态自适应，同时保持应用的正常运行。在这种情况下，需要对收集特定应用指标的监控方法进行动态重编程，例如由于应用响应时间有了新的不同定义。

从边缘计算的角度来看，为支持边缘计算应用的动态适应，监控系统所需满足的所有重要非功能性需求（如第2节综述文献中所讨论的）如下所列：

可扩展性 ：一个可扩展的监控系统能够处理大量被监控资源和服务（Clayman等，2010b）。这一监控特性在边缘计算环境中极为重要，因为需要管理跨越框架各层的大量需监控参数。在包含数千个节点的边缘架构中，对虚拟机或容器进行运行时编排，需要一个可扩展的解决方案以灵活且及时的方式提供监控数据。由于边缘计算应用的分布式特性，现有的集中式监控工具因缺乏可扩展性而不适用，它们无法分发监控负载，从而导致单点故障（Xu等，2016）。
非侵入性 ：边缘计算的观点旨在以轻量级、简单的方式提供一组应用服务，因此任何边缘计算监控解决方案都应遵循这种轻量级方法论。因此，由于需要对应用和基础设施的正常流程保持轻量级，监控实现应采取非侵入性方法（Taherizadeh等，2016b）。因此，通过采用最小化处理、内存容量和通信流量来实现的低开销监控工具，是提高此类环境效率的关键要素（Agelastos等，2014）。
互操作性 ：边缘计算旨在实现应用服务在集中式云和边缘基础设施上的自动协同部署与组合，适用于高度分布式或潜在的联邦环境。企业可以将应用组件复制到由不同云基础设施提供商托管的设施中，以平衡服务、提高可用性和可靠性，或在不同的网络条件和流量规模下降低响应时间（Grozev 和 Buyya，2013）。因此，未来需要的是针对高度自适应云应用的监控系统互操作性。然而，IaaS 提供商开发的监控工具通常仅限于特定的底层基础设施，无法监控运行在其他云服务商基础设施上的应用程序（Alhamazani等，2015）。
鲁棒性 ：监控系统本身的各个部分，甚至连接它们的网络链路，都可能出现故障，从而可能导致监控系统无法持续运行。现代监控工具面临的一个重要挑战是，必须能够检测环境中的漏洞，并适应新情况以继续运行（Fatema等，2014）。基于这一监控方面的要求，显然需要投入大量精力来开发更加健壮的云监控工具，以应对执行过程中出现的各种故障场景。特别是在边缘计算范式中，每个应用组件都可能与其他组件存在通信路径，从而使整个系统成为一个复杂的通信网络。因此，在缺乏健壮监控工具的情况下，对分布式联邦系统进行问题分析和解决可能会变得繁琐且不可行。
实时迁移支持 ：如今，虚拟化技术提供了多种资源管理选项，例如虚拟机/容器的创建、删除和实时迁移（Liaqat等人，2016）。随着边缘计算框架日益成熟，由一组可独立部署的模块化小型服务构成的高可用性应用程序的需求不断增长。为此，服务的实时迁移是此类解决方案中非常理想的功能。在实时迁移场景中，虚拟化服务可以随时从一台主机迁移到另一台主机而无需停止运行。因此，这一方面的挑战在于监控系统如何能够适应新环境以及变化的网络条件，以防止故障的发生（Toosi等，2014）。

4. 基于已识别分类法的监控工具分析

如前所述，自适应边缘计算应用需要四个监控层级（虚拟机、容器、端到-end链路质量和应用程序）。为此，本节分为两个小节：（I）描述不同广泛使用的云监控工具，以支持分类学分析；（II）根据第3节中提出的分类法分别比较它们的功能。这些全面的介绍有助于深入了解在边缘计算框架内运行的监控工具的技术概念。此外，所讨论的信息有助于根据不同自适应目标，选择最适合开发高质量边缘计算框架应用程序的监控工具。

4.1. 云监控工具

有许多工具可为云应用提供持续监控和可见性。下一小节将介绍可在边缘计算框架中使用的各种广泛使用的监控工具类型，并概述每种工具的优点和缺点。

4.1.1. Zenoss

Zenoss 是一个基于 SNMP 协议的开源无代理监控平台，用于监控网络、服务器、应用程序和服务。Zenoss 的主要功能是监控云的主要特性，例如与系统相关的可用性、库存、配置、性能和事件。它具有开放架构，使用户能够根据自身需求进行定制（Gupta, 2015）。该收集/监控工具广泛应用于企业解决方案中，并提供用户界面，使用户能够配置和监控系统（Telesca et al., 2014）。它还提供有关系统中可用主机和租户的数量及标识符的统计信息。

Zenoss 能够使用预测阈值来保护网络边缘。通过这种方式，它能够识别出边缘节点的网络接口或链路是否突然出现大量流量。此外，它还能够将预定义数据包（例如基于网络地理）从网络边缘的节点中过滤掉。然而，它的健壮性不足，无法支持边缘计算框架内必需的服务实时迁移。此外，该产品仅提供功能有限的开源监控版本，完整版本需要付费，这限制了其在研究环境中的适用性。

4.1.2. Ganglia

Ganglia（Massie 等，2004）是一种强大的分布式监控工具，可扩展用于高性能计算环境，例如网格和集群。目前，它正在被扩展至私有云和公共云监控（例如通过 sFlow）。此外，还有一些基于云的工具与 Ganglia 集成，例如可用于边缘计算用例的 Apache Cassandra 数据库（Confais 等，2016）。然而，到目前为止，该监控平台似乎并未特别聚焦于边缘计算。该监控系统使用户能够查看所有正在运行且被监控的虚拟机/机器的运行时和历史测量数据（如内存利用率和CPU负载）。Ganglia 使用了广泛应用的技术和协议，例如 XDR（外部数据表示）、XML（可扩展标记语言）和 RRDtool，用于存储和可视化时间序列监控数据。其设计可在不同的操作系统和处理器架构上运行，目前已被全球大量集群中使用。由于 Ganglia 主要设计用于收集高性能计算集群中机器的基础设施监控数据，并通过 Web界面以一系列图表形式展示，因此在边缘计算场景中存在局限性，即不适用于批量数据传输（缺乏拥塞避免、窗口式流控等功能）。

4.1.3. Zabbix

Zabbix监控解决方案（Tader，2010）采用服务器/代理架构设计。Zabbix服务器运行在独立的机器上，用于收集和聚合由Zabbix代理发送的监控数据。BonFIRE 是该开源监控软件实现所面向的主要项目之一。Zabbix解决方案支持告警系统，当预定义的事件和条件发生时会触发告警，例如内存利用率超过80%。这些告警非常有用，因为触发器可以启动自适应计划，例如弹性操作。SQL数据库用于存储测量指标，并提供 Web前端和API以访问数据。Zabbix监控工具主要用于监控网络参数和网络服务。Zabbix代理资源占用较低，可部署在边缘节点上，且对边缘网络功能无干扰。由于原生Zabbix代理使用C语言开发，因此占用空间相对较小。然而，Zabbix的鲁棒性可能不足，在某些情况下可能变得不稳定并需要重启（Simmonds和Harrington，2009）。另一个需要考虑的重要缺点是自动发现 Zabbix的这一特性可能效率低下（Murphy，2008）。例如，有时 Zabbix可能需要超过五分钟才能发现网络中的某个主机已不可用。这种时间上的限制在任何运行时自适应场景中都可能成为一个严重问题，特别是当环境条件快速变化时。

4.1.4. Nagios

Nagios监控系统是一种用于监控网络和基础设施资源的开源解决方案。它提供了一种针对机器、交换机、网络等资源的通知机制。当任何资源发生故障时，Nagios能够向管理员发出警报，并在问题被检测到或解决时通知系统。部署Nagios需要复杂的手动配置（Mongkolluksamee，2010；Issariyapat等，2012），而且其可扩展性并不突出。Nagios使用大量缓冲区、管道和队列，在监控大规模云环境时可能造成瓶颈。因此，在此背景下需要进行大量修改。 Consequently，它可能并不适合作为边缘计算框架等动态环境中的合适监控工具。

4.1.5. OpenNebula

OpenNebula 是一个完整的云管理平台。其监控部分用于监控云基础设施，以测量资源状态，例如虚拟机和物理机（Gorbil等，2014）。OpenNebula 的监控工具通过多个称为监控探针的静态感知元件来收集各项指标，这些监控探针运行在资源上。收集模式可以采用推送或拉取方式。在推送模式下，发起方是监控探针。当监控探针检测到变化的指标超过其阈值时，可轻松发送服务质量信息。在拉取模式下，监控管理器会反复查询每个探针。如果处理的是涉及少量节点的实时环境，该方法适用于保持探针与监控管理器之间的最大一致性，但对于高更新频率或大规模基础设施而言可能缺乏可扩展性。OpenNebula 允许用户自定义和创建简单的监控探针，这些探针仅应用拉取机制来发送测量信息。

OpenNebula 提供 OneGate 组件，允许虚拟机将监控数据推送到管理器，以收集应用程序级别参数并识别运行中的应用程序问题。但需要注意的是，此模块仅针对小规模云环境设计。

OpenNebula 能够支持虚拟机迁移，通常可被视为适用于网络边缘的基于虚拟机的用例等动态环境的一种解决方案（Minerva 和 Crespi，2017）。OnLife 项目（Montero 等人，2017）利用 OpenNebula 提出了一种边缘计算设计，旨在将计算服务动态迁移到更靠近用户的位置，以确保物联网服务与用户之间的低延迟交互。然而，OpenNebula 监控组件在采用过程中面临的初步障碍是云互操作性，这是需要解决的主要领域。

4.1.6. PCMONS

私有云监控系统（PCMONS）（Chaves 等人，2011）是一种旨在满足私有云对开源监控技术需求的监控系统。该监控方法与 Eucalyptus IaaS 平台兼容。PCMONS 的主要特点是具有可扩展性，能够适应新环境，例如引入新的监控指标。然而，它存在一些缺点：由于 PCMONS 是一个 Nagios 模块，因此继承了 Nagios 的性能和可扩展性问题，限制了其在大型云基础设施中的应用；并且它仅适用于私有云中的基础设施监控。

4.1.7. DARGOS

DARGOS（Povedano‐Molina 等人，2013）是一种专为云计算基础设施设计的去中心化资源监控解决方案。DARGOS 使用节点监控代理（NMA）和节点管理代理（NSA）。NMA 负责从虚拟机收集监控信息，并将其转发给 NSA。NSA 收集来自被监控资源的测量信息，并能够将监控数据发送到云管理。DARGOS 目前应在 OpenStack 平台上运行。这就是原因所在 OpenStack 平台已进行更改以支持 DARGOS（Nova项目）。因此，DARGOS 主要受限于其集成的云基础设施，因为它依赖于 OpenStack Nova 的实现架构。此外，DARGOS 既不 robust，也不支持服务的实时迁移，而这些在边缘计算框架中常被忽略。由于 DARGOS 目前尚处于早期开发阶段，其所监控的指标集仍相当有限。

4.1.8. Lattice

RESERVOIR项目（Clayman等，2012）提供了高效配置、监控、管理和跨联邦云迁移服务与资源的技术，以最大化其利用率并最小化成本。RESERVOIR引入了Lattice（克莱曼等人，2010a）作为一种非侵入式监控框架，可集成到多种监控系统中。Lattice是一个开源监控系统，原生面向基础设施监控，主要针对包含大量资源的高度动态的云环境进行实现。然而，RESERVOIR并未解决直接向云客户提供监控信息的问题。Lattice的功能集中于通过组播或UDP协议进行监控数据的收集与分发。因此，Lattice不提供可视化、评估和自动告警功能（Katsaros 等，2011a）。

Lattice在概念上提供了一种设计，旨在使应用提供商能够根据自身的独特用例（如边缘计算等分发框架）构建监控解决方案。然而，由于目前尚未提供可在Lattice平台上轻松复用的监控探针库，因此它在边缘计算框架中并未被突出作为监控系统。

4.1.9. JCatascopia

JCatascopia（Trihinas等，2014）是使用Java编程语言实现的一种监控工具，能够监控运行在不同云服务商上的联邦云。它可以获取基础设施层（例如内存和中央处理器）以及应用层（例如服务可用性和吞吐量）的异构监控数据。JCatascopia能够根据被监控指标的测量值与先前值之间的微小差值差异进行自适应