HackMD
全方位強化 Python 服務可觀測性：以 FastAPI 和 Grafana Stack 為例 - 劉義瑋
Collaborative writing start from below
從這裡開始共筆
- Slide: 全方位強化 Python 服務可觀測性：以 FastAPI 和 Grafana Stack 為例
- Demo Project: https://github.com/blueswen/pycon-tw-2024-python-observability
Whitebox Monitoring -> Observability
Observability signals: metrics, logs, traces
traces, 分散式追蹤(Distributed Tracing).e.g., SSO
Grafana: resolve data silo
OpenTelemetry Instrumentation
- Code-based
- Zero-code
會議錄音、逐字稿、摘要與翻譯：https://s.dwave.cc/1QK39eQ
Below is the part that speaker updated the talk/tutorial after speech
講者於演講後有更新或勘誤投影片的部份
Slido 問題回覆
- 如果不想自己架設 Grafana 以及各種 storage server，有推薦把這些觀察資料推到哪個平台呢？Datadog、Grafana Cloud、Baselime?
- 如果是想要用 Grafana 的話首選應該還是 Grafana Cloud，目前都還有資料可以保存 14 天的免費額度
- 想知道 Observability 如何選型？例如 trace 也有 jaeger 可以用， log 可用 elastic log stash/gray log 等
- 格式的話盡可能選擇開源與主流的格式，方便後續切換工具，不用大幅更動架構或對應套件，例如 Metrics 選擇 Prometheus、Traces 選擇 Observability
- 工具方面，我覺得跟一般技術選型的在意的點差不多，社群活絡、盡可能開源，有問題也比較好找到解法，或是有提供諮詢的公司
- 如果目標是想要在 Grafana 中達到資訊交互應用的效果的話，Grafana 也支援查詢 Jaeger、Elasticsearch，簡報中介紹的交互應用方式都可以達到
- 想問一下，關於資料的追蹤這些過去的系統或服務 log 通常會建議保存多久 or 多久清理/壓縮 一次紀錄？有沒有建議的保存/壓縮方式，好讓這些資料不要佔太多硬盤空間
- 保存多久就是看成本跟組織內部的規定
- 要避免佔用過多空間，從源頭減量可能才是更根本的方式，例如 Trace 有些無用的內容可以提前刪除，就不要存到 Datasource 中
- 如果資料是保存在雲端 Object Storage 中，可能可以使用類似 Amazon S3 Intelligent-Tiering 的功能，降低儲存成本時同時保留較長的時間
- 使用者的 API request 中可以塞入traceId 至 http header嗎？
- HTTP Request 中也都是將 Trace ID 放入 HTTP Header 中，如果指的是前端發送的 Request 就要放入 Trace ID 可以參考 OpenTelemetry 的 JavaScript API/SDK 或是 Grafana Faro 的 faro-web-tracing
- Trace 會期望是全採集所有觸發 API 等的資訊嗎還是會部分採樣
- 理想上是可以全採集，但現實終究還是會有成本考量，我覺得可以先全採集，但先透過 OpenTelemetry Collector 這類 Collector 工具刪減不需要的 Trace 與 Trace 內容，例如 health check 或是 metrics 這類的 Trace 就完全不需要收集，如果真的還是壓不下去再考慮部分採樣
