###### tags: `Linux`, `SRE` # SRE 讀書會 Round 4 #17 - 線上讀書會共筆 ## 活動資訊 * Date: [2020/12/10] (四) 20:00 - 21:30 * [導讀進度表](https://docs.google.com/spreadsheets/d/1Lgti3mILkvwxyzklX1vvLraaGD-7ePK9rkmlulfOknE/edit#gid=0) * [導讀 Guideline](https://study-area.sre.tw/GuideLine/) * Github: [study-area-docs](https://github.com/cross-community/study-area-docs) --- # 現場共筆 ## 52 | 案例篇：服務吞吐量下降很厲害，怎麼分析？ - 義格 worker_cpu_affinity * [Tuning NGINX for Performance](https://www.nginx.com/blog/tuning-nginx/) ## 53 | 套路篇：系統監控的綜合思路 - FreddyFan - 監控數據: 定義SLO,SLI,SLA，需要去定義相關內容 - Java vs PHP: cpu使用率會不同 * 可視覺化: * 公司組織架構有差: 例如有監控team，但是ap系統有自己的監控指標，所以不被導入，無法統一監管 - 可參考: 網站可靠性工程工作手冊。 - 本章節為系統層的監控。 - [监控RED方法](https://www.jianshu.com/p/20f3428535e3) ## 54 | 套路篇：應用監控的一般思路 - 義格 - 1. 指標: 請求率,錯誤率,回應時間 - 2. 日誌: 分析當下服務狀態,分級,分類 - 3. 服務之間互動狀況: 依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而導致應用程序的運行受限。 - 依賴服務瓶頸 - 直接或者間接調用的服務出現了性能問題，從而導致應用程序的響應變慢，或者錯誤率升高。 - 應用程式瓶頸 - 多線程處理不當、死鎖、業務算法的複雜度過高等等。 * ACQUIA(專門給Drupal使用): https://www.acquia.com/ > 55 | 套路篇：分析性能問題的一般步驟- Jeri Chen > 講者有提到監控畫面(ACQUIA)為公司內部，要記得剪掉相關內容。 ## 56 | 套路篇：優化性能問題的一般方法 - John * 網路慢的成本比硬碟高 * 陌生系統先看依賴性，是否有需要? - 不需要依賴K8s,不依賴雲端,盡量一台PC可以起來 * open soucre fork是否有需要回饋社群: - 要注意在公司的創作著作權應該屬於公司，貢獻回去會有法律問題 * 重造輪子 v.s. 使用工具: * 優點: 可以練功,未必要在自己的prod使用 * sre角色: 大多為使用方，所以會認為不用重造輪子 - 討論此問題，不同出發點觀察此問題 --- # 參考資料 * [社群FB活動貼文 : Round 4 #17](https://www.facebook.com/groups/sre.taiwan/permalink/1891804660985429/)