created by arch | time：2020/02/19
在生產環境中，保證系統服務執行的穩定性、可靠性十分重要。一方面，要求在服務執行過程中，對服務的執行狀態、負載情況有時刻的掌握；另一方面在服務中斷或者錯誤報出後，及時告警並發現問題，獲取日誌、還原問題場景、排除bug；
縱向的監控體系從上往下分為4個層次的監控（最大外延和最小內涵）：
第1層：業務級
業務的監控物件包括業務關心的各項指標，例如關鍵方法執行耗時、每分鐘的處理里程等。該部分目前主要通過elk實施。
第2層次:應用/服務級
通過對應用/服務實時負載情況、心跳健康狀況、執行時異常錯誤監控，提前做好預防保持穩定，也有利於bug回溯優化現有程式。
（1）監控內容
我們監控告警的內容有三個方面如下：
第一：應用實時負載狀態監控（包含微服務/ml）；
第二：應用心跳檢測，健康中斷檢測監控告警；
第三：應用框架日誌中執行時error錯誤監控告警；
（2）bug現場還原
除了監控告警之外，怎樣儲存問題現場。如果告警成功，我們的錯誤日誌和恢復場景涉及的中間資料庫檔案如何獲取，在物理隔離的生產環境中如何有效的傳遞給開發人員做場景恢復的問題，也是需要考慮討論的。
第3層次：元件級
元件實時執行的負載情況監控；例如redis、pg的實時負載情況；包含程序的程序cpu使用量、記憶體使用率、gc情況的實時狀態；
第4層次：虛擬機器物理資源
虛擬機器資源和負載情況，cpu、網路、磁碟io、網路io情況進行監控，及時掌握對整體資源的利用率。（該部分內容可能是運維人員管理平台的時候自帶的監控管理）
其中前三層是我們關注的重點。
場景1.對spark streaming （ml/broker）相關：
第一，程式異常掉線時候，獲得通知訊息給運維人員，並且將相應的錯誤日誌、以及用於恢復環境的資料庫檔案等down取下來給開發測試人員恢復場景、測試修復bug.
第二，ml程式雖然沒退出執行，但是其中仍然有error日誌需要修復，需要監控捕獲error告警並通知down下來日誌檔案；
第三，（1）需要對業務日誌的業務指標監控（例如特定方法的耗時，超閾值告警等）； （2）需要監控業務指標的實時狀態，這個kibana是否可以自帶dashboard實現。
場景3 針對目前應用/服務、元件的執行實時負載等狀態監控；
（1）例如微服務的執行狀態、maplearning的執行負載狀態（spark ui可見）；
（2）以及各個元件的狀態、例如redis和pg、kafka；
(2)針對場景3解決方案
(3)物理資源健康
其他的像元件宕機監控和節點物理資源監控未做。（可能是四維雲平台要做的）。
(4)關於問題追查與恢復現場解決方案
（1）針對以上問題，第一需要討論現在已有解決方案的合理性和可行性；第二，對現有的方案的補充建議；
重點在於四維雲平台和我們研發的隔離程度，我們以上的方式是否可以滿足上線要求；
（2）目前上線的緊急重點在於：
問題一：如果我們知道了程式出現異常，那麼我們怎樣拿到異常日誌和恢復現場所需要的中間狀態資料，包含redis、pg、kafka等；
問題二： 怎樣將框架日誌down下來？
系統日誌down下來，filebeat從**獲取是難點（dcos/mesos確定的檔案目錄在**?）。
Postfix 佇列監控告警,傳送告警郵件
設定監控的最大佇列數,當postfix佇列數超過設定警戒值自動傳送告警郵件給相關運維管理人員 bin bash 佇列目錄 queue dir naes incoming active bounce defer deferred corrupt hold trace admin 15801509423...
監控告警優化需求的思考
目前主要負責監控告警，屬於運維開發的範疇。公司有三個以上核心專案，應用服務人數超過萬人。運維人員40人左右，總專案幾百個，資源分配不均。只能集中力量辦大事。昨天看到一篇文章，客戶和使用者的區別，當然產品是面向to c的，但是我認為所有的概念都是可以相互轉換的。客戶其實是可以對產品好壞進行評價，具有拍...
prometheus監控告警終極玩法包教包會的那種
倉庫中包含四個資料夾，分別介紹如下 prometheus prometheus的安裝與相關配置檔案。alert 告警的安裝與相關配置檔案。kube state metrics k8s提供的metrics，不是必須安裝的，僅在用到的情況下安裝即可。rules targets 需要持久化的檔案，包括ru...