# 前端可觀測性 - Grafana 在下的一盤大棋 - 許宏翔 (Mike Hsu)

{%hackmd @DevOpsDay/B1cnefOI0 %}

#### 》[議程介紹](https://devopsdays.tw/2024/speaker-page/1493)
#### 》[填寫議程滿意度問卷｜回饋建言給辛苦的講者](https://forms.gle/vWV95UQ2e6ihdpah7)

> 共筆從這開始

## What is Frontend Observability

什麼是前端可觀測性？
幾乎大家都說是： == Grafana or ELK or Datadog === 監控

## Why we need Frontend Observability
humans are impatient, 任何造成延遲的原因都可能導致application失去潛在客戶

目的是什麼？ 服務行為是什麼？，又串接到哪一個服務、如果出現系統的效能變慢，哪一個函數在作怪，錯誤在哪一個階段壞去？

請求時間變長，這些問題是在前端發生還是後端發生的？
………………
以上都是可觀測性都是要解決的問題，目前都是後端。 必須延伸到前端，

真實體感時間是USER從前端按下按鈕開始

Performance Golden Rule

企業角度來看，人類很不耐煩，反應時間延遲和業務績效有絕對關係！

這些精確監控非常重要吧
前端效能是使用者體驗的一部分、甚至網頁畫出來的時間也要考量。
可能很難在本地發現錯誤，在 production 才出現問題

訂票那瞬間卡住情況，讓許多客戶都認為絕對買不到了，就是會卡。

Leverage Real User Monitoring （RUM 工具）監測使用者真實使用情況

RUM 工具用在 production 是**右移**測試的延伸。 （下一堂是測試**左移**）

## Grafana and Their Frontend Observability

- Grafana 小知識
- 不只是做開源，還花錢請別人做開源
- Prometheus, OpenTelemetry

- Grafana 的無限寶石 Labs
- Logs
- Visualizations
- Traces
- Metrics
- Profiles
- Collection

從資料搜集 -> 處理 -> 儲存 -> 進而萃取精華

依靠個服務資訊信號聚合出來的 Grafana，

> Grafana 終極目標：可觀測性的基礎設施必須像水跟電一樣

### Grafana Faro Web SDK

- 為什麼使用 Grafana Faro？
- 前端插入短短幾行即可用
- 擁有 Instrumentations 隨插即用
- 跟 React 高度整合
- 原生支援 OpenTelemetry

### Grafana Cloud: Application Performance
- 可以知道哪一個路徑，效能的表現如何
- 可以知道 Session view log 間的關係
- 可以從 logs 推測使用者的歷程

### Grafana Faro RUM Architecture

- 解決成本問題，降低維運成本

### Sentry RUM Architectiure

- 比較 RUM 霸主 - Sentry
維運門檻高（多個資料庫）

結論： 太貴

### Grafana Faro RUM RECAP

- 總結 Faro 優缺點
- 優點
- 可以馬上點 error，連到 Github 找出這段 code 是誰寫的

### Grafana Scenes
source: https://github.com/grafana/scenes

- 提供很直覺的聲明式 API

## Build highly interactive Grafana Apps

### Grafan Scenes Demo

- 比較這個月和上個月使用區段，判斷是否正常

### Log Volume Explore Demo

- 哪些服務是最佔空間的

###### tags: `DevOpsDays Taipei 2024`

===聊天區===
講者兩個禮拜前去了瑞士，推薦去看冰河

可觀測性是