observability-engineer
設計生產環境可觀測性系統
此技能協助您設計和實施全面的監控、日誌記錄和追蹤系統，適用於企業應用程式。它提供關於 SLI/SLO 管理、分散式追蹤和事件回應工作流程的專業指導。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「observability-engineer」。 為我們每天處理 10 萬訂單的結帳服務設計監控策略
預期結果:
- 指標收集：部署 Prometheus，使用記錄規則監控訂單吞吐量、延遲百分位數（p50、p95、p99）和按類型分類的錯誤率
- 關鍵儀表板：在 Grafana 中建立高階概覽、營運即時和疑難排解下鑽視圖
- 警報：設定 p99 延遲 > 2 秒、錯誤率 > 1% 和結帳成功率 < 99% 的警報
- 追蹤：實施 OpenTelemetry 自動插樁，追蹤取樣率為 10%，錯誤則進行完整追蹤
- 日誌記錄：結構化 JSON 日誌，包含訂單 ID、使用者 ID 和延遲，以便與追蹤關聯
正在使用「observability-engineer」。 為可用性目標 99.9% 的付款 API 定義 SLO
預期結果:
- SLI 定義：成功付款請求 / 總付款請求，以 5 分鐘窗口測量
- SLO：30 天滾動窗口的成功率為 99.9% = 43.8 分鐘允許錯誤預算
- 錯誤預算警報：消耗率警報設定在 2 倍（每天 87.6 分鐘）和 10 倍（每天 438 分鐘）閾值
- 消耗追蹤：儀表板顯示剩餘錯誤預算、每日消耗率和預計違約日期
安全審計
安全Prompt-only skill with no executable code. Static analysis scanned 0 files (0 lines) and detected 0 security issues. The skill provides observability engineering guidance through text prompts only. No dangerous patterns, no network requests, no file system access, and no external commands detected. Content describes legitimate monitoring, logging, and tracing system design.
品質評分
你能建構什麼
設計微服務監控架構
為包含 50 多個服務的微服務系統建立全面的監控策略，包括指標收集、分散式追蹤和警報。
建立 SLI/SLO 框架
為 API 服務定義服務等級指標、目標和錯誤預算，可用性目標為 99.9%，並包含消耗率監控。
實施分散式追蹤
為電子商務平台設定分散式追蹤，以識別延遲瓶頸並執行跨服務邊界的根本原因分析。
試試這些提示
為每天處理 [traffic volume] 請求的 [service type] 設計監控策略。包括指標收集、日誌記錄方法和警報建議。
協助我為可用性目標為 [availability target]% 的 [service name] API 定義 SLI 和 SLO。包括錯誤預算計算和消耗率警報。
為 [incident type] 建立事件回應工作流程，包括警報路由、升級程序、操作手冊建議和事件後分析流程。
分析我們目前的可觀測性設定並推薦成本優化策略。我們目前使用 [tools]，每天產生 [volume] 的遙測資料。
最佳實務
- 從業務成果開始 - 在選擇指標之前，先定義對使用者而言可靠的服務意味著什麼
- 實施漸進式儀器化：首先使用指標獲得可見性，然後使用追蹤進行除錯，最後使用日誌獲取詳細資訊
- 針對症狀而非原因發出警報 - 當使用者受到影響時通知，而非內部元件故障時
避免
- 為每個可能發生的故障建立警報 - 導致警報疲勞和被忽略的通知
- 無目的地監控一切 - 增加成本並降低訊號品質
- 將 SLO 設定得太嚴格 - 造成不必要的壓力和預算耗盡