穩定性 監控 業務後期 - 架構師

穩定性 監控 業務後期 - 架構師 雪崩

本文是以前的思考. 最新思考見穩定性 問題定位 系統優化

總體思路:

    1. 突增緣由

             底層某一個系統資源緊缺的緣由確定來自於上游業務請求量乘以耗時的增加. ( 若是是耗時,那緣由是下游. 若是是流量,緣由是上游 能夠很方便的排除雪崩異常的報警,避免找不到方向..)

             若是都沒有,就有多是內因. 1. 機器緣由 2. 有種多是有幾個耗時語句的執行.(總體統計完,之後看一個耗時接口的各個具體耗時數據,介入分析緣由)

             有了ZipKin統計的各個數據, 就能夠全局的分析耗時成員流量,已經各個依賴關係.

             找到拓撲圖最底層的那個耗時系統進行分析. 1. 請求量有無變,溯源到上游系統相似變化 2.耗時有無變 ,定位到具體某個請求是否耗時佔比比較高,致使總體拔高 (瞬間耗時高,擠佔鏈接數, 這個 佔比區間要儘可能小, 怎麼樣算異常, 要對應到鏈接數 比較少 . 業務方本身配置. ) 3. 都無,可能總體耗時都高.內部硬件,網絡緣由.

         學習 phoenix 的網絡調優經驗

        人工排查經驗,覆盤經驗. 找因果

　　　　 1.  時間點很重要. 因果關係.   (回溯)

             2. 根據各異常,分析上下游耗時,請求量激增.

　　　　 3. 業務核心主流前置接口,用戶重試可瞬間累積到5-10倍. 加上各個流程的重試策略.雪崩時重試級聯.耗時配置= E(下游耗時 * 重試次數) . (累加N個接口每一個都耗時) 重試是爲了可用性,但和穩定性抗壓能力違背.所有默認兩次.

 　　　　　　重試+降級是比較好的方案.按不一樣的業務系統降級.對外服務的系統,隔離性建設很重要.

        穩定性建設:

             外因:

　　　　　　1.作活動 2.催款 

            最終崩塌:

 　　　　　  雪崩. 一個慢 sql,致使全部 sql 耗時增長. 最終致使乘客重試. 致使系統重試 (rpc 重試,mq 重試) 本來保證可用性的都變成了最後一根稻草.

            內因:

                  1. 作好擴容準備

　　　　　　2.作好沒法擴容系統的reviw .

　　　　　　   2.1 非索引

　　　　　　　2.2 索引量查找行數比較大. (對於這些讀,徹底能夠用讀庫擴容的方式實現) .

　　　　　　　　　2.2.1 自動化將99%慢查讀引流到讀庫. 作到可擴容.

　　　　　　   2.3 返回的行數比較大的 sql

　　　　　　　2.4 redis 的 hashList等指令.

 

     案例: 28分 mq 耗時 31

    2. 常態總體就異常

         說明須要擴容了.

            

 

1. 數據採集 (省錢和高效的決策依據)

  1. 操做層級

  2. 網絡層級

  3. 業務層級

       dubbo. 鏈接池 看鏈接無用. 要監控活躍線程樹. 原生是沒有的.

       內部線程池. 活躍線程池數量. 最終提現到流量入口上.

        各個層級的 dubbo 請求數量. 快速定位 provider 耗盡的緣由.

  4. 日誌層級

       error 業務報警, info (再也不穩定性層面,大併發,大流量. )

2. 數據曲線展現 . 大盤本身配置 小米監控 不含 groupby 不如 cboard.

3. 數據監控報警.

    依賴拓撲圖和上面的理論算法.