裝了 Promtail 加 node_exporter 加 OTel Collector？Alloy 用一支 binary 把採集層收齊

2026 年 3 月 2 日，Loki 官方正式宣布 Promtail 結束生命週期。Grafana Agent 更早，在 2025 年就被合併進 Alloy，文件頁上只剩一行 redirect。對於還在跑「Promtail 拉 log、node_exporter 暴露系統指標、OpenTelemetry Collector 處理 trace」這套組合的團隊，這已經不是選配題目——Loki 官方目前推的採集器只剩 Alloy 一個。

Grafana Alloy 是這次整合的最終形態。它把 metrics、logs、traces、profiles 四種訊號的採集收進同一支 binary，並以 OpenTelemetry Collector 發行版的形式對外發布。本文拆解它的定位、實際設定方式，以及取代既有採集 agent 的路徑。

為什麼 Grafana 把這四隻 agent 全收成一隻

過去三年，一臺中等規模的 Linux 伺服器同時跑四隻採集器是常態：Promtail 拉 log 進 Loki、node_exporter 暴露系統指標讓 Prometheus 抓、OpenTelemetry Collector 處理 trace、再加上 Grafana Agent 想把這些事做一遍但只成功了一半。每隻 agent 各自吃資源、各自要維護設定檔、各自要被監控，光是處理「監控本身」的成本就比想像中重。

Alloy 的核心主張是：這四件事在資料管線層面其實是同一件事——收集、轉換、轉發。把它們合進同一個 OpenTelemetry Collector 發行版裡，比維護四個獨立 agent 合理得多。對 Grafana 而言這也是必然選擇，CNCF 標準正在統一所有可觀測訊號的傳輸協定，繼續維護獨立 agent 等於浪費工程資源。

Alloy 不是新東西，是 OpenTelemetry Collector 的發行版

這點常被誤解。Alloy 並不是 Grafana 重新寫的另一個採集器，而是基於 OpenTelemetry Collector 上游的 distribution，類似 Splunk OTel Collector、AWS Distro for OpenTelemetry 的角色。差別是 Grafana 在標準 OTel pipeline 之外，把 Prometheus 生態的 pull-based scrape、各種 exporter，跟 Loki 的 log source 整進來。

2026 年 GrafanaCON 公布的版本進一步加上了 OpenTelemetry Engine mode，可以直接吃標準 OTel Collector 的 YAML 設定檔，不用學新語法。原本擔心 vendor lock-in 的團隊，這條退路至少留好了。

.alloy 語法長這樣

Alloy 用一套叫做 River 的設定語法，檔名是 .alloy。每個元件叫做 component，類似函式呼叫，元件之間用 reference 串成 pipeline：

prometheus.exporter.unix "default" {
}

prometheus.scrape "system" {
  targets    = prometheus.exporter.unix.default.targets
  forward_to = [prometheus.remote_write.local.receiver]
}

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

loki.source.docker "containers" {
  host       = "unix:///var/run/docker.sock"
  targets    = discovery.docker.containers.targets
  forward_to = [loki.write.local.receiver]
}

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

跟傳統 YAML 比起來，這套語法的優勢是元件之間用 reference 而不是字串對應名稱串聯。語法錯誤在 alloy fmt 階段就會被抓到，不會等到 runtime 才爆。IDE 也能做出像樣的補全跟 type check，這在動輒上千行的設定檔上是實質生產力差別。

Promtail 到 Alloy 的遷移成本

Promtail 的 YAML 可以直接轉換。Alloy 內建 convert 指令：

1 2	alloy convert --source-format=promtail \ --output=config.alloy promtail.yaml

實測下來，多數的 promtail.yaml 都能完整轉成 .alloy，但有兩個地方務必檢查。pipeline_stages 裡的 multiline 處理在 Alloy 變成 loki.process 的 stage.multiline block，欄位名跟舊版不完全一致。relabel_configs 則由獨立的 discovery.relabel 元件處理，邏輯更清楚但要重新組裝。

至於 node_exporter，Alloy 沒有提供轉換器，因為 node_exporter 本身沒有設定檔，原本就是 CLI flag 控制。重點是把對應的 collector 在 prometheus.exporter.unix 裡開好。預設啟用的 collector list 跟 node_exporter 不完全一樣——例如 textfile collector 預設沒開，這是一個常被忽略的差異，從 node_exporter 切過去後會發現某些自訂指標突然不見了。

跟原生 OpenTelemetry Collector 該怎麼選

這是 2026 年實際在 deploy 時最常遇到的問題，建議分兩種情境給答案。

已經跑 Loki、Prometheus 自架 stack 的團隊：直接上 Alloy。把舊有 Promtail、node_exporter、Grafana Agent 全收成 Alloy 是最省事的路徑，且 Alloy 對 Loki 跟 Prometheus 的整合明顯比 vanilla OTel Collector 完整，許多 exporter 不必另外接 receiver 就能直接用。

走純 OpenTelemetry、後端不是 Grafana stack 的團隊：留在 vanilla OpenTelemetry Collector。Alloy 雖然支援 OTel YAML mode，但社群 component 跟 receiver 還是以 OTel Collector contrib 的更新最快，CNCF 那一側的相容性也更直接。

值得避免的反模式是：把 Alloy 當成「Grafana 版本的 OTel Collector」然後沿用 OTel 寫法。如果根本不打算用到 Prometheus pull-based scrape 跟 Loki source，純粹跑 OTel pipeline，vanilla collector 反而更輕、更新更快。

單一 binary 在資源佔用上的真實表現

合併四隻 agent 不代表資源用量直接除以四。Alloy 處於空閒（只收 host metrics）狀態大概吃 80MB RAM。同時開啟 Loki source、Prometheus scrape、OTel receiver、tail-sampling 等四個 pipeline 後，記憶體會穩定在 200 到 300MB 之間。

跟分開跑四隻 agent 加總的 400 到 500MB 比起來，省掉 30 到 50% 的記憶體佔用。但更大的價值不是省記憶體，而是除錯成本下降。當所有採集都走同一個 process，內建 web UI 可以看每個 component 的健康狀態跟 sample 資料流，遠比同時看四份 log 容易找出問題。「為什麼這條 log 沒進 Loki」這種問題，原本要查 Promtail log、Loki ingester、relabel 規則，現在可以在 Alloy UI 裡直接看 loki.source.docker 那個元件吐出了什麼。

容器化部署最容易踩的 WAL 問題

Alloy 在 Docker 部署時，預設會把資料存進 container 內的 /var/lib/alloy 目錄。這個目錄存的不只是 cache，還有 write-ahead log（WAL）。如果沒做 volume mount，容器重啟時所有還沒送出的指標、log 都會掉，重啟頻繁的環境特別容易遺失資料。

正確做法是把 WAL 目錄掛到 named volume，並且把 graceful shutdown 時間從預設 30 秒拉到 60 到 90 秒，確保 WAL 的資料能完整 flush：

services:
  alloy:
    # 正式環境請釘定版本，不要用 latest
    image: grafana/alloy:v1.5.1
    command:
      - "run"
      - "--server.http.listen-addr=0.0.0.0:12345"
      - "--storage.path=/var/lib/alloy/data"
      - "/etc/alloy/config.alloy"
    volumes:
      - ./config.alloy:/etc/alloy/config.alloy:ro
      - alloy-data:/var/lib/alloy/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "12345:12345"
    stop_grace_period: 90s

volumes:
  alloy-data:

12345 那個 port 是 Alloy 內建的 HTTP server 與 web UI，可以連進去看每個 component 的狀態跟 live debug。要接收 OTLP 流量需要另外在 .alloy 設定檔加上 otelcol.receiver.otlp 並暴露對應 port（gRPC 慣例 4317、HTTP 4318），不是打開 12345 就會自動收。正式環境記得用反向代理鎖權限，這個介面對所有採集的內容都看得到，沒做存取控制等於把整套系統指標公開。

把採集層收齊之後值得想清楚的事

Alloy 的真正價值不在「省一隻 agent」，而在把採集這層的維運責任收斂到單一介面。原本同時要熟悉 Promtail YAML、node_exporter flag、OTel Collector pipeline 三套配置的工程師，現在只要熟 .alloy 一套語法。在團隊規模有限的情境下，這是非常實際的效益。

但別期待 Alloy 解決所有問題。它依然只是採集層，後端的 Loki、Prometheus、Tempo 還是要自己維運；資料儲存、retention 策略、查詢效能這些都跟 Alloy 沒關係。決定要不要採用，看的是「採集層的維運成本」對團隊現階段的痛點程度，以及未來是否會繼續使用 Grafana 系的後端。

要在臺灣機房內把這套採集管線跟 Loki、Prometheus 後端完整跑起來，VPS 規格、網路品質與磁碟 I/O 都會直接影響整體的可觀測性效能。NCSE Network 提供臺灣是方電訊機房的 VPS 主機，Intel Gold CPU 與 NVMe SSD 的組合適合承擔多 pipeline 採集與時序資料庫高寫入量的負載，有相關自架監控需求歡迎參考 ncse.tw。