本系列文章涵蓋許多基礎性內(nèi)容：它給出了應用程序性能管理（APM）的總體概述；指明了實現(xiàn)一個 APM 策略的主要挑戰(zhàn)；提出了衡量，評估一個企業(yè)級 Node.js 應用程序運行狀況的最重要的 5 條指標；并提出了通過 AppDynamics 方式構(gòu)建一個 APM 解決方案。在文章的***部分，還提出了一些提示和技巧類以幫助您實現(xiàn)***的 APM 策略。具體地說，本文討論了以下主題：

• 業(yè)務交易優(yōu)化

• 快照調(diào)優(yōu)

• 閾值調(diào)優(yōu)

• 層級管理

• 上下文信息捕獲

1.業(yè)務交易優(yōu)化

本文章系列里，我會不斷重復強調(diào)的就是監(jiān)控方案里的業(yè)務交易優(yōu)化一環(huán)。要最有效地利用業(yè)務交易監(jiān)控，您需要做到以下幾項：

• 恰當?shù)孛麡I(yè)務交易以配合您的業(yè)務功能

• 正確識別您的業(yè)務交易

• 通過排除您并不關心的業(yè)務交易來降低噪音

AppDynamics 可以為您自動識別業(yè)務交易，并且盡可能給出***的命名。不過這樣取決于您的應用是如何編寫的，應用名可能可以如實反映業(yè)務交易，也可能不可以。例如，您可 能有一個業(yè)務交易叫做“POST/payment”，對應著檢驗流程。那么如果將其命名為“Checkout”的話，就更能如實反映業(yè)務功能，這將更利于 操作人員操作，也便與生成報表與執(zhí)行人員查看。

下面，如果您有多個業(yè)務交易，卻只有一個入口的話，你需要花一些時間將其分割為獨立的業(yè)務單元。以下幾個可能發(fā)生的例子，包含如下特點：

•  多個 URL 都路由到相同的 MVC 控制器和動作

• 根據(jù)有效負載的制定業(yè)務交易功能

•  根據(jù) GET 參數(shù)制定業(yè)務交易功能

•  復雜的 URL 路徑

如果一個入口卻對應著多個業(yè)務功能，那么就需要根據(jù)不同的指標配置業(yè)務交易。例如，如果 body 里有一個”operation“元素對應著”operation“操作的話，那么就需要根據(jù)”operaiton“對交易進行分割。又如果有一 個”execute“動作接受一個”command“URL 參數(shù)，那么就需要根據(jù)”command“字段對交易進行分割。***，URL 模式可能會因應用不同而不同，所以您需要與您的應用最匹配的形式。例如，AppDynamics 會根據(jù)兩段式自動為您的 URL 定義業(yè)務交易，例如 one/two。大多數(shù) Node.js MVC 框架都會自動路由到對應的應用控制器和動作。如果您的應用使用的是一段式，或者四段式，那么您需要根據(jù)命名規(guī)則來定義業(yè)務交易。

命名和識別業(yè)務交易單元可以確保您捕捉到了正確的業(yè)務功能，但是盡可能多的減噪也同樣重要。您是否有些并不關心的業(yè)務交易呢？比如，會不會有一個網(wǎng) 頁游戲會每隔幾秒就檢查對高分呢？又或者如果有一個每晚都執(zhí)行的 Node.js 的 CLI 作業(yè)，每次都執(zhí)行很長時間，但是由于脫機運行，它并不影響終端用戶，您不關心么？ 如果是的話，排除這些交易，以便減少分析噪音。

2. 快照調(diào)優(yōu)

正如在前面文章提到的，AppDynamics 每隔一段時間就會智能捕獲性能快照，并可以逐漸縮小每次性能會話里快照的個數(shù)。由于這兩個值都是可以調(diào)整的，所以有利于調(diào)優(yōu)。

AppDynamics 直接捕獲整個進程的調(diào)用關系圖，同時去掉配置閾值以下的記錄。如果你只對“大的”性能問題感興趣，那么你可能不需要精確到 10 毫秒以下。如果你把間隔時間增加到 50 毫秒，你會丟失粒度。如果你想微調(diào)應用程序，你可能需要 10 毫秒的粒度，但是如果你不打算讓方法在 50 毫秒內(nèi)執(zhí)行完畢，為什么需要那種級別的粒度呢？問題在于你應該分析需求然后做相應的調(diào)整。

接下來，觀察你的產(chǎn)品故障排除模式，然后判斷 AppDynamics 捕獲的進程快照數(shù)在你當前狀況下是否合適。如果你發(fā)現(xiàn)每分鐘捕獲 2 個快照太多了，那么你可以配置 AppDynamics 來調(diào)整快照間隔。嘗試配置 AppDynamics 讓其每分鐘最多捕獲一個快照。另外如果你只對系統(tǒng)性問題感興趣，你可以把***快照數(shù)降低至 5 個。這會顯著地減少持續(xù)的消耗，但代價是可能會導致捕捉不到有代表性的快照。

3. 閾值調(diào)優(yōu)

AppDynamics 設計了一套通用的監(jiān)控解決方案，并且對于比正常情況慢兩個標準差的業(yè)務事務提供警告。這在大多數(shù)情況下是有效的，但是你需要知道你的應用程序響應時間有多不穩(wěn)定，以便確定這對你的業(yè)務需求來說是否為***配置。

根據(jù)業(yè)務事務對比基準線的估算值，AppDynamics 定義了三種閾值：

• 標準差: 比較業(yè)務事務的響應時間與基準線的幾個標準差

• 百分比: 比較業(yè)務事務的響應時間與基準線的差值百分比

• 靜態(tài) SLA: 比較業(yè)務事務的響應時間和靜態(tài)值，比如2秒

如果您的應用程序的響應時間不穩(wěn)定,那么默認的兩個標準差臨界值可能導致太多的錯誤警報。在這種情況下，您可能希望增加更多的標準差或換一種方式來 處理。如果您的應用程序的響應時間比較穩(wěn)定，你就會想減少你的臨界值提前發(fā)出警告。此外，如果你有提供給特殊協(xié)定用戶的服務或 API（應用程序接口），你應該為此業(yè)務設置一個穩(wěn)定的協(xié)定值。AppDynamics（應用性能管理）會提供給你個人或企業(yè)業(yè)務定義警報規(guī)則的靈活性。

你需要分析你的應用程序的行為，并相應地配置報警引擎。

4. 分層調(diào)優(yōu)

在前面我已經(jīng)提到過，AppDynamics 不僅能夠捕獲業(yè)務事務性能的基準，同時它也能捕獲一個業(yè)務事務在不同服務層上的性能基準。打個比方，如果你的業(yè)務事務調(diào)用了一個規(guī)則引擎提供的服務，那么 AppDynamics將正確捕獲你的業(yè)務事務對規(guī)則引擎部分的調(diào)用數(shù)以及規(guī)則引擎的平均響應時間，并且將會把這些數(shù)據(jù)正確反映到業(yè)務事務的性能基準中。 正是因為 AppDynamics 的這個特性，因此在你的整個系統(tǒng)中***能夠清晰定義所有的服務層，這樣你可以得到一個非常清晰而且優(yōu)秀的業(yè)務事務性能基準。

如果你沒有明確指定系統(tǒng)的服務層次，那么AppDynamics將根據(jù)一定的規(guī)則（不同的協(xié)議棧）自動分析你的應用的服務層次。比如，它將自動把你 的應用分解成 HTTP 服務層，JMS 服務層，JDBC 服務層。舉一個具體的例子，如果 AppDynamics 發(fā)現(xiàn)你的代碼中有一個對 Database 的操作，那么它就會假設你的整個業(yè)務邏輯中存在一個數(shù)據(jù)庫訪問層，因此它就會自動計算你的業(yè)務邏輯用在數(shù)據(jù)庫訪問上的時間。這個對于調(diào)優(yōu)你的業(yè)務邏輯是非 常重要的，因為你不希望在性能基準中只是看到一個信息說你的 ORM class 中的 save 方法執(zhí)行的非常慢，相反的你希望能夠看到更具體的信息，比如說 save 方法花了多少時間把數(shù)據(jù)存儲到數(shù)據(jù)庫中，又花了多少時間執(zhí)行其他的任務。

如果在你的系統(tǒng)中，所有的 service 調(diào)用都使用的是通用協(xié)議棧（比如 HTTP 協(xié)議）， 那么 AppDynamics 將非常***的分析出你的系統(tǒng)的服務層次，但是如果你的系統(tǒng)使用了一個非通用協(xié)議棧和后端系統(tǒng)進行通信，AppDynamics 就無能為力了。舉例來說，目前我在一個保險公司工作，這個保險公司使用一個 AS/400 機器提供詢價服務。在我們的系統(tǒng)中，我們使用了一個私有庫來和 AS/400 通訊，這個庫使用了一個私有的基于 socket 的通訊協(xié)議鏈接到 AS/400 上。在這種情況下，很明顯 AppDynamics 不可能知道系統(tǒng)使用了基于 socket 的通訊協(xié)議，也不可能知道這 個socket 通訊協(xié)議是如何工作的。因此，我們需要告訴 AppDynamics 是哪個方法實現(xiàn)了和 AS/400 之間的通訊，并且標記這個方法為定制化的后端資源。這樣一來，AppDynamics 就會將這個方法識別成一個新的服務層次，接下來 AppDynamics 就可以對這個新的服務層次進行調(diào)用計數(shù)，并計算它的平均響應時間了。

在大部分情況下，你可以使用 AppDynamics 的內(nèi)置功能來分析系統(tǒng)的服務層次，但是如果你有特定的要求，AppDynamics 也提供了 Node.js API，讓你自己定義系統(tǒng)的服務層次。

5. 獲取上下文信息

但性能問題發(fā)生的時候，有時候問題只發(fā)生在某個瀏覽器或者移動設備上，有時候只發(fā)生在客戶端發(fā)送了特定的請求內(nèi)容。在這種情況下，由于問題并不總是能夠重現(xiàn)，那么我們怎么來定位這些問題呢？

答案就是在創(chuàng)建快照的時候，同時獲得上下文信息。你可以通過查看上下文信息，看來發(fā)現(xiàn)一些共性。需要捕獲上下文信息可能有以下這些：

• HTTP 請求頭信息，比如瀏覽器類型（user-agent ），cookies 和 referrer

• HTTP GET 請求發(fā)送的參數(shù)

• 被調(diào)用方法的參數(shù)

• 應用中定義的變量以及變量的值

我們下面就舉一些例子來說明對于一個性能不好的 Node.js 事務，你將如何應用上面說的這些上下文信息來查找和發(fā)現(xiàn)問題。比如，如果你捕獲了 User-Agent HTTP 請求頭信息，那么你就可以知道用戶是在哪個瀏覽器上執(zhí)行商業(yè)事務。如果你提供的 HTTP 服務支持 GET 方法，那么你可能想通過檢查Query String 里面某個或者多個變量的值來知道用戶想查詢什么內(nèi)容。再進一步，如果你知道應用的代碼是如何工作，你可能就想知道一個具體參數(shù)的值。

你可以通過配置讓 AppDynamics 獲取上下文信息并且加入到快照中，可以被捕獲的上下文信息在上一節(jié)中已經(jīng)詳細介紹了。下面我們簡單的介紹一下 AppDynamics 獲取上下文信息的過程：

• AppDynamics 發(fā)現(xiàn)了一個運行緩慢的業(yè)務事務

• 于是 AppDynamics 開始創(chuàng)建一個快照

• 在創(chuàng)建快照的過程中，AppDynamics 根據(jù)你配置的信息，獲取相應的上下文信息并放入快照中

結(jié)果就是當你找到一個可以反映你試圖解決的問題的快照的時候，你可以在 AppDynamics 為你捕獲的上下文信息中查看是否有有用的信息。

當你使用上下文信息捕獲功能的時候，因為 AppDynamics 使用侵入式代碼來獲取方法的參數(shù)值，這將造成原始代碼運行效率有一些下降。因此，只在確實需要的地方使用這個功能。

結(jié)束語

應用性能管理的難處在于它需要在獲取盡量少的數(shù)據(jù)的情況下，能夠讓開發(fā)人員分析出導致性能瓶頸的真正原因。 對于一個 APM 工具，都應該能夠提供一系列的配置選項，以便開發(fā)人員可以在應用程序執(zhí)行過程中，以盡量小的代價獲得足夠的性能分析數(shù)據(jù)。 這篇文章主要介紹了一下這些在 實現(xiàn) APM 策略的時候需要思考的核心點，這些核心點包括：

• 業(yè)務事務優(yōu)化

• 快照調(diào)優(yōu)

• 閥值調(diào)優(yōu)

• 服務層次管理

• 獲取上下文信息

實現(xiàn)一個 APM 系統(tǒng)是非常困難的，但是象 AppDynamics 這樣的系統(tǒng)就極大的簡化了 APM 的實現(xiàn)。通過使用 AppDynamics， 開發(fā)人員可以很方便的在應用中實現(xiàn) APM，而不會對應用本身造成很大的影響（ APM 代碼的引入也是會造成一定的性能下降的）。