PaaS技术的广泛应用需要新的监控技术。这是因为有效的监控对于促进资源自动伸缩、维持高可用性、管理多租户（多种应用共享资源），以及识别应用和PaaS系统中的性能缺陷是至关重要的。
为了从PaaS操作环境中提取充足的信息，必须具备完整和全面的性能数据，并且进行有效率的数据收集——而且收集操作对系统性能不能有太多的影响。因此，应用性能监控（Application Performance Monitoring，APM）系统成功的关键之处就在于要能够有效解决这些问题并且进行相关的权衡取舍。
本文提出了一个新的PaaS APM设计，该云APM系统不是通常人们最为熟悉的外部系统，而是一个与PaaS云平台紧密集成的系统，我们充分利用并增加了现有的组件以提供全面和全栈式的监控、分析和可视化管理。
该设计充分利用了目前PaaS平台所具有的资源弹性伸缩、容错性、安全性和控制特性，同时为云应用提供了低开销和端到端的监控和分析方法。
云APM设计与PaaS集成
与大多数的系统监控解决方案一样，新的云APM具有数据采集、存储、处理（包括数据分析）和可视化等特点。
传感器和代理提供PaaS云平台的应用程序和核心组件，可以收集数据。传感器对于一个特定组件而言是静态的，而软件代理则更为复杂，可以智能地适应不断变化的情况，包括对信息采集进行动态决策——采集什么信息？以及什么时候、如何采集信息？鉴于传感器和代理能够影响行为和性能，它们必须重量小，并且支持非侵入式部署。为达到这些标准，确保准确性，我们将定期的、非穷尽抽样与整个软件堆栈的传感器和代理的智能配置加以结合。
在性能数据的存储和处理方面，我们充分利用PaaS自身提供的可扩展、长期、高度可用的分布式服务。具体而言，我们的系统使用可扩展的键值存储、缓存系统、关系数据库系统、高性能搜索系统，以及批量和串流分析框架，来构建PaaS业务生态系统。对于PaaS系统间的可移植性，各功能定义一个应用软件编程接口（Application Programming Interface，API）。通过这些接口，各功能可以与PaaS组件和业务进行互动。为了能够与新的PaaS交互，API操作被重写并与该PaaS的操作相关联。
图1展示了APM与一个典型PaaS堆栈的集成。左侧深蓝色的区域表示PaaS的架构。箭头指示则针对响应应用请求的数据和命令的方向。PaaS云平台的最底层，即基础设施层由必要的计算、存储和网络资源组成。PaaS可以动态获取并且释放这些资源。
PaaS内核就是一组可管理、可扩展的业务。这些业务执行大多数云应用程序所需的通用功能。应用开发人员将这些业务组合起来进行创新。这些业务通常包括数据存储和缓冲、队列服务、认证、用户管理，以及众多的其它业务。
APM架构
PaaS云平台提供一个API（云软件开发工具包）管理集。开发人员利用这些API将PaaS功能连接到应用程序上。云软件开发工具包——类似PaaS代理机制——简化、控制以及负载均衡针对应用程序和系统间PaaS业务的访问。
应用服务器执行应用程序的副本并且连接应用代码和下层的PaaS内核。同时，这些服务器还将应用代码隔离起来以确保安全的多用户操作，并提供业务控制和计费服务。负载均衡器（或者前端）作为应用程序的入口点，可以拦截应用请求，过滤并发送给适当的服务器实例。
回到图1中，与PaaS组件相连的灰色小方框代表用于监控这个云平台组件的传感器和代理。它们可以收集事件和性能数据。APM收集来自PaaS堆栈（全栈式监控）各层的数据。测量速率是可配置的，并且在许多情况下具有自适应性。传感器和代理程序利用批量操作和异步通信来减少性能故障和费用开销。
APM收集来自前端和负载均衡层的信息，这些信息与后续的应用请求相关。监控代理分析HTTP服务器日志以提取时间戳、源/目标地址、响应时间和其它参数。通常这些信息随时通过目前使用的大部分前端技术，例如Apache HTTPD和Nginx来进行采集。另外，代理还收集活动连接、无效访问尝试和HTTP错误信息。
在应用服务器层内部，传感器收集应用和运行时间/容器日志数据。这些数据一般包括表明单个应用实例的资源使用情况的流程级指标。针对日志文件进行分析可以避免因为构建应用程序和应用服务器而产生的高开销。当然，如果收益能够冲抵开销的话，还是可以增加额外的应用程序和应用服务器的。
在PaaS内核中，我们在所有PaaS业务的入口点都做了如下部署：
- 收集主叫人和被叫人信息；
- 时间戳；
- 各操作调用的执行时间；
- 请求细节，包括参数长度和哈希。
这有助于区别PaaS的不同执行阶段，汇总和描述操作调用实例。同时也可以实现低开销和准确的全栈式监控。
可以通过云基础设施收集来自虚拟机、操作系统容器，以及各物理主机与进程和资源使用相关的信息。这一层的大多数传感器可以分析日志、查询Linux proc文件系统、收集网络/CPU/内存/资源配置的相关指标，以及管理和编排框架做出的回收决定。
收集到的信息支持集群活动和全系统事件。由于PaaS系统通常承载Web应用和服务，因而我们的APM设计将Web请求看作事件。每个HTTP请求头都附有一个请求识别码，对所有组件均可见。然后适当的APM代理经过配置来记录这些识别码。数据处理层随后利用请求识别码进行集群测量，用于单个Web请求的端到端系统分析。
数据处理层存储并提供可扩展的性能数据访问。该数据处理层还支持例行的插件分析，可以用来描述随时间变化的应用与系统行为、检测行为和性能的异常与工作量变化，并且识别出能够实现更有效的资源利用，以及资源、业务和应用实例的自动缩放的机遇。
这些分析程序可以进行推理和预测，并且利用统计分析库批量处理业务和搜索查询系统。
APM的基础：弹性栈
经过全方位评估，我们选择Elastic Stack作为APM的基础。Elastic Stack是一种开源分布式系统，建立在Linux KVM（Kernel-based Virtual Machine）基础之上，用于数据存储和处理。
Elastic Stack包括3大组成部分，即ElasticSearch、Logstash和Kibana。
- ElasticSearch：支持通过自动分库和复制实现结构化和半结构化数据的可扩展、高可用性管理；同时，其还提供全面的数据索引、过滤、汇总和查询支持，可以简化上层数据处理算法的实施过程。ElasticSearch在诸如Spark和MapReduce等大数据工作流中易于整合，实现高级分析。
- Logstash：有利于将数据从广泛的标准日志格式中提取出来。通过简单配置可以支持自定义日志格式。
- Kibana：提供强大的基于Web的仪表盘，支持大量的图表、表格和时间序列。另外，自定义数据处理与分析组件及其扩展可以根据对度量系统的研究实现对可视化数据的优化，从而更加便于提取有价值的信息。
APM应用案例
以下的应用案例利用APM收集的PaaS性能数据来提供新的PaaS特性。其中有两个特别令人感兴趣的问题：第一，APM系统如何帮助预测部署在PaaS云平台端的Web应用的基于性能的服务等级目标（Service Level Objective，SLO）？第二，性能异常是如何在PaaS堆栈中被侦测出来的？
应用响应时间预测
该AMP应用案例提供可扩展和精确的响应时间预测，能够在云供应商和PaaS用户间充当各应用程序SLO的角色。为实现这一目标，我们将托管Web应用的静态程序分析和PaaS云平台的APM监控结合起来。因为我们希望在PaaS用户安装这些应用的时候为其提供预测，所以在PaaS云平台上安装或运行一个应用之前会进行这一静态分析。
对于每个功能路径，我们的静态分析通过传统技术提取PaaS内核呼叫清单以进行基于抽象解释的循环边界分析、分支预测和最坏情况下的执行时间分析。为节省开销，我们禁止应用程序收集运行时的性能指标。相反地，这些清单被记录在APM系统中，业务也在该系统中独立于应用程序的执行之外受到监控。
该系统利用APM收集的PaaS内核业务性能数据，随后分析程序提取清单中每个业务操作执行时间的时间序列，预测方法计算应用响应时间的统计边界，然后云供应商再把这些值作为性能SLO的基础。
为了预测SLO，我们采用基于时间序列的队列边界估算法（Queue Bounds Estimation from Time Series，QBETS），这是我们设计用来预测在高性能计算环境中批量队列系统的调度延迟的一种非参数的时间序列分析方法。我们对这一方法进行优化，使其可以在PaaS APM系统中用来支持“X即服务”以便估算安装应用所需的响应时间。
由于PaaS业务和平台行为负载随时间而变化，预测出的SLO可能随时间的推移而失效。我们的系统可以检测SLO违规，因此云供应商可以进行重新协商。当此类失效情况出现时，PaaS会触发APM的SLO分析程序以建立新的SLO。
目前，我们的云APM已整合在谷歌应用程序引擎内，以及开源PaaS AppScale的完整的堆栈中，以使用这些平台对运行在其上的开源Java Web应用进行广泛的测试和实证评估。我们发现我们的系统在任何情况下都可以生成准确的SLO。
性能异常检测
人们开发了无数的统计模型用于动态检测性能异常，然而之前的大部分工作只关注简单、独立的应用程序。我们的目标是为基于PaaS（分布式）的Web应用提供异常检测。为此，我们部署了大量名为异常检测器的APM分析插件，这些设备可以定期分析PaaS中安装的每个应用的性能数据。
每个检测器使用不同的检测统计方法。应用级的检测器支持不同的应用使用一个或多个不同的异常检测器。每个检测器配有执行时间表和单个已处理数据的滑动窗口，例如，从10分钟前直到现在。
除此之外，路径异常检测器利用PaaS内核呼叫清单检测每个应用请求处理路径。在这种情况下，来自PaaS内核（PaaS内核调用数据）的数据用于推测单个应用的执行路径。检测器计算不同路径的频率分布，检测该分布随时间的变化情况，识别新路径、最频繁的执行路径以及路径频率分布中的重要变化。
一旦检测到异常情况，检测器会发送事件给一组异常处理器。该事件包括与异常情况对应的唯一的异常识别码、时间戳、应用识别码和源检测器的滑动窗口。异常处理器支持全局配置，也可以设置为忽略特定的事件类别。与检测器一样，APM支持大量的异常处理器，用于处理日志异常、发送告警邮件，以及更新仪表盘等等。
此外，我们还提供两种特殊的异常处理器：一种是工作量变化分析器，另外一种是根因分析器。
工作量变化分析器利用一套变化点检测算法分析历史工作量趋势。
根因分析器评估PaaS内核呼叫历史趋势，试图决定最有可能导致异常云（在PaaS内核中）的组件。
异常检测器和异常处理器与固定大小的滑动窗口协同工作，在滑动窗口随时间线移动的同时丢弃旧数据。由于这些实体必须储存的状态信息的数量有严格的上限，因而程序都是轻量级的。如有必要，历史数据能够被保存在APM中进行线下批量处理。
指导新的PaaS业务
由于PaaS的应用日益受到欢迎，利用技术进行监控、分析已安装应用的性能和行为变得十分重要。然而，大多数PaaS云平台无法为轻量级、全栈式的性能、数据收集和分析提供足够的支持。
人们已经设计了许多监控框架来支持收集和分析性能数据以获取系统行为、性能、可用性和故障信息。不幸的是，虽然许多框架都不同程度地支持数据搜集、存储、分析和可视化，但没有一个能够作为云平台的一部分而运行。数据存储机制、API和配置模型作为独立实体，旨在监控服务器或应用程序，无法在更大的系统中支持端到端的请求流跟踪。并且，它们不易扩展，仅支持基本的度量计算，不支持相关性或根因分析。
我们提出了新的易于整合的APM系统作为一个解决方案，该系统可以利用PaaS云平台的特点进行全面、全栈式监控和分析。通过定义一套API呼叫，该APM可以整合到PaaS系统中，促进推理和预测。这一功能可以用来指导新的PaaS业务，包括应用安装时的响应时间SLO、全系统的性能异常和工作量变化点检测，以及应用性能异常的根因分析。
Chandra Krintz和Rich Wolski/文
加利福尼亚大学圣芭芭拉分校计算机科学系适应性计算环境研究实验室主任
