---
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

----

### War Story

Note:
某天中午, 運維組內暴發出警報通知, 一堆訊息湧現. 大家也跳了起來, 發現網站癱瘓了, 外部監控近幾次健康檢查都沒過, 而觸發了警報.

----

Note:
發現網站癱瘓了

----

### Black-Box Monitoring
Note:
登入主機監控系統, 發現網站的系統指標正常, 記憶體也還有, CPU沒到100%, Disk跟IO也還在容許範圍內, 資料庫也活著

----

Note:
不知道原因只好把問題擴大到開發團隊, 因為主機與網站服務的進程本身看起來還算正常

----

Note:
開發團隊也不確定要看什麼, 且它們沒有直接登入正式環境主機的權限; 也不會讓所有人都有權限進入主機, 管理成本高與資安風險高

----

Note:
開發團隊只好與運維團隊一起工作並且只能發號施令
最終在資料庫上發現, 一堆慢查詢跟一堆連線處於CLOSE_WAIT狀態
在Web服務上也看到有幾乎一樣多數量的進程
推測很可能Web服務已經達到了最大處理容量並停止響應新的request(例如healthcheck)
最後把db的query session都砍掉, Web服務上的請求隊列也清空, 就正常了

----

Note:
查找這些問題的根源, 浪費了很多時間;
當問題被升級時, 被波及的人也沒足夠權限查看對找問題有用的主機資訊與服務資訊.
最終還是得依賴運維團隊.且在這種情境下, 每一分鐘的無法服務或停機時間都是要錢的
運維團隊之所以只能把問題擴大, 是因為他們能看到的就幾乎只有主機的監控指標,

----

### Question
- Dev/Ops團隊的分離, 這樣的組織與溝通方式, 有間接成本的產生
Note:
傳統的結構上, 有一條明顯的紅線把開發與運維的職責劃分開.
運維團隊負責主機與基礎設施, 使得應用程式的交付成為可能.

----

Note:
Developer與Operations如果組織結構與合作方式上職責分的太開, 往往會像拔河一般, 分散了力道.
相互拉扯中, 復原時間就流逝了.

----

Note:
最可怕的還是, 使用者對平台提供的服務品質沒信心了, 跳去競品平台了

----

## DevOps

###### [What is SRE | Tasks and Responsibilities of an SRE | SRE vs DevOps](https://youtu.be/OnK4IKgLl24)
Note:
Developer與Operations不應該相互拉扯在拔河, 而分散了眾人的力道.

----


----


###### [非同步系統的服務水準保證 淺談非同步系統的 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

----

## Types of Monitoring

###### [Multi-Cloud Monitoring](https://www.meshcloud.io/2020/08/28/multi-cloud-monitoring-a-cloud-security-essential/)

----

## Monitoring Layers

---

## Logging

Deal with discrete events
- Application debug or error messages
- Audit-trail events
- Request-specific metadata
- Specific events
Note:
應用程式錯誤訊息、稽核事件、HTTP請求事件

----

## Log Monitoring

- 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


---

## Observability

###### [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

----


----

## Pilliars of Obersvability


---

# 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
- [Blog](https://tedmax100.github.io/)
- [IT邦](https://ithelp.ithome.com.tw/users/20104930/ironman)