簡(jiǎn)介：
當(dāng)今的許多 Java 應(yīng)用程序都依賴(lài)于一組復(fù)雜的分布式依賴(lài)關(guān)系和移動(dòng)部件。很多外部因素都可能對(duì)應(yīng)用程序的性能和可用性造成影響。這些影響基本上都無(wú)法完全消除或解決，且難以在預(yù)生成環(huán)境中準(zhǔn)確模擬。Stuff happens。但是，您可以創(chuàng)建并維護(hù)一個(gè)全面的系統(tǒng)來(lái)監(jiān)控應(yīng)用程序的整個(gè)生態(tài)系統(tǒng)，從而顯著降低這些事件的嚴(yán)重性和持續(xù)時(shí)間。
本系列文章給出了實(shí)現(xiàn)此類(lèi)系統(tǒng)的一些模式和技巧。模式，以及我將使用的一些術(shù)語(yǔ)，都表示泛指。通過(guò)結(jié)合示例代碼和插圖，它們將幫助您理解應(yīng)用程序性能監(jiān)控的概念。這種理解強(qiáng)調(diào)解決方案的必要性，并能幫助您選擇商業(yè)或開(kāi)源的解決方案。您可以擴(kuò)展和定制一個(gè)解決方案，或者根據(jù)需要將其作為設(shè)計(jì)解決方案的藍(lán)圖。
第 1 部分：
探究應(yīng)用程序性能管理（APM）系統(tǒng)的屬性
描述系統(tǒng)監(jiān)控的常見(jiàn)反面模式
列舉監(jiān)控 JVM 性能的方法
提供有效插裝應(yīng)用程序源代碼的方法
第 2 部分將重點(diǎn)介紹插裝 Java 類(lèi)及資源而無(wú)需修改原始源代碼的方法。第 3 部分將論述監(jiān)控 JVM 外部資源的方法，包括主機(jī)及其操作系統(tǒng)以及數(shù)據(jù)庫(kù)和消息傳遞系統(tǒng)等遠(yuǎn)程服務(wù)。它還將總結(jié)并歸納其他的 APM 問(wèn)題，如數(shù)據(jù)管理、數(shù)據(jù)虛擬化、報(bào)告和報(bào)警。
APM 系統(tǒng)：模式和反面模式
為讓大家正確入門(mén)，應(yīng)當(dāng)強(qiáng)調(diào)，雖然此處介紹的多數(shù)與 Java 相關(guān)的內(nèi)容看上去與應(yīng)用程序和代碼性能分析的流程類(lèi)似，但其實(shí)并非 如此。性能分析是一個(gè)極具價(jià)值的生產(chǎn)前流程，它可以確認(rèn)您的 Java 代碼是否可擴(kuò)展、高效、快速和足夠出色。但是，根據(jù) stuff happens 公理，當(dāng)您在生產(chǎn)中遇到無(wú)法說(shuō)明的問(wèn)題時(shí)，優(yōu)秀的開(kāi)發(fā)階段代碼性能分析可能無(wú)用武之地。
我的意思是，在生產(chǎn)中實(shí)現(xiàn)性能分析的一些方面，并從運(yùn)行中的應(yīng)用程序收集一些相同的實(shí)時(shí)數(shù)據(jù)及其所有外部依賴(lài)關(guān)系。該數(shù)據(jù)由一系列遍及目標(biāo)的定量測(cè)量指標(biāo)組成，它們?yōu)檎麄€(gè)系統(tǒng)的健康狀況提供細(xì)粒度和詳細(xì)的表示。此外，通過(guò)保留這些指標(biāo)的歷史庫(kù)，您可以捕獲準(zhǔn)確的基線(xiàn)，以幫助您確認(rèn)環(huán)境仍然健康，或查明特定缺陷的根源和規(guī)模。
監(jiān)控反面模式
完全沒(méi)有監(jiān)控資源的應(yīng)用程序微乎其微，但仍然需要考慮這些反面模式，它們經(jīng)常出現(xiàn)在運(yùn)行環(huán)境中：
盲點(diǎn)：某些系統(tǒng)依賴(lài)關(guān)系未受監(jiān)控，或者監(jiān)控?cái)?shù)據(jù)不可訪(fǎng)問(wèn)。運(yùn)行中的數(shù)據(jù)庫(kù)可以覆蓋所有監(jiān)控范圍，但如果受支持的網(wǎng)絡(luò)無(wú)法全面覆蓋，則診斷小組在分析數(shù)據(jù)庫(kù)性能和應(yīng)用服務(wù)器癥狀時(shí)將無(wú)法看到網(wǎng)絡(luò)中的故障。
黑盒：核心應(yīng)用程序或者它的某個(gè)依賴(lài)關(guān)系對(duì)于其內(nèi)部可能不具有監(jiān)控透明性。JVM 是一個(gè)不折不扣的黑盒。舉例來(lái)說(shuō)，診斷小組正在調(diào)查 JVM 中的莫名延時(shí)問(wèn)題，并且只擁有支持操作系統(tǒng)的統(tǒng)計(jì)數(shù)據(jù)（如 CPU 利用率和進(jìn)程需要的內(nèi)存大?。?，則他們可能無(wú)法診斷垃圾收集或線(xiàn)程同步問(wèn)題。
脫節(jié)和斷開(kāi)的監(jiān)控系統(tǒng)：應(yīng)用程序可以由大型共享數(shù)據(jù)中心托管，其中，依賴(lài)關(guān)系由一系列共享資源組成，比如說(shuō)數(shù)據(jù)庫(kù)、存儲(chǔ)區(qū)網(wǎng)絡(luò)（SAN）庫(kù)、消息傳遞及中間件服務(wù)。組織有時(shí)高度孤立，各小組只負(fù)責(zé)管理自己的監(jiān)控和 APM 系統(tǒng)沒(méi)有各依賴(lài)關(guān)系的整合視圖，各組件所有者只能管中窺豹，只見(jiàn)一斑。
圖 1 對(duì)比了孤立和整合的 APM 系統(tǒng)：
圖 1. 孤立和整合 APM 系統(tǒng)的對(duì)比
事后報(bào)告和相關(guān)性：為嘗試解決孤立監(jiān)控的問(wèn)題，運(yùn)營(yíng)支持小組可以運(yùn)行定期進(jìn)程獲取各來(lái)源的數(shù)據(jù)，將這些數(shù)據(jù)整合到一個(gè)地方，然后再生成匯總報(bào)表。這種方法有時(shí)效率低下且不切實(shí)際，因?yàn)樗枰凑罩付l率嚴(yán)格執(zhí)行，而缺乏實(shí)時(shí)數(shù)據(jù)也會(huì)對(duì)診斷小組當(dāng)場(chǎng)發(fā)現(xiàn)問(wèn)題的能力產(chǎn)生負(fù)面影響。此外，事后聚合有時(shí)缺乏足夠的粒度，從而導(dǎo)致重要模式隱藏在數(shù)據(jù)中不被發(fā)覺(jué)。舉例來(lái)說(shuō)，某個(gè)報(bào)告可能顯示某特定服務(wù)調(diào)用昨天平均耗時(shí) 200 毫秒，但卻隱藏了它在下午 1:00 到 1:45 間平均耗時(shí) 3500 毫秒。
定期或隨需應(yīng)變的監(jiān)控：由于某些工具強(qiáng)制占用較高的資源開(kāi)銷(xiāo)，因此不能（或不應(yīng)）經(jīng)常使用它們。結(jié)果，它們很少收集數(shù)據(jù)，或者只在檢測(cè)到問(wèn)題后才收集數(shù)據(jù)。因此，APM 系統(tǒng)只能執(zhí)行最低基線(xiàn)，而無(wú)法在問(wèn)題惡化前提前報(bào)警，并且可能會(huì)自己加劇勢(shì)態(tài)的嚴(yán)重性。
非持久化監(jiān)控：許多工具都提供了有用的性能和可用性指標(biāo)實(shí)時(shí)顯示功能，但它們并不支持持久化指標(biāo)供長(zhǎng)期或短期比較和分析的功能。常見(jiàn)的一種情況是，如果缺少歷下文，則性能指標(biāo)將毫無(wú)價(jià)值，因?yàn)闆](méi)有判斷指標(biāo)優(yōu)劣的基準(zhǔn)。舉例來(lái)說(shuō)，當(dāng)前的 CPU 利用率是 45%。如果不知道歷史利用率的情況，則不好判斷當(dāng)前 CPU 利用率負(fù)荷的輕重程度。但是，如果知道歷史的典型值為百分之 x，可接受的用戶(hù)性能上限是百分之 y，則情況就大有改觀(guān)了。
對(duì)生產(chǎn)前模型的依賴(lài)：假設(shè)所有潛在問(wèn)題都可在生產(chǎn)部署之前從環(huán)境中清除，則完全依賴(lài)生產(chǎn)前監(jiān)控和系統(tǒng)模型的實(shí)踐經(jīng)常會(huì)導(dǎo)致運(yùn)行時(shí)監(jiān)控不夠全面。這些假設(shè)無(wú)法解決不可預(yù)測(cè)事件和依賴(lài)性故障，因此，診斷小組在遇到此類(lèi)事件時(shí)將沒(méi)有工具和數(shù)據(jù)可用。
整合 APM 的實(shí)現(xiàn)并不排除監(jiān)控和診斷工具，如 DBA 管理工具集、低級(jí)網(wǎng)絡(luò)分析應(yīng)用程序和數(shù)據(jù)中心管理解決方案。這些工具仍然是無(wú)價(jià)的資源，但如果它們依賴(lài)于整合視圖的專(zhuān)有性，則難以克服孤立效果的影響。
當(dāng)今的許多 Java 應(yīng)用程序都依賴(lài)于一組復(fù)雜的分布式依賴(lài)關(guān)系和移動(dòng)部件。很多外部因素都可能對(duì)應(yīng)用程序的性能和可用性造成影響。這些影響基本上都無(wú)法完全消除或解決，且難以在預(yù)生成環(huán)境中準(zhǔn)確模擬。Stuff happens。但是，您可以創(chuàng)建并維護(hù)一個(gè)全面的系統(tǒng)來(lái)監(jiān)控應(yīng)用程序的整個(gè)生態(tài)系統(tǒng)，從而顯著降低這些事件的嚴(yán)重性和持續(xù)時(shí)間。
本系列文章給出了實(shí)現(xiàn)此類(lèi)系統(tǒng)的一些模式和技巧。模式，以及我將使用的一些術(shù)語(yǔ)，都表示泛指。通過(guò)結(jié)合示例代碼和插圖，它們將幫助您理解應(yīng)用程序性能監(jiān)控的概念。這種理解強(qiáng)調(diào)解決方案的必要性，并能幫助您選擇商業(yè)或開(kāi)源的解決方案。您可以擴(kuò)展和定制一個(gè)解決方案，或者根據(jù)需要將其作為設(shè)計(jì)解決方案的藍(lán)圖。
第 1 部分：
探究應(yīng)用程序性能管理（APM）系統(tǒng)的屬性
描述系統(tǒng)監(jiān)控的常見(jiàn)反面模式
列舉監(jiān)控 JVM 性能的方法
提供有效插裝應(yīng)用程序源代碼的方法
第 2 部分將重點(diǎn)介紹插裝 Java 類(lèi)及資源而無(wú)需修改原始源代碼的方法。第 3 部分將論述監(jiān)控 JVM 外部資源的方法，包括主機(jī)及其操作系統(tǒng)以及數(shù)據(jù)庫(kù)和消息傳遞系統(tǒng)等遠(yuǎn)程服務(wù)。它還將總結(jié)并歸納其他的 APM 問(wèn)題，如數(shù)據(jù)管理、數(shù)據(jù)虛擬化、報(bào)告和報(bào)警。
APM 系統(tǒng)：模式和反面模式
為讓大家正確入門(mén)，應(yīng)當(dāng)強(qiáng)調(diào)，雖然此處介紹的多數(shù)與 Java 相關(guān)的內(nèi)容看上去與應(yīng)用程序和代碼性能分析的流程類(lèi)似，但其實(shí)并非 如此。性能分析是一個(gè)極具價(jià)值的生產(chǎn)前流程，它可以確認(rèn)您的 Java 代碼是否可擴(kuò)展、高效、快速和足夠出色。但是，根據(jù) stuff happens 公理，當(dāng)您在生產(chǎn)中遇到無(wú)法說(shuō)明的問(wèn)題時(shí)，優(yōu)秀的開(kāi)發(fā)階段代碼性能分析可能無(wú)用武之地。
我的意思是，在生產(chǎn)中實(shí)現(xiàn)性能分析的一些方面，并從運(yùn)行中的應(yīng)用程序收集一些相同的實(shí)時(shí)數(shù)據(jù)及其所有外部依賴(lài)關(guān)系。該數(shù)據(jù)由一系列遍及目標(biāo)的定量測(cè)量指標(biāo)組成，它們?yōu)檎麄€(gè)系統(tǒng)的健康狀況提供細(xì)粒度和詳細(xì)的表示。此外，通過(guò)保留這些指標(biāo)的歷史庫(kù)，您可以捕獲準(zhǔn)確的基線(xiàn)，以幫助您確認(rèn)環(huán)境仍然健康，或查明特定缺陷的根源和規(guī)模。
監(jiān)控反面模式
完全沒(méi)有監(jiān)控資源的應(yīng)用程序微乎其微，但仍然需要考慮這些反面模式，它們經(jīng)常出現(xiàn)在運(yùn)行環(huán)境中：
盲點(diǎn)：某些系統(tǒng)依賴(lài)關(guān)系未受監(jiān)控，或者監(jiān)控?cái)?shù)據(jù)不可訪(fǎng)問(wèn)。運(yùn)行中的數(shù)據(jù)庫(kù)可以覆蓋所有監(jiān)控范圍，但如果受支持的網(wǎng)絡(luò)無(wú)法全面覆蓋，則診斷小組在分析數(shù)據(jù)庫(kù)性能和應(yīng)用服務(wù)器癥狀時(shí)將無(wú)法看到網(wǎng)絡(luò)中的故障。
黑盒：核心應(yīng)用程序或者它的某個(gè)依賴(lài)關(guān)系對(duì)于其內(nèi)部可能不具有監(jiān)控透明性。JVM 是一個(gè)不折不扣的黑盒。舉例來(lái)說(shuō)，診斷小組正在調(diào)查 JVM 中的莫名延時(shí)問(wèn)題，并且只擁有支持操作系統(tǒng)的統(tǒng)計(jì)數(shù)據(jù)（如 CPU 利用率和進(jìn)程需要的內(nèi)存大?。?，則他們可能無(wú)法診斷垃圾收集或線(xiàn)程同步問(wèn)題。
脫節(jié)和斷開(kāi)的監(jiān)控系統(tǒng)：應(yīng)用程序可以由大型共享數(shù)據(jù)中心托管，其中，依賴(lài)關(guān)系由一系列共享資源組成，比如說(shuō)數(shù)據(jù)庫(kù)、存儲(chǔ)區(qū)網(wǎng)絡(luò)（SAN）庫(kù)、消息傳遞及中間件服務(wù)。組織有時(shí)高度孤立，各小組只負(fù)責(zé)管理自己的監(jiān)控和 APM 系統(tǒng)沒(méi)有各依賴(lài)關(guān)系的整合視圖，各組件所有者只能管中窺豹，只見(jiàn)一斑。
圖 1 對(duì)比了孤立和整合的 APM 系統(tǒng)：
圖 1. 孤立和整合 APM 系統(tǒng)的對(duì)比
事后報(bào)告和相關(guān)性：為嘗試解決孤立監(jiān)控的問(wèn)題，運(yùn)營(yíng)支持小組可以運(yùn)行定期進(jìn)程獲取各來(lái)源的數(shù)據(jù)，將這些數(shù)據(jù)整合到一個(gè)地方，然后再生成匯總報(bào)表。這種方法有時(shí)效率低下且不切實(shí)際，因?yàn)樗枰凑罩付l率嚴(yán)格執(zhí)行，而缺乏實(shí)時(shí)數(shù)據(jù)也會(huì)對(duì)診斷小組當(dāng)場(chǎng)發(fā)現(xiàn)問(wèn)題的能力產(chǎn)生負(fù)面影響。此外，事后聚合有時(shí)缺乏足夠的粒度，從而導(dǎo)致重要模式隱藏在數(shù)據(jù)中不被發(fā)覺(jué)。舉例來(lái)說(shuō)，某個(gè)報(bào)告可能顯示某特定服務(wù)調(diào)用昨天平均耗時(shí) 200 毫秒，但卻隱藏了它在下午 1:00 到 1:45 間平均耗時(shí) 3500 毫秒。定期或隨需應(yīng)變的監(jiān)控：由于某些工具強(qiáng)制占用較高的資源開(kāi)銷(xiāo)，因此不能（或不應(yīng)）經(jīng)常使用它們。結(jié)果，它們很少收集數(shù)據(jù)，或者只在檢測(cè)到問(wèn)題后才收集數(shù)據(jù)。因此，APM 系統(tǒng)只能執(zhí)行最低基線(xiàn)，而無(wú)法在問(wèn)題惡化前提前報(bào)警，并且可能會(huì)自己加劇勢(shì)態(tài)的嚴(yán)重性。
非持久化監(jiān)控：許多工具都提供了有用的性能和可用性指標(biāo)實(shí)時(shí)顯示功能，但它們并不支持持久化指標(biāo)供長(zhǎng)期或短期比較和分析的功能。常見(jiàn)的一種情況是，如果缺少歷下文，則性能指標(biāo)將毫無(wú)價(jià)值，因?yàn)闆](méi)有判斷指標(biāo)優(yōu)劣的基準(zhǔn)。舉例來(lái)說(shuō)，當(dāng)前的 CPU 利用率是 45%。如果不知道歷史利用率的情況，則不好判斷當(dāng)前 CPU 利用率負(fù)荷的輕重程度。但是，如果知道歷史的典型值為百分之 x，可接受的用戶(hù)性能上限是百分之 y，則情況就大有改觀(guān)了。
對(duì)生產(chǎn)前模型的依賴(lài)：假設(shè)所有潛在問(wèn)題都可在生產(chǎn)部署之前從環(huán)境中清除，則完全依賴(lài)生產(chǎn)前監(jiān)控和系統(tǒng)模型的實(shí)踐經(jīng)常會(huì)導(dǎo)致運(yùn)行時(shí)監(jiān)控不夠全面。這些假設(shè)無(wú)法解決不可預(yù)測(cè)事件和依賴(lài)性故障，因此，診斷小組在遇到此類(lèi)事件時(shí)將沒(méi)有工具和數(shù)據(jù)可用。
整合 APM 的實(shí)現(xiàn)并不排除監(jiān)控和診斷工具，如 DBA 管理工具集、低級(jí)網(wǎng)絡(luò)分析應(yīng)用程序和數(shù)據(jù)中心管理解決方案。這些工具仍然是無(wú)價(jià)的資源，但如果它們依賴(lài)于整合視圖的專(zhuān)有性，則難以克服孤立效果的影響。