軟體監控與觀察性實踐

– 14 分鐘閱讀

在現今複雜的軟體環境中，僅仰賴傳統的監控方式已不足以應付瞬息萬變的系統狀態。我們需要更深入地瞭解系統內部的運作機制，才能有效地預防和解決問題。因此，可觀察性應運而生，它提供更全面的系統洞察力，協助我們掌握軟體行為的脈絡。本文將探討監控和可觀察性的重要性，並提供實踐，協助開發者建構更可靠、高效能的系統。

傳統監控著重於系統的外部表徵，例如 CPU 使用率、記憶體用量等。然而，這些指標只能反映系統的表面狀態，無法揭示內部運作的細節。可觀察性則更進一步，透過收集和分析系統產生的日誌、指標和追蹤資料，讓我們深入瞭解系統內部的行為和狀態。

import psutil
import time

def monitor_cpu_usage():
    """監控 CPU 使用率並記錄日誌。"""
    while True:
        cpu_percent = psutil.cpu_percent(interval=1)
        timestamp = time.strftime("%Y-%m-%d %H:%M:%S")
        log_message = f"{timestamp} - CPU 使用率：{cpu_percent}%"
        print(log_message)  # 可替換為寫入日誌檔案

        # 根據 CPU 使用率觸發警示或其他操作
        if cpu_percent > 80:
            print("警告：CPU 使用率過高！")

        time.sleep(5)  # 每 5 秒監控一次

if __name__ == "__main__":
    monitor_cpu_usage()

內容解密：

這段 Python 程式碼示範瞭如何使用 psutil 函式庫監控 CPU 使用率，並將監控結果記錄到日誌中。程式碼的核心邏輯在 monitor_cpu_usage 函式內，它會持續監控 CPU 使用率，並將時間戳記和 CPU 使用率百分比記錄下來。當 CPU 使用率超過 80% 時，程式碼會印出警告訊息，提醒開發者注意系統負載。

  graph LR
    A[開始] --> B{取得 CPU 使用率};
    B -- CPU 使用率 > 80% --> C[發出警告];
    B -- CPU 使用率 <= 80% --> D[記錄日誌];
    C --> D;
    D --> E[等待 5 秒];
    E --> B;

圖表翻譯：

此圖示展現了 CPU 監控程式的流程。程式開始後，會先取得 CPU 使用率。如果使用率超過 80%，則發出警告；反之，則將 CPU 使用率資訊記錄到日誌中。無論 CPU 使用率是否超過閾值，程式都會等待 5 秒後再次執行監控流程，形成一個迴圈。

在 Kubernetes 環境中，監控和可觀察性更加重要。Kubernetes 提供了許多內建的監控工具和 API，可以幫助我們收集和分析系統的指標和日誌。此外，我們還可以整合第三方監控工具，例如 Prometheus 和 Grafana，來建構更全面的監控系統。

選擇合適的監控指標對於有效地監控系統至關重要。常用的指標包括 RED 方法（Requests, Errors, Duration）和 USE 方法（Utilization, Saturation, Errors）。RED 方法適用於服務監控，而 USE 方法適用於資源監控。

package main

import (
	"fmt"
	"net/http"
	"time"
)

func handler(w http.ResponseWriter, r *http.Request) {
    start := time.Now()
    // 模擬服務處理邏輯
    time.Sleep(100 * time.Millisecond)

    duration := time.Since(start)
    fmt.Fprintf(w, "請求處理時間: %s", duration)
}

func main() {
	http.HandleFunc("/", handler)
	http.ListenAndServe(":8080", nil)
}

內容解密：

這段 Go 程式碼示範了一個簡單的 HTTP 伺服器，並計算每個請求的處理時間。handler 函式模擬了服務的處理邏輯，並使用 time.Since(start) 計算請求處理時間。最後，將處理時間回傳給使用者端。

  graph LR
    A[收到請求] --> B{處理請求邏輯};
    B --> C[計算處理時間];
    C --> D[回傳處理時間];

圖表翻譯：

此流程圖描述了 HTTP 伺服器處理請求的流程。伺服器收到請求後，會執行處理請求的邏輯。接著，伺服器會計算處理請求所花費的時間，並將計算結果回傳給使用者端。

除了監控指標外，日誌和追蹤也是可觀察性的重要組成部分。日誌記錄了系統的事件和錯誤訊息，可以幫助我們診斷問題。追蹤則記錄了請求在系統中的完整路徑，可以幫助我們分析系統的效能瓶頸。

總而言之，監控和可觀察性是建構可靠、高效能系統的關鍵。透過選擇合適的監控指標、收集和分析日誌和追蹤資料，我們可以更深入地瞭解系統的行為，並有效地預防和解決問題。

持續佈署（CD）流程最佳化

在使用根據容器的 CD 工具（如 Cloud Build）時，盡量減少每個階段容器的大小至關重要。這是因為當建置過程每天執行數十或數百次時，增加的等待時間會對整體效率產生影響。

例如，如果您使用 Sops 進行機密資料解密（見第 252 頁），官方的 mozilla/sops 容器映像將佔用約 800 MB 的空間。但是，透過多階段建置，您可以將映像大小減少到約 20 MB。由於映像在每次建置時都會被載入，因此減少其大小可以大大節省時間。

最佳化建置過程

為了最佳化建置過程，您可以使用多階段建置來減少容器映像的大小。以下是使用 Dockerfile 建立最小容器映像的範例：

# 使用官方的 sops 映像作為基礎
FROM mozilla/sops:latest

# 安裝必要的套件
RUN apt-get update && apt-get install -y \
    git \
    curl \
    wget

# 設定工作目錄
WORKDIR /app

# 複製檔案到工作目錄
COPY. /app

# 執行 sops 解密
RUN sops -d config.yaml > decrypted_config.yaml

# 建立最小容器映像
FROM scratch

# 複製解密後的檔案到最小容器映像
COPY --from=0 /app/decrypted_config.yaml /app/decrypted_config.yaml

# 設定工作目錄
WORKDIR /app

# 執行應用程式
CMD ["sh", "run.sh"]

適應性和彈性

雖然本文中提到的工具和方法可以與大多數 CD 工具整合，但每個專案都有其特點和需求。因此，沒有通用的方法可以適用於所有情況。在實作 CD 流程時，需要考慮工具的選擇、建置過程的定義以及整體流程的最佳化。

Jenkins、GitLab、Drone、Cloud Build 和 Spinnaker

這些工具都是流行的 CD 解決方案，可以與 Kubernetes 整合。除了這些工具外，還有許多其他選擇，例如 Gitkube、Flux 和 Keel，它們專門設計用於自動化 Kubernetes 的佈署。

定義建置過程

定義建置過程以程式碼的形式，可以使其更容易跟蹤和修改。這樣一來，建置過程就可以與應用程式的原始碼一起管理和版本控制。

什麼是觀察性和監控？

觀察性和監控是兩個相關但不同的概念。在軟體開發和維運中，監控通常指的是對系統或應用程式的效能、可用性和其他指標進行實時或近實時的監測，以便快速回應和解決問題。觀察性則是一個更廣泛的概念，涵蓋了監控、日誌記錄、追蹤和分析等多個方面，旨在提供對系統內部工作原理和行為的更深入的理解。

監控的侷限性

傳統的監控方法主要關注系統的外部行為，例如回應時間、錯誤率等指標。然而，這種方法存在一些侷限性：

  1. 只能發現可預測的問題：傳統監控方法通常只能發現已知的、可預測的問題。
  2. 只能應用於外部可存取的系統：傳統監控方法通常只能應用於外部可存取的系統或元件。
  3. 是被動的：傳統監控方法通常是被動的，需要等待問題出現後才會觸發警示。
  4. 不能解釋為什麼會出現問題：傳統監控方法通常只能告訴你係統出了什麼問題，但不能告訴你為什麼會出現這個問題。

觀察性的重要性

觀察性可以幫助我們更好地理解系統的內部工作原理和行為，從而更好地解決問題和最佳化系統。觀察性的重要性體現在以下幾個方面：

  1. 提供更深入的理解：觀察性可以提供對系統內部工作原理和行為的更深入的理解。
  2. 可以發現不可預測的問題：觀察性可以幫助我們發現不可預測的問題和意外的行為。
  3. 可以解釋為什麼會出現問題：觀察性可以幫助我們瞭解為什麼會出現某個問題，從而更好地解決問題。

觀察性的實踐

觀察性的實踐包括以下幾個方面：

  1. 日誌記錄：收集和分析系統的日誌記錄，可以幫助我們瞭解系統的內部工作原理和行為。
  2. 追蹤：追蹤系統的請求和回應，可以幫助我們瞭解系統的效能和可用性。
  3. 分析：分析系統的資料和日誌記錄，可以幫助我們瞭解系統的內部工作原理和行為。

第15章：可觀察性和監控

軟體的透明度

傳統的監控方式可以提供許多有關系統內部機制的資料，例如CPU負載、磁碟活動、網路封包等。但是，這些資料並不能直接告訴我們軟體究竟在做什麼。為了了解軟體的行為，軟體本身需要提供可觀察的資料。

可觀察性是指系統或軟體提供足夠的資訊，以便開發者和使用者瞭解其行為和狀態。這包括了日誌記錄、計量指標、追蹤等方面。透過這些資訊，開發者可以更好地瞭解軟體的執行情況，從而進行最佳化和故障排除。

建立可觀察性文化

可觀察性不僅是一種技術實踐，也是一種文化。它需要開發者、維運人員和其他利益相關者之間的緊密合作，以確保系統的可觀察性。這包括了共同定義監控指標、建立日誌記錄標準、實作追蹤機制等。

透過建立可觀察性文化，組織可以更好地應對複雜系統的挑戰，提高系統的可靠性和效率。同時，也可以促進開發者和維運人員之間的溝通和合作，從而提高整體的工作效率。

可觀察性流程

可觀察性流程是指收集、處理和分析可觀察性資料的過程。這包括了以下幾個步驟：

  1. 資料收集：從系統中收集日誌記錄、計量指標、追蹤等資料。
  2. 資料處理：對收集到的資料進行處理，包括清洗、轉換、聚合等。
  3. 資料分析：對處理後的資料進行分析，包括統計、視覺化等。
  4. 報告和警告：根據分析結果，生成報告和警告，以便開發者和使用者瞭解系統的狀態。

透過可觀察性流程，開發者可以更好地瞭解系統的行為和狀態，從而進行最佳化和故障排除。

Kubernetes中的監控

Kubernetes是一種容器協調系統，它提供了豐富的監控功能。透過Kubernetes的監控功能，開發者可以更好地瞭解系統的行為和狀態，從而進行最佳化和故障排除。

Kubernetes中的監控包括了以下幾個方面：

  1. 外部檢查：透過外部檢查機制，檢查系統的可用性和回應性。
  2. 內部指標：透過內部指標機制，收集系統的效能資料。
  3. 日誌記錄：透過日誌記錄機制，收集系統的日誌記錄。

透過Kubernetes的監控功能，開發者可以更好地瞭解系統的行為和狀態，從而進行最佳化和故障排除。

根據提供的內容，以下是重寫的技術內容：

監控和觀察性

在雲原生應用中，監控和觀察性是非常重要的。監控可以幫助我們發現問題，而觀察性可以幫助我們瞭解系統的行為。

外部監控

外部監控是指從外部觀察系統的行為。這可以透過監控工具，如 Uptime Robot，來實作。外部監控可以幫助我們發現問題，但它也有侷限性。例如，它不能夠提供系統內部的詳細資訊。

內部檢查

內部檢查是指系統內部的自我檢查。這可以透過程式碼實作，例如，透過檢查系統的健康狀態。內部檢查可以提供更詳細的資訊，但它也需要更多的資源。

指標

指標是資料的集合，用於描述系統的行為。指標可以是數值、計數器或測量器。數值指標用於描述系統的狀態，例如，CPU 使用率。計數器指標用於描述事件的次數，例如，請求次數。測量器指標用於描述系統的效能，例如，回應時間。

時間序列資料

時間序列資料是指隨著時間變化的資料。時間序列資料可以用於分析系統的行為，例如，CPU 使用率的變化。

指標型別

指標可以分為兩類別：計數器和測量器。計數器指標用於描述事件的次數，例如，請求次數。測量器指標用於描述系統的效能，例如，回應時間。

選擇合適的指標

選擇合適的指標非常重要。太多的指標會導致資源浪費，而太少的指標會導致資訊不足。選擇指標時，需要考慮系統的需求和限制。

指標分析

指標分析是指對指標資料進行分析，以瞭解系統的行為。指標分析可以用於發現問題、最佳化系統和進行預測。

觀察性

觀察性是指系統的可觀察性。觀察性包括監控、日誌、指標和追蹤。觀察性可以幫助我們瞭解系統的行為和發現問題。

瞭解監控指標的重要性

在軟體開發和佈署的過程中，監控指標（Metrics）扮演著至關重要的角色。它們能夠提供系統執行狀態、效能和可靠性的寶貴資訊，幫助開發人員和維運人員快速識別和解決問題。監控指標的選擇和使用直接影響到系統的可靠性、效能和安全性。

服務監控：RED模式

對於服務監控，RED模式是一種被廣泛接受的方法。RED是Requests、Errors和Duration的縮寫，分別代表請求數、錯誤率和請求處理時間。這三個指標能夠全面地反映服務的執行狀態和使用者經驗。

  • 請求數（Requests）：監控服務接收到的請求數量，可以反映服務的負載情況。
  • 錯誤率（Errors）：計算請求中出錯的比例，有助於評估服務的可靠性和穩定性。
  • 請求處理時間（Duration）：測量服務處理請求所需的時間，直接影響使用者經驗。

資源監控：USE模式

除了服務監控，資源監控也是非常重要的。USE模式是資源監控的一種方法，分別代表Utilization（資源利用率）、Saturation（資源飽和度）和Errors（錯誤率）。

  • 資源利用率（Utilization）：指資源（如CPU、記憶體、磁碟等）被使用的比例，高利用率可能表明資源不足或瓶頸。
  • **資源飽和度（Saturation）****: 表示資源是否已達到其最大容量或處理能力，飽和的資源可能導致系統效能下降。
  • 錯誤率（Errors）：計算與資源相關的錯誤數量，有助於快速識別資源層面的問題。

監控指標的選擇和實施

選擇合適的監控指標需要根據系統的具體需求和特點。以下是一些最佳實踐：

  • 根據系統特點選擇指標：不同的系統有不同的瓶頸和關注點，需要根據實際情況選擇最相關的指標。
  • 實施自動化監控：使用工具和平臺實施自動化監控，可以快速回應問題並減少人工成本。
  • 設定合理的閾值：為每個指標設定合理的閾值，可以及時發現異常情況並進行介入。

洞悉系統行為：監控與可觀察性

在現代軟體開發中，尤其是在微服務架構和雲原生應用盛行的今日，僅僅依靠傳統的監控方式已經不足以應付日益複雜的系統。我們需要更深入地瞭解系統內部的運作，才能有效地預防、診斷和解決問題。這就是為什麼「可觀察性」的概念越來越受到重視。

監控的進化：從外部到內部

傳統的監控，例如使用 Uptime Robot 等工具，主要關注系統的外部表徵，例如服務是否可用、回應時間是否正常等等。這就好比醫生只觀察病人的外在症狀，卻無法瞭解體內的實際情況。這樣的監控方式只能發現已知的、預期中的問題，對於突發的、未知的問題則束手無策。

為了彌補這個不足，我們需要從系統內部收集更多資訊。內部檢查，例如應用程式自行檢查健康狀態，可以提供更細緻的資料。然而，如何有效地收集、整理和分析這些資料，就成了一個新的挑戰。

資料的語言：指標與時間序列

指標（Metrics）是描述系統行為的關鍵資料。它們可以是數值、計數器或測量器，例如 CPU 使用率、請求次數、回應時間等等。這些指標通常以時間序列的形式呈現，也就是說，它們的值會隨著時間變化。透過分析這些時間序列資料，我們可以洞察系統的趨勢、模式和異常。

指標的選擇至關重要。過多的指標會造成資訊過載，增加分析的難度；而過少的指標則可能遺漏關鍵資訊，導致問題無法被及時發現。選擇指標的原則是「精準有效」，只選擇那些真正能夠反映系統關鍵行為的指標。

RED 與 USE 方法：服務與資源監控的利器

在實務中，我們通常會使用 RED 和 USE 方法來選擇監控指標。RED 方法適用於服務監控，它關注三個關鍵指標：請求數（Requests）、錯誤率（Errors）和請求處理時間（Duration）。透過監控這三個指標，我們可以全面瞭解服務的效能和穩定性。

USE 方法則適用於資源監控，它關注資源利用率（Utilization）、資源飽和度（Saturation）和錯誤率（Errors）。透過監控這三個指標，我們可以及時發現資源瓶頸和潛在風險。

可觀察性：洞悉系統全貌

可觀察性是監控的進階版。它不僅包含監控，還包括日誌、指標和追蹤等多種資料來源。透過整合這些資料，我們可以更全面地瞭解系統的行為，快速定位問題的根源，並進行有效的最佳化。

舉例來說，假設某個服務的回應時間突然變慢，透過傳統的監控，我們只能知道這個現象，卻無法得知原因。而透過可觀察性，我們可以結合日誌、指標和追蹤資料，追溯整個請求的流程，找出造成延遲的瓶頸，例如資料函式庫查詢速度變慢、網路延遲等等。

import time
import random

def simulate_request(duration_mean, error_rate):
    """模擬一個請求，包含處理時間和錯誤率。"""
    duration = random.normalvariate(duration_mean, duration_mean * 0.1)
    error = random.random() < error_rate
    time.sleep(duration)  # 模擬處理時間
    return error

def monitor_service(num_requests, duration_mean, error_rate):
    """監控服務的 RED 指標。"""
    requests = 0
    errors = 0
    total_duration = 0

    for _ in range(num_requests):
        requests += 1
        error = simulate_request(duration_mean, error_rate)
        if error:
            errors += 1
        total_duration += duration_mean

    error_rate = errors / requests if requests > 0 else 0
    avg_duration = total_duration / requests if requests > 0 else 0

    print(f"請求數: {requests}")
    print(f"錯誤率: {error_rate:.2%}")
    print(f"平均處理時間: {avg_duration:.2f} 秒")

# 模擬 100 個請求，平均處理時間 0.5 秒，錯誤率 1%
monitor_service(100, 0.5, 0.01)

內容解密：

這段程式碼模擬了一個服務的 RED 指標監控。simulate_request 函式模擬單個請求，包含處理時間和錯誤率。monitor_service 函式則模擬監控服務，計算 RED 指標並輸出結果。程式碼使用了 random 模組來模擬請求的處理時間和錯誤率，並使用 time.sleep 來模擬請求的處理時間。

  graph LR
    A[開始] --> B{模擬請求};
    B -- 發生錯誤 --> C[記錄錯誤];
    B -- 未發生錯誤 --> D[累計處理時間];
    C --> D;
    D --> E[計算指標];
    E --> F[輸出結果];
    F --> G[結束];

圖表翻譯：

此圖示呈現了服務監控的流程。首先，程式會模擬一個請求。如果請求過程中發生錯誤，則記錄錯誤次數。無論是否發生錯誤，都會累計請求的處理時間。接著，程式會根據收集到的資料計算 RED 指標，包括請求數、錯誤率和平均處理時間。最後，程式將計算結果輸出。

在瞬息萬變的科技世界中，系統監控早已不再是單純的資料收集。從外部監控到內部檢查，從指標分析到可觀察性，我們正逐步走向一個更加透明、可控的系統管理時代。 RED 和 USE 方法為我們提供了實用的監控指標選擇框架，而可觀察性則引領我們更深入地理解系統的行為，預測潛在問題，並最終提升系統的穩定性和效能。對於任何一個致力於構建高可靠性、高效能系統的團隊來說，掌握這些監控和可觀察性的核心概念和實務技巧，都將是至關重要的。

玄貓

玄貓

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