别再选错采集器：Loki日志采集选型的3个问题决策树

别再选错采集器：Loki日志采集选型的3个问题决策树

【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki

K8s集群里Pod频繁重启，日志采集延迟飙到5分钟以上，磁盘还被日志堆满。Loki日志采集选型这事，说白了用排除法3步就能定：Promtail、Alloy、Docker驱动，先划掉两个再说。

先问自己三个问题：Loki日志采集工具怎么选

选客户端别先翻文档，用三个问题把范围卡死。

部署形态：K8s、VM还是纯Docker？

如果你的答案是纯Docker环境（单节点、不跑K8s），Promtail和Alloy先往后放，Docker驱动直接进决赛圈——它挂在Docker守护进程里，零代理。如果你的答案是K8s集群，Docker驱动可以直接排除，它管不了K8s的Pod日志。

日志源复杂度：容器日志还是文件日志？

如果你的答案是纯容器日志、基本不需要正则解析和标签重写，重型采集器的pipeline能力都用不上，Docker驱动够用。如果你的答案是/var/log下几十个文件、还要解析时间戳打标签，Docker驱动直接排除，它不碰文件。

资源预算：这台机器还有多少余量？

如果你的答案是内存预算极紧（边车级），Docker驱动约15MB的占用最省。如果你的答案是这套日志体系要长期演进——以后要收指标、接新数据源——别选Promtail，Loki仓库README里写得很直白：Promtail已功能冻结，Alloy取代了它，未来日志采集开发全部投入Alloy。

逐个过招：Promtail和Alloy区别在哪、Docker驱动够不够用

Promtail：存量VM的主力，别再为新环境选它

它能做什么：文件尾随、容器日志采集、pipeline_stages做正则解析/时间戳提取/标签重写，本地磁盘保留做缓冲，稳。它做不了什么：功能已冻结，不采指标和追踪，没有组件化动态配置。什么时候你会后悔：今天为图省事在新环境选了它，明年全量迁Alloy，配置等于重写一遍。

scrape_configs: - job_name: system static_configs: - targets: [localhost] labels: job: varlogs __path__: /var/log/*.log

Alloy：新建K8s集群的默认答案

它能做什么：组件化配置，服务发现、日志、指标、追踪一套通吃，配置支持动态更新。它做不了什么：内存占用比Promtail高（约65MB对45MB），配置语法是新东西，团队得花时间上手。什么时候你会后悔：只有一台VM、只收几个文件日志，为了"完整"上Alloy，杀鸡用牛刀。

loki.source.docker "flog_scrape" { host = "unix:///var/run/docker.sock" targets = discovery.docker.flog_scrape.targets forward_to = [loki.write.default.receiver] } loki.write "default" { endpoint { url = "http://loki:3100/loki/api/v1/push" } }

仓库的 examples/getting-started/ 目录有一份Alloy+Loki+网关的可跑本地示例，照着抄最快。

Docker驱动：Docker日志直推Loki，能省则省

它能做什么：装进Docker守护进程，容器日志直接推Loki，约15MB内存，还支持relabel和加载外部pipeline文件。它做不了什么：只认Docker，K8s（containerd直管）和裸机文件日志都摸不到。什么时候你会后悔：环境开始混部VM，或者要做复杂处理去重，只能再部署一个采集器补位。用法就是给容器加--log-driver=loki和loki-url参数，没有任何配置文件的仪式感。

三种场景走一遍决策树：新建K8s、存量VM、边缘节点

上图就是Loki的整体链路：不管哪种客户端，最后都是Agent角色把日志推给Loki。按场景走一遍：

如果是新建K8s集群 → 直接Alloy（loki.source.* 服务发现开箱即用），Promtail和Docker驱动都不用看 如果是存量VM、文件日志为主 → 已有Promtail：留着别动，迁移收益小于折腾成本 → 没有采集器、只收容器日志：Docker驱动 如果是边缘单节点、资源极紧 → 纯Docker：Docker驱动（👉 零代理，约15MB） → 还有文件日志：轻量跑一个Promtail

别纠结二选一。常见折中：核心业务容器用Alloy做正则解析、标签重写，边缘和一次性容器用Docker驱动直推，日志统一落到同一套Loki存储，两边标签规范对齐就行。

Promtail迁到Alloy不是大工程

官方在 docs/sources/send-data/alloy/ 下准备了迁移入口（Migrating from Promtail 章节），核心就是把scrape_configs翻译成组件配置、pipeline_stages对应到 loki.process 的stage。别停写切换，双跑一周对比标签和延迟，再下Promtail。Promtail和Docker驱动的配置细节分别在 docs/sources/send-data/promtail/ 和 docs/sources/send-data/docker-driver/，对着改就行。

新环境默认Alloy，存量留Promtail，纯容器轻负载用Docker驱动。配置细节去 docs/sources/send-data/ 对应目录对一遍再动手。

【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki