下载文档原格式
龙源期刊网
BMC推出应用性能管理解决方案
作者：
来源：《计算机世界》2011年第29期
BMC日前发布应用性能管理（APM）产品组合。
新集成的产品可基于单一的操作管理框架，为企业、SaaS以及云应用管理创建简化的解决方案，来预测及主动解决应用性能管理的
需求。
BMC的应用性能管理提供了应用程序性能和最终用户体验360度的全面视图，包括数据中心内的应用程序、中间件和基础设施层。
该解决方案包括BMC最终用户体验管理、BMC ProactiveNet性能管理、BMC中间件管理等。
除了监测和服务水平报告，BMC的应用性能管
理还能基于行为学习积极主动地检测问题，通过关联最终用户体验、持续采集的深度诊断和跟踪交易的数据而实现问题的快速诊断。
性能测试中的资源监控和管理方法性能测试是软件开发过程中非常重要的一项工作，它用于评估系统的性能以及性能瓶颈，并针对性地优化系统。
在进行性能测试的过程中，资源监控和管理是不可或缺的环节。
本文将介绍一些常用的性能测试中的资源监控和管理方法。
一、资源监控1. CPU监控在性能测试中，CPU的使用率是衡量系统性能的重要指标之一。
通过监控CPU的使用率，我们可以了解系统在不同负载下的处理能力和性能瓶颈。
通常可以使用系统自带的性能监控工具，如Windows系统的任务管理器或Linux系统的top命令来实时监控CPU的使用率。
2. 内存监控内存的使用情况对系统性能有着重要的影响。
在进行性能测试时，需要监控系统的内存使用情况，包括内存占用量、内存峰值等指标。
可以使用操作系统的性能监控工具或第三方监控工具，如JConsole、Grafana等来监控系统的内存使用情况。
3. 磁盘IO监控磁盘IO是性能测试中的另一个重要指标，它反映了系统对存储资源的利用情况。
通过监控磁盘IO，可以了解系统在不同负载下的IO操作能力和性能瓶颈。
类似地，可以使用操作系统的性能监控工具或第三方监控工具来监控系统的磁盘IO情况。
4. 网络带宽监控对于网络应用来说，网络带宽是一个关键的性能指标。
在进行性能测试时，需要监控系统的网络带宽使用情况，包括带宽利用率、吞吐量等指标。
可以使用网络监控工具，如Wireshark等来实时监控系统的网络带宽使用情况。
二、资源管理1. 资源分配在进行性能测试时，需要合理地分配系统资源，以模拟真实的运行环境。
根据被测系统的特点和性能测试的目标，可以合理配置CPU、内存、磁盘和网络等资源。
例如，可以通过修改系统设置或使用虚拟化技术来控制资源的分配。
2. 资源优化性能测试的目的之一是发现系统的性能瓶颈并进行优化。
在进行资源优化时，可以通过监控系统资源的使用情况，找到资源使用过高或过低的情况，并进行相应的调整。
例如，可以通过调整系统参数、优化代码或增加硬件设备等方式来提高系统的性能。
Dynatrace1、概述过去，企业的IT部门在测量系统性能时，⼀般重点测量为最终⽤户提供服务的硬件组件的利⽤率，如CPU利⽤率以及通过⽹络传输的字节数。
虽然这种⽅法也提供了⼀些宝贵的信息，但却忽视了最重要的因素--最终⽤户的响应时间。
Compuware通过事务处理过程监测、模拟等⼿段可真实测量⽤户响应时间，此外还可以报告谁正在使⽤某⼀应⽤、该应⽤的使⽤频率以及⽤户所进⾏的事务处理过程是否成功完成。
快速定位应⽤系统性能故障。
通过对应⽤系统各种组件（数据库、中间件）的监测，迅速定位系统故障，可以细化到代码级故障。
2、DynaTrace安装2.1 ： Windows环境，查看系统是32位还是64位，选择对应系统位数的安装包；2.2 ：安装DynaTrace server端、client端，agent代理，选择是版本是DynaTrace 6.3，选择Basic installation安装，集成了DynaTrace所有组件；选择安装路径，默认下⼀步，直到⾃动安装完成finish。
3、Agent配置3.1 ：安装版Tomcat Agent配置；1、打开tomcat控制界⾯，在Java Options添加Agent配置串-agentpath:<path>dtagent.dll=name=Tomcat_Monitoring,server=localhost:9998点击保存，重启即可。
3.2：免安装版tomcat Agent配置；1、编辑tomcat/bin⽬录下catalina.bat，找到set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%"有⽂档部署配置说在其后⾯配置-agentpath:<path>dtagent.dll=name=Tomcat_Monitoring,server=localhost:9998但是startup.bat，启动失败tomcat闪退；我的解决⽅法是另起⼀⾏添加set JAVA_OPTS=-agentpath:<path>dtagent.dll"=name=Tomcat_Monitoring,server=192.168.2.148:99984、打开Dynatrace客户端Monitoring，正确页⾯显⽰，请求概要图！打开浏览器输⼊访问路径(监听web应⽤服务器的访问路径)，Dynatrace客户端Monitoring显⽰概要图。
魔力象限之应用性能监控日期：2010年2月18日您需要了解的情况本文修订于2010年2月25日。
如欲了解更多信息，请参见上的更正页面。
应用性能监控(APM)现在需要实现五大不同功能维度的协调决策，其中包括最终用户体验监控(end-user experience monitoring)、用户自定义事务处理剖析(user-defined transaction profiling)、应用组件发现和建模(application component discovery and modeling)、应用组件深入监控(application component deep-dive monitoring)，以及应用性能数据库功能(application performance management database capabilities)。
通过魔力象限，企业可指导厂商进行决策,并评估厂商是否能提供不同功能维度的支持。
基本上，厂商产品会在这五大功能维度中有各自不会的表现，所以企业通常需要从不同产品系列综合选取，从而获得满足自身要求的最佳组合。
魔力象限图1. 采用魔力象限实现应用性能监控数据来源：Gartner（2010年2月）作者：Will Cappelli企业需求推动IT运营管理进一步以应用为中心，同时应用管理的难度也在增大。
厂商如何解决应用性能监控问题,将会对其是否在整个市场上占据重要地位产生重大影响。
注释Gartner魔力象限评估工作需要花费大量时间，厂商可能会在我们完成分析报告后才发表更新产品。
鉴于此，我们会在不同厂商的评价中明确指出分析的产品版本。
我们鼓励您与厂商展开讨论，共同探索当前产品版本能不能解决我们所分析版本中的局限性问题。
厂商的增减我们根据市场变化更改魔力象限和MarketScopes中的厂商名单标准。
因此，不同时期魔力象限或MarketScopes的厂商名单可能不同。
如果某家厂商某年出现在魔力象限或MarketScope名单里而次年又从名单消失，并非表示我们对厂商的评价有所变化，这可能反映了市场在发生变化以及由此导致的选择标准不同，也可能说明厂商的业务重点发生了变化。
应用管理系统应用管理系统是一种用于管理和维护应用程序的软件系统。
它提供了一套工具和功能，帮助组织有效地管理应用程序的生命周期，包括应用的开发、部署、监控和维护等。
应用管理系统的出现极大地简化了应用程序的管理流程，提高了组织的运作效率和应用程序的稳定性。
本文将探讨应用管理系统的基本原理、功能以及对组织的益处。
一、应用管理系统的基本原理应用管理系统的基本原理是将应用程序的管理集中到一个统一的系统中，通过系统化的方法和工具来管理应用程序的不同方面。
主要包括以下几个方面：1. 应用开发：应用管理系统提供了一套开发工具和环境，帮助开发人员进行应用程序的开发。
开发人员可以使用系统提供的编程语言、集成开发环境和调试工具来编写和测试应用程序。
2. 应用部署：应用管理系统提供了应用部署的功能，可将开发完成的应用程序部署到服务器或云平台上。
系统能够自动进行应用的安装和配置，简化了部署过程，提高了部署的效率。
3. 应用监控：应用管理系统可以监控已部署的应用程序的运行状态和性能指标。
系统可以实时监测应用程序的运行情况，包括处理请求的速度、资源使用情况以及错误和异常的发生。
4. 应用维护：应用管理系统提供了应用维护的功能，包括更新应用程序、修复Bug以及对应用进行性能优化等。
系统能够自动进行应用的升级和维护，减少了维护工作的负担。
二、应用管理系统的功能应用管理系统具备以下几个主要功能：1. 用户管理：应用管理系统可以管理用户的访问权限和角色，在系统中分配不同的权限给不同的用户。
这样可以确保只有授权的用户可以访问和操作应用程序。
2. 版本控制：应用管理系统可以对应用程序的各个版本进行管理。
系统能够追踪和存储应用程序的不同版本，并提供版本的比较和回滚功能，方便开发人员进行版本管理。
3. 资源管理：应用管理系统可以管理应用程序所需的资源，包括数据库、文件和网络资源等。
系统可以对资源进行配置、监控和优化，确保应用程序的正常运行。
APM解决方案概述应用程序性能管理（Application Performance Management, APM）是一种通过监控和管理应用程序的性能来提高其可靠性和效率的解决方案。
APM解决方案帮助开发人员和运维团队实时监控应用程序的性能，并提供详细的性能指标和分析报告，以便快速发现和解决性能问题。
APM解决方案的重要性现代应用程序通常由多个组件和服务组成，这些组件和服务可能分布在不同的服务器和云平台上。
这种分布式的应用架构使得监控和管理应用程序的性能变得更加复杂。
APM解决方案提供了一种综合的方法来跟踪和分析应用程序的性能，从而解决以下重要问题：1.快速定位性能问题：APM解决方案可以实时监控应用程序的关键指标，如响应时间、吞吐量和错误率等。
当应用程序出现性能问题时，APM解决方案能够帮助开发人员快速定位问题所在，从而更快地解决问题并提高用户体验。
2.性能优化和容量规划：通过全面监控和分析应用程序的性能，APM解决方案可以提供有关系统瓶颈、资源利用率和容量需求的详细信息。
这些信息有助于开发人员和运维团队进行性能优化和容量规划，从而提高应用程序的可靠性和效率。
3.业务洞察和用户体验：APM解决方案不仅可以监控应用程序的性能，还可以跟踪用户行为和应用程序的业务指标。
这些信息能够帮助企业了解用户体验、应用程序的使用情况以及用户行为模式，从而进行更好的业务决策和战略规划。
APM解决方案的核心功能APM解决方案通常提供以下核心功能来监控和管理应用程序的性能：实时性能监控APM解决方案实时监控应用程序的性能指标，如响应时间、吞吐量、错误率等。
通过可视化的仪表板和图表，开发人员和运维团队能够实时了解应用程序的性能状况，并及时发现潜在的性能问题。
事务跟踪和分析APM解决方案能够跟踪和分析单个事务的性能，从用户请求开始到响应返回的整个过程。
通过事务跟踪和分析，开发人员可以深入了解每个事务的性能瓶颈和优化空间，从而提高整体的应用程序性能。
云智慧推出应用性能管理方案
作者：暂无
来源：《计算机世界》 2015年第1期
通过应用性能管理方案，用户可以随时对业务进行调优。
本报记者李旭阳
12 月18 日，应用性能管理服务商云智慧正式推出了拥有自主知识产权的端到端应用性能管理（APM）解决方案“透视宝”。
“透视宝是业内首款覆盖从用户到服务器的应用性能管理产品，通过端到端的立体监控、端到端的数据采集、端到端的性能分析，以业务价值为中心为运维、开发和运营提供解决问题的有效决策。
”云智慧CEO 殷晋表示。
云智慧方面表示，透视宝是新一代面向业务的端到端应用性能管理平台，不论是移动APP 还是Web 应用，透视宝都能从真实用户体验的视角，为企业提供实时的性能监控、分析与管理解决方案。
帮助运维工程师快速定位故障查找问题提速90%，协助开发人员定位到代码级的深层问题，不断优化性能瓶颈和IT 架构，业务上线周期缩短60%。
借助透视宝运营和业务人员可以实时掌握关键事务、用户体验与性能的关联问题，降低运营风险30%，据了解，云智慧在2014 获得了“中国应用性能最佳产品奖”和“中国创新成长企业TOP100”等荣誉。
小米、聚美优品、同程等中国互联网百强中，有30 多家企业正在使用云智慧的应用性能管理服务。
同时，云智慧还正式发起并支持成立由多家云服务供应商组成的企业云服务联盟。
联盟成员全面覆盖SaaS、IaaS 和PaaS 等云服务领域，产品包含云基础应用、企业协同、云通讯、云安全等专业服务。
据悉，此次由云智慧发起的企业云服务联盟第一期已有30 多家云企业伙伴加入。
接下来，联盟将通过各类市场活动增强联盟成员之间的凝聚力和合作力，同时向企业用户推出更专业化的一站式服务。
Compuware应用性能管理观摘要：端到端应用性能管理（End-to-end Application Performance Management，简称APM）指的是一种IT 服务方法，包括识别、区分优先次序以及解决影响业务应用的性能和可用性问题。
APM 正在变得越来越重要，因为终端用户依赖日益复杂的应用来实现关键业务交易。
应用性能低下将降低生产力，影响客户满意度，并有损IT 声誉，进而导致成本攀升、收入减少、IT 变得效率低下——这些问题通常比可用性问题更加严重。
端到端应用性能管理（End-to-end Application Performance Management，简称APM）指的是一种IT服务方法，包括识别、区分优先次序以及解决影响业务应用的性能和可用性问题。
APM正在变得越来越重要，因为终端用户依赖日益复杂的应用来实现关键业务交易。
应用性能低下将降低生产力，影响客户满意度，并有损IT声誉，进而导致成本攀升、收入减少、IT 变得效率低下——这些问题通常比可用性问题更加严重。
传统的监测解决方案通常无法识别和解决应用性能问题的根源。
事实上，最近在终端用户体验监测、依赖性映射和相关性方面的最新进展，已让IT运行经理能够更有效地监测和解决不满足服务水平的问题。
这些技术帮助提高对整个网络、服务器（分布式和大型主机）和其它应用层的可视性，借助技术分析因果关系，从业务的角度确定哪些响应该优先进行。
实际上，即使基础架构测量指标仍然提供主要的故障和容量数据，强调重点也已从基础架构测量指标变成了业务测量指标。
我们将撰写一系列应用性能管理最佳实施的文章，从问题和事件管理的视角剖析APM。
问题和事件管理是APM 的两个核心ITIL（信息技术基础架构库，简称ITIL）流程。
事件管理（Incident Management）是当IT 出现问题的时候解决它们，作为对服务质量降低的一种响应。
事件管理的目标是恢复服务，对业务造成尽可能小的影响。
问题管理（Problem Management）强调识别和消除问题的根源。
它通过改变服务和APM 解决方案，增加了服务质量改进的概念。
本文将首先概括地讲述APM 设计、实施和运营的基本要素，将端到端APM作为一个流程来进行探讨。
一、APM设计APM 解决方案通常是作为草根、基础架构监测实践开始的，由IT 机构的某个独立业务部门实施，缺乏一致的目标。
例如，网络团队可能要部署一个开源网络工具，以获得基础网络的可视性，而web 服务器团队则可能会从一个主流的服务器厂商那里部署一个服务器监测工具。
然而，自上而下地设计一个APM 方案要切合实际得多。
使用这种方法，您先设想结果，然后将它应用于您选择的解决方案组件。
您如何着手开始呢？在ITIL 的世界里，最终支持服务级别协议（service level agreement，简称SLA）的运行级别目标（operational level target，简称OLT）是一个好的起点；这些将已经解决了预期的业务产出和成本限制，并且应该实现一个高水平的设计。
不与ITIL 相关？您仍然能够采用适合您需求的部分最佳实施。
从与业务部门讨论、理解业务目标开始，确定APM 预算，使用对应用交付基础架构的理解和它的性能敏感性，并草拟一个方案。
您很可能想把这个作为一个练习，测试什么可能会出错，尽可能广泛地扩展范围；成本和其它的实际考虑将很快专注于这一设计。
您当然不会是第一个采取这种方法的人，您可充分利用与供应商的关系、用户群和咨询合作伙伴，来理解类似尝试可能会有的成功和失败。
公司高层提供的资源支持和参与对于任何APM 项目的成功都是至关重要的，因为这将要求来自多个IT 部门的积极支持。
更重要的是，这些部门对于项目的业务价值要有一致的理解，因为他们每个都可能会面对新的企业可视性（他们在高管仪表板上的测试指标），对某些东西失去控制（应对问题的新流程），或者放弃一个最受欢迎的工具。
开始一个小型的APM 项目，选择一个战略性的应用，为业务所有者和IT 机构阐明价值，大多数机构将会从中受益。
这样一个项目的成功，将能够被一个更全面、收益更明显的解决方案利用。
然而，我们大多数人并不是从临时拼凑开始设计APM 解决方案；我们已经拥有许多一直服务于我们的目的的基础架构工具。
那么，是什么将一系列“结合平台的”（platform-aligned）工具转变成APM 解决方案的呢？尽管对于这个问题可能会有许多技术回答，但是，这里有两个最重要的主题：•业务一致性（business alignment）。
全新的主要设计目标仍然应该从注重业务产出开始。
对业务来说，重要的将是终端用户的体验——这个可通过性能和可用性进行测量。
•相关性和故障隔离（correlation and fault isolation）。
对根源的可视性，是将基础架构提升至APM、真正理解基础架构测量指标如何影响业务生产力的关键。
很容易明白诸如终端用户体验（end-user experience，简称EUE）和基础架构测量指标等业务相关的测量指标的相关性为何如此重要。
将终端用户体验到的性能问题与基础架构测量指标结合起来，隔离主要的根源，这能让IT 小组快速准确地专注于问题的起源，同时避免对不相关的组件采取行动。
通过适当的阈值调整，这为持续业务改进奠定了基础。
同样地，通过EUE 的相关性，以及受影响的用户数量和所在位臵、每天交易的次数和业务价值，可以找到问题对业务的影响。
通过一系列基础架构工具构建APM 解决方案，会带来集成和相关性方面的挑战；您需要对主要的单一供应商（single-vendor）解决方案进行评估权衡，因为供应商和定制化的多供应商（multi-vendor）解决方案构建和交付了集成。
对于更小一些的部署，定制化的解决方案可能会更省钱，但是对于较大的实施，可扩展性和维护方面的考虑将会迅速改变价格。
在设计流程里，保持对终端用户交易响应时间的专注很重要。
这有两个原因。
第一，性能分析和问题解决是为更好的了解以业务为导向的环境并提出重要意见。
尽管在传统上，基础架构测量指标是满足事件和问题管理的数据，但是，这些基础测量指标和它们的阈值驱动警报在没有业务相关性的情况下能够变得几乎毫无意义。
例如，对于一个2 M 广域网连接来说，75% 的利用率究竟是好还是坏呢？一个被报告的交易性能问题是由SAN 里长度为8 的测量磁盘阵列引起的吗？当应用的性能降级时，这些组件级的测量还将总会被突出？其次，从对业务影响的角度来说，IT 能够优先对事件作出响应是有价值的，它代表了向业务一致性迈出的重要一步。
同样重要的是，与技术和IT 资源的成本相关的设计限制。
许多APM 项目不成功，是因为缺少关注和支持，因为无法维持这一解决方案、无法适应基础架构的变化并无法定义基于真实世界反馈的流程。
二、APM 实施——将解决方案转变为运行基线对于任何APM 实施来说可能是最重要的技术成功因素之一。
基线确定了服务的正常运行，为设定警报起点提供了参考，并提供了有价值的趋势和容量规划信息，因为它们是真实的数据。
通常，APM 解决方案会动态地为一些被观察到的测量指标构建基线；经过数天或数星期，这些基线趋于一个正常的定义。
对于其它的测量指标，您很可能想要基于一段时间内的观察手动设定基线。
将这些基线作为参考点，然后您就能够确定性能阈值；当测量违反了特定的行为准则时，警报就会产生。
至少在最初的时候，这些阈值很可能以一个超出基线的比例被设定。
例如，当页面性能从基线降低25% 的时候，就会引发一个警报。
这些引发也很可能基于一个模板或一套规则被设定，能够包括更复杂的逻辑；再例如，当磁盘写队列在60 秒内超出2 至少5 次的时候。
重要的、需要考虑的是哪些指标被监测，使用什么阈值；大多数的APM 工具提供多种多样的测量选项，深入的显示出能够被分散甚至误导的水平值。
缺省值或特定平台的模板可能通过APM 解决方案厂商、软件/硬件厂商、系统集成商或用户社区获得。
然而，无论是什么资源，确定这些阈值是否适用于您的特定环境都是非常必要的。
尽管这一决定部分地能够在实施期间作出，但是大多数阈值的改进都是在运行期间实现的。
最后，我们应该关注最终由EUE 测量驱动的相关性能力。
对于有效的相关性来说，最重要的是理解依赖性或交易在系统里经过的路径。
它也建议要注意测量时间。
当然，不是所有的指标都能够被连续评估，因此有些是在一段时间内进行取样。
这是一种检测普遍性问题的有效方法。
然而，间歇的问题本质上可能会是短暂的，以至于它们在取样期间被隐藏起来。
尽管这些通常只会带来更小的业务影响（因为它们以更小的频率影响更少的用户），但是它们本质上更难解决。
交易“跟随”（following）——通常通过贴标签——可能对特定的环境是合适的，然而，暂时缩短的取样间隔时间为解决间歇问题提供一种更通用的方法。
一个实现强大APM配臵的明智方法是，在前生产测试实验室实施关键APM 监测组件，这样您就能够观察到一系列系统负载上的正常行为，这对于设臵基线是非常有用的。
通常，您将会找到性能的瓶颈。
知道哪些测量指标表明了该瓶颈的根源和它发生的阈值，这是一个理解依赖性并积极配臵生产监测阈值的理想办法，而且其带来的影响也很小。
三、APM运行——持续的服务改进成功的运行需要在稳定性和持续的服务改进（CSI）之间保持平衡。
对许多企业来说，仅仅只有在故障发生并严重威胁到业务的时候，CSI 才会成为一个项目。
一旦该问题得到解决，这一概念又会立即被抛到脑后，直到下一个重大故障发生的时候才会被再次记起。
一个更周全的CSI 方法将在事件和问题管理方面带来明显的改善，帮助IT 机构更好地解决和预防问题的发生。
正如之前提及的，APM 成功的关键——既确保业务一致性，又能解决问题——在于相关性。
一个强大的CSI 流程强调去改进被监测到的并找到更合适的阈值。
考虑一个APM的实施，终端用户体验和基础架构指标要能被监测。
当事件发生的时候——无论这个事件是由EUE 警报引起的，还是因为一个实际的终端用户——IT 人员都要将这一事件和它的根源关联起来。
确认并修正敏感性或瓶颈——至少暂时要做到这点。
如果瓶颈指标数据没有被监测到，那么，无论如何也要开始对APM进行明显改进来监测它。
如果瓶颈指标数据被监测到了，那也要着手改进去调整警报阈值，因此下一次警报能够在用户抱怨之前就识别到问题。
警报可能是被动的——超过某一阈值的用户正在经历性能问题——也可能是主动的——超出阈值给出了一个尽早的警告：如果用户继续这么做的话，他将会出现性能问题。
最终，持续的服务改进应该不止是通过改善APM 解决方案的质量来改进业务服务的水平。
它可能意味着，通过拨出额外的资源或者对资源的使用给予优先考虑来控制资源，以致瓶颈将不再发生。
