Crashlytics on Tarragonhttps://tarrragon.github.io/blog/tags/crashlytics/Recent content in Crashlytics on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 19 Jun 2026 00:00:00 +0000Firebase 套件https://tarrragon.github.io/blog/monitoring/06-commercial-comparison/firebase-suite/Fri, 19 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/monitoring/06-commercial-comparison/firebase-suite/<p>Firebase 把 client-side 監控拆成多個獨立產品：Crashlytics 負責 crash 報告、Analytics（GA4）負責行為分析、Remote Config 負責功能旗標和 A/B test。三個產品各自有 SDK、dashboard 和計費模型，但共享 Firebase project 的使用者識別。</p> <h2 id="crashlytics">Crashlytics</h2> <p>Firebase Crashlytics 專注在 crash 報告 — fatal crash（app 當機）和 non-fatal exception（被捕獲但值得記錄的錯誤）。</p> <h3 id="自動-crash-報告">自動 crash 報告</h3> <p>Crashlytics SDK 在 app crash 時自動收集 crash 資訊（stack trace、device info、OS version），在下次 app 啟動時上傳。不需要開發者寫程式碼 — SDK 初始化後自動運作。</p> <h3 id="issue-分群">Issue 分群</h3> <p>和 Sentry 類似，Crashlytics 用 stack trace 自動把 crash 分群成 issue。每個 issue 有影響的使用者數、趨勢、crash-free session 比率。</p> <h3 id="和-analytics-的關聯">和 Analytics 的關聯</h3> <p>Crashlytics 可以在 crash 報告中附加 Analytics 的使用者屬性和自訂 key。但兩者的 dashboard 獨立 — crash 資料在 Crashlytics console，行為資料在 Analytics console。要從「crash」追蹤到「crash 前使用者做了什麼」需要在兩個 console 之間切換。</p> <h2 id="analyticsga4">Analytics（GA4）</h2> <p>Firebase Analytics 是 Google Analytics 4（GA4）的 mobile SDK 版本。記錄使用者操作事件（screen view、button click、purchase）和使用者屬性。</p> <h3 id="自動收集事件">自動收集事件</h3> <p>GA4 SDK 自動收集一組預定義事件：<code>first_open</code>、<code>session_start</code>、<code>screen_view</code>、<code>user_engagement</code>。開發者不需要手動埋點就能得到基礎的使用統計。</p> <h3 id="自訂事件">自訂事件</h3> <p>開發者用 <code>logEvent(name, parameters)</code> 記錄自訂事件。事件名稱和參數的命名有限制（名稱 40 字元、參數 25 個、參數值 100 字元）。</p> <h3 id="和四類事件的對應">和四類事件的對應</h3> <p>GA4 主要處理 Event 類和 Lifecycle 類事件（<a href="https://tarrragon.github.io/blog/monitoring/01-mental-model/four-event-types/" data-link-title="四類事件的完整定義" data-link-desc="Event / Error / Metric / Lifecycle 四類事件各自的語意、觸發時機和典型用途 — 分類是監控體系的統一語言">模組一</a>）。Error 類由 Crashlytics 處理。Metric 類沒有原生支援 — 需要把 metric 包裝成 event 的 parameter。</p> <h2 id="remote-config">Remote Config</h2> <p>Firebase Remote Config 讓開發者在不更新 app 的情況下修改 app 的行為 — 功能旗標（feature flag）、UI 文案、數值參數。</p> <h3 id="和-ab-test-的整合">和 A/B test 的整合</h3> <p>Remote Config 和 Firebase A/B Testing 整合：定義實驗（variant A: 舊 UI / variant B: 新 UI），Remote Config 自動分配使用者到 variant，Analytics 收集兩組使用者的行為數據，A/B Testing console 顯示統計結果。</p> <p>這個整合是 Firebase 生態的獨特優勢 — config 分發、使用者分群、行為收集、統計分析在同一個平台完成，不需要整合多個工具。</p> <h2 id="firebase-的取捨">Firebase 的取捨</h2> <p>Firebase 的設計取捨是「拆分但整合」— 每個產品獨立運作（可以只用 Crashlytics 不用 Analytics），但組合使用時有整合優勢（Crashlytics + Analytics 的 user ID 共享）。</p>Firebase 把 client-side 監控拆成多個獨立產品：Crashlytics 負責 crash 報告、Analytics（GA4）負責行為分析、Remote Config 負責功能旗標和 A/B test。三個產品各自有 SDK、dashboard 和計費模型，但共享 Firebase project 的使用者識別。

Crashlytics

Firebase Crashlytics 專注在 crash 報告 — fatal crash（app 當機）和 non-fatal exception（被捕獲但值得記錄的錯誤）。

自動 crash 報告

Crashlytics SDK 在 app crash 時自動收集 crash 資訊（stack trace、device info、OS version），在下次 app 啟動時上傳。不需要開發者寫程式碼 — SDK 初始化後自動運作。

Issue 分群

和 Sentry 類似，Crashlytics 用 stack trace 自動把 crash 分群成 issue。每個 issue 有影響的使用者數、趨勢、crash-free session 比率。

和 Analytics 的關聯

Crashlytics 可以在 crash 報告中附加 Analytics 的使用者屬性和自訂 key。但兩者的 dashboard 獨立 — crash 資料在 Crashlytics console，行為資料在 Analytics console。要從「crash」追蹤到「crash 前使用者做了什麼」需要在兩個 console 之間切換。

Analytics（GA4）

Firebase Analytics 是 Google Analytics 4（GA4）的 mobile SDK 版本。記錄使用者操作事件（screen view、button click、purchase）和使用者屬性。

自動收集事件

GA4 SDK 自動收集一組預定義事件：first_open、session_start、screen_view、user_engagement。開發者不需要手動埋點就能得到基礎的使用統計。

自訂事件

開發者用 logEvent(name, parameters) 記錄自訂事件。事件名稱和參數的命名有限制（名稱 40 字元、參數 25 個、參數值 100 字元）。

和四類事件的對應

GA4 主要處理 Event 類和 Lifecycle 類事件（模組一）。Error 類由 Crashlytics 處理。Metric 類沒有原生支援 — 需要把 metric 包裝成 event 的 parameter。

Remote Config

Firebase Remote Config 讓開發者在不更新 app 的情況下修改 app 的行為 — 功能旗標（feature flag）、UI 文案、數值參數。

和 A/B test 的整合

Remote Config 和 Firebase A/B Testing 整合：定義實驗（variant A: 舊 UI / variant B: 新 UI），Remote Config 自動分配使用者到 variant，Analytics 收集兩組使用者的行為數據，A/B Testing console 顯示統計結果。

這個整合是 Firebase 生態的獨特優勢 — config 分發、使用者分群、行為收集、統計分析在同一個平台完成，不需要整合多個工具。

Firebase 的取捨

Firebase 的設計取捨是「拆分但整合」— 每個產品獨立運作（可以只用 Crashlytics 不用 Analytics），但組合使用時有整合優勢（Crashlytics + Analytics 的 user ID 共享）。

優勢 代價
自動收集、零配置啟動 自訂彈性受限（事件命名限制、參數數量限制）
Crashlytics 免費且無量限制 Analytics 的進階功能需要 BigQuery export（另收費）
A/B test 整合開箱即用 鎖定 Google 生態（資料 export 有限制）
Mobile 優先，Flutter 支援佳 Web 的支援較弱（GA4 web 是獨立產品線）

下一步路由

]]>商業方案的事件類型對應https://tarrragon.github.io/blog/monitoring/01-mental-model/commercial-event-mapping/Fri, 19 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/monitoring/01-mental-model/commercial-event-mapping/<p>商業監控方案各自有不同的事件分類體系。理解它們的分類邏輯和四類事件（event / error / metric / lifecycle）的對應關係，才能在接入時正確映射自架方案的事件，避免資料遺漏或分類錯誤。</p> <h2 id="sentry">Sentry</h2> <p>Sentry 的核心概念是 error tracking，但已擴展到 performance monitoring 和 session replay。</p> <table> <thead> <tr> <th>四類事件</th> <th>Sentry 對應</th> <th>說明</th> </tr> </thead> <tbody> <tr> <td>Event</td> <td>Breadcrumb</td> <td>使用者操作記錄在 breadcrumb trail，附加在 error 上</td> </tr> <tr> <td>Error</td> <td>Event（Exception type）</td> <td>Sentry 的核心。自動捕獲 + 手動 captureException</td> </tr> <tr> <td>Metric</td> <td>Transaction + Span</td> <td>Performance monitoring 的度量單位</td> </tr> <tr> <td>Lifecycle</td> <td>Breadcrumb（navigation）</td> <td>app 生命週期記錄為 navigation/system breadcrumb</td> </tr> </tbody> </table> <p>Sentry 的設計假設是「error 是主角，其他事件是 error 的 context」。Event 和 lifecycle 都以 breadcrumb 形式附加在 error 報告上，獨立查看的能力有限。Breadcrumb 預設保留最近 100 條且不可獨立查詢 — 它是 error 報告的附件，不是獨立的事件資料庫。Metric 對應的 Transaction + Span 則有獨立的 Performance 頁面可以查看，和 error 是不同的 UI 入口。如果主要需求是行為分析而非 error tracking，Sentry 的 breadcrumb 模型可能不夠用。</p> <h2 id="firebase-crashlytics--analytics">Firebase Crashlytics + Analytics</h2> <p>Firebase 把 error tracking 和行為分析拆成兩個獨立產品。</p> <table> <thead> <tr> <th>四類事件</th> <th>Firebase 對應</th> <th>說明</th> </tr> </thead> <tbody> <tr> <td>Event</td> <td>Analytics custom event</td> <td>GA4 的 event，有 parameters 附加屬性</td> </tr> <tr> <td>Error</td> <td>Crashlytics exception</td> <td>fatal + non-fatal exception 分開處理</td> </tr> <tr> <td>Metric</td> <td>Analytics event + parameters</td> <td>用 event 的 parameters 記錄數值（無原生 metric）</td> </tr> <tr> <td>Lifecycle</td> <td>Analytics auto events</td> <td>screen_view、app_open 等自動收集</td> </tr> </tbody> </table> <p>Firebase 的特點是 Crashlytics 和 Analytics 各自獨立運作 — error 資料在 Crashlytics console，行為資料在 Analytics console。Metric 沒有原生支援，只能用 Analytics event 的 parameters 欄位記錄數值（例如 <code>event: 'page_load', parameters: {duration_ms: 320}</code>），查詢時需要在 BigQuery export 中自行聚合。兩個 console 之間的關聯需要手動（在 Crashlytics 的 custom key 中設定 user ID，再到 Analytics 用同一個 ID 查行為）。</p> <h2 id="datadog-rum">Datadog RUM</h2> <p>Datadog Real User Monitoring 從全棧 APM 的角度設計 client-side 監控。</p> <table> <thead> <tr> <th>四類事件</th> <th>Datadog RUM 對應</th> <th>說明</th> </tr> </thead> <tbody> <tr> <td>Event</td> <td>Action</td> <td>使用者操作（click、tap、scroll）自動或手動捕獲</td> </tr> <tr> <td>Error</td> <td>Error</td> <td>JS exception、network error、custom error</td> </tr> <tr> <td>Metric</td> <td>Long Task + 自訂</td> <td>長任務自動捕獲，自訂 metric 用 global context</td> </tr> <tr> <td>Lifecycle</td> <td>View</td> <td>頁面/畫面的進入和離開，自動偵測 SPA route 變換</td> </tr> </tbody> </table> <p>Datadog RUM 的特點是和 backend APM 的深度整合。Client-side 的 action 可以關聯到 server-side 的 trace，形成從按鈕點擊到 database query 的完整鏈路。自架方案通常做不到這個深度的跨層關聯。</p>商業監控方案各自有不同的事件分類體系。理解它們的分類邏輯和四類事件（event / error / metric / lifecycle）的對應關係，才能在接入時正確映射自架方案的事件，避免資料遺漏或分類錯誤。

Sentry

Sentry 的核心概念是 error tracking，但已擴展到 performance monitoring 和 session replay。

四類事件 Sentry 對應 說明
Event Breadcrumb 使用者操作記錄在 breadcrumb trail，附加在 error 上
Error Event（Exception type） Sentry 的核心。自動捕獲 + 手動 captureException
Metric Transaction + Span Performance monitoring 的度量單位
Lifecycle Breadcrumb（navigation） app 生命週期記錄為 navigation/system breadcrumb

Sentry 的設計假設是「error 是主角，其他事件是 error 的 context」。Event 和 lifecycle 都以 breadcrumb 形式附加在 error 報告上，獨立查看的能力有限。Breadcrumb 預設保留最近 100 條且不可獨立查詢 — 它是 error 報告的附件，不是獨立的事件資料庫。Metric 對應的 Transaction + Span 則有獨立的 Performance 頁面可以查看，和 error 是不同的 UI 入口。如果主要需求是行為分析而非 error tracking，Sentry 的 breadcrumb 模型可能不夠用。

Firebase Crashlytics + Analytics

Firebase 把 error tracking 和行為分析拆成兩個獨立產品。

四類事件 Firebase 對應 說明
Event Analytics custom event GA4 的 event，有 parameters 附加屬性
Error Crashlytics exception fatal + non-fatal exception 分開處理
Metric Analytics event + parameters 用 event 的 parameters 記錄數值（無原生 metric）
Lifecycle Analytics auto events screen_view、app_open 等自動收集

Firebase 的特點是 Crashlytics 和 Analytics 各自獨立運作 — error 資料在 Crashlytics console，行為資料在 Analytics console。Metric 沒有原生支援，只能用 Analytics event 的 parameters 欄位記錄數值（例如 event: 'page_load', parameters: {duration_ms: 320}），查詢時需要在 BigQuery export 中自行聚合。兩個 console 之間的關聯需要手動（在 Crashlytics 的 custom key 中設定 user ID，再到 Analytics 用同一個 ID 查行為）。

Datadog RUM

Datadog Real User Monitoring 從全棧 APM 的角度設計 client-side 監控。

四類事件 Datadog RUM 對應 說明
Event Action 使用者操作（click、tap、scroll）自動或手動捕獲
Error Error JS exception、network error、custom error
Metric Long Task + 自訂 長任務自動捕獲，自訂 metric 用 global context
Lifecycle View 頁面/畫面的進入和離開，自動偵測 SPA route 變換

Datadog RUM 的特點是和 backend APM 的深度整合。Client-side 的 action 可以關聯到 server-side 的 trace，形成從按鈕點擊到 database query 的完整鏈路。自架方案通常做不到這個深度的跨層關聯。

接入策略

接入商業方案時的映射原則：

自架事件名稱是 source of truth。商業方案的事件名稱是自架名稱的映射，不是取代。映射邏輯集中在一個 adapter 層，商業方案更換時只改 adapter。

不要為了配合商業方案改變自架的分類。Sentry 把 event 記錄為 breadcrumb 不代表自架方案也要把 event 降級成 error 的附屬品。自架的四類分類是語意正確的，商業方案的分類是它自己的產品設計。

同時接入多個方案時做去重。Error 同時發到 Sentry 和 Crashlytics 會產生重複。在 adapter 層控制「哪類事件發到哪個方案」，避免同一個事件在多個 dashboard 出現。

下一步路由

]]>模組六：商業方案對照https://tarrragon.github.io/blog/monitoring/06-commercial-comparison/Fri, 19 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/monitoring/06-commercial-comparison/<p>回答「什麼時候該從自架切換到商業方案」。</p> <h2 id="待寫章節">待寫章節</h2> <ul> <li><input checked="" disabled="" type="checkbox"> 自架 vs 商業的判斷決策表（使用者數 / 網路範圍 / 功能需求 / 合規要求）</li> <li><input checked="" disabled="" type="checkbox"> Sentry 深入（error + performance + session replay 的架構）</li> <li><input checked="" disabled="" type="checkbox"> Firebase 套件（Crashlytics + Analytics + Remote Config 的整合）</li> <li><input checked="" disabled="" type="checkbox"> Datadog RUM（全棧 APM 的 client-side 觀點）</li> <li><input checked="" disabled="" type="checkbox"> Mixpanel / Amplitude（行為分析專用 vs 通用監控的差異）</li> <li><input checked="" disabled="" type="checkbox"> 部署光譜（BaaS + Serverless / PaaS / 完全自架 / 商業 SaaS 四條路徑）</li> </ul> <h2 id="跨分類引用">跨分類引用</h2> <ul> <li>→ <a href="https://tarrragon.github.io/blog/monitoring/08-business-analytics/" data-link-title="模組八：行為資料的商業利用" data-link-desc="Funnel / Cohort / Attribution / A/B test / 推薦系統 / RFM — 從 debug 工具到商業資產的翻轉">monitoring 模組八 商業利用</a>：商業方案的核心賣點是行為分析功能</li> <li>→ <a href="https://tarrragon.github.io/blog/backend/04-observability/" data-link-title="模組四：可觀測性平台" data-link-desc="整理 log、metric、trace、dashboard 與 alert 的後端操作實務">backend 04 可觀測性</a>：server-side 商業方案（Datadog / New Relic）的對照</li> </ul>回答「什麼時候該從自架切換到商業方案」。

待寫章節

  • 自架 vs 商業的判斷決策表（使用者數 / 網路範圍 / 功能需求 / 合規要求）
  • Sentry 深入（error + performance + session replay 的架構）
  • Firebase 套件（Crashlytics + Analytics + Remote Config 的整合）
  • Datadog RUM（全棧 APM 的 client-side 觀點）
  • Mixpanel / Amplitude（行為分析專用 vs 通用監控的差異）
  • 部署光譜（BaaS + Serverless / PaaS / 完全自架 / 商業 SaaS 四條路徑）

跨分類引用

]]>