introduction Grafana Alloy
Grafana Alloy: 前身為 grafana agent
由 grafana 推出的 all-in-one observability collector, 能夠同時蒐集 metric/log/trace
為什要放棄 grafana agent 可見官方的 blog
- https://grafana.com/blog/2024/04/09/grafana-agent-to-grafana-alloy-opentelemetry-collector-faq/
- https://grafana.com/blog/2024/04/09/grafana-alloy-opentelemetry-collector-with-prometheus-pipelines/
alloy 優勢如下
-
discovery 自動發現 scrape target

-
整合多個 metric exporter: 你不需要再各自安裝 exporter 簡化環境建置

但要注意內建的 expoter 產生的 metric name/label 可能會與社群不同, 導致 dashboard 可能需要修改
alloy 弱勢如下
- log 部份僅支援 loki
實戰
使用 helm chart https://artifacthub.io/packages/helm/grafana/alloy 進行測試
scrape metrics in k8s
簡易的 helm values 如下
|
|
-
grafana alloy 會藉由
discovery.kubernetes會去取得 pod 的 ip:port
新增至 scrape targets
prometheus.scrape會使用 endpoint/metrics嘗試取得 metrics -
grafana alloy 會利用內建的 node-exporter 產生 scrape tragets
prometheus.scrape取得 metrics -
利用
prometheus.remote_write將 metrics 送至 promethues
同一時間我們看看 resource usage
$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
alloy-7kwd9 39m 461Mi
victoria-metrics-agent-d6cff6696-lg964 2m 102Mi
victoria-metrics-agent-prometheus-node-exporter-6l5jm 4m 10Mi 坦白說 這 resource usage 令我難以接受
看來採用 victoria-metrics-agent 依舊是較佳選擇
scrape logs in k8s
簡易的 helm values 如下
|
|
-
grafana alloy 會藉由
discovery.kubernetes會去取得 pod 的 label 新增至 scrape targets
loki.source.kubernetes取得 logs -
利用
loki.source.file取的 host log -
利用
loki.write將 log 送至 loki
同一時間我們看看 resource usage
$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
alloy-85jxg 8m 74Mi
promtail-9hpgh 30m 126Mi 作為對比 alloy 比 promtail 好上不少
看起來是能夠放心轉換 promtail 至 alloy
雖然 fluent-bit 在前面的測試中 cpu 表現較差
但其功能性絕對是碾壓 alloy , 因此我依舊會建議採用 fluent-bit
conclusion
grafana alloy 雖然理念很好
但 all-in-one observability collector 依舊是呈現術業有專攻的現象
以目前來說, 各自採用合適的 collector 依舊是較佳的選擇