干貨|單類型監控、業務交易與基礎資源聚合監控的技術方法解析

一、概述

隨著現代信息系統越來越龐大，機器數量呈現指數級增長，信息系統運維對平臺化服務能力要求越來越高，建立有效的監控體系準確及時發現系統運行中出現的問題，對于保障應用系統穩定運行具有重要意義。為提升生產問題感知及響應能力，通常會配置各種類型的監控，本文從單類型監控、業務交易之間聚合監控、業務交易與基礎資源聚合監控等方面介紹監控常用技術方法，供讀者進行參考學習。

二、單類型監控

單類型監控是指使用單一類型技術進行應用系統監控，常用的監控方法包括Ajax請求報文響應報文監控、業務日志監控、頁面內容監控、業務數據監控、基礎資源監控。

方面對幾種監控類型詳細介紹：

1、Ajax監控：通過第三方監控平臺定時發送業務交易請求，并對響應報文進行斷言的方法驗證交易的正確性。

方法1：http狀態碼監控。對http請求的狀態碼進行判斷，是否符合預期結果，各類http狀態碼含義如下，我們僅需要配置狀態碼斷言即可判斷交易是否正常。

示例：

Request URL:https://msg.csdn.net/v1/web/message/view/unread

Request Method:POST

Status Code:200

方法2：http響應報文監控。http狀態碼監控可以監控交易報文是否正常響應，但是無法判斷交易邏輯是否正常，對http報文響應報文具體內容進行監控，可以彌補該問題。通過判斷http響應報文中具體字段的值對交易進行監控。

示例：ajax響應報文中包含如下信息，則可以對message字段的值進行監控。

message:"success"

status:true

適用場景：適用于對http協議響應報文、響應碼進行監控。

2、日志監控：日志監控是對應用系統運行過程中產生的日志進行監控。以log4j為例，日志級別包括ALL、TRACE、DEBUG、INFO、WARN、ERROR、FATAL、OFF，其中ALL是打印所有日志，OFF是所有日志都不打印，為了排查系統運行問題，通常開發人員根據需要會打點一定的日志，但是如果loglevel配置的太低，則會打印過多的日志信息，從而影響系統性能。

日志監控通常可以基于ERROR、FATAL類日志打印進行監控。開發人員在業務邏輯中進行相應的判斷，并打印錯誤日志，例如：Log.error(“123456”);監控平臺可以抓取系統中打印的錯誤日志，并基于正則表達式判斷是否符合異常告警條件。符合告警規則，則進行郵件、短信等告警。

日志告警可以精準獲取異常告警的代碼位置，從而便于進行問題分析。

適用場景：適用于系統開發人員在代碼的關鍵邏輯中打點了日志信息時使用。

3、網頁監控：對于DOC類型的請求，可以通過發送請求報文，對響應頁面html內容設置監控，判斷響應頁面內容是否包含指定的內容，網頁內容監控是指監控網頁標題、網頁關鍵詞、網頁描述、出站鏈接等內容信息進行監控。

使用方式：通過提取網頁內容做為監控的對象，對比與上一次監測記錄的變化情況，例如：。

頁面監控配置流程：

適用場景：具有前端頁面的系統可以采用該方法進行頁面內容監控。

4、數據監控：通過定時執行數據庫sql腳本或者數據分析，驗證具有關聯性的表是否出現不受控制的異常數據記錄，數據內容監控可以發現業務邏輯異常造成的數據問題，并及時提供給運營人員進行后續處理，以應對數據不一致對用戶產生的影響。

數據監控分類如下：

數據監控配置流程：

適用場景：對于熟悉數據表邏輯關系及不同表中字段之間邏輯關系時可以使用該方法。

5、資源監控：對于CPU、內存、硬盤等基礎資源的監控，并設置閾值，對于分機房類應用系統，可以按照機房分別配置資源監控，可以及時發現底層資源故障，提示系統運維人員及時進行資源擴容或者問題排查，具體重要的意義。

通常當CPU、內存利用率超過80%時，系統性能將逐步出現瓶頸，從而會嚴重影響用戶使用體現，因此可以設置CPU、內存等使用率超過80%時進行告警；對于數據庫服務，可以對數據庫的連接數、表空間、系統日志等信息進行監控；對于磁盤、網絡設置可以監控IO速率的參數以發現相關問題。

但基礎資源監控無法具體判斷具體是哪些業務造成的資源問題，以及對哪些業務造成的影響比較大，結合其他監控方法可以達到更好的效果。

幾種監控方法對比：

適用場景：對于依賴的底層資源的服務可以采用這種監控方法。

三、聚合類型監控

1、交易調用鏈路聚合監控

對于系統之間調用較為復雜的業務場景，僅僅通過單系統的監控難以具體定位到故障節點。交易接口之間聚合監控是指對已經建立的具有調用關系的接口監控項建立綁定關系，從而根據調用鏈路上各個節點的執行結果判斷業務系統群的可用性情況及故障節點。

如下圖所示，A系統的一個業務交易trans1,調用B系統的交易和C系統的交易，B系統又會調用D系統交易。在這種場景下，僅僅對A系統業務交易進行監控，發生告警后，無法準備判斷A、B、C、D 4個系統中哪個系統發生了故障，造成業務交易無法執行成功，需要開發人員根據交易鏈條逐個判斷分析，大大增加了系統問題分析的難度。

使用交易調用鏈路聚合監控方法，拿A系統trans1交易這個場景來說，對A、B、C、D 4個系統分別配置監控案例mA、mB、mC、mD，并建立鏈路綁定關系（mA->mB、mB->mD、mB->mC）。這樣在系統發生告警后，可以根據A、B、C、D 4個系統監控交易執行情況，迅速找到故障節點。

A系統Trans1交易監控案例綁定關系：

優勢：能夠快速找到故障節點，降低故障分析復雜程度。因為交易監控之間建立了綁定關系:mA->mB->mD、mB->mC，當mA、mB、mC、mD4個監控項按照一定頻率執行時并獲取到對應的執行結果后，可以根據根據交易之間的綁定關系判斷故障節點。例如：

某時間節點：mD執行成功，mB執行失敗，mA執行失敗，可以判斷是由于mB交易執行失敗造成mA執行失敗，從而提升問題處置效率。

缺點：配置復雜程度高，需要清楚交易調用鏈路，并分別配置監控案例，并建立綁定關系。

適用場景：對于交易鏈路比較復雜，難以判斷問題故障具體出在什么位置的情況下建議增加使用該方法監控。

2.業務監控與資源監控聚合

隨著信息系統復雜程度和可靠性要求的不斷提高，信息系統的部署架構也越來越復雜。信息系統的部署會采用多地區多機房的部署方式，從而根據用戶所在區域訪問不同的后臺服務，以提升系統響應能力。業務監控與資源監控聚合是指將業務交易監控與資源級監控建立綁定關系，并根據各個監控項的執行結果進行聚合分析，從而判斷系統故障節點的監控方法。

業務交易的可用性與基礎資源是緊耦合的關系，基礎資源的故障或性能瓶頸會嚴重影響業務交易的運行。通過業務交易監控無法準備定位到具體哪些基礎資源故障引起。例如業務交易訪問失敗，可能是因為服務器停機、機器無法正常響應請求等問題造成。具體哪個資源故障造成業務交易無法正常執行卻無法判斷。

通過將業務交易監控和基礎資源監控進行綁定聚合可以有效解決該問題。例如我們的業務系統已經配置了業務監控m1、tomcat服務器監控m2、數據庫服務器監控m3三個監控配置，通過建立監控項m1、m2、m3的綁定關系（如下圖所示），當發生基礎資源造成的業務交易報錯后，可以迅速找到問題原因以進行問題響應。

適用場景：對于業務交易依賴底層資源，底層資源故障會造成部分業務交易報錯的情況下可以使用該種監控方法。

四、總結

本文首先介紹了幾種單應用系統環境監控方法及主要技術，包括ajax請求響應報文監控，日志監控、基礎資源監控、業務數據監控、頁面內容監控、高級腳本監控，并分析了這幾種技術的主要使用場景，之后對業務交易聚合監控、業務交易與基礎資源監控方法進行了介紹，希望給測試人員、應用環境運維人員、監控平臺建設者提供一定的參考，提升信息系統運維服務能力。

最后：在我的V：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。