二进制部署 loki+promtail+grafana 最可控低耗易排查；docker 方式易因权限、挂载问题导致日志丢失；常见故障包括端口冲突、路径未创建、标签不匹配、时间范围不当及权限配置缺失。
直接上结论：CentOS 7 或 AlmaLinux 等主流 Linux 发行版上，用二进制方式部署 loki + promtail + grafana 是最可控、资源占用最低、也最容易排查问题的方案；Docker 方式虽快，但一旦 promtail 权限或路径挂载出错，日志根本收不到，且 systemd 日志和容器日志混在一起反而更难定位。
loki 启动失败：端口被占或配置路径不存在
常见现象是执行 ./loki-linux-amd64 -config.file=loki.yaml 后立即退出，journalctl -u loki 查不到日志，或者报错 listen tcp :3100: bind: address already in use。
- 先确认端口：运行
ss -tuln | grep :3100，若被占用，改配置里http_listen_port为3101或杀掉冲突进程 -
loki.yaml中所有路径必须提前创建好，比如directory: /opt/loki/index，得手动mkdir -p /opt/loki/index，否则启动直接静默失败 -
auth_enabled: false必须显式写上，CentOS 7 默认没开 SELinux 也要写，否则某些版本会因权限校验卡住 - 如果用 systemd 管理，
ExecStart要带完整绝对路径，例如/opt/loki/bin/loki-linux-amd64 -config.file=/opt/loki/etc/loki.yaml
promtail 收不到日志：路径、标签、服务发现三处易错
最典型的是 promtail 进程在跑，但 Grafana 里查不到任何日志流，loki 的 /metrics 页面里 loki_ingester_streams_created_total 为 0。
-
static_configs下的paths必须是绝对路径，且promtail进程用户（如loki用户）有读取权限，/var/log/*.log不等于/var/log/messages—— 得写全或用通配符明确匹配 -
labels至少设一个，比如job: "system"，否则 Loki 会丢弃该流；多个标签用换行对齐，不要写成一行 JSON - 确保
loki_address指向的是loki实际监听的地址，不是localhost（跨主机时）；若同机部署，用http://127.0.0.1:3100/loki/api/v1/push更稳妥 - 检查
promtail自身日志：./promtail-linux-amd64 -config.file=promtail.yaml 2>&1 | head -20，常能直接看到 “failed to tail file” 或 “connection refused”
Grafana 添加 Loki 数据源后查不到日志：时间范围与标签不匹配
添加成功、无报错，但 LogQL 查询 {job="system"} 返回空，或只显示“no logs found”。
- 默认时间范围是最近 5 分钟，而
promtail可能刚启动、还没推第一批日志，手动调大到 “Last 24 hours” 再试 - LogQL 中的标签名必须和
promtail.yaml里labels定义的完全一致，大小写敏感；比如配置了host: "web01"，就不能查{hostname="web01"} - 确认
loki的schema_config中from时间早于你日志的实际生成时间，例如日志是 2026-04-19 生成的，from: 2021-01-01没问题，但from: 2026-04-20就会跳过所有数据 - 在 Grafana 的 Explore 面板右上角点 “Settings”，把 “Max lines per query” 调高（默认 1000），避免日志量大时被截断
真正麻烦的从来不是安装步骤，而是路径权限、标签拼写、时间偏移这三类低级但隐蔽的问题——它们不会报错，只会让日志“安静地消失”。每次改完配置，别急着刷新 Grafana，先看 promtail 控制台输出、再 curl 一下 loki 的 /readyz 和 /metrics，比反复重装快得多。
