复杂环境下的应用性能监控和问题诊断一直以来是企业技术支持部门面临的重大技术挑战。
作为企业运维部门的技术和管理人员,时常面临着来自最终客户或内部业务部门的抱怨:
l 我正在登录你们的网上银行系统,在进行网上支付的页面,点击“确认”,结果系统给我弹回“页面不存在”的提示框。你能帮我查查这笔支付交易成功没有?
l 我正在操作“新建保单”的业务操作,中间需要我录入客户的相关资料,结果等我录入客户资料完成之后,点击“下一步”时,页面一直停留在那没有返回,同时,我发现我的浏览器的页面跳转的图标一直在转动,好像系统死在那儿似的。你能帮我瞧瞧到底是怎么回事呀?
l 你们的网上交易系统做的太烂了,每个页面响应都奇慢无比,你得建议你们的开发团队好好学学别人的做法,真是需要好好改进。
每到这个时候,大家都希望自己能够像那神通广大无所不能的孙大圣,化身为一只小蜜蜂,从用户的电脑开始,沿着其连接的网线,透过光纤,进入数据中心的主机系统,解剖后端业务系统,仔细的查看每一环节的当前状况,全面分析其中的不足和隐患,最终快速诊断出业务故障出现的根本原因,从而及时高效的进行故障处理。这就好比是众多好莱坞大片中的黑客高手,运用高超的专业知识和驯熟技能,有效破解和攻击对方的安全堡垒,但对企业运维部门的技术人员来说,这几乎是不可能完成的任务。
现有应用性能监控和问题诊断工具的不足
传统的应用运维管理软件号称有四大家,包括HP,IBM,CA和BMC等,大家都或多或少提供了性能管理包。大量的性能监控和问题诊断工具,都是局限在各自擅长的领域,有针对服务级别管理的,有针对网络、主机、存储设备监控的,有针对数据库监控的,有针对中间件监控的,也有针对业务应用监控的,但各自的监控除了给出各自领域的当前资源状况和不同的配置项视图之外,很少有全局观,能够站在一个业务系统的视角,整合各类与业务相关的资源视图和层级关联,建立一个资源跟踪线索,从而有效的隔离和分析上下级资源的相关性和因由关系,帮助客户快速的识别或业务代码或资源配置的问题。
正是基于这样的理解,Oracle通过收购、整合不同业务领域的专业厂商和专业技术,同时,通过融入自身在应用、中间件、数据库等多个领域的专业优势,打造了一个端到端的应用性能管理平台。
引入新一代性能管理手段,从用户体验入手,全面打造自上而下的应用性能监控和问题诊断,快速定位问题所在
Oracle的应用性能管理,以响应用户的最佳体验为开始,通过引入应用系统自动建模,同时在不同资源之间进行跨层关联诊断,以业务的视角,打造一个端到端的应用性能监控和问题诊断平台。
l 通过REUI产品,从服务级别管理,从不同业务功能模块的性能分析,从交易漏斗,从页面的加载和显示等性能指标上,确认业务响应时间的合理性,识别性能有问题的页面。
l 通过CAMM产品,自动进行J2EE和SOA应用系统建模,找出不同业务功能模块的最差性能环节。
l 通过AD4J产品,提供操作系统、JAVA虚拟机、JAVA类、数据库等不同层次的资源占用视图,实现从JAVA应用到数据库之间的双向诊断。
基于Oracle的应用性能管理平台,其典型的性能诊断步骤如下:
1. 通过RUEI确认性能不足的特定页面;
2. 点击该页面URL的下钻链接,在CAMM业务模型上识别后端业务逻辑的层次关系,找出最影响业务性能的相关业务模块,相关业务操作,可以层层下钻,直至某个原子的业务操作(譬如JDBC访问数据库,JMS访问消息队列)。
3. 点击该业务操作的下钻链接,在AD4J的不同资源视图上,确认是什么原因导致了该业务操作占用了更多的时间,是由于在数据库上等待数据库解锁,还是内存不足导致某个对象在不断的换入换出,还是由于没有释放导致内存增长厉害等。
一个好消息,随着Oracle Enterprise Manager(企业管理器)11g的在4月份的正式发布,Oracle应用性能管理方案中的CAMM和AD4J已经全部融入到Grid Control这个统一的管理界面上,这很好的简化了业务运维人员对这些工具的使用。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16179196/viewspace-663224/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/16179196/viewspace-663224/