相关专题：
2018年07月19日16:12 来源：移动通信网T|T
作者：Riverbed亚太区技术方案架构师李耀宗
【移动通信网】如果您正在计划使用云应用，一定也希望看到大量的并发用户、应用、交易、服务器、实例和对象等等信息。而实际上，当您需要大规模部署应用性能管理（APM）时，就意味着将面临一系列全新的挑战。许多传统APM解决方案是无法支持海量交易的，而且它们还频繁通过采样和触发机制迫使用户在规模和数据质量之间做出选择。如果您正在使用云应用并且遇到了问题，不妨继续读完以下内容。
挑战1：交易采样
许多APM产品都使用“采样法”。它们并不是每时每刻都为所有的用户捕获所有交易。当您在大规模云环境中使用采样类产品时，只能获取很小一部分交易数据。您拥有的并发用户越多，系统需要处理的交易就越多，而APM产品捕获的交易反而越少。例如，除非你意识到你每天看到的一百万笔交易只占交易总数的10%，否则你会认为秒级采样已经是一个相当高的频率了。但对于众多日交易量在数十亿次的客户来说，他们会感受到捕获的数据比例有多么微乎其微。
采样法不仅会影响数据和计算的准确性，还会增加丢失重要交易的风险。当您只捕获了一笔几十元的小额交易而却错过了一笔数万元的大额交易时怎么办？如果每笔交易都很重要，您又该如何扩展数据采样的规模呢？
Riverbed的端对端应用性能分析方案SteelCentralAppInternals，能够自始至终为所有用户捕获全部交易！SteelCentralAppInternals基于完整的数据集进行计算，包括所有交易，不再局限于采样。您可以借助其大数据来查找特定用户交易。同时，自然语言搜索功能也可帮助客户轻松筛选数据以快速查找交易！
挑战2：所监测环境的规模
您的APM解决方案需要具备在云环境中监测应用中大量对象的能力。在某些情况下，监测对象的绝对数量可能会影响监测解决方案的成败。一些监测解决方案会选择在较大规模的环境中使用SaaS，而在较小环境使用完全不同的本地解决方案。
许多情况下，APM解决方案会被配置用于监测较小的开发环境中的几乎所有内容，并用于监测生产环境中运行对象的子集。当不可避免的故障发生时，常规的处理方法是由APM管理员来添加需要监测的其他对象，便于在下次出现故障时找到根本原因。而这种方法的缺点在于延长了调查时间，还增加了压力！另一种常用技术是在多个监测服务器间划分监测环境。在某些情况下，这是一个不错的解决方案，但如果您的监测解决方案能够扩展到支持业务增长并使用单个分析服务器的大型应用环境中岂不是更好？
SteelCentralAppInternals既可在本地运行，也可作为SaaS运行。在新版SteelCentral中，还引入了分析服务器的多系统集群部署方式来满足监测大规模环境的需求。
刚刚推出的新型集群架构，又将AppInternals的扩展能力提高了一个数量级，其单个分析服务器现可支持数以万计的代理，每天捕获数十亿次交易。
集群方法在多个工作进程间分配处理，提高存储指标、分析交易和提供性能数据的能力。如下工作进程会在群集中运行：
熆刂破鞴ぷ鳎捍娲⒅副辏灰茁肪逗团渲檬荨�
熃馕銎鞴ぷ鳎航馕龊头治鼋灰茁肪段募�
熕饕ぷ鳎核饕灰灼尾⒒殖啥说蕉私灰住�
熡没Ы缑婀ぷ鳎和泄芊治龇衿鱓eb界面以查看性能数据并执行配置任务
挑战3：架构复杂性
了解系统中组件的相互关系对于监测和排障非常重要。只对主机、JVM、实例或类别进行简单监测，却不了解之间的相互关系，对排除故障不会有任何帮助。
您的应用中包含哪些组件？对于以前的传统应用而言，它很简单。但对云应用而言，可是个大问题。您的应用可能包括用户代码，公司基础设施及第三方函数库。您的应用也可能正在调用连您也不知道的外部服务。如果您的APM解决方案无法自动发现组件并检测代码，那它如何完全了解您的应用及其复杂性？您是如何知道故障形成原因并加以解决的？一些解决方案仅用于简单的资源监测，另外一些方案则可以从中央管理界面获取信息并将其呈现给用户。某些情况下，显示器只显示正在交互的双方，但这或许难以满足用户需求。
SteelCentralAppInternals能自动发现应用组件间的关系，能自动检测代码并发现交易与代码，SQL或外部调用所消耗的时间之间的关系。AppInternals借助一个称之为性能视图的创新可视化功能来简化架构的复杂性。如下图所示，左侧交易的许多入口可能是从右侧代码/SQL中获取的。性能视图将这种复杂性抽象化，并将最耗时的业务交易与被消耗的时间源之间的直接关系呈现出来。性能视图能帮助应用所有者快速查看需要投入昂贵开发资源的位置，然后对应用进行修复或优化，并重点关注业务相关事务。
是时候为监测云应用做好准备了，就是现在。
