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