gin日志不能直接发给loki，因其无http客户端、标签管理、重试等能力，需通过promtail采集stdout或文件日志再推送；强行集成loki sdk违背关注点分离原则，且易导致日志丢失。
Gin 应用本身不直接对接 Loki，必须通过 Promtail（或类似日志代理）采集其 stdout/stderr 或文件日志，再推给 Loki。Grafana 只负责查，不参与日志生成环节。
为什么 Gin 的日志不能直接发给 Loki
Gin 默认使用 log 包或 gin.DefaultWriter 输出到标准输出（stdout），它没有内置 HTTP 客户端、标签管理、批次压缩、重试等能力——这些是 Loki 生态中 promtail 的职责。强行在 Gin 里集成 Loki SDK 会污染业务逻辑、增加维护成本，且违背“关注点分离”原则。
- 所有容器化部署的 Gin 服务，推荐统一走 stdout → Docker 日志驱动 → Promtail 文件/套接字采集路径
- 若 Gin 写日志到文件（如
access.log），Promtail 可监听该文件路径，但需确保日志轮转（logrotate）不破坏 inode 连续性，否则 Promtail 会丢日志 - 不要在 Gin 中调用
loki/api/v1/push手动推送：无背压控制、无失败重试、无标签自动注入（如pod,namespace），极易造成日志丢失或格式错乱
Promtail 配置要点：匹配 Gin 容器日志
关键在于让 Promtail 正确识别 Gin 容器，并打上可区分的标签。以下配置片段适用于 Docker Compose 或 Kubernetes 环境：
scrape_configs:
- job_name: gin-app
static_configs:
- targets: [localhost]
# 若 Gin 运行在容器中，优先用 docker_sd_configs 自动发现
docker_sd_configs:
- host: unix:///var/run/docker.sock
refresh_interval: 5s
filters:
- name: label
values: ["app=gin-api"] # 要求启动 Gin 容器时加 --label app=gin-api
relabel_configs:
- source_labels: [__meta_docker_container_name]
regex: '/(.*)'
target_label: container
- source_labels: [__meta_docker_container_label_app]
target_label: app
- source_labels: [__meta_docker_container_image]
target_label: image
- source_labels: [__meta_docker_container_id]
target_label: container_id
- action: drop
regex: ''
source_labels: [app] # 过滤掉没打 app 标签的容器
- 务必在运行 Gin 容器时加上
--label app=gin-api，否则docker_sd_configs无法精准筛选 -
relabel_configs中的__meta_docker_container_label_*是 Promtail 从 Docker daemon 自动提取的元数据，不是你手动写的 label 值 - 若 Gin 容器使用
json-file日志驱动（Docker 默认），Promtail 会读取/var/lib/docker/containers/<id>/<id>-json.log</id></id>；路径权限需确保 Promtail 容器能访问/var/run/docker.sock和该目录
Grafana 查询 Gin 日志的 LogQL 写法
标签对齐后，Grafana 中用 LogQL 查 Gin 日志才真正可控。常见场景示例：
{app="gin-api"} |= "error" |~ "timeout|50[0-9]"
-
{app="gin-api"}是基础过滤，依赖 Promtail 注入的app标签，不是靠 grep 文本匹配，性能高且稳定 -
|= "error"表示行内包含 "error" 字符串；|~ "timeout|50[0-9]"是正则匹配，适合抓超时或 HTTP 错误码 - 避免写
{job="promtail"} |= "gin"：太宽泛，可能混入其他服务日志；job是 Promtail 自身 job 名，不是业务标识 - 如果 Gin 启用了结构化日志（如用
zerolog输出 JSON），可在 Promtail 中加pipeline_stages解析字段，再用jsonparser 提取level,path,status_code等做条件过滤
最易被忽略的一点：Promtail 的 positions.yaml 文件默认存在容器内临时路径，重启 Promtail 容器会导致日志重复采集或跳过——生产环境必须挂载宿主机持久化路径（如 /data/promtail/positions.yaml）并设为 volume，否则日志链路不可靠。
