###### 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/)