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

• 業務交易優化

• 快照調優

• 閾值調優

• 層級管理

• 上下文信息捕獲

1.業務交易優化

本文章系列里，我會不斷重復強調的就是監控方案里的業務交易優化一環。要最有效地利用業務交易監控，您需要做到以下幾項：

• 恰當地命名業務交易以配合您的業務功能

• 正確識別您的業務交易

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

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

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

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

• 根據有效負載的制定業務交易功能

•  根據 GET 參數制定業務交易功能

•  復雜的 URL 路徑

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

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

2. 快照調優

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

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

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

3. 閾值調優

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

根據業務事務對比基準線的估算值，AppDynamics 定義了三種閾值：

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

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

• 靜態 SLA: 比較業務事務的響應時間和靜態值，比如2秒

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

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

4. 分層調優

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

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

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

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

5. 獲取上下文信息

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

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

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

• HTTP GET 請求發送的參數

• 被調用方法的參數

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

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

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

• AppDynamics 發現了一個運行緩慢的業務事務

• 于是 AppDynamics 開始創建一個快照

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

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

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

結束語

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

• 業務事務優化

• 快照調優

• 閥值調優

• 服務層次管理

• 獲取上下文信息

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