監控告警規則怎麼設計提示詞（Prometheus 告警規則、閾值與持續時間、告警分級、減少告警疲勞）
要給服務配置監控告警，或者現有告警太多太吵、真正的故障反而被淹沒時用：AI 從用戶感受到的症狀出發設計告警（錯誤率、延遲、可用性），給出 Prometheus 告警規則、合理的閾值與持續時間、分級與通知策略，並審查現有規則中的噪音來源。
通用大模型 對話模型通用
你是一名站點可靠性工程師，信奉「告警應該少而準：每一條告警都意味着需要有人立刻處理」。請幫我設計告警規則。 - 服務類型：[服務類型]（例：對外 HTTP 接口服務） - 已有的指標：[已有指標]（例：請求總數、耗時直方圖、實例存活） - 業務目標：[業務目標]（例：可用性 99.9%，P95 延遲 300 毫秒） - 通知渠道與值班方式：[通知方式]（例：嚴重告警打電話，其他發群消息） - 現有告警規則（如果要審查）： [粘貼現有規則，沒有就寫無] 請輸出： 1. 告警設計原則：優先基於症狀（用戶能感知的錯誤率、延遲、可用性）告警，原因類指標（CPU、內存）通常只作為輔助或低級別提醒；每條告警都要有對應的處理手冊。 2. 規則清單：告警名 | 表達式 | 持續時間 | 級別 | 含義 | 處理手冊要點。至少覆蓋： - 錯誤率； - 延遲（基於直方圖計算分位數）； - 實例或目標不可用； - 資源即將耗盡的趨勢（如磁盤按當前速度幾小時後寫滿），而不是簡單的「使用率超過 80%」； - 監控本身失效（指標消失）。 3. 閾值與持續時間：說明如何根據業務目標和歷史數據確定；持續時間太短會導致抖動誤報，太長會延誤發現。 4. 分級與路由：嚴重、警告、提示各自的標準和通知方式；告警的分組、抑制（例如整個集群不可用時，不再逐個發出實例告警）、靜默的用法。 5. 審查現有規則（如果提供）：找出重複告警、沒有持續時間的規則、閾值不合理的規則、對用戶沒有影響的規則，給出修改或刪除建議。 輸出符合 Prometheus 告警規則文件格式的 YAML，帶中文註釋；表達式中用到的指標名按我提供的名稱，沒有提供的用常見命名並註明需要替換。
高亮處換成你自己的內容：[服務類型]、[已有指標]、[業務目標]、[通知方式]、[粘貼現有規則，沒有就寫無]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[已有的指標] 盡量寫出真實的指標名，表達式才能直接使用。[業務目標] 用來確定閾值，例如可用性目標為 99.9% 時，錯誤率持續超過千分之幾需要告警。
常見坑：
- 給每台機器的 CPU、內存都設定「超過 80% 告警」，結果每天幾十條告警，大部分對用戶沒有影響，值班的人逐漸開始忽略告警。
- 告警規則沒有設定持續時間，指標瞬間抖動一下就發出告警，幾秒後又恢復。
- 只配置了「服務掛了」的告警，卻沒有配置「監控本身掛了」的告警，採集中斷時會誤以為一切正常。
追問技巧：追問「把錯誤率告警改成基於錯誤預算消耗速度的多窗口告警」，或「為每條嚴重告警寫一份處理手冊」（可配合 1023 號提示詞）。
示例輸出
示例，僅供參考（節選）
yaml
groups:
- name: order-api
rules:
- alert: OrderApiHighErrorRate
# 5 分鐘內 5xx 比例超過 2%，持續 5 分鐘
expr: |
sum(rate(http_requests_total{job="order-api",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="order-api"}[5m])) > 0.02
for: 5m
labels: { severity: critical }
annotations:
summary: "訂單接口錯誤率 {{ $value | humanizePercentage }}"
runbook: "https://wiki.example.com/runbook/order-api-5xx"
- alert: DiskWillFillIn6Hours
# 按過去 6 小時的增長趨勢，6 小時內寫滿
expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 6 * 3600) < 0
for: 30m
labels: { severity: warning }同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～