高效能監控關鍵要素與分析方法

– 16 分鐘閱讀

傳統的靜態門檻值監控方式在面對動態的系統環境時效果有限，需要更智慧化的技術分析資料視窗而非單一時間點。同時，提高監控頻率和保留足夠的歷史資料對於快速識別故障、滿足使用者對回應時間的期望以及有效診斷問題至關重要。自動化監控，包含佈署管理、儀表化和資料視覺化，能有效提升監控效率。一個良好的監控系統需要全面的狀態監控，並融入開發與佈署流程。監控技術的核心機制包含探測和內省兩種方式，混合使用能提供更全面的系統可視性。監控系統的運作模式則分為提取和推播兩種，各有優劣，需根據實際需求選擇。

高效能監控的關鍵要素

現代IT系統的監控工作面臨諸多挑戰，無效或不適當的監控策略可能導致關鍵問題被忽視。根據知名資料函式庫效能分析廠商VividCortex的觀察，傳統的門檻值監控方式如同壞掉的鐘表，雖然看似運作但實際上毫無參考價值。

監控常見問題與解決方案

傳統監控方式存在多項缺陷，包括：

  1. 靜態門檻值的侷限性

    • 不同系統特性各異，靜態門檻無法適應動態環境
    • 系統負載隨時間變化，固定門檻難以發揮作用
    • 需採用智慧化技術分析資料視窗而非單一時間點

  2. 監控頻率不足

    • 多數監控工具預設檢查週期過長（5至15分鐘）
    • 關鍵事件可能發生在檢查間隔期間而未被捕捉
    • 需提高監控頻率以滿足以下需求：
      • 快速識別故障與異常
      • 符合使用者對回應時間的期望
      • 提供足夠細粒度資料以分析效能問題與趨勢

  3. 歷史資料儲存不足

    • 需保留足夠歷史資料（通常為數天至數週）
    • 才能有效識別趨勢與週期性問題
    • 資料保留不足將導致問題診斷困難

自動化監控的重要性

許多監控實施失敗的原因在於其複雜性和缺乏自動化。為提升監控效率，應實作以下自動化措施：

  1. 佈署管理自動化

    • 使用組態管理工具進行佈署管理
    • 透過自動發現或自助服務提交組態主機和服務

  2. 儀表化簡化

    • 提供可插拔的工具模式簡化應用程式的儀表化過程
    • 開發人員可輕鬆整合相關函式庫

  3. 資料視覺化自助服務

    • 允許使用者自行查詢和視覺化監控輸出
    • 雖然仍需建立預設儀錶板，但使用者應可自定義查詢

良好監控的定義

有效的監控系統應具備以下特性：

  1. 全面的狀態監控

    • 從業務層面到底層基礎設施的全方位監控
    • 協助故障診斷
    • 為不同角色提供所需資訊

  2. 融入開發與佈署流程

    • 將監控納入應用程式開發和佈署生命週期
    • 盡可能實作自動化和自助服務

監控技術的核心機制

監控技術主要分為兩大類別：探測（Probing）和內省（Introspection）。

探測監控

  • 關注應用程式的外部特性
  • 檢查應用程式是否對特定埠作出回應
  • 範例：使用ICMP檢查網路連通性
  • 工具範例：Nagios

內省監控

  • 關注應用程式內部狀態
  • 需要對應用程式進行儀表化以收集內部運作資訊
  • 可提供更豐富、更具上下文的狀態資訊
  • 通常透過事件、紀錄檔和指標等方式輸出監控資料

混合監控策略的最佳實踐

雖然內省監控能提供更詳盡的內部資訊，但探測監控仍有其價值，特別是在評估第三方應用程式或檢測網路層面的問題時。因此，建議採用混合策略：

  1. 使用內省監控作為主要診斷工具
  2. 以探測監控作為安全網，用於捕捉外部可見的問題

這種雙重監控策略能夠提供更全面的系統可視性，有助於及時發現和解決潛在問題。透過結合兩種監控方式的優勢，能夠更有效地維護系統穩定性和效能。

監控系統的核心：提取與推播模式

監控系統的運作方式主要分為兩種：提取（Pull）與推播（Push）。這兩種模式各有其優缺點，並且在不同的應用場景下有不同的適用性。

提取模式

在提取模式下，監控系統會主動向被監控的應用程式或服務傳送請求，以取得相關的指標資料或狀態資訊。例如，使用ICMP協定對目標主機進行探測，或是抓取應用程式暴露的指標端點。這種模式的優點在於監控系統可以控制資料收集的頻率和內容，但缺點是可能會增加網路負擔，並且在某些情況下可能會錯過瞬時事件。

推播模式

與提取模式相反，推播模式是由被監控的應用程式或服務主動向監控系統推播事件或指標資料。這種模式的優點是可以即時反映事件的發生，並且可以減少監控系統對網路的輪詢壓力。然而，其缺點是需要被監控端具備推播能力，並且可能會增加被監控端的負擔。

Prometheus是一種主要的提取式監控系統，但同時也支援透過閘道器接收推播事件。這使得Prometheus能夠靈活地適應不同的監控需求。

監控資料的型別

監控工具可以收集多種型別的資料，主要包括：

  • 指標（Metrics）：指標是最常見的監控資料型別，用於記錄應用程式或系統的狀態和效能。它們通常以時間序列的形式儲存，具有時間戳和數值。
  • 日誌（Logs）：日誌是應用程式輸出的事件記錄，通常用於故障診斷和問題調查。雖然本文主要關注指標，但市面上有許多工具（如ELK堆積疊）可用於收集和管理日誌事件。

指標詳解

指標是監控架構中最為關鍵的部分。它們提供了對系統和應用程式狀態的動態、實時檢視，有助於管理和決策。正確地利用指標，可以實作異常檢測和模式分析，甚至在問題發生前進行預警。

指標是用於衡量軟體或硬體屬性的測量值。為了使指標有用，我們會隨著時間記錄其狀態，這些記錄稱為觀測值。一個觀測值包括數值、時間戳，有時還包括描述觀測值的屬性，如來源或標籤。這些觀測值的集合稱為時間序列。

時間序列資料

時間序列資料是以時間順序排列的觀測值列表。選擇合適的粒度（或解析度）對於記錄指標至關重要。過粗的粒度可能導致細節遺漏，而過細的粒度則可能導致資料儲存和解釋的困難。

graph LR
    A[開始收集指標] --> B[選擇合適的粒度]
    B --> C[收集觀測值]
    C --> D[儲存時間序列資料]
    D --> E[視覺化資料]

此圖示展示了時間序列資料的收集和處理流程。

指標的視覺化

時間序列指標通常透過二維圖表進行視覺化，y軸表示資料值，x軸表示時間。這種視覺化方式能夠提供對關鍵資料的直觀理解，並且能夠顯示歷史變化趨勢，有助於理解環境中發生的變化。

內容解密：
  1. 監控模式選擇：根據實際需求選擇提取或推播模式。例如，若需要即時監控某個服務的狀態，可以使用推播模式；若需要定期檢查系統效能，則提取模式可能更為合適。
  2. 指標的重要性：指標提供了對系統狀態的動態檢視，是實作異常檢測和預警的基礎。
  3. 時間序列資料處理：選擇合適的粒度對於有效利用時間序列資料至關重要。
  4. 視覺化的作用：透過視覺化，可以直觀地理解系統狀態和歷史變化趨勢，從而更好地進行管理和決策。

監控系統中的度量指標型別與分析方法

在監控系統和應用程式的維運過程中，度量指標（Metrics）扮演著至關重要的角色。度量指標能夠幫助我們瞭解系統的執行狀態、效能瓶頸以及業務營運情況。本文將探討常見的度量指標型別及其分析方法。

度量指標型別

1. 計量表（Gauges）

計量表是一種用於表示某個特定測量值的瞬時狀態的指標。它們通常代表某個可以隨時間變化而增減的數值，例如：

  • 系統資源使用率：CPU 使用率、記憶體使用率、磁碟使用率等。
  • 即時業務資料：網站當前線上人數、即時交易額等。

計量表提供了一個快照，讓我們能夠瞭解系統在某一時刻的狀態。

2. 計數器（Counters）

計數器是一種只會增加不會減少的指標，雖然它們不會減少，但可能會重置為零後重新開始累積。常見的計數器包括：

  • 系統執行時間。
  • 網路裝置傳送和接收的位元組數。
  • 使用者登入次數。
  • 業務資料：每月銷售額、訂單數量等。

計數器的價值在於能夠計算變化率，透過觀察單位時間內的變化，可以得出諸如每秒登入次數等有價值的資訊，幫助識別系統或業務的活躍程度。

3. 頻次分佈圖（Histograms）

頻次分佈圖是一種對觀察資料進行抽樣並計算其頻次分佈的指標。它透過將資料分組（稱為“分箱”），並以視覺化的方式呈現各組的大小，從而展示資料的分佈情況。頻次分佈圖通常以柱狀圖的形式展示，能夠直觀地反映資料的分佈特徵。

例如，在衡量應用程式延遲（latency）的時候，頻次分佈圖能夠有效地展示不同延遲範圍內的請求數量，從而幫助我們瞭解系統的效能特徵。

度量指標匯總分析

單一的度量指標往往難以提供足夠的資訊，因此需要對指標進行匯總分析。常見的匯總方法包括：

  • 計數（Count）：統計特定時間間隔內的觀察次數。
  • 總和（Sum）：對特定時間間隔內的資料進行求和。
  • 平均值（Average）：計算特定時間間隔內資料的平均值。
  • 中位數（Median）：找出資料的中間值，有一半的資料小於它，另一半大於它。
  • 百分位數（Percentiles）：衡量某一百分比以下的觀察值。
  • 標準差（Standard Deviation）：衡量資料分佈的離散程度。
  • 變化率（Rates of Change）：展示資料在時間序列上的變化程度。

這些匯總方法能夠幫助我們更好地理解資料背後的意義，例如，透過計算平均延遲和延遲的標準差，可以評估系統的穩定性和效能。

多指標聚合分析

除了對單一指標進行匯總分析外，將多個來源的指標進行聚合分析也非常重要。這種方法能夠幫助我們從整體上把握系統或業務的執行狀況。例如，將所有應用伺服器的磁碟使用率進行聚合，可以更容易地發現整體趨勢，如負載平衡器的間歇性故障可能導致多台伺服器的流量下降。

平均值的陷阱：為什麼平均值會誤導我們

在網路營運的世界裡，許多公司的生存與死亡取決於其網站或API的平均回應時間。平均值之所以吸引人，是因為它們很容易計算。假設我們有一組七個時間序列的值：12、22、15、3、7、94和39。要計算平均值，我們將這些值的總和除以列表中的值的數量。

(12 + 22 + 15 + 3 + 7 + 94 + 39) / 7 = 27.428571428571

首先，我們將七個值相加，得到總計192。然後，我們將總和除以值的數量（這裡是7），得到平均值：27.428571428571。看起來很簡單，對吧？但問題在於細節。

平均值的假設

平均值假設存在一個正常的事件，或者你的資料呈現正態分佈（或高斯分佈）。例如，在我們的平均回應時間中，假設所有事件都以相同的速度執行，或者回應時間分佈大致呈鐘形曲線。但在實際應用中，情況很少如此。事實上，有一個古老的統計學笑話：一個統計學家跳入一個平均深度只有10英寸的湖裡，差點淹死…

為什麼平均值會誤導我們

這個統計學家差點淹死的原因是，湖裡有大片的淺水區和一些深水區。由於淺水區面積較大，平均深度較低。在監控領域，同樣的原理也適用：我們的平均值中的許多低值會扭曲或隱藏高值，反之亦然。這些隱藏的異常值可能意味著，雖然我們認為大多數使用者正在體驗優質服務，但實際上有相當一部分使用者並非如此。

讓我們來看一個使用回應時間和網站請求的例子。

回應時間的平均值

在這裡，我們有一個顯示多個請求的回應時間的圖表。計算平均回應時間將給我們4.1秒。大多數使用者可能會體驗到（可能）健康的4.1秒回應時間。但是，許多使用者的回應時間長達12秒，這可能被認為是較差的體驗。

讓我們再來看另一個具有更廣泛值分佈的例子。

更廣泛的回應時間分佈

在這裡，我們的平均值將是一個較差的6.8秒。但是，更糟糕的是，這個平均值比大多數使用者經驗到的回應時間要好得多，因為請求時間的分佈在9、10和11秒左右。如果我們僅僅依靠平均值，我們可能會認為我們的應用程式表現比實際上要好得多。

中位數：一個可能的解決方案

此時，你可能會想知道使用中位數。中位數是我們的值的中間位置：恰好有50%的值低於它，50%的值高於它。如果值的數量是奇數，那麼中位數就是中間的值。對於我們的第一個資料集——12、22、15、3、7、94和39——中位數是15。如果值的數量是偶數，中位數將是中間兩個值的平均值。因此，如果我們從資料集中刪除39，使其成為偶數，中位數將變為13.5。

讓我們將其應用於我們的兩個圖表。

回應時間的平均值和中位數

在第一個示例圖中，我們看到中位數是3，這提供了一個更加樂觀的資料圖景。

在第二個示例中，中位數是8，比平均值稍微好一些，但仍然不夠有效。

你可能已經看出來了，這裡的問題再次出現，就像平均值一樣，中位數在資料呈鐘形曲線時效果最佳… 而在現實世界中，這並不現實。

標準差：衡量資料分佈

正如我們在本章前面所學到的，標準差衡量資料集中的變異或分佈。標準差為0意味著大多數資料接近平均值。更高的標準差意味著資料更加分散。標準差用帶有sigma符號的正數或負數表示——例如，1 sigma是距離平均值的一個標準差。

標準差的侷限性

然而，就像平均值和中位數一樣，標準差在資料呈正態分佈時效果最佳。在正態分佈中，有一個簡單的方法來描述分佈：經驗法則，也稱為68-95-99.7規則或三sigma規則。在這個規則中，一個標準差（1到-1）代表了平均值兩側68.27%的所有交易，兩個標準差（2到-2）代表了95.45%，三個標準差代表了99.73%。

許多監控方法利用經驗法則，並觸發距離平均值超過兩個標準差的交易或事件，從而可能捕捉到效能異常值。然而，在像我們之前的兩個例子中，標準差並不是非常有幫助。沒有正態分佈的資料，得到的標準差可能會具有很大的誤導性。

百分位數：一個更好的選擇

百分位數衡量一組觀察值中落在某一百分比以下的值。本質上，它們關注的是資料集中的值的分佈。例如，我們上面看過的中位數就是第50百分位數（或p50）。在中位數中，50%的值低於它，50%的值高於它。對於指標來說，百分位數非常有意義，因為它們使值的分佈易於理解。例如，某個交易的第99百分位數值為10毫秒，很容易解釋：99%的交易在10毫秒或更短的時間內完成，1%的交易花費了超過10毫秒的時間。

百分位數的優勢

百分位數非常適合識別異常值。如果在你的網站上，回應時間少於10毫秒被視為良好的體驗，那麼第99百分位數告訴你，99%的使用者正在體驗良好的體驗——但1%的使用者並非如此。一旦你意識到這一點，你就可以專注於解決導致那1%使用者問題的效能問題。

讓我們將其應用於我們之前的請求和回應時間圖表，看看會發生什麼。我們將對第一個示例資料集應用兩個百分位數：第75百分位數和第99百分位數。

此圖示展示了從請求到評估效能的流程，使用不同的統計方法來評估回應時間。

百分位數如何幫助我們

透過使用百分位數，我們可以更好地理解資料的分佈，並識別出可能被平均值或中位數隱藏的異常值。這使我們能夠更準確地評估應用程式的效能，並針對特定的問題進行最佳化。

效能監控與百分位數分析的重要性

在現代的軟體開發和維運中，效能監控是一項至關重要的任務。為了更準確地瞭解系統的效能，我們需要藉助多種監控方法和指標。本文將重點介紹百分位數分析以及兩種重要的監控方法論：Brendan Gregg 的 USE 方法和 Google 的 Four Golden Signals。

百分位數分析的實際應用

百分位數分析是一種統計方法，用於瞭解資料的分佈情況。在效能監控中，百分位數可以用來衡量請求回應時間的分佈。例如，第 75 百分位數（p75）代表 75% 的請求回應時間小於或等於該值，而第 99 百分位數（p99）則代表 99% 的請求回應時間小於或等於該值。

圖表分析

根據圖 1.14 和圖 1.15 的資料，我們可以看到兩個不同的資料集在請求回應時間上的差異。圖 1.14 中，p75 為 5.5 秒，p99 為 10.74 秒，這意味著 99% 的使用者請求在 10.74 秒內完成，而 1% 的使用者請求則超過了這個時間。圖 1.15 中，p75 為 10 秒，p99 為 12 秒，這表明該系統的請求回應時間分佈更為集中，但仍有部分使用者經歷了較長的等待時間。

程式碼範例與解析

import numpy as np

# 模擬請求回應時間資料
response_times = np.random.exponential(scale=5, size=1000)

# 計算百分位數
p75 = np.percentile(response_times, 75)
p99 = np.percentile(response_times, 99)

print(f"第 75 百分位數：{p75:.2f} 秒")
print(f"第 99 百分位數：{p99:.2f} 秒")

#### 內容解密：
# 使用 NumPy 的 random.exponential 函式生成符合指數分佈的請求回應時間資料。
# np.percentile 用於計算指定百分位數的值。
# 輸出 p75 和 p99 的值，以瞭解請求回應時間的分佈情況。

監控方法論

USE 方法

USE 方法由 Brendan Gregg 提出，專注於主機層級的監控。它建議對每個資源檢查三個方面：利用率（Utilization）、飽和度（Saturation）和錯誤率（Errors）。這種方法有助於快速識別系統中的效能瓶頸。

Four Golden Signals

Google 的 Four Golden Signals 方法則關注應用層級的監控，提出了四個關鍵指標：延遲（Latency）、流量（Traffic）、錯誤率（Errors）和飽和度（Saturation）。這些指標提供了對應用程式效能的全面瞭解，有助於及時發現和解決問題。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 高效能監控關鍵要素與分析方法

package "資料視覺化流程" {
    package "資料準備" {
        component [資料載入] as load
        component [資料清洗] as clean
        component [資料轉換] as transform
    }

    package "圖表類型" {
        component [折線圖 Line] as line
        component [長條圖 Bar] as bar
        component [散佈圖 Scatter] as scatter
        component [熱力圖 Heatmap] as heatmap
    }

    package "美化輸出" {
        component [樣式設定] as style
        component [標籤註解] as label
        component [匯出儲存] as export
    }
}

load --> clean --> transform
transform --> line
transform --> bar
transform --> scatter
transform --> heatmap
line --> style --> export
bar --> label --> export

note right of scatter
  探索變數關係
  發現異常值
end note

@enduml

此圖示說明瞭監控流程，從開始監控到收集指標、分析百分位數，再到應用不同的監控方法論，最終實作系統的調優和改進。

監控系統的黃金訊號與通知策略

在現代化的IT基礎設施中，監控系統扮演著至關重要的角色。一個有效的監控系統不僅能夠及時發現問題，還能幫助團隊快速診斷和解決問題，從而減少系統停機時間，提升使用者經驗。在本章中，我們將探討監控系統中的黃金訊號（Golden Signals）、如何設計有效的通知策略，以及視覺化資料的重要性。

黃金訊號：監控的基礎

黃金訊號是一種簡單而有效的監控框架，主要包括四個關鍵指標：延遲（Latency）、流量（Traffic）、錯誤（Errors）和飽和度（Saturation）。這些指標能夠幫助團隊快速瞭解系統的健康狀態和效能瓶頸。

  • 延遲：請求處理時間，過高的延遲可能指示系統效能問題。
  • 流量：系統的負載情況，高流量可能導致系統資源耗盡。
  • 錯誤：錯誤率，過高的錯誤率可能指示系統存在缺陷或組態問題。
  • 飽和度：系統資源的使用情況，過高的飽和度可能導致系統當機。

透過監控這些黃金訊號，團隊可以及時發現問題並採取相應的措施。

設計有效的通知策略

通知是監控系統輸出的主要形式，但設計一個有效的通知系統並非易事。一個好的通知系統需要考慮以下幾個方面：

  • 通知的內容：通知應該包含足夠的上下文資訊，以便接收者能夠快速理解問題的性質和嚴重程度。
  • 通知的物件：根據問題的性質和嚴重程度，通知應該傳送給適當的人員或團隊。
  • 通知的方式：根據接收者的偏好和緊急程度，選擇合適的通知方式，如電子郵件、簡訊或工單系統。
  • 通知的頻率：避免過於頻繁的通知，以免造成通知疲勞。
  • 通知的停止或升級：根據問題的解決情況，適時停止通知或將問題升級給更高階別的人員。

以下是一個典型的Nagios通知範例：

Nagios 通知範例

PROBLEM Host: server.example.com
Service: Disk Space
State is now: WARNING for 0d 0h 2m 4s (was: WARNING) after 3/3 checks
Notification sent at: Thu Aug 7th 03:36:42 UTC 2015 (notification number 1)
Additional info:
DISK WARNING - free space: /data 678912 MB (9% inode=99%)

這個通知告訴我們server.example.com上的/data磁碟空間已經使用了91%，但是它沒有提供足夠的上下文資訊，例如磁碟空間的使用率是如何變化的，是否需要立即採取行動等。

視覺化資料

視覺化是分析和解釋資料的一種強大工具。透過視覺化，團隊可以快速瞭解系統的狀態和趨勢。然而，視覺化也可能導致誤解，例如將相關性誤認為因果關係。

在設計視覺化時，我們應該遵循以下原則：

  • 清晰展示資料：視覺化應該清晰地展示資料，避免不必要的裝飾。
  • 引導觀眾思考實質內容：視覺化應該引導觀眾思考資料的含義，而不是被視覺效果所幹擾。
  • 避免扭曲資料：視覺化不應該扭曲或誤導資料。
  • 使大型資料集具有一致性：視覺化應該能夠處理大型資料集，並保持一致性。
  • 允許改變粒度而不影響理解：視覺化應該允許使用者改變資料的粒度，而不會影響對資料的理解。

Edward Tufte的《The Visual Display of Quantitative Information》一書對視覺化設計有著深入的探討，值得一讀。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。