--- title: Talking About DevOps & Observability tags: Sinyi, Observability, Monitoring, Log description: Retrospect and Prospect 2022 slideOptions: controls: true allottedMinutes: 5 --- # Talking About DevOps & Observability.. > Nathan Lu <div style="text-align: right"> 02/23/2022 </div> --- # Outline - 運維盲區Operational Blindness - 監控Monitoring - 紀錄Logging - 指標Metrics - Observability --- # 前言 主要針對公司內部現況做分享. 站在DevOps的右側, 偏運維角度看事情 Observability的部分只是介紹 --- ## Operational Blindness ![](https://i.imgur.com/1dnit6x.jpg =600x400) ---- ### War Story ![](https://i.imgur.com/POdkXcJ.png) Note: 某天中午, 運維組內暴發出警報通知, 一堆訊息湧現. 大家也跳了起來, 發現網站癱瘓了, 外部監控近幾次健康檢查都沒過, 而觸發了警報. ---- ![](https://i.imgur.com/k8DCN9x.png =700x500) Note: 發現網站癱瘓了 ---- ### Black-Box Monitoring ![](https://i.imgur.com/CknOiks.png) Note: 登入主機監控系統, 發現網站的系統指標正常, 記憶體也還有, CPU沒到100%, Disk跟IO也還在容許範圍內, 資料庫也活著 ---- ![](https://i.imgur.com/G82g0nD.png) Note: 不知道原因只好把問題擴大到開發團隊, 因為主機與網站服務的進程本身看起來還算正常 ---- ![](https://i.imgur.com/Vm783kK.png =600x400) Note: 開發團隊也不確定要看什麼, 且它們沒有直接登入正式環境主機的權限; 也不會讓所有人都有權限進入主機, 管理成本高與資安風險高 ---- ![](https://i.imgur.com/uep3689.png) Note: 開發團隊只好與運維團隊一起工作並且只能發號施令 最終在資料庫上發現, 一堆慢查詢跟一堆連線處於CLOSE_WAIT狀態 在Web服務上也看到有幾乎一樣多數量的進程 推測很可能Web服務已經達到了最大處理容量並停止響應新的request(例如healthcheck) 最後把db的query session都砍掉, Web服務上的請求隊列也清空, 就正常了 ---- ![](https://i.imgur.com/wI4sTlx.png) Note: 查找這些問題的根源, 浪費了很多時間; 當問題被升級時, 被波及的人也沒足夠權限查看對找問題有用的主機資訊與服務資訊. 最終還是得依賴運維團隊.且在這種情境下, 每一分鐘的無法服務或停機時間都是要錢的 運維團隊之所以只能把問題擴大, 是因為他們能看到的就幾乎只有主機的監控指標, ---- ### Question - Dev/Ops團隊的分離, 這樣的組織與溝通方式, 有間接成本的產生 Note: 傳統的結構上, 有一條明顯的紅線把開發與運維的職責劃分開. 運維團隊負責主機與基礎設施, 使得應用程式的交付成為可能. ---- ![](https://i.imgur.com/X3kUYGy.png) Note: Developer與Operations如果組織結構與合作方式上職責分的太開, 往往會像拔河一般, 分散了力道. 相互拉扯中, 復原時間就流逝了. ---- ![](https://i.imgur.com/EW4950D.png) Note: 最可怕的還是, 使用者對平台提供的服務品質沒信心了, 跳去競品平台了 ---- ## DevOps ![](https://i.imgur.com/B4a94yh.png) ###### [What is SRE | Tasks and Responsibilities of an SRE | SRE vs DevOps](https://youtu.be/OnK4IKgLl24) Note: Developer與Operations不應該相互拉扯在拔河, 而分散了眾人的力道. ---- ![](https://i.imgur.com/mQNibxr.png) ---- ![](https://i.imgur.com/IuNaQsC.png) ###### [非同步系統的服務水準保證 淺談非同步系統的 SLO 設計-91APP](https://www.91app.tech/static/97979df17dd25408c24c20ae74e27155/SLO-design-of-the-asynchronous-system-Andrew.pdf) Note: SLI(service level indicator) 指的是指標,例如:QPS,TPS,Duration,準確性,延遲,性能等 不是所有的metric都視為SLI,選擇儘可能少的SLI,但這些SLI卻能說明服務是否穩定,可靠。 SLO(service level objective):服務等級目標 指的是一段時間內的目標,例如:1個月內的QPS 99.99%,響應時間<10ms等等 SLO是一組值的範圍,這個值就是由SLI定義的服務級別數值。自然的SLO定義就是,某SLI在正常情況下需要小於某值或者處於某個大小值之間。 選擇一個合適的SLO並不是一件容易的事情,當然一開始並不需要設定好這個範圍 SLA (service level agreement):服務等級協議 指的是整個協議,協議的內容包含了SLI,SLO以及恢復的方式和時間等等一系列所構成的協議 ---- - 基於時間的可用性 > 基於時間的可用性 = 系統正常運行時間 / (系統正常運行時間 + 停機時間) > SLO 99.95%, 以一年來看, 不可用佔了4小時22分鐘 > SLO 99.99%, 以一年來看, 不可用佔了52分鐘 ---- - 基於次數合計的可用性 > 基於合計的可用性 = 成功請求數 / 請求數總和 > SLO 99.99%, 如果一天要接受2.5M個請求, 每天錯誤個數應<250個 ###### [事件處理案例](https://study-area.sre.tw/Incidents/) ---- - 基於延遲 > SLO 99% 前台每秒User訪問延遲 < 300ms ###### [[架構師的修練] #2, SLO - 如何確保服務水準?](https://columns.chicken-house.net/2021/06/04/slo/) --- ## Monitoring ![](https://i.imgur.com/6rgwWMz.png) ---- ## Types of Monitoring ![](https://i.imgur.com/YUJ8QG7.png) ###### [Multi-Cloud Monitoring](https://www.meshcloud.io/2020/08/28/multi-cloud-monitoring-a-cloud-security-essential/) ---- ## Monitoring Layers ![](https://i.imgur.com/vImhE4B.png =500x450) --- ## Logging Deal with discrete events - Application debug or error messages - Audit-trail events - Request-specific metadata - Specific events Note: 應用程式錯誤訊息、稽核事件、HTTP請求事件 ---- ## Log Monitoring ![](https://i.imgur.com/J9PjBD0.png) - Troubleshooting - Monitor ---- - Clearly log level - Good log message ([Structured Log](https://ithelp.ithome.com.tw/articles/10277678)) - Log aggregation Note: Show Loki 單行Log, 又是JSON格式, 針對各種類型的服務定義出固定的metadata key ---- ## Defect of Log Monitor - Low value density ``` [INFO] .... initializing... [INFO] ... request from xxx.xxx.xxx.xxx user_id xxxxxx ``` Note: 有價值的資訊密度太低, 很多都是第一行那樣的無價值資訊 ---- 這部影片主要講了很多 Log Cetralize and Monitor的好處 跟Log要怎清楚的表達 [Logging in the age of Microservices and the Cloud](https://www.youtube.com/watch?v=zdfhgtcm4uk) ---- - Write log into RDBMS - log如果併發寫入很高, 寫入的資料庫又是RDBMS, 併發事務量不會很高 - 就算buffer pool加大, 也是有極限的, 也不建議 - log字段很多種類, 索引選擇困難 - DB真出事了, 想登入看log也沒法, 搞不好還沒寫進去 - 很容易就是壓死DB的那根樹枝 - 讓DB回歸, 業務狀態與資料的存儲與存取吧 --- ## Metrics 4 Golden Signals - Latency : time to serivce a request - Traffic : requests/second - Error : error rate of request - Saturation : fullness of a service ###### [SRE-book](https://sre.google/sre-book/monitoring-distributed-systems/) ###### [Observability: Metric, Logging, and Tracing, Oh My!](https://www.youtube.com/watch?v=ZVKrN1RLetI) Note: 反映用戶體驗,衡量系統核心性能。如:系統的處理時間,作業計算系統的作業完成時間等。 反映系統的服務量。如:請求數,發出和接收的網絡封包大小等。 幫助發現和定位故障和問題。如:錯誤總量、調用服務失敗率等。 反映系統的飽和度和負載。如:系統佔用的內存、作業隊列的長度等。 ---- - [Metrics](https://prometheus.io/docs/concepts/data_model/#notation) for Prometheus - metric name and label sets ``` <metric name>{<label name>=<label value>, ...} ``` ``` # TYPE http_requests_total counter |--------------------------- Metric ----------------------------|-timestamp -|-value-| |--- metric name --|------------------ labelsets ---------------| http_requests_total{code="200",handler="prometheus",method="get"} 721 ``` Note: label sets代表了這個metric name下的一個維度,可以有多個維度方便做聚合操作 ---- ## Metric Types - Counters (rate) - Gauges (value) - Distribution - Histogram (heatmap) - Summary ###### [Observability of Distributed Systems](https://www.youtube.com/watch?v=SoZZzB-yTOk&list=WL&index=115&t=77s) Note: counter只增不減, 通常用來取得request總量, 任務完成的數量, 錯誤發生次數, 或者計算某段時間內的rate變化率; 能事前透過壓力與負載測試能取得可預期的上限, 做監控與警告; 查詢當前系統中,訪問量前10的HTTP URL. gauge即時變化情況, 隨著時間不斷變化, 通常用來記錄cpu, mem用量, coroutine數量, pool usage, 併發請求數...; 透過計算樣本的線性回歸模型, 對數據的變化趨勢進行預測. Histogram會對觀測數據取樣,然後將觀測數據放入有數值上界的桶中,並記錄各桶中數據的個數,所有數據的個數和數據數值總和, 請求時延, 各種有樣本數據;用來區分是平均的慢還是長尾的慢,快速了解監控樣本的分佈情況 Summary 與 Histogram 類似,會對觀測數據進行取樣,得到數據的個數和總和。此外,還會取一個滑動窗口,計算窗口內樣本數據的分位數。 ---- ## Archetecture ![](https://i.imgur.com/MHtKRgQ.png =x550) --- ## Observability ![](https://i.imgur.com/Z0x2oFn.jpg) ###### [The Observability Pipeline](https://www.slideshare.net/TylerTreat/the-observability-pipeline) Note: Monitoring tells you whether system works, observability lets you ask why it's not working ---- ![](https://i.imgur.com/dNaiuoB.png) ---- ## Pilliars of Obersvability ![](https://i.imgur.com/kf6Xd1i.jpg) --- # News [【企業SRE實例:新加坡星展集團】頂尖數位銀行如何再進化,SRE轉型是變身科技公司的關鍵](https://www.ithome.com.tw/news/144120) [【臺灣SRE實例:17Live集團】多功能型SRE化身內部信心來源,天天成為開發團隊後盾](https://www.ithome.com.tw/news/144122) [【臺灣SRE實例:Line臺灣】如何確保Line服務天天不中斷,專責SRE扮演開發與維運的橋樑](https://www.ithome.com.tw/news/144121) [Line臺灣百億筆遙測數據的可觀察性平臺架構大公開](https://www.ithome.com.tw/news/149317) [臺灣大型企業如何上手SRE,Google建議先做這4件事](https://www.ithome.com.tw/news/144119) --- ## Reference [SRE-BOOK](https://sre.google/sre-book/table-of-contents/) [Operations Anti-Patterns, DevOps Solutions](https://books.google.com.tw/books?id=g3kFEAAAQBAJ&dq=Operations+Anti-Patterns,+DevOps+Solutions&hl=zh-TW&source=gbs_navlinks_s) [Logging and Log Management](https://books.google.com.tw/books?id=Rf8M_X_YTUoC&dq=logging+and+log+management&hl=zh-TW&source=gbs_navlinks_s) [阿里雲-日誌服務](https://help.aliyun.com/document_detail/48869.html) [Grafana Documentation](https://grafana.com/docs/grafana/latest/) [Prometheus](https://prometheus.io/docs/prometheus/latest/getting_started/) [Loki Documentation](https://grafana.com/docs/loki/latest/) [FluentBit Documentation](https://docs.fluentbit.io/manual/) --- ### Thank you! You can find me on ![](https://member.ithome.com.tw/avatars/120846?s=ithelp) - [Blog](https://tedmax100.github.io/) - [IT邦](https://ithelp.ithome.com.tw/users/20104930/ironman)