存储 频道

Tivoli实战:应用故障和性能监控管理

对于IT运行维护管理工作来讲,应用的监控是业务部门经常提出的需求,是业务部门迫切要求需要解决的问题,但对于应用的监控管理,却涉及多个方面,并依据业务的复杂性而具有多样性。通常,应用的监控涉及两个层面:应用故障监控和应用性能监控。

    应用故障监控

    针对应用的性能管理,一般通过对应用日志监控实现。此种监控管理方法,依赖于应用设计和编程时,考虑到未来应用监控的需要,在应用出现故障时,将故障信息写入应用日志中。不过,即使应用程序可以将故障信息写入自己的日志中,但一般只是后台记录日志而已,不能及时通知系统管理员或监控管理员。为了能够及时发现应用的故障,需要通过通用代理,将应用产生的日志信息及时送到事件控制台,使管理员可以在一个统一的窗口中了解应用的运行情况。

    通过通用代理实现应用日志监控,还需要考虑一下情况:

    通用代理支持秒级为单位的灵活的采样周期;支持不同的语言包和字符集;对多条记录的逻辑判断,比如将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 页请求所用的时间。第二个度量是浏览器呈现时间,即该页从第一个到最后一个像素在客户浏览器中呈现所用的时长。第三个度量是总体往返时间,即从开始到完成所需的时间。

0
相关文章