- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
应用软件运行状况全掌握
在业务数据和业务处理逐步集中,信息化日益普及的大背景下,软件系统的大型化和复杂化是必然趋势,这就对软件系统的可用性提出了更高的要求。一般而言,软件系统的高可用性是由软件的各项技术指标综合决定的,如软件系统的稳定性、安全性、可维护性、系统性能等。系统实现了高稳定性、高可维护性、高安全性、高性能,即可以取得高的系统可用性。从应用角度来说,提高这些技术指标的方法可以分为两大类,一是在问题出现前预警,二是在问题出现后有高效的解决手段,通俗地说就是及早发现和快速解决。
如何为运维人员提供充足、及时的预警,如何为运维人员跟踪解决问题提供有力的支持呢?孙子说“知彼知己者,百战不殆”,现代军事领域也有一个论断是:“发现即被消灭”,说的都是侦察手段的重要性,如果战争一方的行动完全被对方掌握,那他被消灭就是很容易的事情。同样在应用程序运行维护过程中,如果应用软件系统的各种运行状态、各个模块、各个函数、甚至每个数据的变化都是可知的、可跟踪、甚至可预测的,也就是说这些信息完全被运维人员所掌握,那么系统正常运行就易于得到保障,即使出现问题解决起来也将不是很难的事情。
本文将应用软件在运行过程中以多种方式、多层次、多角度将自身运行情况呈现给用户的能力称为应用软件系统的可视性(applicationvisibility);相应地,具有良好可视性的应用系统称为可视化应用系统(visualapplication)。
应用软件的管理难题
全面掌握应用系统的运行状况对应用软件管理员而言非常重要,因为这可以提前发现隐患,一旦出现故障也能及时找到问题之所在。然而,做到这一点并不容易,其中面临着应用程序监控和系统运维过程的不确定性等诸多难题。
1.应用系统监控之难
与操作系统、中间件等基础性软件相比,应用程序的监控要困难得多。比如,中国人寿目前已经建立起来比较完善的基础平台监控机制,通过整合利用基础平台提供的各种监控接口,统一到监控平台上,形成一个完整的基础平台运行视图,并增加各种管理功能,取得了很好的效果。其之所以成功,一个很重要的因素是各种基础平台,包括硬件、操作系统、数据库、中间件等都是成熟的通用平台产品,这些产品自身都包含了丰富的运行监控接口(可称之为具有良好的可视性),管理者或使用者所做的就是利用和挖掘这些功能,并根据自己的应用特点进行针对性的整合,以统一友好的界面展现给管理人员。
而应用监控虽然也取得了一些非常好的效果,但相比系统监控效果还是有不小的差距,最根本的原因在于应用系统自身没有提供足够的、有效的关于自身运行的详细信息,也就说应用软件自身不具有很好的软件可视性。仅从应用程序消耗的公共资源来判断应用运行情况具有很大的局限性,如跟踪Tuxedo服务队列可以判断某个应用功能的排队情况,但不能很好地给出进一步的信息。就好像一台高档中央空调,仅仅能够监控它的电压、电流、温度这些通用指标是没法很好满足监控需要的,要想知道空调运行情况还需要很多指标以反映其内部部件的运行情况。应用程序监控的另一思路是对应用日志的监控,但很多情况下应用程序日志也不能满足监控要求,需要反过来在源程序中增加针对性的日志输出。另外,不同应用系统源程序的结构差异使得增加理想日志信息的工作量和风险都具有不确定性,而且这种打补丁的方式缺乏规划和统一管理。这种状况其实是反映了程序原有的可视性不能很好满足应用监控的要求。
2.系统运维过程的不确定性
目前由于主要应用系统运行文档、运维文档不够完善,系统运维过程中查看源程序仍是最重要的问题定位、问题分析手段。系统运行中出现问题时,界面上和日志文件中的报错信息是问题定位的切入点,如果报错信息、日志记录比较明确、比较完整,运维人员就比较容易跟踪到出错前程序的运行轨迹,继而根据程序上下文逻辑判断出现问题的根本原因;反之如果日志记录不明确、不完整。例如,在程序流程跟踪过程中某个关键变量的值变化没有记录下来,运维人员判断和解决起来就困难得多,虽然看得见却摸不着,这时候问题的解决就需要依靠运维人员的经验想办法进行问题重现,有时甚至要修改源程序加入调试信息并模拟运行。这种情况下运维的效率很大程度上依赖程序日志的详细程度,依赖运维人员经验的积累,这就导致整体上应用软件的问题定位效率具有不确定性,直接后果是系统高可用性无法得到保证。
分析其原因,一是目前主要应用系统提供的日志很多是软件在开发过程中加入的调试信息,并不能称为软件系统的运行日志;二是日志侧重于记录出错现场的异常信息,不注重正常运行信息,而在实际生产环境中,那些在测试环境中从来不出现异常的地方还是会出现异常。
如果解决了目前应用软件系统的日志不全面的问题是不是就可以适应将来的需要,尤其是大集中系统的需要呢?笔者认为仍然不能满足。按目前的模式,在源程序中加入全覆盖的日志,将对
原创力文档


文档评论(0)