tags: Linux, SRE

SRE 讀書會 Round 4 #17 - 線上讀書會共筆

活動資訊

現場共筆

52 | 案例篇：服務吞吐量下降很厲害，怎麼分析？ - 義格

worker_cpu_affinity

53 | 套路篇：系統監控的綜合思路 - FreddyFan

  • 監控數據: 定義SLO,SLI,SLA，需要去定義相關內容

    • Java vs PHP: cpu使用率會不同
    • 可視覺化:
    • 公司組織架構有差: 例如有監控team，但是ap系統有自己的監控指標，所以不被導入，無法統一監管

  • 可參考: 網站可靠性工程工作手冊。

  • 本章節為系統層的監控。

  • 监控RED方法

54 | 套路篇：應用監控的一般思路 - 義格

    1. 指標: 請求率,錯誤率,回應時間
    1. 日誌: 分析當下服務狀態,分級,分類
    1. 服務之間互動狀況: 依APM進行使用
      java melody可以看

Q1 : 系統監控與應用監控有什麼差別?
A1 : 不同組織與不同知識背景會有不同看法

55 | 套路篇：分析性能問題的一般步驟 - Jeri Chen

  • 應用程序的監控
    • 指標監控:
      • 主要是對一定時間段內的性能指標進行測量，然後再通過時間序列的方式，進行處理、存儲和告警。
    • 日誌監控:
      • 則可以提供更詳細的上下文信息，通常通過ELK 技術棧，來進行收集、索引和圖形化展示。

系統資源瓶頸: (是最為常見的性能問題)
*可以通過USE法，即使用率、飽和度以及錯誤數這三類指標來衡量

  • 硬件資源:
    • CPU、內存、磁盤和文件系統以及網絡等
  • 軟件資源:
    • 文件描述符數、連接跟踪數、套接字緩衝區大小等
  • 四大模塊核心
    • cpu
      • top、vmstat、pidstat、strace 以及perf 等 tools
    • memery
      • free、vmstat 等 tools
    • disk,file system
      • iostat
    • network

應用程序瓶頸:

  • 資源瓶頸
    • CPU、內存、磁盤和文件系統I/O、網絡以及內核資源等各類軟硬件資源出現了瓶頸，從g.4而導致應用程序的運行受限。
  • 依賴服務瓶頸
    • 直接或者間接調用的服務出現了性能問題，從而導致應用程序的響應變慢，或者錯誤率升高。
  • 應用程式瓶頸
    • 多線程處理不當、死鎖、業務算法的複雜度過高等等。

55 | 套路篇：分析性能問題的一般步驟- Jeri Chen
講者有提到監控畫面(ACQUIA)為公司內部，要記得剪掉相關內容。

56 | 套路篇：優化性能問題的一般方法 - John

  • 網路慢的成本比硬碟高

  • 陌生系統先看依賴性，是否有需要?

    • 不需要依賴K8s,不依賴雲端,盡量一台PC可以起來

  • open soucre fork是否有需要回饋社群:

    • 要注意在公司的創作著作權應該屬於公司，貢獻回去會有法律問題

  • 重造輪子 v.s. 使用工具:

    • 優點: 可以練功,未必要在自己的prod使用
    • sre角色: 大多為使用方，所以會認為不用重造輪子
    • 討論此問題，不同出發點觀察此問題

參考資料

Select a repo