3、Loki日志模型：Stream、Label、Chunk、Index概念，以及LogQL基础语法
理解Loki的日志模型是进行高效查询、容量规划与故障定位的基石。与Elasticsearch基于全文索引的模型不同，Loki的设计哲学是“仅索引元数据，不索引日志内容”，这使其在成本与性能上具有显著优势。本节将深入剖析Loki的核心数据模型，并掌握其查询语言LogQL的基础语法。
3.1 核心概念：Stream、Label、Chunk、Index
Loki的日志数据模型围绕四个核心概念构建，它们共同决定了数据的组织、存储与检索方式。
| 概念 | 定义 | 作用与特点 |
|---|---|---|
| Stream（日志流） | 一组具有相同Label集合的日志条目的有序序列。 | 是Loki中数据组织的基本单位。每个Stream对应一个唯一的Label组合，所有写入该Stream的日志按时间戳排序。 |
| Label（标签） | 键值对（Key-Value），用于标识和分类日志流。 | 是Loki的索引核心。查询时通过Label匹配快速定位到目标Stream，而非扫描全部日志内容。常见的Label包括 job、instance、namespace、app 等。 |
| Chunk（数据块） | 日志数据的实际存储单元，包含一段时间内同一Stream的日志内容。 | 是Loki实现低成本存储的关键。Chunk在写入前会被压缩（通常使用gzip或snappy），显著降低存储开销。默认Chunk大小约为1.5MB~2MB。 |
| Index（索引） | 存储Label到Chunk的映射关系。 | 负责快速定位包含目标Label的Chunk。Loki的索引远小于Elasticsearch的倒排索引，因为它只索引Label，不索引日志文本。索引可存储在BoltDB（单机）或Cassandra/BigTable（集群）中。 |
容量规划要点： Label的基数（Cardinality）直接影响Index的大小和查询性能。高基数Label（如
user_id、request_id）会导致Index膨胀，应避免使用。建议将Label基数控制在10万以内。
下图展示了日志从采集到存储的完整数据流，以及Stream、Label、Chunk、Index之间的关系。
3.2 LogQL基础语法
LogQL是Loki的查询语言，语法上受PromQL和SQL启发。它主要分为两个部分：日志流选择器（Log Stream Selector）和日志管道（Log Pipeline）。
3.2.1 日志流选择器
用于通过Label匹配筛选目标Stream。语法与PromQL的标签匹配器一致。
- 精确匹配：
=例如{job="varlogs"} - 非精确匹配：
!=例如{job!="varlogs"} - 正则匹配：
=~例如{job=~"app.*"} - 非正则匹配：
!~例如{job!~"system.*"}
示例： 查询
production 命名空间下，app 为 nginx 的所有日志流。
{namespace="production", app="nginx"}3.2.2 日志管道
在选定Stream后，通过管道操作符对日志行进行过滤、解析、计算和格式化。
| 操作符 | 功能 | 示例 |
|---|---|---|
|= |
行包含（子串匹配） | {app="nginx"} |= "error" |
!= |
行不包含 | {app="nginx"} != "health" |
|~ |
行正则匹配 | {app="nginx"} |~ "5[0-9]{2}" |
!~ |
行非正则匹配 | {app="nginx"} !~ "2[0-9]{2}" |
| json |
解析JSON格式日志 | {app="api"} | json |
| logfmt |
解析logfmt格式日志 | {app="api"} | logfmt |
| regexp |
使用正则提取字段 | {app="api"} | regexp "(?P<method>\w+) (?P<path>[\w/]+)" |
| unwrap |
提取数值用于计算 | | unwrap duration |
| label_format |
重命名或格式化Label | | label_format new_name=old_name |
3.2.3 度量查询（Metric Queries）
LogQL支持将日志行转换为时间序列指标，用于聚合计算和可视化。这是容量压测和故障定位中非常强大的功能。
- 速率计算：
rate({job="api"} |= "error" [5m])计算过去5分钟内错误日志的速率。 - 计数：
count_over_time({job="api"} [5m])统计过去5分钟内的日志行数。 - 分位数：
quantile_over_time(0.95, {job="api"} | unwrap duration [5m])计算请求延迟的P95值。
性能避坑： 在度量查询中使用
unwrap 时，确保提取的字段是数值类型，否则会导致查询失败。同时，避免在 rate 或 count_over_time 中使用高基数Label进行聚合，这会显著增加计算开销。
下图展示了LogQL查询的执行流程，从选择器筛选Stream，到管道处理，再到最终结果输出。
3.3 实战：使用LogQL定位故障
结合上述概念，我们通过一个故障定位场景来巩固理解。
场景： 线上API服务响应延迟飙升，需要快速定位问题根因。
- 筛选目标Stream：
{namespace="production", app="api-gateway"} - 过滤错误日志：
{namespace="production", app="api-gateway"} |= "error" - 解析JSON提取延迟字段：
{namespace="production", app="api-gateway"} |= "error" | json | duration > 2s - 聚合计算P99延迟：
quantile_over_time(0.99, {namespace="production", app="api-gateway"} | json | unwrap duration [10m]) - 按端点分组查看错误率：
sum by (endpoint) (rate({namespace="production", app="api-gateway"} |= "5xx" [5m]))
通过以上步骤，可以快速从海量日志中定位到是哪个端点的延迟异常，以及错误率的变化趋势，从而辅助故障定界。