# 國泰人壽的可觀測性實踐 - 劉義瑋 Blueswen

{%hackmd @DevOpsDay/BJXaW1_k6 %}

> 從這裡開始寫

簡報：https://lihi3.cc/k3auo
我的 GitHub：https://github.com/blueswen
目前正在連載的鐵人賽：[時光之鏡：透視過去、現在與未來的 Observability](https://ithelp.ithome.com.tw/users/20162175/ironman/6445)
POC Demo Project:
1. Python FastAPI: https://github.com/blueswen/fastapi-observability
2. Java Spring Boot: https://github.com/blueswen/spring-boot-observability

---

# 日常開發與維運時最痛苦的事情是什麼?

- 排查問題, 跟因定位
- 可能很快但大多時候都很耗時

## 背景與挑戰 – 排查問題效率低落的影響

收入 - 成本 = 利潤

排查問題慢的話、使用者不開心 間接導致利潤減少，成本上升

開發速度慢 -> 專案延宕、加班加人，成本上升

### 背景與挑戰 – 如何排查問題

> 假設問題的根因root cause -> 使用工具驗證假設

#### 資訊不足

1. CPU
2. RAM
3. Log
4. IO
5. Networking 等等
以上指標都無法來描述問題發生的背景或主因

#### Data Silo

資料不互通 -> 分裂的查詢體驗

### 增加觀測資訊,解決資訊不足

Observability, 透過數據, **明確**了解系統發生什麼事

- 黑箱監控
- 白箱監控
- Application 主動揭露 metrics, logs ,traces

### 建立單一的平台,打破 Data Silo

統一整合遙測資料

# 可觀測性強化

## Observability Signals

- (發生什麼事情)
- metrics 指標, 徵狀 (CPU, API response)
- 脈絡(怎麼發生)
- log 日誌, 脈絡 (Debug, Execption)
- traces 鏈路追蹤 (e.x SSO 登入橫跨多個不同服務), 脈絡

### 資訊處理四步驟

生成 -> 收集 -> 儲存 -> 使用

### Observability Signals:Metrics

透過prometheus量測出metrics, 也收集並儲存metrcis data
但prometheus並無法處理海量/分散式儲存的議題

能透過Grafana Mimir
來儲存Prometheus生成的資料, 查詢API與PromQL是兼容

### Observability Signals:Logs

語言和框架**產生**的log, 搭配好的格式
再透過fleuntbit等工具**收集**並加工, 傳送至其他服務儲存
最後**儲存**在可提供查詢, 儲存成本低的方案來儲存, 例如Grafana Loki, 有提供LogQL查詢語法

### Observability Signals:Traces

透過統一的trace id來串連一個請求在不同服務間的歷程資訊.

trace生成, OpenTelemtry Protocol定義的
[OTLP](https://opentelemetry.io/docs/specs/otlp/)

Instrumentation, 額外配備上的能力
- manual mode : 手動配置
- automatic : 自動配置, 注入
[automatic instrumentation](https://opentelemetry.io/docs/instrumentation/js/automatic/)
- 也會自動記錄進出入該服務的網路請求

透過OpenTelemetry Collector來收集trace, 能加工, 篩選, 轉發至其他儲存服務
能透過Grafana Tempo來儲存trace, 有提供TraceQL查詢語法

### Observability Signals:Span Metrics

遺留/祖傳系統也能用!（搭配侵入性較小的 automatic instrumentation）

### Observability Signals:資料流

箭頭表示資料流

### Observability Signals:LGTM

部署架構, 查詢語法都類似, 能降低運維和入門門檻

# 觀測平台建立

打破data silo
- Logs, Metrics Traces 互相連結在 Grafana

## Grafana

單一的查詢平台, 避免分裂的查詢體驗

## Signals 搭配綜效

TraceId 來追蹤 Logs, Trace to metrics

三種遙測資料都能透過LGTM來相互增強彼此的知識維度,能倆倆搭配連結提供不同的維度來分析

## 多租戶規劃與管理

解決管理議題的設計方案

### 多租戶規劃與管理:資料隔離、權限卡控

Logs 很麻煩，有個資，需要相對應的權限才可查閱
- Loki有提供multi tenancy多租戶模式
- Grafana Org 可以隔離 使用者、儀表板、資料源
Trace 本就是跨系統，會增加不便

### 多租戶規劃與管理:IaC with Terraform

透過terrafrom來解決這麼多工具組合起來部署的管理議題

# 推廣策略與挑戰

- Top-down : 搭配組織策略來推動
- Bottom-up : 由基層發起, 獲取成果

## 策略選擇

DevOps Team
- 目標
- 要有權責
- 能力

### step 1 : 意識awareness啟發

認識這好東西

### step 2 : 驗證場景

選擇pilot user來驗證場景
選擇與現有監控部分重疊的場景, 更能體驗價值
強調與現有監控部分差異的部分，尋找對差異買單的 Pilot User

### step 3 : 持續擴散跟優化

1. Workshop, 技術講座 增加使用者
2. 搜集更多案例、需求、改進、Legacy system 提高 Dev & Ops 的管理
3. 散播品質的重要性，讓開發者可以 leverage 現成的平台了解產品系統情況

# 結論

* 善用開源工具
* Grafana Stack, Prometheus, OpenTelemerty
* 降低使用門檻
* POC 搭配 Pilot User
* Workshop, 預設儀表板
* Support Enginner

> if you can't measure it, you can't manage it

## 聊天室

後排,求投影片分享(?

講者先提供投影片了，讚讚
<3 <3
真的讚

支持這種風氣
感謝共筆大大
感謝大家共筆支援