Loki告警日志内容
在LogQL V1的时代，受限于简单的日志过滤解释器影响，我们往往只能通过简单的聚合函数将日志转化成区间向量加以告警，它的规则大改就像这个样子：
rules:
- alert: xxx告警
expr: sum(count_over_time({<日志标签>} |~ "xx关键字或者正则匹配字符串"[1m])) by (xxx) > 0
for: 0
labels:
service: xxx服务
annotations:
summary: "xxx服务出现xx错误{{ $labels.value }}次"
- alert: kube-apiserver日志错误数大于10
expr: count_over_time({job=~"message"}[1m]|="kube-apiserver"|~`E\d+`) > 10
for: 1m
labels:
severity: waning
team: wechat
annotations:
description: "kube-apiserver日志错误总数大于10,当前日志总数 {{humanize $value}} 详情 xxxx"
message: 日志报警恢复
summary: 日志报警
可以看到使用V1的语法将日志转成区间向量后，只保留日志流中原本的标签，而这里面的信息量极少，对于我们接收到日志告警时，期待看到的关键信息来说是远不够的。
有的同学就说了，“ 那我把关键信息放到日志流的label中不就好了？”
当然可以，不过考虑到两个成本，我相信你很快就会放弃这个想法。
1. 日志采集端的逻辑过于复杂
直接在日志采集端提取日志的关键信息作为标签，虽然理论上可行，不过在不同的业务、实例里面都要维护这套规则本身会带来大量的运维配置操作，相比在中心的的Loki实例上直接查询，时间成本上来说得不偿失。
2. 过多的日志流标签拖垮Loki性能
稍微了解Loki的小伙伴应该都知道，Loki不会索引日志内容，而是对日志流进行索引的，这样它能通过日志流的标签快速的查询出与之对应的日志内容 无界限的Label会造成高基，严重则直接拖垮集群。
那么有没有骚方法来解决上述矛盾呢？经过测试我们通过LogQL V2的语法还真可以解决这个问题。
相关语法学习：https://grafana.com/docs/loki/latest/logql/
1. 主要思路
LogQL v2的主要更新点在于将以往的log-filter换成了log-pipeline。在日志管道内我们可以通过Parser Expression将日志内容解析到label当中在做聚合处理。
它大改的流程如下：
日志流 -> 日志解析器 > 日志流（包含新label）> 日志过滤器 > 聚合函数
当下日志解释器分别支持regexp、logfmt和json这3种类型的格式处理。
regexp - 正则解析
大部分情况下我们的日志没有经过特殊格式化，它就像如下格式一样，这里我拿kubelet杀死nginx容器失败的日志来做告警样例
日志格式
E1217 23:38:52.832192 142923 kubelet_pods.go:1093] Failed killing the pod "nginx: failed to "KillContainer" for "nginx" with KillContainerError: "rpc error: code = Unknown desc = operation timeout: context deadline exceede
告警规则
rules:
- alert: kubelet faild killing pod
expr: |
sum by (systemd,level,alert_time,method,message,pid)
(count_over_time(
{systemd="kubelet"}
|~ "Failed killing the pod"
| regexp "(?P<level>\\w)(?P<alert_time>\\d{4}\\s\\d{2}:\\d{2}:\\d{2}.\\d{6})\\s+(?P<pid>\\d+) (?P<method>.*)] (?P<message>.*)$"[1m]))
> 0
for: 0
labels:
severity: high
annotations:
summary: "服务: {{ $labels.systemd }}
进程: {{ $labels.pid }}
时间：{{ $labels.alert_time }}
级别: {{ $labels.level }}
方法：{{ $labels.method }}
内容：{{ $labels.message }}"我们可以用expr中的语句在grafana的Expolre中进行验证，如果能得到如下的度量指标这表示语句正常
logfmt格式
logfmt格式的日志是一个可阅读性较好的结构化格式，LogQL V2的解释器能够直接提取logfmt的日志，下列我们以docker的日志为例子,我们要将error级别中关于OCI运行时报错的内容告警出来：
日志格式
time="2020-12-17T04:09:13.227200674+08:00" level=error msg="Handler for POST /containers/7912b27694555c0d6645011ad901d94425b032cd48fe3f2f3c9d0e631e1cee79/start returned error: OCI runtime create failed: container_linux.go:345: starting container process caused \"process_linux.go:303: getting the final child's pid from pipe caused \\\"EOF\\\"\": unknown"
告警规则
rules:
- alert: Docker OCI runtime exec faild
expr: |
sum by (time,level,systemd,msg)
(count_over_time(
{systemd="docker"}
| logfmt
| level = "error"
|~ "OCI" [1m]))
> 0
for: 0
labels:
severity: high
annotations:
summary: "服务: {{ $labels.systemd }}
时间：{{ $labels.time }}
级别: {{ $labels.level }}
内容：{{ $labels.msg }}"json格式
json是一种轻量级的数据交换格式，虽然可阅读性没有logfmt那么好，不过好在简单和易解析的优势，在很多开源服务里面也采用了此格式。在LogQL中json解释器的用法和logfmt一样
{"time":"2020-12-17T04:09:13.227200674+08:00","level":"error","msg":"Handler for POST /containers/7912b27694555c0d6645011ad901d94425b032cd48fe3f2f3c9d0e631e1cee79/start returned error: OCI runtime create failed: container_linux.go:345: starting container process caused \"process_linux.go:303: getting the final child's pid from pipe caused \\\"EOF\\\"\": unknown"}
rules:
- alert: Docker OCI runtime exec faild
expr: |
sum by (time,level,systemd,msg)
(count_over_time(
{systemd="docker"}
| json
| level = "error"
|~ "OCI" [1m]))
> 0
for: 0
labels:
severity: high
annotations:
summary: "服务: {{ $labels.systemd }}
时间：{{ $labels.time }}
级别: {{ $labels.level }}
内容：{{ $labels.msg }}"2. 启用Ruler
Ruler配置
当前启用Loki的Ruler组件比较简单，只要将下列的相关配置引入，并在Loki启动的参数里面加入-target=ruler即可
ruler:
# 触发告警事件后的回调查询地址
# 如果用grafana的话就配置成grafana/explore
external_url:
# alertmanager地址
alertmanager_url: <alertmanager_endpoint>
enable_alertmanager_v2: true
# 启用loki rules API
enable_api: true
# 对rules分片，支持ruler多实例
enable_sharding: true
# ruler服务的一致性哈希环配置，用于支持多实例和分片
ring:
kvstore:
consul:
host: <consul-endpoint>:8500
store: consul
# rules临时规则文件存储路径
rule_path: /tmp/rules
# rules规则存储
# 主要支持本地存储（local）和对象文件系统（azure, gcs, s3, swift）
storage:
type: local
local:
directory: /loki/rules
# rules规则加载时间
flush_period: 1m
调整Limit限制
由于我们用聚合函数将日志转成series，对于将日志内容提取到标签中，Loki是有一个默认的长度限制的，我们需要在limits_config中合理调整。
limits_config:
#label的name长度
max_label_name_length: <int> | default = 1024]
#label的value长度，这里就是日志内容的最大长度
max_label_value_length: <int> | default = 2048]
#label的name个数，如果解释器内容太多则需要调整此配置
max_label_names_per_series: <int> | default = 30]
#最大查询series的个数，解释器提取的键值对对应一个唯一的series
max_query_series: <int> | default = 500]合理的调整limits_config将影响我们LogQL v2语句查询结果，大家在用的时候请结合自己实际场景灵活调整
3. 总结
LogQL v2的语法给我们带来了很多骚操作，不过目前它仍然是单行的处理日志，期待告警时将该行的日志上下文一同打印出来，目前是不太可能实现的，我们只能通过告警的时间和内容再去Loki中查询当时的日志现场。
