iT邦幫忙

2025 iThome 鐵人賽

DAY 29
0

前言

今天要為我們的系統整合進一點監控的東東。以前不太 care 這些東西,就是日誌、錯誤訊息、監控指標這些,總覺得應該跟自己無關吧,但實際工作後才知道,這些東西真的超級重要,沒有這些資訊 Trouble Shooting 真的是會找到死,有日誌都不一定找得到 bug 了,尤其是那些系統資源所引發的災難,更是需要透過監控來找到問題。

沒有監控的系統就像是黑盒子,永遠不知道系統內部發生了什麼。系統出現問題只能靠用戶投訴或運維手動檢查才能發現,這種被動的運維方式在節奏快速的公司體系中是無法接受的,絕對被幹死。

監控解決了三個核心問題:系統現在的狀態如何、歷史趨勢是怎樣、以及什麼時候需要人工介入。通過數據驅動的方式,我們可以從猜測轉向精確的決策,從被動響應轉向主動預防。

實作:方案與技術決策

監控解決方案有很多種,我先選最簡單 Spring Boot Actuator 跟 Claude 推薦的 Micrometer。

Spring Boot Actuator 是 Spring 官方提供的監控解決方案,與 Spring Boot 生態系統完美整合,無需額外的學習成本和配置複雜度。它提供了開箱即用的健康檢查、指標收集和管理端點功能。

Micrometer 則扮演了指標收集的統一介面角色。它抽象了不同監控系統的差異,讓程式碼與具體的監控後端解耦,代表我們可以輕鬆地在 Prometheus、Grafana、CloudWatch 等不同監控系統之間切換。

我們只需要兩個依賴就能建立一個簡陋的監控體系:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

配置方面同樣保持簡潔,只暴露必要的監控端點:

management:
  endpoints:
    web:
      exposure:
        include: health,prometheus,metrics
  endpoint:
    health:
      show-details: always
  metrics:
    tags:
      application: playground-module
      environment: ${spring.profiles.active:local}

健康檢查

健康檢查是監控的基礎。通過 /actuator/health 端點,我們可以獲得系統各個組件的狀態資訊。這個端點不僅顯示應用本身的狀態,還會檢查所有依賴服務的健康狀況,包括資料庫連線、快取服務、外部 API 等。

健康檢查的設計遵循快速失敗的原則。當任何關鍵依賴出現問題時,整個應用的健康狀態會立即變為 DOWN,這樣負載均衡器和服務發現系統就能及時將流量轉移到健康的實例上。

指標收集

/actuator/metrics 端點提供了應用運行時的詳細指標資訊。這些指標涵蓋了系統的各個層面,從 JVM 運行狀態到應用層面的業務指標。

/actuator/prometheus 端點則將這些指標以 Prometheus 格式輸出,這是業界廣泛採用的監控數據格式標準。通過這個端點,Prometheus 服務器可以定期抓取應用的指標數據,進行長期存儲和分析。

系統層級指標

系統層級指標反映了應用運行的基礎環境狀況。這些指標與具體的業務邏輯無關,但是對於系統的穩定運行至關重要。

JVM 相關指標是 Java 應用監控的重點。記憶體使用情況、垃圾回收頻率和效率、執行緒狀態等指標直接影響應用的性能和穩定性。通過監控這些指標,我們可以及時發現記憶體洩漏、GC 壓力過大、執行緒死鎖等問題。

作業系統指標包括 CPU 使用率、磁碟空間、系統負載等。這些指標幫助我們了解應用對系統資源的消耗情況,為容量規劃和性能優化提供數據支援。

中間件層級

中間件指標反映了應用與外部系統互動的狀況。資料庫連線池指標顯示了資料庫連線的使用效率和潛在瓶頸。Redis 連線指標幫助我們了解快取系統的性能狀況。

HTTP 伺服器指標記錄了所有 HTTP 請求的處理情況,包括請求數量、響應時間、狀態碼分佈等。這些指標是判斷應用服務質量的直接依據。

應用層級

應用層級指標主要包括啟動時間、運行時長、日誌統計等。啟動時間指標對於評估部署效率和系統重啟恢復時間很有價值。日誌統計可以幫助我們快速發現系統異常,特別是錯誤日誌的數量變化。

指標數據

這些監控數據的價值在於它們能夠回答運維和開發人員,系統現在是否正常運行?性能表現如何?資源使用是否合理?是否存在潛在的風險?

通過歷史數據的趨勢分析,我們可以進行容量規劃和性能優化。通過設置適當的告警規則,我們可以在問題影響用戶之前就發現並解決它們。

監控系統驗證

建立監控體系後,需要驗證其有效性。首先確認各個監控端點能夠正常存取,返回預期的數據格式。健康檢查端點應該顯示所有依賴服務的狀態,指標端點應該包含完整的系統和應用指標。

通過實際的系統負載測試,我們可以觀察監控數據的變化,驗證指標收集的準確性和及時性。這個過程也幫助我們建立對正常指標範圍的認知,為後續的異常檢測打下基礎。

監控數據解讀

監控數據的解讀需要結合系統的實際運行情況。例如,JVM 記憶體使用率的上升可能是正常的業務增長,也可能是記憶體洩漏的早期跡象。通過觀察記憶體使用的模式和垃圾回收的效果,我們可以做出準確的判斷。

HTTP 請求指標中的響應時間分佈能夠揭示系統的性能特徵。如果大部分請求的響應時間都在可接受範圍內,只有少數請求特別慢,那可能是某些特定操作的性能問題。

擴展方向

現有監控已具備基本能力,但還有進一步擴展的空間。下一步整合 Prometheus 和 Grafana,建立視覺化的監控儀表板。通過 AlertManager 建立告警系統,實現主動的異常通知。還要分布式追蹤系統,建立請求在整個系統中的完整調用鏈。這對於微服務架構中的問題定位很重要。

總結

通過 Spring Boot Actuator 和 Micrometer 的組合,我們能夠以最小的成本獲得完整的監控能力。之後開始多認識一下

通過 Spring Boot Actuator 和 Micrometer 的組合,我們能夠以最小的成本獲得完整的監控能力。之後開始多認識一下Prometheus 和 Grafana 這兩個工作上也會碰到的組件,另外還有最常用到的 ELK。


上一篇
Day 28 | 第三階段系統優化 | 用 Lua 優化限流算法 -0
下一篇
Day 30 | 下台一鞠躬,明年會更好
系列文
系統設計一招一式:最基本的功練到爛熟就是殺手鐧,從單體架構到分布式系統的 Lab 實作筆記30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言