loki在linux上启动失败八成因三处配置未对齐：路径不存在、端口被占、标签未设；二进制部署更可控，需确保storage_config.filesystem.directory已手动创建、http_listen_port未冲突、auth_enabled: false显式配置，且promtail的paths为绝对路径、labels非空、clients.url用127.0.0.1而非localhost，grafana查询前须调大时间范围并严格匹配logql标签名。
loki 在 Linux 上跑不起来，八成不是版本问题，而是三处配置没对齐：路径不存在、端口被占、标签没设。二进制部署比 Docker 更可控，尤其当你需要查 systemd 日志或调试文件权限时。
loki 启动失败：检查 http_listen_port 和 storage_config.filesystem.directory
执行 ./loki-linux-amd64 -config.file=loki.yaml 后秒退，常见原因有两个：
-
http_listen_port: 3100被占用——运行ss -tuln | grep :3100确认，冲突就改配置 +docker-compose.yml或systemd的端口映射 -
storage_config.filesystem.chunks_directory指向的路径（如/opt/loki/chunks）未创建——必须手动mkdir -p /opt/loki/chunks，否则静默失败，journalctl -u loki里看不到错误 -
auth_enabled: false必须显式写在common块下，CentOS/AlmaLinux 默认不启用 SELinux 也要写，否则某些内核版本会卡在权限校验
promtail 收不到日志：static_configs.paths 和 labels 是硬门槛
promtail 进程在跑，但 loki_ingester_streams_created_total 为 0，说明日志根本没推过去。关键看三处：
-
paths必须是绝对路径，且promtail运行用户（比如loki用户）有读权限：/var/log/messages可以，/var/log/*.log不行——得写成/var/log/**/*.log或明确列出 -
labels至少含一个非空字段，例如job: "system"；空labels: {}或全注释掉会导致 Loki 直接丢弃该流 -
clients.url别写localhost——同机部署用http://127.0.0.1:3100/loki/api/v1/push，跨主机则填目标 IP，不能依赖 DNS 或容器网络别名
Grafana 查不到日志：时间范围和 LogQL 标签要匹配
数据源添加成功、无报错，但 {job="system"} 返回空，大概率是：
- 默认时间范围是 “Last 5 minutes”，而
promtail刚启动，第一批日志还没推送完成——手动调成 “Last 24 hours” 再试 -
LogQL中的标签名必须和promtail-config.yaml里labels下定义的完全一致，大小写敏感：job≠Job，host≠hostname - 如果用了
pipeline_stages做解析（比如提取 level 字段），但没在labels里加level，那这个字段就无法用于 LogQL 过滤
promtail 自身日志输出——它不往 systemd 写，得直接运行 ./promtail-linux-amd64 -config.file=promtail.yaml 2>&1 | head -20，里面常有 failed to tail file 或 connection refused 这种直白提示。别只盯着 Grafana 界面。
