走完 Observability 各種工具的介紹後，會發現要真正組成一套完整的監控系統，往往得自行架設並長期維運多個元件。對大型組織來說這或許不是問題，但對小團隊或個人開發者而言，這代表大量原本可拿來開發產品的時間，會被基礎設施的維護吃掉。本章整理 Grafana Labs 推出的兩個工具：託管服務（Managed Service）型態的 Grafana Cloud，以及作為通用 Telemetry Collector 的 Grafana Agent。

SaaS 化的監控解決方案#

市面上提供 Observability SaaS 的廠商不少，例如 Datadog、New Relic、Grafana Cloud 等。它們的共通賣點都是「一站式監控」：使用者只負責產生訊號並送出，建構與維運由廠商負責。對於不想養伺服器、養儲存系統的團隊，這是縮短導入時間的捷徑。

SaaS 不只是把工具搬上雲，更重要的是讓使用者把資源集中在「使用觀測資料」，而非「維運觀測平台」本身。

Grafana Cloud#

Grafana Cloud 由 Grafana Labs 推出，整合旗下多項產品作為託管後端，包含 Prometheus 相容的 Metrics、Loki、Tempo、Pyroscope，再加上 Grafana 本身。免費方案大致提供：

  • Logs、Traces、Profiles 各約 50GB 的儲存配額。
  • Prometheus Metrics 約 1 萬筆 series。
  • 資料保存期限約 14 天。

對個人或小型專案而言，免費額度通常已綽綽有餘；若有更大規模需求，再評估升級到付費方案即可。

Grafana Labs 在收購負載測試工具 k6 之後，也將其整合進 Grafana Cloud。透過雲端機器發起壓測，可避免本地硬體吃緊，也能更貼近不同地區使用者的真實體驗，測試結果還能直接和其他觀測訊號交叉檢視。

Grafana Agent#

Grafana Agent 最初是為了把資料推送到 Grafana Cloud 而生，後來逐步演進成通用的 Telemetry Collector，支援以 OpenTelemetry Protocol 收發 Metrics、Logs、Traces。雖然定位為通用收集器，但對 Grafana 自家的 LGTM Stack（Loki、Grafana、Tempo、Mimir）支援度仍然最完整。

兩種執行模式#

Grafana Agent 提供兩種使用模式：

  • Static Mode：原始模式，跟 Grafana Cloud 整合度高，沿用較久的設定方式。
  • Flow Mode：自 0.29 版（2022 年 9 月）開始提供，使用類似 Terraform 的語法描述 Pipeline，並附帶 UI 可視化排查問題。

以下範例皆採 Flow Mode，其區塊語法大致為：

BLOCK_NAME "BLOCK_LABEL" {
  IDENTIFIER = EXPRESSION
}

每個區塊代表一個 Component，例如可抓取 Prometheus 指標的 prometheus.scrape、讀取本機檔案的 local.file、以 OTLP 輸出資料的 otelcol.exporter.otlp 等。多個 Component 串起來就構成一條 Pipeline，UI 上能看到每個元件的設定與健康狀態。

三條 Pipeline 的共通骨架#

Grafana Agent 對 Metrics、Logs、Traces 採用同一套寫法：先宣告 Source（如 prometheus.scrape、loki.source.docker、otelcol.receiver.otlp），再透過 forward_to 接到 Exporter（如 prometheus.remote_write、loki.write、otelcol.exporter.otlp）。以最簡單的 Metrics Pipeline 為例：

prometheus.scrape "app" {
  targets    = [{"__address__" = "app-a:8000"}]
  forward_to = [prometheus.remote_write.prom.receiver]
}

prometheus.remote_write "prom" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

Logs Pipeline 通常會多接一個 discovery.docker 取得容器清單、用 loki.relabel 把 __meta_* 重新命名；Traces Pipeline 則改用 otelcol.receiver.otlp 與 otelcol.exporter.otlp。完整的多種 Component 設定範例可參考 Grafana Agent Flow 官方文件。設定完成後，UI 會把這些區塊視覺化成資料流圖，方便確認對接是否正確。

串接到 Grafana Cloud#

要把資料送往 Grafana Cloud，只需把對應後端的 URL、使用者名稱、API Key 填入 endpoint。實務上建議透過 env(...) 注入敏感資訊，避免設定檔被一起 commit。以 Prometheus remote write 為例：

prometheus.remote_write "cloud" {
  endpoint {
    url = env("PROMETHEUS_URL")
    basic_auth {
      username = env("PROMETHEUS_USERNAME")
      password = env("GRAFANA_CLOUD_API_KEY")
    }
  }
}

Loki 與 OTLP 的寫法相同，只需替換成對應的 Block 與環境變數即可。

同一份 Flow Mode 設定，只要切換 endpoint 就能在自架 LGTM 與 Grafana Cloud 之間移動，方便 Lab 與 Production 共用設定骨幹。

小結#

Grafana Agent 雖然在眾多 Data Collector 中功能不算最豐富，但 UI 排查與 Terraform 風格語法是它的優勢，對熟悉 Terraform 的工程師上手很快。即使不搭配 Grafana Cloud，也能扮演機器層級的 Metrics/Logs/Traces 收集器，再轉發給自架後端。

許多開源專案的母公司，主要透過 SaaS 服務獲利。對使用者而言，付費換來的不是工具本身，而是「快速擁有監控能力」這個結果，正如有人需要的不是電鑽，而是「一個洞」，Grafana Cloud 就是把這個洞直接遞到使用者手中的選項之一。

原文出處#

  • 原書/iThome：https://ithelp.ithome.com.tw/articles/10338316
Backward 可觀測性 Grafana 視覺化平台 Forward