应用故障监控
针对应用的性能管理,一般通过对应用日志监控实现。此种监控管理方法,依赖于应用设计和编程时,考虑到未来应用监控的需要,在应用出现故障时,将故障信息写入应用日志中。不过,即使应用程序可以将故障信息写入自己的日志中,但一般只是后台记录日志而已,不能及时通知系统管理员或监控管理员。为了能够及时发现应用的故障,需要通过通用代理,将应用产生的日志信息及时送到事件控制台,使管理员可以在一个统一的窗口中了解应用的运行情况。
通过通用代理实现应用日志监控,还需要考虑一下情况:
通用代理支持秒级为单位的灵活的采样周期;支持不同的语言包和字符集;对多条记录的逻辑判断,比如将5条相同属性组的记录合为一条,或是通过特定的分隔符模式来动态的判断多条记录的逻辑关系。
支持动态文件名的监控:在指定被监控的文件名时,可以使用通配符,如:
{########}.abc 文件名为8位数字,扩张名是abc的文件
{########}.* 忽略扩张名,文件名是8位数字中最大的文件
PS{###}FTP.txt 以PS开始、FTP结束、中间3位数字最大,扩张名是txt的文件
或是以日期格式指定的文件。如
{YYYYMMDD}.log 20070930.log 或是20071015.log
{MMDDYY}.log 101105.log 或是110105.log
对于监控的内容,通过代理可以设定关键字匹配等方式(告警条件)监控日志文件,当有写入新的记录并符合告警条件时,通用代理会在控制台中显示告警,并将相应的记录转到事件管理平台中。
对于应用日志的监控,使监控应用故障问题的最直接的方法,除此以外,应用程序运行所依赖的硬件设备、网络环境和数据库等中间件的监控,也是判断应用故障的有效手段,并需要同时采用,综合分析故障原因。
应用性能监控管理
对于应用性能监控管理,我们所关心的是:
Ø 这个交易成功了么?
Ø 如果交易失败,是什么原因导致的呢?
Ø 用了多少时间,用户才得到反馈?
Ø 如果交易中包含子交易(例如调用其他交易),那么这个子交易用了多少时间呢?
Ø 在整个过程中,哪个地方是瓶颈?
Ø 每一类交易都被执行了多少次?
Ø 如何配置我们的应用和环境参数,才能得到更好的服务效果?
在此领域,主要采用基于国际标准的ARM(ApplicationResponseMeasurement)接口,实现应用性能监控管理方法。
ARM(应用程序响应评测)API是一系列标准“应用程序编程接口”(API)调用,它使进行集中的应用程序性能评测。一些知名的IT 公司已经就这些调用达成一致。
API旨在允许评测任何应用程序的性能。应用程序监视能力最可能用于评测响应时间。然而,分析同一个应用程序事件或进程的一系列时间调整,也可以用于构建应用程序可用性记录和应用程序用法记录。
图 ARM工作原理
要评测应用程序的响应时间,必须根据ARMAPI标准检测该应用程序。这意味着必须将 ARM API 调用嵌入应用程序代码。
编译和链接应用程序所需的ARM库文件和include 文件是在产品安装过程中自动提供的。
ARMAPIV2可用于确定应用程序性能差的原因,也可用于报告其可用性。还可能传递关于到 ARM 2 API 的字节数的信息。此信息可在图中用来显示不同大小的交易的长度。
使用ARM调用实现应用响应时间监控:
此方法的好处在于,可将开始和停止响应时间时钟的调用,准确地放置在要评测的应用程序部件中。在程序中定义单独的应用程序和交易(事务),并将ARMAPI调用放置在交易(事务)开始和交易(事务)结束处。
图 ARM交易示例
对于B/S结构的应用来讲,如果是基于业界的中间件(WebSphere、WebLogic等)的J2EE应用,由于这些业界中间直接支持ARM标准,在其上开发的应用可以不需要任何修改,通过专用的工具软件,即可进行响应时间的监控。对于C/S结构的应用,如果没有考虑未来应用性能的监控,则需要对源代码进行修改,主要是在需要监控性能的应用交易(事务)代码前后添加ARM调用,然后通过专用软件工具进行监控。
有两种基本方法可用来捕捉最终用户对交易的看法:1)主动监控,使用模拟交易的记录和播放来监控和测量性能;2)被动监控,监控实际最终用户流量的性能。
主动监控。顾名思义,主动监控包括主动执行业务交易来检查性能和可用性。通过软件工具可以记录基于web和Windows 的交易,然后从整个企业、DMZ 或互联网上的不同端点播放这些记录的脚本。记录过程包括逐步完成整个业务流程(例如购书、检查银行余额、运行SAP查询),就象最终用户执行该任务一样。业务流程的模拟脚本一般由多个交易或步骤组成。然后,这个记录的交易将会捕捉为脚本,部署到根据设定播放脚本及报告性能和可用性的客户端。例如,如果脚本每十分钟播放一次,它们就能为关键业务交易的性能问题提供优秀的早期报警系统,而且如果交易没有完成,它们也能用于将可用性问题告知操作人员。在生产中使用由开发小组(通常最了解应用逻辑)编写的测试脚本,而且新脚本可以利用现有的技能编写。
被动监控:被动监控测量实际最终用户执行交易时的响应时间。被动监控显示的是实际最终用户的响应时间,而不是有效监控情形中的模拟用户。但是,由于被动监控报告单个用户请求,因此不能象模拟交易那样在上下文中了解整个业务流程的响应时间。例如,购书过程的每个步骤(注册登录、搜索目录、将选定书籍放进购物车、结帐退出等)将报告一个单独交易。软件工具产品通过web交易服务质量 监控程序和 Application Response Measurement (ARM) 检测支持被动监控。
QoS:QoS监控程序允许测量实际客户体验到的响应时间,而不必在他们的桌面上安装代码。QoS为基于web 的交易提供了三个关键度量。第一个度量是后端处理时间,即Web 基础架构响应 Web 页请求所用的时间。第二个度量是浏览器呈现时间,即该页从第一个到最后一个像素在客户浏览器中呈现所用的时长。第三个度量是总体往返时间,即从开始到完成所需的时间。