不少朋友都在 Ubuntu 服务器上折腾过日志收集，早期用 ELK 那套——Elasticsearch 吃内存实在太狠，在一台 2G 内存的机器上既要跑 ES 又要跑 Kibana，光是存活就已经拼尽全力了。后来 Grafana 生态里出了 Loki，主打“低成本、轻量级、跟 Grafana 无缝集成”，这套组合一下就吸引了我的注意。只是想用日志排查问题、做简单告警的话，真没必要上 ES 全家桶，Loki 的压缩存储和 LogQL 查询方式足够覆盖绝大多数场景。这篇就把我在 Ubuntu 24.04 上从零部署 Loki + Alloy + Grafana 的完整过程写出来，含配置文件和踩坑记录，可以直接照着抄。
1. 项目概述：为什么是 Loki + Alloy + Grafana
1.1 这套系统能解决什么问题
传统的日志排查，最原始的办法就是 SSH 到服务器上tail -f /var/log/app.log，单台机器还好说，一旦服务变成多个实例、多个容器，挨个登录看日志就完全行不通了。我们需要一个集中式的日志平台，让所有机器、所有服务的日志都汇到一个地方，再用统一的入口去检索和分析。
ELK 确实是最经典的方案，但它的痛点非常明显：Elasticsearch 是 Java 写的，默认堆内存就给你吃掉几个 G，加上索引存储的副本机制，磁盘和内存的压力都不小。对个人开发者、小团队、或者只是几台服务器的小规模场景来说，ELK 属于典型的“杀鸡用牛刀”。
Loki 的设计思路完全不一样，它不建立全文索引，而是只对日志的标签建立索引，日志原文用压缩块存储。这个思路导致它查询速度和 ES 相比在某些复杂场景下慢一些，但换来了极低的内存占用和运维成本。搭配 Grafana 做可视化，从采集到展示的链路完整，而且 Grafana 本身你大概率已经用它做监控了，不用再额外学一套 Kibana 的操作习惯。
这套组合最吸引我的一点是部署简单。不用搭 Kafka、不用调 JVM 参数，一个 docker-compose 文件就能把三个服务全部拉起来。后续扩容也只是加个 Alloy 采集器的问题，非常适合中小规模的基础设施。
1.2 Alloy 和 Promtail 的关系，为什么选 Alloy
老玩家应该知道，Loki 官方之前主推的采集器是 Promtail，专门为 Loki 设计，支持从文件、journald、syslog 等来源采集日志。但 Grafana Labs 后来推出了 Alloy，一个统一的采集器，目标是替代 Promtail，同时还能采集 Prometheus 指标、OpenTelemetry 链路数据，通吃 metrics、logs、traces 三类信号。我也用过 Promtail 一段时间，它的配置其实挺清晰的，但每次看到 Grafana 官方博客和文档都在推 Alloy，就已经注定它会是未来的主方向。加上 Alloy 的配置语法用了 HCL，和生态里的很多工具一致，写起来比 Promtail 的 YAML 格式更灵活一些。这篇就按 Alloy 来写，毕竟新项目应该直接上新的东西，免得才搭好就要迁移。
1.3 Ubuntu 24.04 下的部署方式选择
部署这套系统的主流方案有两种：一是直接用二进制文件跑，二是用 Docker。Linux 上跑二进制还要处理 systemd 服务文件、数据目录权限等问题，比较繁琐。Docker 方式一条命令解决依赖问题，日志系统的所有组件都有官方镜像，基本不需要考虑版本冲突。Ubuntu 24.04 的 Docker 安装也简单，官方提供了 apt 源，几步就能搞定。所以下面的流程全用 Docker。
2. 核心设计思路与方案选型
2.1 Loki 的存储机制：为什么它这么省资源
Loki 的存储分两块：索引和块数据。索引默认存在本地文件系统（单机模式），块数据也默认存在本地文件系统。它把日志按照流（stream）来组织，每个流由一组标签唯一定义，比如{job="nginx", instance="web-01"}就是一条流。写入时日志先被压缩、切块，再落盘；查询时通过标签先过滤流，再在流内做内容匹配。
这种设计的直接好处是写入路径很轻。ES 写入的时候要做分词、建倒排索引，CPU 消耗高；Loki 写入基本就是追加压缩，对 CPU 和内存的消耗小得多。代价是查询时如果标签过滤不当，会扫很多数据，所以要有点 LogQL 的使用技巧（后面会细说）。对应到实际体验，同一台 2C4G 的服务器，跑 ES 经常内存告警，跑 Loki 单机模式却很从容，差距非常明显。
2.2 目录规划与资源规划
部署之前，先想清楚文件放哪里。我的建议是单独建一个/opt/loki-stack目录放所有配置文件和数据目录，不跟项目代码混在一起，也方便备份和迁移。Docker 的 volume 如果不好管理，直接做目录挂载最直观。
资源规划上，单机版 Loki 的最低要求其实很低：512M 内存就能跑起来，但为了业务高峰期不被打爆，建议至少给 Loki 分配 1G 内存。Alloy 比较轻量，但它在高吞吐时也会占用不少 CPU，建议至少 256M 内存。Grafana 同样很成熟，256M 内存起步。整体下来，一台 2C4G 的服务器，跑这套系统加两三个业务容器，资源是完全够用的。在做规划时可以粗略估算日志量：每台机器每天产生 1-2GB 原始日志，Loki 压缩后能降到十分之一左右，所以这个部署方案的存储压力也不大。
2.3 采集链路：Alloy 如何抓到容器和系统日志
Alloy 的日志采集流程可以简单理解成三个环节：发现目标 → 读取日志 → 转发给 Loki。
在 Docker 环境中，每个容器的标准输出（stdout/stderr）其实都会被 Docker 接管，以 JSON 文件形式存在宿主机的/var/lib/docker/containers/<容器ID>/目录里。Alloy 是通过 Docker 的 API 或者直接读取宿主机文件来发现和采集这些容器日志的。如果采集的是宿主机上的普通文件日志（比如 Nginx 的 access.log），那就直接指定路径就行。Alloy 会把日志内容按行读取，然后按配置好的标签结构，推送到 Loki 的 HTTP API 接口。
这套链路中比较容易混淆的点是：Alloy 不一定非要跑在容器里，但它要能访问到日志文件。为了让 Alloy 容器能读到宿主机上的容器日志，我们后面会把宿主机的/var/lib/docker/containers目录和/var/log目录挂载进 Alloy 容器里，这也是采集容器日志的标准做法。
3. 快速部署实战（Ubuntu 24.04 + Docker）
3.1 环境准备和基础配置
我的环境是一台刚装好 Ubuntu 24.04 LTS 的服务器，2C4G，IP 是192.168.1.100（这里用内网地址来示例）。第一步当然是把系统更新到最新，然后安装 Docker。
# 更新系统软件包索引 sudo apt update && sudo apt upgrade -y # 安装 Docker 依赖 sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加 Docker 官方 apt 源（注意 Ubuntu 24.04 的代号是 noble） echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装 Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin注意：Ubuntu 24.04 的代号是 noble，之前网上很多教程写的是 jammy（22.04），直接抄的话 apt 会报错。我一开始就踩了这个坑，后来检查
/etc/os-release才反应过来。
装完之后确认 Docker 能正常运行：
sudo systemctl enable --now docker sudo docker version docker compose version如果docker compose version能正常输出版本号，说明 compose 插件已经装好了，后面可以直接用docker compose命令。
然后创建项目目录结构：
sudo mkdir -p /opt/loki-stack/{config,data/{loki,grafana}}这里的config目录放 Loki 和 Alloy 的配置文件，data/loki和data/grafana分别是两个服务的数据持久化目录。一开始就把目录结构规划好，后面排错会轻松很多。
3.2 编写 docker-compose.yml
我习惯把所有服务的编排写在一个docker-compose.yml里，这样一条命令就能启动和停止整套环境，也方便统一管理网络。来看这个完整的文件：
version: "3.8" services: loki: image: grafana/loki:3.3.2 container_name: loki restart: unless-stopped ports: - "3100:3100" volumes: - /opt/loki-stack/config/loki-config.yaml:/etc/loki/local-config.yaml - /opt/loki-stack/data/loki:/loki command: -config.file=/etc/loki/local-config.yaml networks: - loki-net alloy: image: grafana/alloy:v1.4.1 container_name: alloy restart: unless-stopped ports: - "12345:12345" volumes: - /opt/loki-stack/config/alloy-config.alloy:/etc/alloy/config.alloy - /var/lib/docker/containers:/var/lib/docker/containers:ro - /var/log:/var/log:ro depends_on: - loki networks: - loki-net grafana: image: grafana/grafana:11.2.0 container_name: grafana restart: unless-stopped ports: - "3000:3000" environment: - GF_SECURITY_ADMIN_USER=admin - GF_SECURITY_ADMIN_PASSWORD=admin123 - GF_USERS_ALLOW_SIGN_UP=false volumes: - /opt/loki-stack/data/grafana:/var/lib/grafana depends_on: - loki networks: - loki-net networks: loki-net: driver: bridge几个细节需要说明一下：
第一，restart: unless-stopped很关键，服务器重启后容器会自动拉起来，省去手动恢复的麻烦。第二，Alloy 容器把宿主机的/var/lib/docker/containers和/var/log以只读方式挂载进去，这是采集容器日志和宿主机日志的前提。第三，depends_on只保证启动顺序，不保证服务已经就绪，Loki 启动速度很快，一般不会有问题，但如果 Alloy 报连接拒绝，可以手动重启一下 alloy 容器。
Grafana 的环境变量里我直接设置了初始账号密码，生产环境建议改成强密码，并通过环境变量文件或者 Docker secret 管理，而不是直接写在 compose 文件里。
3.3 Loki 配置文件详解
Loki 的配置项非常多，但快速部署时只需要一个最精简的单机模式配置。我在/opt/loki-stack/config/loki-config.yaml写入以下内容：
auth_enabled: false server: http_listen_port: 3100 common: instance_addr: 127.0.0.1 path_prefix: /loki storage: filesystem: chunks_directory: /loki/chunks rules_directory: /loki/rules replication_factor: 1 ring: kvstore: store: inmemory schema_config: configs: - from: 2024-01-01 store: tsdb object_store: filesystem schema: v13 index: prefix: index_ period: 24h limits_config: allow_structured_metadata: true volume_enabled: true retention_period: 168h这里面的几个关键点要理解：
auth_enabled: false表示关闭多租户认证。单机自用场景不需要租户隔离，如果关掉之后所有日志都归到默认的 fake 租户里，查询和写入都不用带认证头。如果是多人共用，可以开启多租户，但要对每个租户做鉴权，复杂度上来了。
schema_config里store: tsdb是 Loki 3.x 的新默认存储，比之前的 boltdb-shipper 性能更好；schema: v13也是当前版本推荐的值，不要手动改成别的。如果参考老的教程用 v11 schema，虽然也能跑，但没法享受新版特性，而且将来升级更麻烦。
limits_config.retention_period是日志保留时间，我设置为168h，也就是 7 天。这个值直接决定磁盘占用，日志量大而磁盘有限的话可以改成 72h，或者干脆只在 Grafana 里对数据做持久化裁剪。值得提醒的是，单机模式下 Loki 不会自动做物理删除，只在查询时过滤掉过期数据，所以磁盘回收效果有限。如果对磁盘占用极度敏感，得配置专门的 retention 清理策略，这是另一个话题了。
3.4 Alloy 配置文件详解
Alloy 的配置语法是 HCL 风格，和 Promtail 的 YAML 完全不同。我的采集需求有两个：一是采集宿主机所有 Docker 容器的标准输出，二是采集宿主机/var/log/下的 syslog 日志。下面是与之对应的/opt/loki-stack/config/alloy-config.alloy：
logging { level = "info" } // 发现所有 Docker 容器的日志目标 discovery.docker "containers" { host = "unix:///var/run/docker.sock" } // 从 Docker API 获取容器的日志流 loki.source.docker "container_logs" { host = "unix:///var/run/docker.sock" targets = discovery.docker.containers.targets forward_to = [loki.write.default.receiver] } // 读取宿主机系统日志文件 loki.source.file "system_logs" { targets = [ {__path__ = "/var/log/syslog", "job" = "system"}, {__path__ = "/var/log/auth.log", "job" = "system"}, ] forward_to = [loki.write.default.receiver] } // 统一写入 Loki loki.write "default" { endpoint { url = "http://loki:3100/loki/api/v1/push" } }这里有个容易踩坑的地方：Alloy 容器如果要通过 Docker API 发现容器，必须把宿主机的 docker socket 挂载进来。上面的 compose 文件里我故意没写这一行，需要补一下。修改后 Alloy 的 volumes 部分要加上：
volumes: - /opt/loki-stack/config/alloy-config.alloy:/etc/alloy/config.alloy - /var/lib/docker/containers:/var/lib/docker/containers:ro - /var/log:/var/log:ro - /var/run/docker.sock:/var/run/docker.sock等等，这里有两个采集容器日志的方案：loki.source.docker依赖 Docker API，loki.source.journal依赖 systemd journal。前者的好处是能自动拿到容器的标签（容器名、镜像名等），后者的好处是不依赖 Docker socket，安全性更高。我前面用了discovery.docker+loki.source.docker，就需要 docker.sock。如果你对挂载 docker.sock 有安全顾虑，可以改成直接读文件方式，但会丢失容器标签的自动发现能力。
socket 挂载的安全风险我自己评估过：Alloy 容器如果被攻破，攻击者可以直接控制宿主机的 Docker 进程。但这是在单机自用场景，风险可控。如果多人共用同一个 Alloy，那就需要慎重了。
另外，Alloy 的每个组件都可以独立设置日志级别，排查问题的时候可以把logging { level = "debug" }打开，但平时建议保持 info，避免日志刷屏。
3.5 启动与验证
配置文件都准备好了，先检查一下语法，然后启动服务：
cd /opt/loki-stack # 验证 Alloy 配置语法（需要先拉取镜像，第一次会比较慢） docker compose run --rm alloy run --config.file=/etc/alloy/config.alloy --server.http.listen-addr=0.0.0.0:12345 --dry-run实际中 Alloy 没有直接的 dry-run 参数，我更常用的是打开容器日志看有没有报错。所以直接启动再验证：
docker compose up -d docker compose ps正常情况下三个容器都是 Up 状态。首次拉取镜像可能需要几分钟，耐心等。启动完成后验证 Loki 是否正常接收数据：
# 查看 Loki 的 ready 接口 curl http://localhost:3100/ready # 通过 Loki API 查询日志流 curl -s "http://localhost:3100/loki/api/v1/labels" | head -20如果看到ready返回ready，并且labels接口返回了一堆 label 键（比如container_name、job等），说明 Alloy 已经把容器日志采集进 Loki 了。到这里核心链路已经通了，剩下的是在 Grafana 里把它用起来。
4. Grafana 接入与日志查询实践
4.1 添加 Loki 数据源
打开浏览器访问http://192.168.1.100:3000，用前面设置的 admin/admin123 登录。进入后左侧菜单选择 Connections → Data sources → Add data source，找到 Loki 并点击。
关键配置只有一项：URL。因为 Grafana 和 Loki 在同一个 docker 网络里，所以可以直接用服务名http://loki:3100。如果你只是想测试，也可以填http://<服务器IP>:3100，效果一样，但走的是宿主机端口转发。
填完后点击 Save & test，如果看到绿色的 "Successfully queried the Loki API" 提示，就说明数据源配置成功了。这里唯一可能出错的就是网络不通或者 Loki 没起来，按提示排查即可。
4.2 LogQL 基础查询示例
LogQL 是 Loki 的查询语言，和 PromQL 长得有点像，核心分两部分：日志流选择器和过滤器。日志流选择器用大括号包着一组标签，例如：
{job="system"}这表示查询所有 job 标签为 system 的日志流。更进一步，可以按容器名过滤：
{container_name="alloy"}如果只想看包含特定关键字的日志，加一个管道符：
{container_name="nginx"} |= "error"|= "error"是包含过滤，还有几个常用的：
# 不包含 error {container_name="nginx"} != "error" # 正则匹配 {container_name="nginx"} |~ "ERROR|FATAL" # 提取 JSON 字段后过滤（适合结构化日志） {container_name="app"} | json | level="error"实际排障中最常用的姿势是：先用标签过滤流，再按关键字搜。比如应用报错了，我一般先查{container_name="api-gateway"} |= "Exception"，如果结果太多，再加时间范围或者再加一层过滤|= "NullPointer"，逐步缩小范围。掌握这几个 LogQL 语法，日常工作基本够用了。
4.3 快速搭建一个日志可视化面板
Loki 的数据主要用于检索和趋势分析，不像 Prometheus 的指标数据那样适合做复杂的仪表盘。但有一个场景很实用：统计错误日志的数量趋势。
在 Dashboards → New dashboard → Add visualization 中，数据源选择 Loki，然后输入以下 LogQL：
sum(count_over_time({container_name="nginx"} |= "error" [5m]))这条查询的含义是：统计 nginx 容器最近 5 分钟内包含 error 的日志条数。用 count_over_time 把日志转为时间序列，再 sum 汇总，就能画出一张错误日志趋势图。配合 Grafana 的告警功能，当错误数量超过阈值时自动发通知，这就是一个简单可用的日志告警链路。
Grafana 的 Explore 页面是日常排查日志的主战场，可以快速切换数据源、设置时间范围、按标签筛选。建议把常用的查询保存下来，下次排查直接一键打开，效率高很多。
5. 常见问题与排查技巧实录
5.1 Alloy 采集不到日志怎么办
这是最常见的问题。先用下面的命令确认 Alloy 是否真的发现了日志目标：
docker logs alloy --tail 50如果日志里没有报错，但还是查不到数据，多半是目标发现有问题。Alloy 提供了一个内置的 UI 界面，在浏览器里访问http://192.168.1.100:12345，可以看到所有组件的运行状态、目标列表以及每个目标的标签信息。这是排查采集问题最直观的手段。
打开 UI 后找到loki.source.docker.container_logs这个组件，点进去能看到发现的所有容器目标。如果这里显示的目标列表为空，说明discovery.docker没有拿到容器列表，检查 docker.sock 挂载是否正常；如果能看到目标但 Loki 里没数据，检查loki.write的 endpoint 地址是否能通。
另外，还有一个常见原因是容器日志驱动不是 json-file。Docker 默认的日志驱动是 json-file，Alloy 能直接读到。但如果有人把某个容器的日志驱动改成journald或者syslog，/var/lib/docker/containers下就不会有对应的日志文件，自然采集不到。排查时可以用docker inspect <容器名> --format '{{.HostConfig.LogConfig.Type}}'确认。
5.2 Loki 内存占用过高
单机版 Loki 默认会缓存很多块索引，内存占用会随着日志量缓慢上涨。如果发现 Loki 容器 RSS 居高不下，可以从这几个方向优化。
首先，在loki-config.yaml里限制缓存大小：
chunk_store_config: chunk_cache_config: enable_fifocache: true fifocache: max_size_bytes: 500MB max_entries: 5000其次，限制每个查询的最大日志量，防止一次查询扫太多数据把内存打爆：
limits_config: max_entries_limit_per_query: 5000 max_query_series: 500另外，压缩率也很影响内存，可以开启 gzip 压缩。常见做法是在 Loki 的配置里对 HTTP 响应开启压缩，Grafana 端会透明处理，这样网络开销也能降下来。
在实际使用中，我遇到过 Grafana 查询一个跨度很大的时间范围（比如查 30 天日志）时，Loki 内存飙升到近 2G 的情况。后来把查询范围控制在 24 小时内，配合分批次查询，就基本不会再触顶了。这不是系统缺陷，而是 Loki 的架构特性决定的，所以查询习惯也要跟着调整。
5.3 Grafana 提示数据源报错或连接到 Loki 失败
如果 Grafana 的数据源测试报错，先分清楚是网络问题还是配置问题。在 Grafana 容器里手动测试一下能不能访问 Loki：
docker exec -it grafana curl http://loki:3100/ready如果不能通，检查三个容器是不是在同一个 docker 网络里。我用docker network ls确认过，如果 compose 里定义了自定义网络，Grafana 和 Loki 通常会自动加入。但如果你手动创建过容器或者改过网络，就可能出现跨网络不通的问题。
如果网络通了，还是报错，看一下 Grafana 日志：
docker logs grafana --tail 50有时候是版本兼容性问题。比如老版本的 Grafana 用默认设置去连接 Loki 3.x 新增的端点，会报datasource not found之类的错误。解决方案很简单：把 Grafana 升级到较新版本，或者确保 Loki 配置中auth_enabled: false，避免多租户问题。
5.4 日志时间不对，差 8 小时怎么办
这是一个时区问题。很多容器里的日志时间默认是 UTC，而中文用户习惯用北京时间（UTC+8），导致 Grafana 里看到的时间总是“少了 8 小时”。这个问题要从两头解决。
一头是 Alloy 读取日志时，需要把时间戳正确传递。另一头是 Loki 的配置里默认时间字段是纳秒级，如果日志里带的时间戳是秒级，Loki 会当成纳秒解析，时间就会变得很奇怪。常见的做法是让 Alloy 的loki.source.file组件解析日志中的时间字段，或在写入前用stage.timestamp统一格式。
对我这种用 Docker 容器标准输出的场景，最简单的方式是给容器设置TZ=Asia/Shanghai环境变量，看日志时把 Grafana 的时间显示切换成本地时区，就能直接对齐。要注意的是，Loki 存储的一律是 UTC 时间戳，Grafana 展示时可以按浏览器时区转换，这并不影响数据准确性。排查问题时心里要清楚，系统内部是 UTC，展示层是本地时间，就不会被差 8 小时搞懵了。
6. 个人实操心得与后续扩展
整套系统从装 Docker 到跑通日志查询，我大概花了不到一个小时，对喜欢折腾的人来说，这已经算很快了。对比之前部署 ELK 的经历——光是调 Elasticsearch 的 JVM 堆就折腾了半天，Loki 这套确实是省心不少。如果你手里正有几台服务器，日志排查全靠 ssh 加 grep，我强烈建议照这篇部署一套，体验一下“在一个页面里搜所有机器日志”的爽感。
几个我踩坑后的经验再啰嗦一遍：第一，版本尽量选新的，Loki 3.x 的 schema 和 Alloy 的配置语法变化都比较大，网上老教程容易把你带沟里。第二，Alloy 的 UI 界面是排查采集问题的利器，别忽略它。第三，日志保留时间设置务必在部署时就定好，数据量上来之后再改 retention，要等很久才生效。第四，生产环境给 Grafana 和 Loki 设置独立的强密码，不要把 admin/admin123 留到上线。
后续如果想扩展，可以按这几个方向走：一是给 Alloy 增加更多采集源，比如 Java 应用的 logback 直接推送日志，或者抓取 Kubernetes 集群日志；二是在 Grafana 里配置告警规则，让 Loki 的错误日志数量触发告警通知到钉钉或企业微信；三是接入 Prometheus 指标监控，把日志和指标联动分析，比如看到错误日志峰值的同时，观察 CPU 和内存指标变化，定位问题的能力会强很多。这套组合的想象空间不小，值得慢慢玩。
