# 微服務在雲原生環境的可觀測性應用 - 李泰穎 Tommy

{%hackmd @DevOpsDay/BJXaW1_k6 %}

> 從這裡開始寫

> cloud native 與microservice architecture的時代, 痛點在於如何快速找出問題, 把損失降到最低

## 建構雲原生平台的可觀測性

- Opensource Observability stack 服務技術堆疊方案
- 三大遙測支柱：Log、Metrics、Tracing
- 使用 Grafana 統整 Log、Metrics、Tracing
- OpenTelemetry 在 Tracing 的三種應用模式 Manual, Auto, Injection

- 2022年進入CNCF是一個高度自動化的解決方案的開始

## API互相呼叫會產生出很複雜的網路, 如果某個API的節點發生問題會很難找出問題

- SLA定義，把損失降低

## 技術堆疊

- 透過Grafana來整合所有遙測資料的呈現.
- k8s 可觀測性稍延不足，所以需要技術堆疊
- Opensource Observability stack:
- Istio, kiali(Istio管理資料與流量from prometheus), OPT, Prometheus, Grafana Loki, Grafana Tempo(pipeline), Grafana

- Istio Service mesh 機制
- sidecar mode
- pods互相溝通的所有流量資訊都需要經過 sidecar (envoy)
- 輕量級網路代理
- 應用程序無感知
- 協助解耦
- 可讓 Prometheus 取得 metrics。
- Rolling update: 利用流量控制測試服務版本

- Prometheus(istio -> prometheus server -> Grafana and Kiali)
- 分為 pull \ push 方式取得監控數據
- 自己寫exporter讓系統吐metric出來
- 讓 ServiceMonitor通知prome server去哪裡拿
- Enable Istio sidecar 就可以自己做到metrics 而不用自己寫exporter，prome server就會知道要去sidecar拿metric

- OpenTelemetry(OPT -> Tempo -> Grafana)
- 此專案項目推動三大觀測性支柱：Log、Metrics、Tracing
- 期許標準化、收集數據流程
- Loki 藉由 log stdout 機制，取得微服務log
- fluentB collect from node
- fluentD filter
- OPT藉由Tempo作為grafana data source以呈現之
- 在不同的系統與服務之間進行數據交換與集成
- 傳播組件與搜集組件
- 有三種實現方式：Manual, Auto, Injection(推薦)
- Manual：侵入式修改程式，自行處理 Tracing ID傳遞需求
- Auto：半侵入式 rebuild image
- Injection：非侵入式的在 yaml 檔案上宣告 inject.(lung)即可(java, .net, nodejs, python, golang...) ref: https://github.com/open-telemetry/opentelemetry-operator#opentelemetry-auto-instrumentation-injection
-

- Log
- 能透過fluentbit, fluentd來採集後, 送至Grafana Loki

- Grafana
- 三種資料來源：Loki、Prometheus、Tempo（from OpenTelemetry）12 factor

## Deepflow

- 2022年度進入 CNCF ，是一個高度自動化的可觀測性平台解決方案
- DeepFlow 是使用eBPF技術
- 僅包含網路的Log; 程式Log要自己印出來

## 總結

- Developer 要會寫 yaml, PromQL, Span, LogQL 還要學會 K8s
- Cloud Native Non-Functional Requirements
- 整個目的與重點：
- 非侵入式：不要造成開發人員開發的負擔、建議使用Istio與OPT injection model
- 統一管理介面：透過 Grafana 獲得一致性的資訊

- Grafana Dashboard: 右邊放Tempo、左邊放Loki

(有人能支援圖片嗎XDD 完全看不到字)

以上是一個共筆版本
##################################
以下是另外一個共筆版本

### Roadmap of Opensource Observability Stack in k8s

### 微服務service mesh 的特點


### Service Mesh Sidecar Enable Metrics Collection


Basic Architecture of Prometheus

Before
(ref: https://prometheus.io/docs/tutorials/getting_started/)

### 可觀測性三大支柱

- Logging
- Matrics
- Tracing

* Logs：透過「文字」將在某個時間下發生的事件、實料、和有意義的
資訊記錄起來
* Metrics：透過视紧一定時間之内量化後的數據•常用的Metrics有 Query per second (QPS) 、Transaction per second (TPs) •而常用的Business metrics有Daily active users (DAU)等等
* Tracing： 為 「a tree of spans 」 •Tracing記錄觀每個功能其應用程式完整的執行過程。由於執行過程會充滿著「上下游的呼叫關像」若將這些呼叫開係記錄起來便形成了一棵樹


要如何在複雜的網路環境中快速找到可能的錯誤 ?

OpenTelemetry提供一個標準化的流程與套件.

### Opensource Observability Stack 元件交互


OpenTelemetry collector主要是收集與分發遙測資料的中介服務.

# Demo1 : Logs observability - 12 factor standard output


能透過Loki的LogQL來搜尋到我們要的log

# Demo2 : metrics observability

能透過istio 來做流量控管, 做測試

# Demo3 : tracing observability


# OpenTelemtry


## Otel 3種模式: Manual, auto, injection mode


### Manual Mode

以 Python 為例需要將 module import，自行開發每個 Spec 並自行處理 TracingID 傳遞的問題。

- 維運成本高、非常麻煩


### Auto Mode

半侵入式，Build Image 時將相關模塊引入。


opentelemetry-instrument python xxx

### Inject Mode

在 YAML 檔案上面宣告，目前只支持 Java、.NET、node.js、Python、golang

僅需在 K8s manifest 上描述，做到非侵入式啟動觀測。

[OTel inejction]( https://opentelemetry.io/docs/kubernetes/operator/automatic/)

# DeepFlow

啟用 eBPF 技術

採集網路拓墣的資訊與應用程式的三大遙測資料結合


## Architecture


# 總結


「沒有比以前輕鬆，比以前加倍痛苦」 --> 今天重點 XD

## 聊天室：

ithome 502 QQ

用 Istio 網路速度會有影響嗎？ 會有但基本可無視, 畢竟要過sidecar

真的有人分享圖片 太神拉 感謝

投影片字好小 ><
字的顏色很淡 眼睛不好
XD

字真的有點小...

第一排燈有可能關掉嗎？不知道關掉後會不會好一點
會, 他的顏色太淺, 關掉會比較舒服

有工作人員在看共筆嗎？
我是共筆的, 看有沒有現場人員

部"屬" XD

"布" 屬 xD

完全看不到字
+1

講者有要release投影片嗎
第三排就幾乎啥字都看不到惹QQ

唯一支持 Datadog
datadog好用是好用 就是有點傷錢包

拜託前兩排的聽眾幫忙拍一下投影片貼上來...後面完全看不到字 ><

感謝圖片支援