---
# System prepended metadata

title: 2024/01/24 第9章 可觀測性與監控如何配合？

---

# [點此加入 Google Meet 會議室](https://meet.google.com/mch-yqjg-sdg)

## 時間軸
- 20:50-21:00 閒聊/進場/確認相關軟、硬體
- 21:00-21:40 各章節負責人分享 
- 21:40-21:50 閒聊/完畢


## 相關資料
- [標題](連結)

## 可觀測性和監控如何配合？


一開始有點被監控和可觀測性兩個混淆，所以整理了可觀測性和監控上的差異，但我自己的感覺是監控就是可觀測性中的一個子集，有做好可觀測性，那監控就自然會有做好，只是監控的範圍和大小，就取決於組織的軟體服務而定。

傳統的監控方法對於傳統的系統已經足夠，但在管理現代系統的時候，這不代表我們應該丟掉所有舊有的方式，直接用新的比較潮的工具重新開始呢？

也許有些公司有這樣做，但對大多數的公司來說，實際情況應該由採取的責任來決定，因為每個組織的責任劃分也許都不一樣，所以沒有一個通則。

### 可觀測性：深入理解系統的內在
- **定義**：理解和解釋系統行為的藝術，不僅僅是收集數據，更重要的是從這些數據中獲得洞察。
- **核心原則**：透過外部輸出來理解系統的內部狀態，特別是在出現問題時。
- **實際應用**：例如在微服務架構中，使用追蹤技術來看不同服務間的互動，或分析日誌找出問題所在。

### 監控：及時發現和反應問題
- **定義**：系統健康狀態的持續追蹤，依賴於預設的指標和閾值。
- **核心原則**：當系統出現已知問題時，監控系統會及時提醒。它是被動的警報系統。
- **實際應用**：設置CPU使用率的警報，當超過閾值時，系統通知。

### 系統和軟體的考量：不再那麼分明
- **軟體**：開發的程式碼，運行在生產環境中，為客戶創造價值。
- **系統**：支撐軟體運行的基礎設施和平台。
    - 例如: SQL、VM、Storage

### 評估組織需求：找到最適合我們的方式
- **軟體導向的組織**：需要強大的可觀測性工具，確保提供最佳用戶體驗。
- **基礎設施導向的組織**：依賴傳統監控系統，確保硬體和網絡穩定運行。

### 例外狀況：無法忽略的基礎設施監控
- **重點**：即使在高度自動化和智能化的環境中，對基礎設施層面的傳統監控仍不可忽視。
- **實際建議**：結合可觀測性和傳統監控，確保從基礎設施到應用層的全面覆蓋。

### 實際案例：將理論付諸實踐
1. **多工具生態系統的整合**
   - 情境：公司使用Prometheus進行監控，Jaeger進行分佈式追蹤，及APM工具。
   - 轉變：轉向可觀測性方法，整合需求，減少工具使用，使監控系統與可觀測性系統共存。
   - 結果：軟體工程團隊使用可觀測性工具理解 Production 環境的服務，運營團隊使用 Prometheus 監控基礎設施。
2. **新創公司的 Tech stack**
   - 情境：新公司的 Tech stack，利用無服務器功能和SaaS平台，幾乎無自己基礎設施。
   - 策略：依賴應用 Dashboard 和可觀測性理解 Production 環境的服務。
   - 結果：數據導出進行長期聚合和倉儲，支持業務需求。
3. **金融服務公司的數字轉型**
   - 情境：成熟金融服務公司進行數字轉型，有舊基礎設施和新開發應用。
   - 策略：舊服務保持監控方法，新應用設計為可觀測性。
   - 結果：新應用使用公司基礎設施時，軟體工程團隊訪問基礎設施指標監控資源使用。

### 📚 總結：整合可觀測性和監控的重要性
- **結論**：可觀測性和監控相互補充，有效結合兩者，重點的是提高系統可靠性和效率。

---
# 共筆區塊

---
# 聊天區塊
