在大型語言模型（LLM）應用席捲全球的今天，如何有效監控並觀測這些「黑盒子」的行為，已成為維運團隊最迫切的挑戰。許多團隊早已建立了成熟的 Grafana / Datadog 可觀測性平台，用以監控傳統應用服務的指標、追蹤與日誌。現在，難道我們需要為 LLM 應用再造一套全新的監控系統嗎？
LLM (Large Language Model) 應用開發的浪潮下，可觀測性 (Observability) 成為確保系統穩定性和效能優化的關鍵。作為一名 DevOps 工程師或開發人員，我們常常面臨如何監控 LLM 應用的挑戰，包括追蹤延遲、成本、錯誤率等指標。
這篇文章將會以我在 2025 devops day 中的 Bootcamp 內容，介紹 OpenLIT 這個開源的可觀測性平台解決方案，並重點探討它如何透過 OpenTelemetry 標準與我們現有的 Grafana 可觀測性平台無縫整合。只要掌握這個概念，我們不僅能快速建置 LLM 代理應用，還能實現原生的 traces、metrics 和 logs 整合，讓現有基礎設施發揮更大價值。
OpenLIT 是一個專為 LLM 應用設計的開源可觀測性平台，由 OpenLIT 團隊開發，旨在幫助開發者輕鬆收集和視覺化 LLM 相關的遙測資料 。它的定位是作為 LLM 專屬的 observability 工具，聚焦於 AI 應用的特定需求，例如監控提示 (prompt) 效能、模型回應品質、token 使用量等。相較於通用可觀測性平台，OpenLIT 提供了內建的 LLM 特定儀表板和指標，讓開發者能快速洞察 AI 應用的瓶頸。
在 OpenLIT 自身的平台中，它提供了一個直觀的 dashboard，用來顯示收集到的資料。
這個 dashboard 展示了 LLM 呼叫的詳細指標，例如延遲分佈、錯誤率和成本追蹤，幫助開發者優化應用。
使用者可以透過簡單的 SDK 整合，將 LLM 呼叫的 traces、metrics 和 logs 發送到 OpenLIT 後端，後者基於 OTEL 標準處理這些資料。這使得 OpenLIT 不僅是獨立的平台，還能作為橋樑，連接 LLM 應用與更廣泛的 observability 生態系。
OpenLIT 的核心優勢在於其 SDK 採用通用的 OpenTelemetry (OTEL) 格式。這是 OTEL 標準的開放性，讓 OpenLIT 能輕鬆將 traces、metrics 和 logs 匯出到任何支援 OTEL 的後端，例如 Prometheus (用於 metrics)、Jaeger 或 Tempo (用於 traces)，以及 Loki (用於 logs)。
而 OpenLit 原來的架構也是透過 OpenTelemetry Clickhouse Exporter 將資料輸出到 ClickHouse 的方式傳遞資料。
這意味著，我們無需大規模修改現有基礎設施，就能將 LLM 特定的遙測資料原生整合進 Grafana 等平台。
在架構上，OpenLIT 扮演「收集器」的角色：
這種設計避免了資料孤島，讓 LLM 可觀測性成為現有系統的延伸。例如，在生產環境中，我們的 Grafana 已經用於監控應用效能，現在只需配置 OTEL exporter，就能將 LLM 指標無縫加入。
為了示範這個整合，我在 repo 中設計了三階段的 bootcamp，每階段都有 docker-compose.yaml 和相應的 README，讓讀者能輕鬆重現。以下是關鍵操作步驟，並附上相關圖片。
這個階段聚焦於建置 LLM 代理，使用 Google Agent Development Kit (ADK) 來創建 code optimizer 和 multi-tool agent。
複製 .env.example 為 .env，並填入 Google API key（可從 Google Cloud Console 取得）。
執行 docker-compose up -d，啟動 ADK 服務。Web UI 位於 http://localhost:8000。
而我們預期能夠快速的運作一個具有多個工具的 Agent 來可視化其中的工具與 Prompt 調度過程。
在這裡，你可以測試 Agent 的運作，例如輸入程式碼優化請求，觀察 Agent 如何呼叫 LLM 並整合工具。
這個階段建立 LLM 應用基礎，後續將注入可觀測性。
基於第一階段的應用，我們加入 OpenLIT SDK 來收集資料。
在 openlit 目錄下，複製 .env.example 為 .env，配置 OTEL exporter（指向 OpenLIT 後端）。
執行 docker-compose up -d，啟動 OpenLIT 服務。
在 ADK 應用中嵌入 OpenLIT SDK，例如在 Python 程式碼中 import openlit 並初始化 tracer。
import openlit
import os
openlit.init(
otlp_endpoint=os.environ.get('OTEL_EXPORTER_OTLP_ENDPOINT',
'http://host.docker.internal:4318'),
application_name='multi_tool_agent',
environment='dev'
)
現在，當 Agent 運行時，遙測資料會自動發送到指定的 OTEL 端口並且轉發到任何兼容的後端。
這展示了 OpenLIT 如何輕鬆注入 LLM 應用，無需改變核心邏輯。
最後，將 OpenLIT 收集的 OTEL 資料匯出到 Grafana。
在 grafana 目錄下，執行 docker-compose up -d，啟動 Grafana 服務（http://localhost:3300）。
配置 OpenLIT 的 exporter，將 metrics 發送到 Prometheus，logs 到 Loki。
在 Grafana 中新增資料來源，並建立自訂 dashboard，顯示 LLM 特定指標如成本、延遲和錯誤率。
在 Grafana Explore 頁面中，選擇 Tempo 的 dashsource 查看 google adk agent 的相關 prompt 追蹤詳細內容。
透過這些步驟，我們看到從應用建置到可觀測性整合的全流程。
在現有的 Grafana 平台中實現 LLM 可觀測性非常直觀：只需將 OpenLIT 作為 OTEL collector 的前端，匯出資料到 Grafana 的後端儲存。這樣，我們能在單一平台監控整個系統，包括傳統應用和 LLM 部件。舉例來說，Grafana 可以顯示混合 dashboard，結合伺服器 metrics 與 LLM token 使用率，幫助診斷跨層問題。
然而，OpenLIT 和 Grafana 的定位有明顯差距：
總之，OpenLIT 作為補充，能強化 Grafana 在 AI 領域的不足。想體驗的朋友可以透過我的 bootcamp repo，你可以親自體驗這個整合！
| 面向 | OpenLIT（懂 LLM 的語意層） | 既有 Grafana 平台（通用可觀測中心） |
|---|---|---|
| 主要儲存/查詢 | ClickHouse，對 LLM 成本/Token/Prompt 分析友善 | Prometheus（metrics）、Tempo（traces）、Loki（logs） |
| 資料模型 | 遵循 OTel（含 GenAI 語意規範）輸入；預建製 LLM Dashboard | 通用時序/追蹤/日誌視圖，擅長跨服務關聯與告警 |
| 強項 | Token/Cost 透明化、Prompt/模型選型比較、互動儀表板 | 完整 SRE 監控、告警、跨遙測訊號聯動（metrics⇄logs⇄traces） |
| 角色 | LLM 工程與產品分析面板 | 組織級觀測主控台 |
在 LLM 應用快速演進的時代，可觀測性不再是可有可無的附加品，而是確保 AI 系統可靠運行的核心要素。透過 OpenLIT 這個開源平台，我們不僅能輕鬆捕捉 LLM 特有的指標，如 token 消耗、提示效能和成本追蹤，還能憑藉其 OTEL 標準的 SDK，將這些資料無縫注入既有的 Grafana 基礎設施中。這避免了重複投資，讓 DevOps 團隊在熟悉的環境中擴展監控範圍，從而實現全域視圖的統一管理。
這個 bootcamp demo 證明了整合的簡易性：從建置 Google ADK 代理，到注入 OpenLIT SDK，再到 Grafana 的視覺化輸出，只需幾個步驟即可上手。無論你是 AI 開發者還是 SRE 工程師，這種方法都能加速你的 LLM 專案落地，降低運維風險。未來，隨著 OTEL 在 AI 生態的深化，我們絕對可以預期更多工具將採用此標準，進一步簡化可觀測性的建置。
iThome鐵人賽
看影片追技術