參考：
當我們的伺服器或某些業務指標出現差錯時，告警系統可以反饋資訊
減少人力監控，算是自動化運維的一種手段
這樣不用時時盯著伺服器，可以睡個稍微好一點的覺~
1.每次收到告警提示之後可以立即評估影響的範圍，並且每乙個告警都需要做出分級響應；
2.使一些無關緊要的事情不會告警；
3.要採集真正重要的指標，盲目地採集那些容易獲取的指標，並隨意地設定閾值告警是大部分糟糕的告警質量的根源。
4.告警的本質是當一些無法自動化維護的服務出錯後，通知人去修正，所以一些可以自動化的操作，告警系統可以自己執行
比如伺服器掛了，自動切換為備份機，再去人工修復主機。
關於業務規則的監控的例子：
比如吃雞中，不同的槍和被打中人的護甲造成的傷害應該是一定的，如果超過這個限度，就說明有人開掛了，這時候就應該告警了；
當然，還有很多其他維度，比如開槍後槍的後座力如何等等，只要不符合實際情況，即可告警。關於系統可靠性的監控的例子：
比如伺服器是否掛了，併發是否過高等等；
系統1：
可以使用訊息佇列，來將請求和響應解耦，也加快處理速度，因為告警並非實時性的業務
當然，實際應用中，系統不會孤立執行，改造成的系統2如下：
最下方為其他系統，不同系統需要不同的資源
如乙個db會依賴於底層的cpu，記憶體，磁碟等資源；乙個http服務會依賴於底層的db服務；乙個應用會依賴於數個底層的rpc服務
如何判斷需要獲取哪些指標呢？可以根據我們的目標來判斷：
a.系統是否在持續完成其設定的工作第乙個問題是最重要的，我們必須保證系統正常的執行，而系統能否正常執行，取決於許多服務，如dbb.使用者體驗是否好
c.問題或者瓶頸在**
C告警設計
本模組的功能是將產生的告警輸出到串列埠或者日誌檔案 輸出到串列埠的告警等級預設為info級別 輸出到檔案的告警等級預設為alert級別，將alert及更高階別的資訊儲存到檔案。當其他模組有告警產生時，呼叫syslogmsg moduleidmodule,levelid level,const cha...
關於積分的系統設計
需求是這樣的 後台可以設定一系列的積分規則，比如使用者註冊在這段時間內送200積分，過段時間只送100積分，再過段時間可能就不送積分了，然後針對使用者下單購買，也送一定的積分，想請教這樣乙個需求，從資料庫設計到系統實現，分別該怎麼設計呢？我目前想的是 1 資料庫設計 資料庫表包含 id，方法名，積分...
綜合日誌分析系統 綜合告警系統
日誌審計輸出 日誌審計系統通過三個途徑向審計人員提供審計能力 實時告警 分析報告 事件查詢 實時告警 日誌審計系統實時監控網路及安全裝置 系統平台的安全訪問和各種效能狀態，並進行實時分析記錄，出現不符合預定規則就應該通過裝置遠端主控台 簡訊 郵件 語音提示 qq msn等方式向審計人員傳送實時告警訊...