*?報警系統的意義
*?報警方式
*?報警系統觸發條件
*?接入方式
*?應用場景舉例

## 報警系統的意義 ##

> 結合我們現有的系統，沒有對生產環境運行情況的監控，每天都會報出很多用戶投訴信息，而且開發人員對自己做的系統的運行情況沒有一個全面的掌握，SOA架構里面，接口滿天飛，單一業務出問題，很難找出是哪個模塊導致的， 搞得開發人員處理問題很被動，而且故障都讓用戶第一時間發現并投訴，體驗也不好。

>大家設想一下這樣的場景： 一個用戶在前端頁面下訂單，支付成功后，頁面仍然顯示未支付，在用戶焦慮等待后要投訴時，我們的客服電話或者短信已經通知了用戶，并告知”系統出現異常，我們正在緊急為你處理，請耐心等待后續通知“ ，用戶會感到滿滿的安全感。

總結：先于用戶發現系統異常，并及時處理


##報警方式##

> 根據異常級別，采用短信、郵件方式通知。
> 每周給出報警匯總。

## 報警系統的觸發條件##

1.?所有FATA級別錯誤。
2.?Error錯誤根據指定ErrorCode觸發。
3.?Info類型根據指定ErrorCode頻次觸發。
4.?根據指定接口的響應時長閥值觸發。
5.?根據業務場景自定義。

## 接入方式##

1.?根據所有業務方接入日至系統中的日志來做分析。
2.?平臺指定根據Appid，確定郵件組。
3.?平臺指定ErrorCode，映射郵件人及短信接收人。

## 應用場景舉例##

1.?前段時間生產環境集群cpu load值居高不下，php進程持續高位的問題，根據服務器端排查，確定為php程序鏈接外部資源超時所致，但系統的復雜性，沒辦法確定是什么項目在調用什么服務（接口、數據、分布式文件）時導致的，在排查半天無果后，自動恢復了， 追其原因是因為A項目修改了memcache的鏈接服務器，因memcache響應緩慢導致A項目對外提供的接口偶爾超時導致。?

2.?訂單支付處理異常的問題，偶爾也會接到用戶投訴，根據支付處理的規則分為兩種：
????1.?支付方系統故障，延遲回調。
????2.?我方接受到支付回調結果，但支付腳本異常導致。

????針對這個問題， 支付腳本在處理支付時，會記錄文本及數據庫log，但是不會主動通知到開發者，導致開發者很被動，而且開發者排查問題時，能借助的就是服務器端的log和數據記錄，而無法還原出錯場景。

3.?數據庫連接錯誤、隊列無法寫入、 重要日志記錄失敗（文件、DB無法寫入）

轉載于:https://blog.51cto.com/wufaliang/1543599

總結

以上是生活随笔為你收集整理的报警系统设想的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。