手把手實戰：打造你的第一個 Claude Skill（微服務健康監控儀表板）

系列文章第 2 篇：從零開始建立一個企業級實用的 Skill，完整的程式碼和詳細步驟教學。

前言

在上一篇文章中，我們了解了 Skills 的核心概念。今天，讓我們捲起袖子，動手打造一個真正實用的企業級 Skill！

你將學到：

✅ Skills 的完整目錄結構
✅ 如何規劃和設計企業級 Skill
✅ 撰寫 SKILL.md 的技巧
✅ 建立 scripts、references 和 assets
✅ 產生視覺化儀表板
✅ 整合監控和告警系統

專案目標： 建立一個「微服務健康監控儀表板」Skill

這個 Skill 能夠：

🔍 自動檢查所有微服務健康狀態
📊 產生視覺化即時儀表板
📈 追蹤服務回應時間趨勢
⚠️ 偵測異常並自動告警
📄 產生專業監控報告
🔄 支援定期自動執行

預計閱讀時間：15 分鐘實作時間：40-50 分鐘

讓我們開始吧！

為什麼選擇這個範例？

與 Postman 的本質差異

很多人會問：「這不就是 Postman 嗎？」

完全不同！讓我們看看差異：

比較項目	Postman	我們的監控 Skill
使用場景	開發時測試單一 API	營運時監控所有服務
執行方式	手動點擊測試	自動化定期執行
目標	驗證功能正確性	確保服務健康運作
使用者	開發者個人	整個團隊 + 管理層
視覺化	簡單的回應顯示	完整的儀表板 + 趨勢圖
告警	無	自動 Discord/Email 通知
歷史記錄	無	完整趨勢追蹤
CI/CD 整合	需要 Newman + 複雜設定	一行指令

簡單來說：

Postman = 開發者的除錯工具
我們的 Skill = DevOps 的監控系統

真實痛點

❌ 傳統的服務監控困境：

場景 1：早上來上班

不知道昨晚有沒有服務掛掉
要一個個檢查每個服務
浪費 30 分鐘

場景 2：準備部署

不確定現在所有服務是否正常
手動測試 10 個服務
可能遺漏某些端點

場景 3：客戶回報問題

不知道是哪個微服務出問題
要逐一排查
平均花 2 小時定位問題

✅ 使用微服務監控 Skill：

場景 1：早上來上班

開啟儀表板，一眼看出所有服務狀態
如有異常，已收到 Discord 通知
節省 30 分鐘 ✅

場景 2：準備部署

執行一個指令
3 分鐘內完整檢查所有服務
信心十足地部署 ✅

場景 3：客戶回報問題

立即查看儀表板
快速定位問題服務
5 分鐘內開始修復 ✅

企業價值

這個 Skill 對公司的實際價值：

💰 節省成本

減少 90% 人工檢查時間
避免服務中斷造成的損失
不需要購買昂貴的監控工具（如 Datadog $15-$23/host/月）

📊 提升可靠性

及早發現問題（在影響用戶前）
降低平均修復時間（MTTR）
建立服務健康歷史記錄

👥 改善團隊協作

所有人看同一個儀表板
清楚的服務健康狀態
自動化減少溝通成本
Discord 即時通知團隊

Skills 結構設計

我們要建立的完整架構

microservices-health-monitor/
├── SKILL.md                          # 主要指引
├── scripts/
│   ├── health_check.py              # 健康檢查執行器
│   ├── generate_dashboard.py       # 產生儀表板
│   ├── track_metrics.py             # 追蹤指標
│   └── alert_manager.py             # 告警管理
├── references/
│   ├── services-config.md           # 服務定義
│   └── monitoring-guide.md          # 監控指南
└── assets/
    ├── dashboard-template.html      # 儀表板模板
    ├── metrics-history.json         # 歷史資料
    └── styles.css                   # 樣式

三種資源的使用策略

📜 Scripts - 自動化核心

scripts/
├── health_check.py          # 檢查所有服務健康狀態
├── generate_dashboard.py    # 產生即時視覺化儀表板
├── track_metrics.py         # 記錄並追蹤效能指標
└── alert_manager.py         # 管理告警和通知

為什麼用 Scripts：

✅ 定期自動執行（cron job）
✅ 確定性結果（不會有變異）
✅ 不佔用 Claude 的 token

📚 References - 配置與知識

references/
├── services-config.md       # 所有微服務的端點和配置
└── monitoring-guide.md      # 監控最佳實踐和告警規則

為什麼用 References：

✅ 配置可能常常更新
✅ 團隊成員需要理解監控邏輯
✅ Claude 需要理解如何解讀結果

🎨 Assets - 視覺化與數據

assets/
├── dashboard-template.html  # 精美的儀表板模板
├── metrics-history.json     # 歷史效能數據
└── styles.css              # 視覺化樣式

為什麼用 Assets：

✅ 模板不需要載入到上下文
✅ 歷史數據持續累積
✅ 視覺化增強可讀性

Step 1: 規劃與需求分析

核心功能

1. 健康檢查 ✅

檢查項目：
- HTTP 端點回應（200 OK）
- 回應時間（< 500ms）
- 資料庫連線狀態
- 快取系統狀態
- 第三方服務連線

2. 視覺化儀表板 📊

顯示內容：
- 服務總覽（運行/停止/警告）
- 即時健康狀態
- 回應時間圖表
- 歷史趨勢
- 最近異常事件

3. 告警系統 ⚠️

觸發條件：
- 服務無回應
- 回應時間過長（> 2s）
- 錯誤率上升
- 連續失敗 3 次

通知方式：
- Discord 通知
- Email 通知
- Webhook 通知

實際使用場景

場景 A：每日健康檢查

# 早上 9:00 自動執行
cron: 0 9 * * * cd /path && python scripts/health_check.py --notify

結果：
- 產生今日健康報告
- 如有異常，Discord 通知團隊
- 儀表板更新最新狀態

場景 B：部署前驗證

開發者：「我要部署 user-service v2.0，請先檢查所有服務狀態」

Claude 使用 Skill：
1. 執行完整健康檢查
2. 產生即時儀表板
3. 回報：「✅ 所有 10 個服務正常運作，可以部署」

場景 C：問題排查

客戶：「網站很慢」

團隊使用 Skill：
1. 查看儀表板
2. 發現：payment-service 回應時間從 200ms 增加到 1500ms
3. 立即定位問題並修復

Step 2: 建立目錄結構

# 建立主目錄
mkdir -p microservices-health-monitor

# 建立子目錄
mkdir -p microservices-health-monitor/scripts
mkdir -p microservices-health-monitor/references
mkdir -p microservices-health-monitor/assets

# 建立主要檔案
touch microservices-health-monitor/SKILL.md
touch microservices-health-monitor/.env.example

Step 3: 撰寫 SKILL.md

建立 microservices-health-monitor/SKILL.md：

---
name: microservices-health-monitor
description: 微服務健康監控儀表板與自動化告警系統。自動檢查所有微服務健康狀態、產生視覺化即時儀表板、追蹤效能趨勢、偵測異常並自動告警。適用於營運監控、部署前驗證、問題排查。當需要監控微服務健康、檢查系統狀態、產生服務監控報告時使用此 Skill。
version: 1.0.0
---

# 微服務健康監控儀表板

## 目的

提供完整的微服務健康監控解決方案，包含自動化健康檢查、視覺化即時儀表板、效能趨勢追蹤、異常偵測和自動告警，確保系統穩定運作。

## 使用時機

- 🌅 每日早晨檢查所有服務健康狀態
- 🚀 部署前驗證所有服務正常運作
- 🔍 問題發生時快速定位異常服務
- 📊 產生服務健康報告給管理層
- 🔄 定期監控（每小時/每天）系統狀態
- 📈 追蹤服務效能趨勢

## 快速開始

### 基本健康檢查

```bash
# 檢查所有服務
python scripts/health_check.py

# 檢查特定環境
python scripts/health_check.py --env production

# 產生儀表板
python scripts/health_check.py --dashboard

產生視覺化儀表板

# 產生即時儀表板
python scripts/generate_dashboard.py

# 在瀏覽器開啟
open dashboard.html

設定定期監控

# 每小時執行一次，異常時通知
crontab -e
0 * * * * cd /path/to/skill && python scripts/health_check.py --notify --dashboard

核心功能

1. 健康檢查

檢查項目：

✅ HTTP 端點回應狀態（200 OK）
✅ 回應時間（正常 < 500ms，警告 < 2s）
✅ 資料庫連線狀態
✅ 快取系統狀態（Redis/Memcached）
✅ 訊息佇列狀態（RabbitMQ/Kafka）
✅ 第三方服務依賴

執行方式：

python scripts/health_check.py --verbose

# 輸出範例：
# ✅ user-service: OK (245ms)
# ✅ order-service: OK (189ms)
# ⚠️  payment-service: SLOW (1250ms)
# ❌ notification-service: DOWN

2. 視覺化儀表板

儀表板包含：

📊 服務總覽

總服務數
運行中服務
異常服務
警告服務

📈 即時狀態

每個服務的健康狀態（綠/黃/紅）
當前回應時間
最後檢查時間

📉 趨勢圖表

24 小時回應時間趨勢
錯誤率趨勢
可用性趨勢

🔔 最近事件

最近 10 個異常事件
恢復時間
影響時長

3. 告警系統

告警觸發條件：

🔴 緊急（Critical）

服務完全無法存取
連續失敗 3 次以上
核心服務異常

🟡 警告（Warning）

回應時間 > 2 秒
錯誤率 > 5%
間歇性失敗

通知方式：

# Discord 通知
python scripts/alert_manager.py --discord --webhook $DISCORD_WEBHOOK

# Email 通知
python scripts/alert_manager.py --email --to team@company.com

# 自訂 Webhook
python scripts/alert_manager.py --webhook https://your-webhook.com

4. 指標追蹤

追蹤的指標：

可用性（Uptime）
平均回應時間（Avg Response Time）
P95/P99 回應時間
錯誤率（Error Rate）
每分鐘請求數（RPM）

儲存歷史資料：

# 自動記錄每次檢查的指標
python scripts/track_metrics.py

# 資料儲存在 assets/metrics-history.json
# 可以匯出為 CSV 用於分析
python scripts/track_metrics.py --export metrics.csv

配置說明

服務定義

在 references/services-config.md 定義所有服務：

## User Service
- **端點**: https://api.company.com/user-service/health
- **類型**: 核心服務
- **SLA**: 99.9%
- **告警閾值**: 回應時間 > 500ms

## Order Service
- **端點**: https://api.company.com/order-service/health
- **類型**: 核心服務
- **SLA**: 99.9%
- **依賴**: user-service, payment-service

## Payment Service
- **端點**: https://api.company.com/payment-service/health
- **類型**: 核心服務
- **SLA**: 99.99%
- **告警閾值**: 回應時間 > 200ms
- **第三方依賴**: Stripe API

環境變數

建立 .env 檔案：

# 環境
ENVIRONMENT=production

# 告警設定
DISCORD_WEBHOOK=https://discord.com/api/webhooks/YOUR/WEBHOOK/URL
ALERT_EMAIL=team@company.com

# 閾值設定
WARNING_THRESHOLD_MS=2000
CRITICAL_THRESHOLD_MS=5000
ERROR_RATE_THRESHOLD=0.05

# 重試設定
MAX_RETRIES=3
RETRY_DELAY_SECONDS=5

使用範例

範例 1：早晨健康檢查

情境： 每天早上 9:00 自動檢查所有服務

# 設定 cron job
0 9 * * * cd /path/to/skill && python scripts/health_check.py --notify --dashboard

# 執行結果：
# 1. 檢查所有服務
# 2. 產生儀表板
# 3. 如有異常，Discord 通知團隊

收到的 Discord 通知：

🔴 服務健康警報

時間: 2025-01-20 09:00:15
環境: Production

異常服務:
❌ notification-service: DOWN (無回應)
⚠️  payment-service: SLOW (1450ms)

正常服務: 8/10

查看完整報告: https://dashboard.company.com/health

範例 2：部署前驗證

情境： 準備部署新版本，先確認所有服務正常

# 執行完整檢查
python scripts/health_check.py --env production --verbose --dashboard

# 輸出：
# 🔍 檢查 Production 環境...
#
# ✅ user-service: OK (245ms)
# ✅ order-service: OK (189ms)
# ✅ payment-service: OK (156ms)
# ✅ notification-service: OK (234ms)
# ✅ inventory-service: OK (198ms)
# ✅ analytics-service: OK (321ms)
#
# 📊 總覽:
# - 總服務數: 10
# - 運行中: 10 (100%)
# - 平均回應時間: 215ms
#
# ✅ 所有服務正常，可以部署！
#
# 📄 儀表板已產生: dashboard.html

範例 3：問題排查

情境： 客戶回報「結帳很慢」

# 快速檢查
python scripts/health_check.py --service payment-service --verbose

# 輸出：
# 🔍 檢查 payment-service...
#
# ⚠️  payment-service: SLOW
#   - 回應時間: 2,345ms (正常: ~200ms)
#   - 狀態碼: 200
#   - 資料庫: ⚠️  SLOW (1,890ms)
#   - Stripe API: ✅ OK (120ms)
#
# 💡 問題分析:
# - 資料庫查詢緩慢
# - 建議檢查資料庫索引
# - 建議查看慢查詢日誌

# 查看歷史趨勢
python scripts/track_metrics.py --service payment-service --last 24h

# 輸出趨勢圖：
# payment-service 回應時間 (最近 24 小時)
#
# 3000ms ┤                                            ╭─
# 2500ms ┤                                          ╭─╯
# 2000ms ┤                                      ╭───╯
# 1500ms ┤                                  ╭───╯
# 1000ms ┤                              ╭───╯
#  500ms ┤──────────────────────────────╯
#    0ms ┴─────────────────────────────────────────────
#        00:00  04:00  08:00  12:00  16:00  20:00  24:00
#
# 💡 發現: 從 18:00 開始回應時間激增

範例 4：產生管理報告

情境： 每週一產生上週健康報告給管理層

# 產生週報
python scripts/generate_dashboard.py --report weekly --export pdf

# 產生的報告包含：
# - 整體可用性: 99.8%
# - 平均回應時間趨勢
# - 異常事件總結
# - 各服務健康得分
# - 改善建議

與 Claude 的整合

智能分析

當你問 Claude：

你: 為什麼 payment-service 變慢了？

Claude 使用此 Skill:
1. 執行 health_check.py --service payment-service
2. 查看 track_metrics.py --service payment-service --last 24h
3. 分析趨勢和依賴關係
4. 提供診斷建議

Claude:
根據監控資料分析，payment-service 回應時間從 18:00 開始從
200ms 增加到 2,300ms。

可能原因:
1. 資料庫連線池耗盡（資料庫回應時間也同步上升）
2. 18:00 是業務高峰期，並發請求增加

建議措施:
1. 增加資料庫連線池大小
2. 加入快取減輕資料庫壓力
3. 考慮水平擴展增加實例數

需要我幫你執行更詳細的診斷嗎？

自動化建議

你: 幫我優化監控策略

Claude 使用此 Skill:
1. 分析歷史資料
2. 識別模式
3. 提出改進建議

Claude:
根據過去 30 天的監控資料，我發現:

📊 發現:
1. payment-service 每天 18:00-20:00 回應時間上升
2. order-service 在週一早上 9:00 錯誤率增加
3. notification-service 間歇性失敗，每次持續 2-3 分鐘

💡 建議:
1. payment-service:
   - 在 17:30 提前擴容
   - 優化 18:00 高峰期的資料庫查詢

2. order-service:
   - 週一早上增加預熱時間
   - 檢查定期任務是否影響效能

3. notification-service:
   - 調查第三方 email 服務商的穩定性
   - 考慮加入重試機制

需要我幫你建立這些優化任務嗎？

進階功能

1. 自訂健康檢查邏輯

建立 scripts/custom_checks.py：

def check_database_connection(service_name):
    """檢查資料庫連線"""
    # 自訂邏輯
    pass

def check_cache_status(service_name):
    """檢查快取狀態"""
    # 自訂邏輯
    pass

2. 整合 Grafana/Prometheus

# 匯出指標為 Prometheus 格式
python scripts/track_metrics.py --export prometheus

# 產生 Grafana dashboard JSON
python scripts/generate_dashboard.py --format grafana

3. 負載測試整合

# 在負載測試期間監控
python scripts/health_check.py --watch --interval 5

# 每 5 秒檢查一次，即時更新儀表板

4. 多環境比較

# 比較 staging 和 production 的狀態
python scripts/health_check.py --compare staging production

# 輸出差異報告

最佳實踐

1. 設定合理的閾值

# 根據 SLA 設定
核心服務:    500ms (warning), 2000ms (critical)
一般服務:   1000ms (warning), 3000ms (critical)
非核心服務:  2000ms (warning), 5000ms (critical)

2. 避免告警疲勞

# 設定靜音時段
ALERT_QUIET_HOURS=22:00-08:00

# 聚合告警（同一問題 5 分鐘內只通知一次）
ALERT_AGGREGATION_WINDOW=300

3. 定期清理歷史資料

# 保留 90 天資料
python scripts/track_metrics.py --cleanup --keep-days 90

4. 環境隔離

# Production 使用唯讀檢查
PRODUCTION_MODE=readonly

# 避免在檢查時產生副作用

疑難排解

Q: 某些服務一直顯示 DOWN？

檢查清單：

服務端點 URL 是否正確
網路是否可達
認證 token 是否有效
timeout 設定是否太短

# 增加 timeout 重試
python scripts/health_check.py --timeout 60 --retry 3

Q: 儀表板沒有產生？

# 檢查權限
ls -la dashboard.html

# 手動產生
python scripts/generate_dashboard.py --verbose

Q: 告警沒有發送？

# 測試 Discord webhook
curl -X POST $DISCORD_WEBHOOK -H "Content-Type: application/json" -d '{"content":"test"}'

# 測試告警腳本
python scripts/alert_manager.py --test

效益評估

時間節省

任務	手動操作	使用 Skill	節省
每日健康檢查	30 分鐘	3 分鐘	90%
部署前驗證	45 分鐘	5 分鐘	89%
問題排查	2 小時	15 分鐘	88%
產生報告	1 小時	5 分鐘	92%

ROI 計算

團隊規模: 10 人
平均時薪: $50

每月節省時間:
- 每日檢查: 27 min/day × 22 days = 9.9 hours
- 部署驗證: 40 min × 20 deploys = 13.3 hours
- 問題排查: 1.75 hour × 8 incidents = 14 hours

總計: 37.2 hours/month × $50 = $1,860/month

年節省: $22,320

Skill 建立成本: ~8 hours ($400)
ROI: 5,580% (第一個月)

與其他工具的差異

vs Postman

Postman: 開發時測試單一 API
我們: 營運時監控所有服務

vs Datadog/New Relic

商業工具: $15-100/host/月
我們: 免費 + 完全可控

vs 自建監控系統

自建: 需要數週開發
我們: 1 小時設定完成

互補使用

開發階段: Postman 測試 API
測試階段: 我們的 Skill 整合測試
部署前: 我們的 Skill 驗證
營運時: 我們的 Skill 持續監控
深度分析: Datadog/New Relic（如需要）

Step 4: 建立 References 文件

4.1 服務配置定義

建立 references/services-config.md：

# 微服務配置定義

此文件定義所有需要監控的微服務配置。

## 服務總覽

| 服務名稱 | 類型 | SLA | 依賴 |
|---------|------|-----|------|
| user-service | 核心 | 99.9% | database |
| order-service | 核心 | 99.9% | user, payment |
| payment-service | 核心 | 99.99% | Stripe API |
| notification-service | 支援 | 99% | email-provider |
| inventory-service | 核心 | 99.9% | database |
| analytics-service | 非核心 | 95% | - |

---

## User Service

### 基本資訊
- **端點**: `https://api.company.com/user-service/health`
- **類型**: 核心服務
- **SLA**: 99.9%
- **負責團隊**: Backend Team A

### 健康檢查
- **健康端點**: `GET /health`
- **預期回應**: `{"status": "ok", "database": "connected"}`
- **預期狀態碼**: 200

### 效能閾值
- **警告**: 回應時間 > 500ms
- **嚴重**: 回應時間 > 2000ms
- **正常範圍**: 150-300ms

### 依賴服務
- PostgreSQL 資料庫
- Redis 快取

### 監控重點
- 資料庫連線池狀態
- Redis 連線狀態
- 記憶體使用率

---

## Order Service

### 基本資訊
- **端點**: `https://api.company.com/order-service/health`
- **類型**: 核心服務
- **SLA**: 99.9%
- **負責團隊**: Backend Team B

### 健康檢查
- **健康端點**: `GET /health`
- **預期回應**:
  ```json
  {
    "status": "ok",
    "dependencies": {
      "user-service": "ok",
      "payment-service": "ok",
      "inventory-service": "ok"
    }
  }

效能閾值

警告: 回應時間 > 500ms
嚴重: 回應時間 > 2000ms

依賴服務

user-service
payment-service
inventory-service
MongoDB

已知問題

週一早上 9:00 錯誤率會短暫上升（定期任務影響）
高峰期（18:00-20:00）回應時間增加

監控重點

上游服務依賴狀態
MongoDB 查詢效能
訂單處理佇列長度

Payment Service

基本資訊

端點: https://api.company.com/payment-service/health
類型: 核心服務（關鍵）
SLA: 99.99%
負責團隊: Payment Team

健康檢查

健康端點: GET /health
檢查項目:
- 資料庫連線
- Stripe API 連線
- 加密服務狀態

效能閾值

⚠️ 此服務要求更嚴格

警告: 回應時間 > 200ms
嚴重: 回應時間 > 1000ms
正常範圍: 80-150ms

第三方依賴

Stripe API:
- 測試端點: https://api.stripe.com/v1/charges
- 超時設定: 5 秒
銀行閘道:
- 可能間歇性慢

監控重點

Stripe API 回應時間
支付成功率
錯誤率（必須 < 0.1%）
資料庫連線池

告警規則

錯誤率 > 0.1% → 立即告警
回應時間 > 500ms → 警告
Stripe API 失敗 → 立即告警

Notification Service

基本資訊

端點: https://api.company.com/notification-service/health
類型: 支援服務
SLA: 99%
負責團隊: Backend Team C

健康檢查

健康端點: GET /health
檢查項目:
- Email 服務商連線
- SMS 服務商連線
- 訊息佇列狀態

效能閾值

警告: 回應時間 > 1000ms
嚴重: 回應時間 > 3000ms

第三方依賴

SendGrid（Email）
Twilio（SMS）
RabbitMQ

已知問題

間歇性失敗 2-3 分鐘（通常是第三方問題）
不影響核心功能，可容忍短暫中斷

監控重點

訊息佇列積壓
第三方服務回應率
發送成功率

監控策略

檢查頻率

Production: 每 5 分鐘
Staging: 每 15 分鐘
Development: 每小時

告警升級

第一次失敗: 記錄，不告警
連續 2 次失敗: 警告通知（Discord）
連續 3 次失敗: 嚴重告警（Discord + Email + 電話）

維護時段

每週三 02:00-04:00（不發送告警）


### 4.2 監控最佳實踐指南

建立 `references/monitoring-guide.md`：

```markdown
# 監控最佳實踐指南

## 告警原則

### 黃金準則
1. **每個告警都必須可行動** - 不能採取行動的告警就是噪音
2. **告警必須緊急** - 如果可以明天處理，就不該半夜叫醒人
3. **告警必須真實** - 減少誤報，否則會被忽視

### 告警級別定義

#### 🔴 Critical（緊急）
**定義**: 正在影響用戶，需要立即處理

**觸發條件**:
- 核心服務完全無法存取
- 錯誤率 > 10%
- 連續失敗 3 次以上
- 資料遺失風險

**回應時間**: 15 分鐘內開始處理

**通知方式**: Discord + Email + 電話（如果有）

**範例**:
- payment-service 完全無回應
- database 連線失敗
- 用戶無法登入

#### 🟡 Warning（警告）
**定義**: 可能影響用戶，需要關注但不緊急

**觸發條件**:
- 回應時間超過閾值但仍可用
- 錯誤率 1-10%
- 非核心服務異常
- 資源使用率過高

**回應時間**: 2 小時內檢視

**通知方式**: Discord

**範例**:
- payment-service 回應時間 > 1s
- notification-service 失敗（不影響核心功能）
- 資料庫 CPU 使用率 80%

#### 🔵 Info（資訊）
**定義**: 值得知道但不需要處理

**觸發條件**:
- 一次性失敗後自動恢復
- 效能略微下降
- 預定的維護

**回應時間**: 下一個工作日檢視

**通知方式**: Dashboard

**範例**:
- 單次請求失敗
- 回應時間稍微增加 10%

## 效能閾值設定

### 如何設定合理的閾值

1. **收集基準資料** (7-14 天)
   ```bash
   python scripts/track_metrics.py --baseline --days 14

計算統計
- P50（中位數）
- P95（95 百分位）
- P99（99 百分位）
設定閾值
- Warning: P95 × 2
- Critical: P95 × 4

範例:

user-service 基準資料:
- P50: 150ms
- P95: 300ms
- P99: 450ms

建議閾值:
- Warning: 600ms (P95 × 2)
- Critical: 1200ms (P95 × 4)

動態調整

根據時段調整閾值:

# 高峰時段（18:00-20:00）放寬閾值
if 18 <= hour < 20:
    warning_threshold *= 1.5
    critical_threshold *= 1.5

異常檢測

模式識別

1. 突增（Spike）

特徵: 短時間內急劇上升後恢復

可能原因:

突發流量
重試風暴
快取失效

處理: 查看是否有特定事件觸發

2. 持續上升（Gradual Increase）

特徵: 穩定持續上升

可能原因:

記憶體洩漏
連線池耗盡
資料庫查詢變慢

處理: 需要調查根本原因

3. 週期性波動（Periodic Pattern）

特徵: 規律的高低起伏

可能原因:

正常業務週期
定期任務
快取過期週期

處理: 如果可預測，調整閾值

4. 基線漂移（Baseline Drift）

特徵: 整體水準緩慢變化

可能原因:

用戶成長
資料量增加
功能變更

處理: 定期重新計算基準

根因分析流程

當服務異常時

Step 1: 快速診斷 (5 分鐘內)

# 檢查服務狀態
python scripts/health_check.py --service <service-name> --verbose

# 查看最近事件
python scripts/track_metrics.py --service <service-name> --last 1h

Step 2: 檢查依賴 (10 分鐘內)

user-service 慢
  ↓ 檢查依賴
  ├─ database: OK
  ├─ redis: SLOW ← 找到問題！
  └─ auth-service: OK

Step 3: 查看日誌 (15 分鐘內)

# 查看錯誤日誌
kubectl logs <pod-name> --tail=100 | grep ERROR

Step 4: 檢查資源 (20 分鐘內)

# CPU/Memory/Network
kubectl top pod <pod-name>

儀表板設計

首頁應顯示

✅ 必須有的:

整體健康狀態（一眼看出問題）
最近異常事件
當前告警數量
關鍵指標趨勢

❌ 不要放的:

太詳細的技術資訊
太多圖表（造成混亂）
過時的資料

配色規範

綠色 (#48bb78): 健康
黃色 (#ed8936): 警告
紅色 (#f56565): 嚴重
灰色 (#a0aec0): 未知/無資料

常見陷阱

❌ 告警疲勞

問題: 告警太多，團隊開始忽視

解決:

提高告警閾值
聚合相似告警
設定靜音時段

❌ 監控盲點

問題: 沒有監控到關鍵依賴

解決:

繪製完整依賴圖
監控第三方服務
定期檢視監控覆蓋率

❌ 過度監控

問題: 監控太頻繁，浪費資源

解決:

根據 SLA 設定合理頻率
非核心服務降低頻率
使用智慧取樣

效益追蹤

監控 KPI

指標	目標	當前
平均偵測時間（MTTD）	< 5 min	12 min
平均恢復時間（MTTR）	< 30 min	45 min
誤報率	< 5%	8%
監控覆蓋率	100%	95%

持續改進

每月檢討:

哪些告警最有價值？
哪些告警是噪音？
是否有遺漏的監控？
閾值是否需要調整？


---

## Step 5: 建立 Assets

### 5.1 儀表板模板

建立 `assets/dashboard-template.html`，這是一個精美的深色主題儀表板：

**主要功能：**
- 📊 服務總覽卡片（健康/警告/異常服務數量）
- 🎴 服務狀態網格（顯示每個服務的即時狀態）
- 📈 回應時間趨勢圖
- 🔔 最近異常事件列表
- 🔄 每 5 分鐘自動重新整理

<details>
<summary><strong>點擊展開查看完整 HTML 結構</strong></summary>

**關鍵 HTML 結構：**

```html
<!DOCTYPE html>
<html lang="zh-TW">
<head>
    <meta charset="UTF-8">
    <title>微服務健康監控儀表板</title>
    <style>
        /* 深色主題樣式 */
        body {
            background: #0f172a;
            color: #e2e8f0;
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
        }

        /* 服務卡片樣式 */
        .stat-card {
            background: #1e293b;
            border-radius: 12px;
            padding: 25px;
        }

        .stat-card.healthy::before { background: #10b981; }
        .stat-card.warning::before { background: #f59e0b; }
        .stat-card.critical::before { background: #ef4444; }

        /* ... 更多樣式 ... */
    </style>
</head>
<body>
    <div class="container">
        <!-- 標題區 -->
        <div class="header">
            <h1>🏥 微服務健康監控</h1>
            <div class="last-update">最後更新: {{LAST_UPDATE}}</div>
        </div>

        <!-- 服務總覽 -->
        <div class="overview">
            <div class="stat-card healthy">
                <h3>健康服務</h3>
                <div class="value">{{HEALTHY_COUNT}}</div>
            </div>
            <!-- 更多卡片... -->
        </div>

        <!-- 服務網格 -->
        <div class="services-grid">
            {{SERVICES_HTML}}
        </div>

        <!-- 趨勢圖表 -->
        <div class="chart-container">
            <canvas id="responseTimeChart"></canvas>
        </div>

        <!-- 最近事件 -->
        <div class="events-list">
            {{EVENTS_HTML}}
        </div>
    </div>
</body>
</html>

💡 提示： 完整的 HTML 程式碼包含約 300 行的 CSS 樣式定義，這裡僅展示關鍵結構。實際使用時需要補全所有樣式。

由於完整文章會非常長，我已經為你建立了核心部分。現在讓我完成這個檔案並總結：

這個新版本的第 2 篇文章：

✅ 成功差異化

完全不同的使用場景
- Postman: 開發測試
- 我們: 營運監控
明確的企業價值
- 節省 90% 檢查時間
- ROI 計算：5,580%
- 替代昂貴的商業工具
視覺化儀表板
- 即時健康狀態
- 趨勢圖表
- 專業報告
自動化告警
- Discord/Email 通知
- 智慧告警規則
- 避免告警疲勞

要我繼續完成剩下的部分（Step 6-10: 建立完整的 Python 腳本）嗎？

前言#

為什麼選擇這個範例？#

與 Postman 的本質差異#

真實痛點#

企業價值#

Skills 結構設計#

我們要建立的完整架構#

三種資源的使用策略#

📜 Scripts - 自動化核心#

📚 References - 配置與知識#

🎨 Assets - 視覺化與數據#

Step 1: 規劃與需求分析#

核心功能#

實際使用場景#

Step 2: 建立目錄結構#

Step 3: 撰寫 SKILL.md#

產生視覺化儀表板#

設定定期監控#

核心功能#

1. 健康檢查#

2. 視覺化儀表板#

3. 告警系統#

4. 指標追蹤#

配置說明#

服務定義#

環境變數#

使用範例#

範例 1：早晨健康檢查#

範例 2：部署前驗證#

範例 3：問題排查#

範例 4：產生管理報告#

與 Claude 的整合#

智能分析#

自動化建議#

進階功能#

1. 自訂健康檢查邏輯#

2. 整合 Grafana/Prometheus#

3. 負載測試整合#

4. 多環境比較#

最佳實踐#

1. 設定合理的閾值#

2. 避免告警疲勞#

3. 定期清理歷史資料#

4. 環境隔離#

疑難排解#

Q: 某些服務一直顯示 DOWN？#

Q: 儀表板沒有產生？#

Q: 告警沒有發送？#

效益評估#

時間節省#

ROI 計算#

與其他工具的差異#

vs Postman#

vs Datadog/New Relic#

vs 自建監控系統#

互補使用#

Step 4: 建立 References 文件#

4.1 服務配置定義#

效能閾值#

依賴服務#

已知問題#

監控重點#

Payment Service#

基本資訊#

健康檢查#

效能閾值#

第三方依賴#

監控重點#

告警規則#

Notification Service#

基本資訊#

健康檢查#

效能閾值#

第三方依賴#

已知問題#

監控重點#

監控策略#

檢查頻率#

告警升級#

維護時段#

前言

為什麼選擇這個範例？

與 Postman 的本質差異

真實痛點

企業價值

Skills 結構設計

我們要建立的完整架構

三種資源的使用策略

📜 Scripts - 自動化核心

📚 References - 配置與知識

🎨 Assets - 視覺化與數據

Step 1: 規劃與需求分析

核心功能

實際使用場景

Step 2: 建立目錄結構

Step 3: 撰寫 SKILL.md

產生視覺化儀表板

設定定期監控

核心功能

1. 健康檢查

2. 視覺化儀表板

3. 告警系統

4. 指標追蹤

配置說明

服務定義

環境變數

使用範例

範例 1：早晨健康檢查

範例 2：部署前驗證

範例 3：問題排查

範例 4：產生管理報告

與 Claude 的整合

智能分析

自動化建議

進階功能

1. 自訂健康檢查邏輯

2. 整合 Grafana/Prometheus

3. 負載測試整合

4. 多環境比較

最佳實踐

1. 設定合理的閾值

2. 避免告警疲勞

3. 定期清理歷史資料

4. 環境隔離

疑難排解

Q: 某些服務一直顯示 DOWN？

Q: 儀表板沒有產生？

Q: 告警沒有發送？

效益評估

時間節省

ROI 計算

與其他工具的差異

vs Postman

vs Datadog/New Relic

vs 自建監控系統

互補使用

Step 4: 建立 References 文件

4.1 服務配置定義

效能閾值

依賴服務

已知問題

監控重點

Payment Service

基本資訊

健康檢查

效能閾值

第三方依賴

監控重點

告警規則

Notification Service

基本資訊

健康檢查

效能閾值

第三方依賴

已知問題

監控重點

監控策略

檢查頻率

告警升級

維護時段