Loki 的定位
Loki 是 Grafana 自家的日志聚合系统，设计哲学是「像 Prometheus 一样对待日志」：不解析、不索引日志全文，只给每条日志流打上一组标签（labels），内容以压缩块形式存进对象存储。代价是查询要靠标签定位后逐行过滤，收益是写入便宜、运维轻量，特别适合已经在用 Prometheus 标签体系的团队。
添加 Loki 数据源
- 打开 Connections → Data sources → Add data source，选择 Loki。
- 在 Loki URL 填入服务地址，例如本地
http://localhost:3100（容器化部署时注意用 Grafana 可达的地址）。 - 有网关或多租户路由时，在 Custom headers 里附加请求头。
- 点击 Save & test 确认连通，然后到 Explore 里选它跑一条查询。
LogQL 基础
一条日志查询由三段组成：流选择器、行过滤器、解析器，可以像管道一样逐级收窄。
- 标签选择器决定「读哪些日志流」，与 PromQL 完全同构：
{app="nginx", env="prod"}。 - 行过滤器决定「留哪些行」：
|= "timeout"包含、!= "debug"排除、|~ "err(or)?"正则匹配。 - 解析器把行内容展开成字段以便进一步过滤与统计，常用
| json、| logfmt、| regexp。
组合示例——找出 nginx 日志中超时的请求，并统计每分钟速率：
sum by (host) (rate({app="nginx"} |= "timeout" | json [1m]))提示： 先用 Labels 浏览器（查询框旁的 Labels 按钮）确认标签键值再手写选择器，比凭记忆猜标签名高效得多。
指标与日志互跳
可观测性的关键一步是「从异常曲线跳到当时的日志」：
- 指标 → 日志：Prometheus 面板的图例或数据点菜单里提供 Logs for your query 类入口，会带着当前标签过滤器跳到 Loki 查询。
- 日志 → 其他信号：在 Loki 数据源配置的 Derived fields 里声明一个正则（
matcherRegex），从日志行里抽取 traceID 或指标标签，命中后日志行会渲染出跳转 Tempo/Prometheus 的链接。这是「点一条日志看整条链路」的实现方式，具体字段以配置界面为准。
常见坑
- 不带标签选择器的查询极慢甚至超时：这是 Loki 的设计使然，时间范围再短也应先用标签锁定流。
- 标签基数失控：把 user_id、request_id 这类高基数值做成标签，等于放弃 Loki 的成本优势——它们应该留在日志内容里靠
json解析。 - 时间与日志行不符：采集端未解析日志内时间戳时，使用的是采集时间；排查看不到「那分钟」的日志时，先确认这一点。
- Live tail 打开很久不关：实时追流会持续占用查询资源，看完记得停。
下一步
- 日志检索的操作路径，见探索日志。
- 日志的上游数据源，见连接 Prometheus。
- 用日志做告警的实战写法，见指标与日志告警实战。