微服務異常感知與快速定位排錯

場景：

1. 背景一
   1. 在一個歡快假期中的夜深人靜的享受着各自屬於自己夜生活的時候。突然，電話響了！公司的領導讓你馬上處理線上系統問題。
   2. 此時此刻，你的臉可能是這樣的。   (ΩДΩ)      o((⊙﹏⊙))o
   3. 靈魂三問在你的腦海裏迴響着。
      1. 我是誰？
      2. 哪個系統出問題了？
      3. 我該怎麼辦？
2. 背景二
   1. 在一個歡快假期中的夜深人靜的享受着各自屬於自己夜生活的時候。突然，電話響了！N個業務人員告訴你，系統無法操作了，點什麼都沒反應。
   2. 此時此刻，你的臉可能是這樣的。 ┓(;´_｀)┏
   3. 開始忙碌起來了。
      1. 收集物證
      2. 接聽各自電話
      3. 向上反饋
   4. 默默安慰用戶與等待處理。
3. 背景三
   1. 在一個歡快假期中的夜深人靜的享受着各自屬於自己夜生活的時候。突然，企業微信響了，異常聊天羣裏面滿滿的都是運維人員反饋的各種異常問題。
   2. 此時此刻，你的臉可能是這樣的。（＞﹏＜） 不～ 
   3. 開始忙碌起來了。
      1. 聯繫項目負責人
         1. 聯繫技術負責人
            1. 聯繫 1 或 N個 服務負責人
               1. 聯繫1 或者 N 個開發
      2. 聯繫技術負責人
         1. 聯繫 1 或 N個 服務負責人
            1. 聯繫1 或者 N 個開發
      3. 開始協調各自資源與默默等待處理。
4. 場景回到 背景一。

問題：

1. 問題是我們都是知道用戶操作的系統出了問題了，但是不知道是系統哪裏出了問題。
2. 從開始異常到各自通知溝通，再到研發開發開始定位問題，時間已經過去了很久。
3. 核心問題點是
   1. 異常自動感知，不需要等待用戶反饋。
   2. 研發人員可以快速定位問題。
      1. 爲什麼是快速定位問題？
         1. 絕大部分的服務都不是新上線的服務，是經過嚴格測試與實際運行的。代碼邏輯錯誤的可能性是最低的。

如何解決問題：

1. 從上訴來看，我們定位了問題的核心點。
   1. 服務異常感知，我們有各自的監控方案並且也在逐步完善與整合。但是目前缺少一個從服務自身爲維度，進行檢查的監控方案。
      1. 服務定期自檢，反饋是否正常
   2. 提高研發人員定位問題的速度
      1. 覆盤我們出現問題，研發人員需要做哪些步驟，做哪些處理。優化簡化流程。
   3. 不光研發可以定位處理問題，在常見情況下，其他人員也可以定位問題。
      1. 出現問題的情況收集，當看到異常感知報錯的信息後，對比異常消息，直接定位到異常問題。進行鍼對解決。

解決方案

整體思維導圖

 

介紹

1. 頁面
   2. 地址 http://10.10.6.246:18101/wallboard 

2. 報錯通知
   1. DB
      1.  

2. Hystrix

問題排查

1. hystrix

2. 日誌
   1.  

動態日誌級別調整

 

1. 使用場景
   1. 線上問題排查。
2. 使用方式
   1. 直接調整單個運行的節點的日誌級別獲取更詳細的日誌信息。
3. 使用效果
   1. 無需重啓服務即可打印詳細日誌。
   2. 單節點調整，不會影響其他節點。

 

  

歷史狀態日誌

1. 查看一定時間內的微服務狀態信息
   1. 上線下情況
   2. 訪問情況
   3. 異常情況及其詳細信息
   4. 狀態變化時間點

 

實際案例

1. 微服務執行對應數據庫測試語句失敗。
2. 監控頁面微服務對應顏色從綠色變成紅色。
3. 觸發企業微信通知
4. 相關人員獲知微服務出現的異常情況與原因
5. 解決問題
   1. 可以通過異常信息直接判斷異常原因
      1. 直接進行相關處理。
   2. 通過異常信息無法判斷異常原因
      1. 直接訪問該微服務的異常節點查看相關日誌。

 

  

 

低版本問題

 

1. 低版本的配置中心會每次檢查都會訪問一次配置中心數據
   1. 解決方案
      1. 升級爲部門標準版本
   2. 高版本優化
      1. 加入緩存