《JAVA基础-Java系统运行时性能和可用性监控.docx》由会员分享，可在线阅读，更多相关《JAVA基础-Java系统运行时性能和可用性监控.docx（4页珍藏版）》请在金锄头文库上搜索。
1、 JAVA基础:Java系统运行时性能和可用性监控当今的很多 Java 应用程序都依靠于一组简单的分布式依靠关系和移动部件。许多外部因素都可能对应用程序的性能和可用性造成影响。这些影响根本上都无法完全消退或解决，且难以在预生成环境中精确模拟。Stuff happens。但是，您可以创立并维护一个全面的系统来监控应用程序的整个生态系统，从而显着降低这些大事的严峻性和持续时间。本系列文章给出了实现此类系统的一些模式和技巧。模式，以及我将使用的一些术语，都表示泛指。通过结合例如代码和插图，它们将帮忙您理解应用程序性能监控的概念。这种理解强调解决方案的必要性，并能帮忙您选择商业或开源的解决方案。您可以
2、扩展和定制一个解决方案，或者依据需要将其作为设计解决方案的蓝图。第 1 局部：探究应用程序性能治理（APM）系统的属性描述系统监控的常见反面模式列举监控 JVM 性能的方法供应有效插装应用程序源代码的方法第 2 局部将重点介绍插装 Java 类及资源而无需修改原始源代码的方法。第 3 局部将论述监控 JVM 外部资源的方法，包括主机及其操作系统以及数据库和消息传递系统等远程效劳。它还将总结并归纳其他的 APM 问题，如数据治理、数据虚拟化、报告和报警。APM 系统：模式和反面模式为让大家正确入门，应当强调，虽然此处介绍的多数与 Java 相关的内容看上去与应用程序和代码性能分析的流程类似，但其
3、实并非 如此。性能分析是一个极具价值的生产前流程，它可以确认您的 Java 代码是否可扩展、高效、快速和足够精彩。但是，依据 stuff happens 公理，当您在生产中遇到无法说明的问题时，优秀的开发阶段代码性能分析可能无用武之地。我的意思是，在生产中实现性能分析的一些方面，并从运行中的应用程序收集一些一样的实时数据及其全部外部依靠关系。该数据由一系列普及目标的定量测量指标组成，它们为整个系统的安康状况供应细粒度和具体的表示。此外，通过保存这些指标的历史库，您可以捕获精确的基线，以帮忙您确认环境仍旧安康，或查明特定缺陷的根源和规模。监控反面模式完全没有监控资源的应用程序微乎其微，但仍旧需要
4、考虑这些反面模式，它们常常消失在运行环境中：盲点：某些系统依靠关系未受监控，或者监控数据不行访问。运行中的数据库可以掩盖全部监控范围，但假如受支持的网络无法全面掩盖，则诊断小组在分析数据库性能和应用效劳器病症时将无法看到网络中的故障。黑盒：核心应用程序或者它的某个依靠关系对于其内部可能不具有监控透亮性。JVM 是一个不折不扣的黑盒。举例来说，诊断小组正在调查 JVM 中的莫名延时问题，并且只拥有支持操作系统的统计数据（如 CPU 利用率和进程需要的内存大小），则他们可能无法诊断垃圾收集或线程同步问题。脱节和断开的监控系统：应用程序可以由大型共享数据中心托管，其中，依靠关系由一系列共享资源组成，
5、比方说数据库、存储区网络（SAN）库、消息传递及中间件效劳。组织有时高度孤立，各小组只负责治理自己的监控和 APM 系统没有各依靠关系的整合视图，各组件全部者只能管中窥豹，只见一斑。图 1 比照了孤立和整合的 APM 系统：图 1. 孤立和整合 APM 系统的比照事后报告和相关性：为尝试解决孤立监控的问题，运营支持小组可以运行定期进程猎取各来源的数据，将这些数据整合到一个地方，然后再生成汇总报表。这种方法有时效率低下且不切实际，由于它需要根据指定频率严格执行，而缺乏实时数据也会对诊断小组当场发觉问题的力量产生负面影响。此外，事后聚合有时缺乏足够的粒度，从而导致重要模式隐蔽在数据中不被觉察。举例
6、来说，某个报告可能显示某特定效劳调用昨天平均耗时 200 毫秒，但却隐蔽了它在下午 1:00 到 1:45 间平均耗时 3500 毫秒。定期或随需应变的监控：由于某些工具强制占用较高的资源开销，因此不能（或不应）常常使用它们。结果，它们很少收集数据，或者只在检测到问题后才收集数据。因此，APM 系统只能执行最低基线，而无法在问题恶化前提前报警，并且可能会自己加剧势态的严峻性。非长久化监控：很多工具都供应了有用的性能和可用性指标实时显示功能，但它们并不支持长久化指标供长期或短期比拟和分析的功能。常见的一种状况是，假如缺少历下文，则性能指标将毫无价值，由于没有推断指标优劣的基准。举例来说，当前的
7、CPU 利用率是 45%。假如不知道历史利用率的状况，则不好推断当前 CPU 利用率负荷的轻重程度。但是，假如知道历史的典型值为百分之 x，可承受的用户性能上限是百分之 y，则状况就大有改观了。对生产前模型的依靠：假设全部潜在问题都可在生产部署之前从环境中去除，则完全依靠生产前监控和系统模型的实践常常会导致运行时监控不够全面。这些假设无法解决不行猜测大事和依靠性故障，因此，诊断小组在遇到此类大事时将没有工具和数据可用。整合 APM 的实现并不排解监控和诊断工具，如 DBA 治理工具集、低级网络分析应用程序和数据中心治理解决方案。这些工具仍旧是无价的资源，但假如它们依靠于整合视图的专有性，则难以克制孤立效果的影响。
