服務(wù)器監(jiān)控告警規(guī)范一、概述

服務(wù)器監(jiān)控告警規(guī)范旨在建立一套系統(tǒng)化、標準化的告警管理流程，確保及時發(fā)現(xiàn)并處理服務(wù)器運行中的異常情況，保障IT基礎(chǔ)設(shè)施的穩(wěn)定性和可靠性。本規(guī)范涵蓋了告警閾值設(shè)定、告警級別劃分、告警通知機制、告警處理流程及文檔管理等方面，適用于企業(yè)內(nèi)部所有服務(wù)器及相關(guān)系統(tǒng)的監(jiān)控告警管理。

二、告警閾值設(shè)定

（一）性能指標閾值

1.CPU使用率：

-警告級別（黃色）：>70%，持續(xù)5分鐘；

-嚴重級別（紅色）：>90%，持續(xù)10分鐘。

2.內(nèi)存使用率：

-警告級別：>75%，持續(xù)10分鐘；

-嚴重級別：>95%，持續(xù)20分鐘。

3.磁盤I/O：

-警告級別：I/O延遲>100ms，持續(xù)15分鐘；

-嚴重級別：I/O延遲>300ms，持續(xù)30分鐘。

4.網(wǎng)絡(luò)流量：

-警告級別：單接口流量>1Gbps，持續(xù)10分鐘；

-嚴重級別：單接口流量>1.5Gbps，持續(xù)20分鐘。

（二）服務(wù)狀態(tài)閾值

1.Web服務(wù)（HTTP/HTTPS）：

-警告級別：響應(yīng)時間>5秒，持續(xù)5分鐘；

-嚴重級別：服務(wù)不可達（500/503錯誤），持續(xù)10分鐘。

2.數(shù)據(jù)庫服務(wù)（MySQL/Oracle）：

-警告級別：連接數(shù)>90%容量，持續(xù)10分鐘；

-嚴重級別：主從延遲>5秒，持續(xù)20分鐘。

三、告警級別劃分

（一）告警分類

1.警告級別（黃色）：一般性異常，不影響核心業(yè)務(wù)，需及時關(guān)注。

2.嚴重級別（紅色）：重大異常，可能影響業(yè)務(wù)運行，需立即處理。

3.緊急級別（紫色）：系統(tǒng)崩潰或數(shù)據(jù)丟失風險，需立即停機排查。

（二）告警優(yōu)先級

1.緊急級別>嚴重級別>警告級別。

2.相同級別內(nèi)，按影響范圍和恢復時間排序。

四、告警通知機制

（一）通知渠道

1.短信：適用于緊急級別告警。

2.郵件：適用于警告級別及以上。

3.企業(yè)微信/釘釘：適用于日常監(jiān)控告警。

4.監(jiān)控平臺彈窗：適用于實時告警。

（二）通知流程

1.監(jiān)控系統(tǒng)觸發(fā)告警后，自動推送至對應(yīng)責任人。

2.30分鐘內(nèi)未響應(yīng)的告警，升級至下一級責任人。

五、告警處理流程

（一）告警接收與確認

1.責任人30分鐘內(nèi)確認告警狀態(tài)。

2.記錄告警時間、指標及初步現(xiàn)象。

（二）問題排查與解決

1.按以下步驟操作：

(1)檢查監(jiān)控數(shù)據(jù)與實際日志是否一致；

(2)分析可能原因（如負載過高、配置錯誤等）；

(3)執(zhí)行修復措施（如重啟服務(wù)、擴容資源等）。

2.處理過程中需同步更新告警狀態(tài)。

（三）告警關(guān)閉與歸檔

1.確認問題解決后，關(guān)閉告警。

2.記錄處理結(jié)果及改進建議，存檔至監(jiān)控平臺。

六、文檔管理

（一）定期更新

1.每季度審核告警閾值及處理流程。

2.根據(jù)實際案例調(diào)整告警規(guī)則。

（二）培訓與維護

1.每半年組織一次告警規(guī)范培訓。

2.確保監(jiān)控團隊熟悉告警流程及職責。

一、概述

服務(wù)器監(jiān)控告警規(guī)范旨在建立一套系統(tǒng)化、標準化的告警管理流程，確保及時發(fā)現(xiàn)并處理服務(wù)器運行中的異常情況，保障IT基礎(chǔ)設(shè)施的穩(wěn)定性和可靠性。本規(guī)范涵蓋了告警閾值設(shè)定、告警級別劃分、告警通知機制、告警處理流程及文檔管理等方面，適用于企業(yè)內(nèi)部所有服務(wù)器及相關(guān)系統(tǒng)的監(jiān)控告警管理。其核心目標是通過明確的規(guī)則和流程，減少誤報和漏報，優(yōu)化資源分配，提升故障響應(yīng)效率，最終降低業(yè)務(wù)中斷風險。

二、告警閾值設(shè)定

（一）性能指標閾值

1.CPU使用率：

-警告級別（黃色）：

-首次觸發(fā)：>70%，持續(xù)5分鐘；

-重復觸發(fā)：>65%，持續(xù)3分鐘。

-嚴重級別（紅色）：

-首次觸發(fā)：>90%，持續(xù)10分鐘；

-重復觸發(fā)：>85%，持續(xù)5分鐘。

-說明：針對核心應(yīng)用服務(wù)器，閾值可適當調(diào)低；對于后臺任務(wù)服務(wù)器，可適當調(diào)高。

2.內(nèi)存使用率：

-警告級別：

-交換空間使用率>50%，持續(xù)10分鐘；

-堆內(nèi)存使用率>75%，持續(xù)15分鐘。

-嚴重級別：

-交換空間使用率>70%，持續(xù)20分鐘；

-堆內(nèi)存使用率>90%，持續(xù)30分鐘。

-說明：需區(qū)分物理內(nèi)存和虛擬內(nèi)存（交換空間）的告警。

3.磁盤I/O：

-警告級別：

-平均磁盤讀寫延遲>100ms，持續(xù)15分鐘；

-IOPS（每秒輸入/輸出操作數(shù)）低于平均值的50%，持續(xù)10分鐘。

-嚴重級別：

-平均磁盤讀寫延遲>300ms，持續(xù)30分鐘；

-IOPS持續(xù)低于平均值的30%，持續(xù)20分鐘。

-說明：重點關(guān)注數(shù)據(jù)庫、文件服務(wù)等I/O密集型應(yīng)用的磁盤性能。

4.網(wǎng)絡(luò)流量：

-警告級別：

-單接口流量>1Gbps，持續(xù)10分鐘；

-入侵檢測系統(tǒng)（IDS）或防火墻發(fā)出特定類型告警（如SQL注入嘗試）。

-嚴重級別：

-單接口流量>1.5Gbps，持續(xù)20分鐘；

-IDS/防火墻發(fā)出高危攻擊告警。

-說明：網(wǎng)絡(luò)流量告警需結(jié)合業(yè)務(wù)周期（如促銷活動期間流量正常升高）。

（二）服務(wù)狀態(tài)閾值

1.Web服務(wù)（HTTP/HTTPS）：

-警告級別：

-平均響應(yīng)時間>5秒，持續(xù)5分鐘；

-5XX錯誤率>1%，持續(xù)10分鐘。

-嚴重級別：

-平均響應(yīng)時間>10秒，持續(xù)10分鐘；

-5XX錯誤率>5%，持續(xù)20分鐘；

-服務(wù)不可達（500/503錯誤），持續(xù)10分鐘。

-說明：需監(jiān)控特定API接口的響應(yīng)時間，而非全站平均。

2.數(shù)據(jù)庫服務(wù)（MySQL/Oracle）：

-警告級別：

-主從延遲>1秒，持續(xù)5分鐘；

-連接數(shù)>90%容量，持續(xù)10分鐘；

-InnoDB日志文件大小>80%閾值。

-嚴重級別：

-主從延遲>3秒，持續(xù)10分鐘；

-連接數(shù)>95%容量，持續(xù)20分鐘；

-數(shù)據(jù)庫進程阻塞時間>30秒。

-說明：需定期檢查慢查詢?nèi)罩荆R別潛在性能問題。

（三）磁盤存儲閾值

1.磁盤空間：

-警告級別：

-文件系統(tǒng)可用空間<10%，持續(xù)10分鐘；

-臨時日志文件（如MySQLbinlog）占用>70%分區(qū)。

-嚴重級別：

-文件系統(tǒng)可用空間<5%，持續(xù)20分鐘；

-臨時文件占用>90%分區(qū)。

-說明：需監(jiān)控關(guān)鍵業(yè)務(wù)分區(qū)（如數(shù)據(jù)庫數(shù)據(jù)盤、應(yīng)用日志盤）。

2.磁盤健康度：

-警告級別：

-SMART檢測到“警告”狀態(tài)（如Reallocated_Sector_Ct增加）；

-磁盤讀寫錯誤率>0.1%。

-嚴重級別：

-SMART檢測到“失敗”狀態(tài)；

-磁盤讀寫錯誤率>0.5%。

-說明：需配置監(jiān)控工具定期執(zhí)行磁盤健康自檢。

（四）系統(tǒng)日志閾值

1.警告級別：

-關(guān)鍵服務(wù)（如SSH、Nginx、數(shù)據(jù)庫守護進程）出現(xiàn)“警告”級別日志，持續(xù)5分鐘。

2.嚴重級別：

-關(guān)鍵服務(wù)出現(xiàn)“錯誤”或“嚴重”級別日志，持續(xù)10分鐘。

-說明：需配置日志分析工具（如ELKStack、Splunk），提取關(guān)鍵字段（如錯誤碼、時間戳）。

三、告警級別劃分

（一）告警分類

1.警告級別（黃色）：一般性異常，當前未影響核心業(yè)務(wù)，但可能發(fā)展為嚴重問題，需在下一個工作周期內(nèi)關(guān)注。

-示例：CPU使用率短期峰值、磁盤空間輕微不足、非核心服務(wù)響應(yīng)時間略長。

2.嚴重級別（紅色）：重大異常，已影響或可能影響核心業(yè)務(wù)，需立即響應(yīng)處理。

-示例：核心服務(wù)響應(yīng)時間顯著增加、數(shù)據(jù)庫主從延遲、關(guān)鍵磁盤空間不足。

3.緊急級別（紫色）：系統(tǒng)崩潰或數(shù)據(jù)丟失風險，需立即停機或采取緊急措施恢復。

-示例：操作系統(tǒng)崩潰、數(shù)據(jù)庫實例丟失、磁盤控制器故障。

（二）告警優(yōu)先級

1.優(yōu)先級排序：緊急級別>嚴重級別>警告級別。

2.同一級別內(nèi)，按以下標準排序：

-影響業(yè)務(wù)范圍（全站>核心業(yè)務(wù)>單服務(wù)）；

-恢復難度（停機修復>重啟修復>配置調(diào)整）；

-數(shù)據(jù)丟失風險（高風險>中風險>低風險）。

3.示例排序（嚴重級別）：

-優(yōu)先級1：核心數(shù)據(jù)庫服務(wù)不可用；

-優(yōu)先級2：全站W(wǎng)eb服務(wù)響應(yīng)時間>20秒；

-優(yōu)先級3：非核心應(yīng)用服務(wù)不可用。

四、告警通知機制

（一）通知渠道配置

1.短信：適用于緊急級別告警，需確保發(fā)送服務(wù)商覆蓋所有責任人手機號。

2.郵件：適用于警告級別及以上，郵件內(nèi)容需包含告警指標、影響范圍、初步建議。

-標準郵件模板：

```

主題：【告警】[服務(wù)器名]-[告警級別]-[告警指標]

內(nèi)容：

-時間：[告警時間]

-指標：[具體數(shù)值]

-影響服務(wù)：[受影響服務(wù)列表]

-建議：[初步處理步驟]

```

3.企業(yè)微信/釘釘：適用于日常監(jiān)控告警，需創(chuàng)建告警機器人，支持自定義關(guān)鍵詞觸發(fā)。

4.監(jiān)控平臺彈窗：適用于實時告警，需在監(jiān)控大屏和責任人電腦上展示。

（二）通知對象與流程

1.告警分級通知：

-緊急級別：立即通知一線運維及值班經(jīng)理；

-嚴重級別：通知一線運維、二線技術(shù)專家；

-警告級別：通知對應(yīng)業(yè)務(wù)負責人及一線運維。

2.通知確認機制：

-收到通知的責任人需在監(jiān)控平臺確認收到，避免重復通知。

3.通知升級流程：

-30分鐘內(nèi)未確認處理的告警，自動升級至下一級責任人（如從一線到二線）。

-示例升級路徑：一線運維（告警接收）→二線技術(shù)專家（復雜問題處理）→運維主管（協(xié)調(diào)資源）。

五、告警處理流程

（一）告警接收與確認

1.接收環(huán)節(jié)：

-監(jiān)控系統(tǒng)（如Zabbix、Prometheus、Nagios）告警觸發(fā)后，自動通過通知渠道推送。

-責任人30分鐘內(nèi)必須確認告警狀態(tài)（如點擊“已讀”或回復“收到”）。

2.確認內(nèi)容：

-核實告警指標是否屬實（可通過監(jiān)控平臺或日志驗證）；

-記錄首次確認時間、告警ID及初步現(xiàn)象描述。

（二）問題排查與解決（StepbyStep）

1.第一步：初步評估

-查看告警歷史：該指標是否為首次告警？近期是否有類似告警？

-檢查關(guān)聯(lián)告警：是否存在其他相關(guān)告警（如CPU高+內(nèi)存高通常關(guān)聯(lián)內(nèi)存泄漏）。

-核實業(yè)務(wù)影響：該服務(wù)器是否承載核心業(yè)務(wù)？當前業(yè)務(wù)狀態(tài)如何？

2.第二步：數(shù)據(jù)收集

-查看系統(tǒng)日志：/var/log/messages、/var/log/syslog、應(yīng)用日志等。

-使用監(jiān)控工具采集實時數(shù)據(jù)：如`top-c`、`free-m`、`iostat-x110`、`netstat-tulnp`。

-檢查外部依賴：如數(shù)據(jù)庫主從同步狀態(tài)、負載均衡器健康檢查。

3.第三步：定位原因

-按以下場景排查：

-CPU高：

-使用`psauxf`查找TOP進程；

-檢查進程狀態(tài)（僵尸進程、睡眠狀態(tài)）；

-分析是否為內(nèi)存泄漏（結(jié)合內(nèi)存使用率）。

-內(nèi)存高：

-使用`htop`或`vmstat`分析內(nèi)存分配；

-檢查OOMKiller記錄（/proc/vmstat中的ksm_oom)；

-查看應(yīng)用日志是否存在內(nèi)存錯誤。

-磁盤I/O慢：

-使用`iostat-x`分析磁盤活動隊列長度（await）；

-檢查磁盤空間是否已滿；

-使用`iotop`定位高I/O進程。

-網(wǎng)絡(luò)流量異常：

-使用`nload`或`iftop`檢查流量來源/去向；

-檢查防火墻規(guī)則是否誤攔；

-對比歷史流量數(shù)據(jù)。

-服務(wù)不可達：

-檢查服務(wù)進程是否存活（`systemctlstatus[service_name]`）；

-檢查端口監(jiān)聽狀態(tài)（`ss-tulnp`）；

-檢查防火墻端口是否開放。

4.第四步：執(zhí)行修復

-根據(jù)原因采取行動：

-負載過高：重啟高負載進程、增加服務(wù)器資源（如CPU/內(nèi)存）、調(diào)整應(yīng)用配置（如限流）。

-內(nèi)存泄漏：臨時重啟服務(wù)、修復代碼Bug、優(yōu)化內(nèi)存使用策略。

-磁盤空間滿：清理臨時文件、擴容磁盤、調(diào)整日志存儲策略。

-服務(wù)故障：重啟服務(wù)、回滾最近變更、更換故障硬件。

-處理過程中需持續(xù)監(jiān)控指標變化，驗證修復效果。

5.第五步：記錄與歸檔

-在監(jiān)控平臺更新告警狀態(tài)為“處理中”；

-處理完成后，更新為“已解決”，并記錄：

-解決方法；

-處理耗時；

-是否需要后續(xù)跟進（如代碼上線、配置變更）。

（三）告警升級與應(yīng)急響應(yīng)

1.升級條件：

-責任人超時未處理；

-告警指標持續(xù)惡化（如CPU從90%升至95%）；

-初步處理無效，問題未得到緩解。

2.應(yīng)急響應(yīng)預案：

-緊急級別：啟動應(yīng)急預案，如切換備用服務(wù)器、臨時降級服務(wù)、通知管理層。

-嚴重級別：調(diào)動二線專家介入，必要時暫停非核心服務(wù)以保障核心業(yè)務(wù)。

六、文檔管理

（一）規(guī)范更新與維護

1.定期審核（每季度一次）：

-回顧近三個月告警數(shù)據(jù)，統(tǒng)計誤報率、漏報率；

-評估現(xiàn)有閾值是否合理（如業(yè)務(wù)變化導致指標異常）。

2.閾值調(diào)整流程：

-提出調(diào)整申請（說明原因、建議值）；

-技術(shù)團隊測試驗證；

-運維主管審批后更新監(jiān)控配置。

3.案例庫建立：

-收集典型告警案例（如內(nèi)存泄漏、磁盤故障）；

-記錄排查過程、解決方案及預防措施。

（二）培訓與考核

1.新人培訓：

-新入職運維人員需在1個月內(nèi)完成告警規(guī)范培訓；

-考核內(nèi)容包括：告警流程理解、常用監(jiān)控工具操作、典型問題排查。

2.定期培訓：

-每半年組織一次進階培訓，內(nèi)容涵蓋復雜場景分析、應(yīng)急預案演練。

3.考核機制：

-通過監(jiān)控平臺數(shù)據(jù)統(tǒng)計告警響應(yīng)時間、解決率；

-將告警處理能力納入績效考核指標。

（三）工具與文檔同步

1.監(jiān)控平臺配置：

-定期檢查告警規(guī)則有效性，確保通知渠道正常；

-優(yōu)化告警規(guī)則，減少同類告警合并（如連續(xù)5次CPU高告警合并為一次）。

2.文檔更新要求：

-規(guī)范內(nèi)容變更后，需在文檔庫同步更新；

-告警處理流程圖、閾值表等可視化文檔需保持最新。

七、附錄

（一）常用監(jiān)控工具命令清單

1.CPU使用率：`top-c`、`mpstat-PALL12`

2.內(nèi)存使用率：`free-m`、`vmstat12`

3.磁盤I/O：`iostat-x110`、`iotop-o`

4.網(wǎng)絡(luò)流量：`nload`、`iftop-n`

5.服務(wù)狀態(tài)：`systemctlstatus[service_name]`、`ss-tulnp`

6.日志查看：`journalctl-xe`、`grep"ERROR"/var/log/syslog`

（二）告警處理流程圖

（此處可插入流程圖，展示從告警接收→確認→排查→解決→歸檔的完整步驟）

（三）緊急聯(lián)系人列表

（列出各層級責任人及聯(lián)系方式，按告警級別劃分優(yōu)先級）

一、概述

服務(wù)器監(jiān)控告警規(guī)范旨在建立一套系統(tǒng)化、標準化的告警管理流程，確保及時發(fā)現(xiàn)并處理服務(wù)器運行中的異常情況，保障IT基礎(chǔ)設(shè)施的穩(wěn)定性和可靠性。本規(guī)范涵蓋了告警閾值設(shè)定、告警級別劃分、告警通知機制、告警處理流程及文檔管理等方面，適用于企業(yè)內(nèi)部所有服務(wù)器及相關(guān)系統(tǒng)的監(jiān)控告警管理。

二、告警閾值設(shè)定

（一）性能指標閾值

1.CPU使用率：

-警告級別（黃色）：>70%，持續(xù)5分鐘；

-嚴重級別（紅色）：>90%，持續(xù)10分鐘。

2.內(nèi)存使用率：

-警告級別：>75%，持續(xù)10分鐘；

-嚴重級別：>95%，持續(xù)20分鐘。

3.磁盤I/O：

-警告級別：I/O延遲>100ms，持續(xù)15分鐘；

-嚴重級別：I/O延遲>300ms，持續(xù)30分鐘。

4.網(wǎng)絡(luò)流量：

-警告級別：單接口流量>1Gbps，持續(xù)10分鐘；

-嚴重級別：單接口流量>1.5Gbps，持續(xù)20分鐘。

（二）服務(wù)狀態(tài)閾值

1.Web服務(wù)（HTTP/HTTPS）：

-警告級別：響應(yīng)時間>5秒，持續(xù)5分鐘；

-嚴重級別：服務(wù)不可達（500/503錯誤），持續(xù)10分鐘。

2.數(shù)據(jù)庫服務(wù)（MySQL/Oracle）：

-警告級別：連接數(shù)>90%容量，持續(xù)10分鐘；

-嚴重級別：主從延遲>5秒，持續(xù)20分鐘。

三、告警級別劃分

（一）告警分類

1.警告級別（黃色）：一般性異常，不影響核心業(yè)務(wù)，需及時關(guān)注。

2.嚴重級別（紅色）：重大異常，可能影響業(yè)務(wù)運行，需立即處理。

3.緊急級別（紫色）：系統(tǒng)崩潰或數(shù)據(jù)丟失風險，需立即停機排查。

（二）告警優(yōu)先級

1.緊急級別>嚴重級別>警告級別。

2.相同級別內(nèi)，按影響范圍和恢復時間排序。

四、告警通知機制

（一）通知渠道

1.短信：適用于緊急級別告警。

2.郵件：適用于警告級別及以上。

3.企業(yè)微信/釘釘：適用于日常監(jiān)控告警。

4.監(jiān)控平臺彈窗：適用于實時告警。

（二）通知流程

1.監(jiān)控系統(tǒng)觸發(fā)告警后，自動推送至對應(yīng)責任人。

2.30分鐘內(nèi)未響應(yīng)的告警，升級至下一級責任人。

五、告警處理流程

（一）告警接收與確認

1.責任人30分鐘內(nèi)確認告警狀態(tài)。

2.記錄告警時間、指標及初步現(xiàn)象。

（二）問題排查與解決

1.按以下步驟操作：

(1)檢查監(jiān)控數(shù)據(jù)與實際日志是否一致；

(2)分析可能原因（如負載過高、配置錯誤等）；

(3)執(zhí)行修復措施（如重啟服務(wù)、擴容資源等）。

2.處理過程中需同步更新告警狀態(tài)。

（三）告警關(guān)閉與歸檔

1.確認問題解決后，關(guān)閉告警。

2.記錄處理結(jié)果及改進建議，存檔至監(jiān)控平臺。

六、文檔管理

（一）定期更新

1.每季度審核告警閾值及處理流程。

2.根據(jù)實際案例調(diào)整告警規(guī)則。

（二）培訓與維護

1.每半年組織一次告警規(guī)范培訓。

2.確保監(jiān)控團隊熟悉告警流程及職責。

一、概述

服務(wù)器監(jiān)控告警規(guī)范旨在建立一套系統(tǒng)化、標準化的告警管理流程，確保及時發(fā)現(xiàn)并處理服務(wù)器運行中的異常情況，保障IT基礎(chǔ)設(shè)施的穩(wěn)定性和可靠性。本規(guī)范涵蓋了告警閾值設(shè)定、告警級別劃分、告警通知機制、告警處理流程及文檔管理等方面，適用于企業(yè)內(nèi)部所有服務(wù)器及相關(guān)系統(tǒng)的監(jiān)控告警管理。其核心目標是通過明確的規(guī)則和流程，減少誤報和漏報，優(yōu)化資源分配，提升故障響應(yīng)效率，最終降低業(yè)務(wù)中斷風險。

二、告警閾值設(shè)定

（一）性能指標閾值

1.CPU使用率：

-警告級別（黃色）：

-首次觸發(fā)：>70%，持續(xù)5分鐘；

-重復觸發(fā)：>65%，持續(xù)3分鐘。

-嚴重級別（紅色）：

-首次觸發(fā)：>90%，持續(xù)10分鐘；

-重復觸發(fā)：>85%，持續(xù)5分鐘。

-說明：針對核心應(yīng)用服務(wù)器，閾值可適當調(diào)低；對于后臺任務(wù)服務(wù)器，可適當調(diào)高。

2.內(nèi)存使用率：

-警告級別：

-交換空間使用率>50%，持續(xù)10分鐘；

-堆內(nèi)存使用率>75%，持續(xù)15分鐘。

-嚴重級別：

-交換空間使用率>70%，持續(xù)20分鐘；

-堆內(nèi)存使用率>90%，持續(xù)30分鐘。

-說明：需區(qū)分物理內(nèi)存和虛擬內(nèi)存（交換空間）的告警。

3.磁盤I/O：

-警告級別：

-平均磁盤讀寫延遲>100ms，持續(xù)15分鐘；

-IOPS（每秒輸入/輸出操作數(shù)）低于平均值的50%，持續(xù)10分鐘。

-嚴重級別：

-平均磁盤讀寫延遲>300ms，持續(xù)30分鐘；

-IOPS持續(xù)低于平均值的30%，持續(xù)20分鐘。

-說明：重點關(guān)注數(shù)據(jù)庫、文件服務(wù)等I/O密集型應(yīng)用的磁盤性能。

4.網(wǎng)絡(luò)流量：

-警告級別：

-單接口流量>1Gbps，持續(xù)10分鐘；

-入侵檢測系統(tǒng)（IDS）或防火墻發(fā)出特定類型告警（如SQL注入嘗試）。

-嚴重級別：

-單接口流量>1.5Gbps，持續(xù)20分鐘；

-IDS/防火墻發(fā)出高危攻擊告警。

-說明：網(wǎng)絡(luò)流量告警需結(jié)合業(yè)務(wù)周期（如促銷活動期間流量正常升高）。

（二）服務(wù)狀態(tài)閾值

1.Web服務(wù)（HTTP/HTTPS）：

-警告級別：

-平均響應(yīng)時間>5秒，持續(xù)5分鐘；

-5XX錯誤率>1%，持續(xù)10分鐘。

-嚴重級別：

-平均響應(yīng)時間>10秒，持續(xù)10分鐘；

-5XX錯誤率>5%，持續(xù)20分鐘；

-服務(wù)不可達（500/503錯誤），持續(xù)10分鐘。

-說明：需監(jiān)控特定API接口的響應(yīng)時間，而非全站平均。

2.數(shù)據(jù)庫服務(wù)（MySQL/Oracle）：

-警告級別：

-主從延遲>1秒，持續(xù)5分鐘；

-連接數(shù)>90%容量，持續(xù)10分鐘；

-InnoDB日志文件大小>80%閾值。

-嚴重級別：

-主從延遲>3秒，持續(xù)10分鐘；

-連接數(shù)>95%容量，持續(xù)20分鐘；

-數(shù)據(jù)庫進程阻塞時間>30秒。

-說明：需定期檢查慢查詢?nèi)罩荆R別潛在性能問題。

（三）磁盤存儲閾值

1.磁盤空間：

-警告級別：

-文件系統(tǒng)可用空間<10%，持續(xù)10分鐘；

-臨時日志文件（如MySQLbinlog）占用>70%分區(qū)。

-嚴重級別：

-文件系統(tǒng)可用空間<5%，持續(xù)20分鐘；

-臨時文件占用>90%分區(qū)。

-說明：需監(jiān)控關(guān)鍵業(yè)務(wù)分區(qū)（如數(shù)據(jù)庫數(shù)據(jù)盤、應(yīng)用日志盤）。

2.磁盤健康度：

-警告級別：

-SMART檢測到“警告”狀態(tài)（如Reallocated_Sector_Ct增加）；

-磁盤讀寫錯誤率>0.1%。

-嚴重級別：

-SMART檢測到“失敗”狀態(tài)；

-磁盤讀寫錯誤率>0.5%。

-說明：需配置監(jiān)控工具定期執(zhí)行磁盤健康自檢。

（四）系統(tǒng)日志閾值

1.警告級別：

-關(guān)鍵服務(wù)（如SSH、Nginx、數(shù)據(jù)庫守護進程）出現(xiàn)“警告”級別日志，持續(xù)5分鐘。

2.嚴重級別：

-關(guān)鍵服務(wù)出現(xiàn)“錯誤”或“嚴重”級別日志，持續(xù)10分鐘。

-說明：需配置日志分析工具（如ELKStack、Splunk），提取關(guān)鍵字段（如錯誤碼、時間戳）。

三、告警級別劃分

（一）告警分類

1.警告級別（黃色）：一般性異常，當前未影響核心業(yè)務(wù)，但可能發(fā)展為嚴重問題，需在下一個工作周期內(nèi)關(guān)注。

-示例：CPU使用率短期峰值、磁盤空間輕微不足、非核心服務(wù)響應(yīng)時間略長。

2.嚴重級別（紅色）：重大異常，已影響或可能影響核心業(yè)務(wù)，需立即響應(yīng)處理。

-示例：核心服務(wù)響應(yīng)時間顯著增加、數(shù)據(jù)庫主從延遲、關(guān)鍵磁盤空間不足。

3.緊急級別（紫色）：系統(tǒng)崩潰或數(shù)據(jù)丟失風險，需立即停機或采取緊急措施恢復。

-示例：操作系統(tǒng)崩潰、數(shù)據(jù)庫實例丟失、磁盤控制器故障。

（二）告警優(yōu)先級

1.優(yōu)先級排序：緊急級別>嚴重級別>警告級別。

2.同一級別內(nèi)，按以下標準排序：

-影響業(yè)務(wù)范圍（全站>核心業(yè)務(wù)>單服務(wù)）；

-恢復難度（停機修復>重啟修復>配置調(diào)整）；

-數(shù)據(jù)丟失風險（高風險>中風險>低風險）。

3.示例排序（嚴重級別）：

-優(yōu)先級1：核心數(shù)據(jù)庫服務(wù)不可用；

-優(yōu)先級2：全站W(wǎng)eb服務(wù)響應(yīng)時間>20秒；

-優(yōu)先級3：非核心應(yīng)用服務(wù)不可用。

四、告警通知機制

（一）通知渠道配置

1.短信：適用于緊急級別告警，需確保發(fā)送服務(wù)商覆蓋所有責任人手機號。

2.郵件：適用于警告級別及以上，郵件內(nèi)容需包含告警指標、影響范圍、初步建議。

-標準郵件模板：

```

主題：【告警】[服務(wù)器名]-[告警級別]-[告警指標]

內(nèi)容：

-時間：[告警時間]

-指標：[具體數(shù)值]

-影響服務(wù)：[受影響服務(wù)列表]

-建議：[初步處理步驟]

```

3.企業(yè)微信/釘釘：適用于日常監(jiān)控告警，需創(chuàng)建告警機器人，支持自定義關(guān)鍵詞觸發(fā)。

4.監(jiān)控平臺彈窗：適用于實時告警，需在監(jiān)控大屏和責任人電腦上展示。

（二）通知對象與流程

1.告警分級通知：

-緊急級別：立即通知一線運維及值班經(jīng)理；

-嚴重級別：通知一線運維、二線技術(shù)專家；

-警告級別：通知對應(yīng)業(yè)務(wù)負責人及一線運維。

2.通知確認機制：

-收到通知的責任人需在監(jiān)控平臺確認收到，避免重復通知。

3.通知升級流程：

-30分鐘內(nèi)未確認處理的告警，自動升級至下一級責任人（如從一線到二線）。

-示例升級路徑：一線運維（告警接收）→二線技術(shù)專家（復雜問題處理）→運維主管（協(xié)調(diào)資源）。

五、告警處理流程

（一）告警接收與確認

1.接收環(huán)節(jié)：

-監(jiān)控系統(tǒng)（如Zabbix、Prometheus、Nagios）告警觸發(fā)后，自動通過通知渠道推送。

-責任人30分鐘內(nèi)必須確認告警狀態(tài)（如點擊“已讀”或回復“收到”）。

2.確認內(nèi)容：

-核實告警指標是否屬實（可通過監(jiān)控平臺或日志驗證）；

-記錄首次確認時間、告警ID及初步現(xiàn)象描述。

（二）問題排查與解決（StepbyStep）

1.第一步：初步評估

-查看告警歷史：該指標是否為首次告警？近期是否有類似告警？

-檢查關(guān)聯(lián)告警：是否存在其他相關(guān)告警（如CPU高+內(nèi)存高通常關(guān)聯(lián)內(nèi)存泄漏）。

-核實業(yè)務(wù)影響：該服務(wù)器是否承載核心業(yè)務(wù)？當前業(yè)務(wù)狀態(tài)如何？

2.第二步：數(shù)據(jù)收集

-查看系統(tǒng)日志：/var/log/messages、/var/log/syslog、應(yīng)用日志等。

-使用監(jiān)控工具采集實時數(shù)據(jù)：如`top-c`、`free-m`、`iostat-x110`、`netstat-tulnp`。

-檢查外部依賴：如數(shù)據(jù)庫主從同步狀態(tài)、負載均衡器健康檢查。

3.第三步：定位原因

-按以下場景排查：

-CPU高：

-使用`psauxf`查找TOP進程；

-檢查進程狀態(tài)（僵尸進程、睡眠狀態(tài)）；

-分析是否為內(nèi)存泄漏（結(jié)合內(nèi)存使用率）。

-內(nèi)存高：

-使用`htop`或`vmstat`分析內(nèi)存分配；

-檢查OOMKiller記錄（/proc/vmstat中的ksm_oom)；

-查看應(yīng)用日志是否存在內(nèi)存錯誤。

-磁盤I/O慢：

-使用`iostat-x`分析磁盤活動隊列長度（await）；

-檢查磁盤空間是否已滿；

-使用`iotop`定位高I/O進程。

-網(wǎng)絡(luò)流量異常：

-使用`nload`或`iftop`檢查流量來源/去向；

-檢查防火墻規(guī)則是否誤攔；

-對比歷史流量數(shù)據(jù)。

-服務(wù)不可達：

-檢查服務(wù)進程是否存活（`systemctlstatus[service_name]`）；

-檢查端口監(jiān)聽狀態(tài)（`ss-tulnp`）；

-檢查防火墻端口是否開放。

4.第四步：執(zhí)行修復

-根據(jù)原因采取行動：

-負載過高：重啟高負載進程、增加服務(wù)器資源（如CPU/內(nèi)存）、調(diào)整應(yīng)用配置（如限流）。

-內(nèi)存泄漏：臨時重啟服務(wù)、修復代碼Bug、優(yōu)化內(nèi)