Loki告警的正确姿势

2020/12/21 21:04
阅读数 210

正文共1255字
预计阅读时间:3分钟

小白之前有通过Grafana设置Loki数据源的骚操作来做日志告警,虽然能直接在Grafana面板上配置告警,但它们还是没办法集中维护和管理。小白前面介绍了那么多关于Loki的文章,那么它有没有像Prometheus一样的rules来管理策略呢?答案是肯定的!

根据Loki的RoadMap,Ruler组件将于Loki 1.7.0版本正式推出。那么小白今天先带大家尝尝鲜,体验下在Loki里日志告警的正确姿势。

Loki Ruler

Loki1.7将包含一个名为Ruler的组件,它是从Crotex项目里面引入进来的(还记得Loki分集群的架构吗?)Ruler的主要功能是持续查询rules规则,并将超过阈值的事件推送给Alert-Manager或者其他Webhook服务。结合Cortex,Loki的Ruler组件也是如上的架构。可以看到loki和cortex的架构主要区别只剩下Configs API了。😂不过,牛逼的是借助注册到consul的一致性hash环,Loki的ruler同样支持多实例的分布式部署,实例和实例之间会自己根据分片协调需要使用的rules。不过这是一个动态的过程,任何ruler实例的添加或删除都会导致rules的重新分片

当前启用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

想快速体验Ruler的同学,可以用小白之前docker-compose来部署demo

https://github.com/CloudXiaobai/loki-cluster-deploy/tree/master/demo/docker-compose

Alert配置

Loki的rulers规则和结构与Prometheus完全兼容,唯一的区别在于查询语句不同。在Loki中我们用logQL来查询日志指标。一个典型的rules配置说明如下:

groups:
# 组名称
- name: <string>
rules:
# Alert名称
- alert: <string>
# logQL查询语句
expr: <string>
# 产生告警的持续时间
pending.
[ for: <duration> | default = 0s ]
# 自定义告警事件的label
labels:
[ <labelname>: <tmpl_string> ]
# 告警时间的注释
annotations:
[ <labelname>: <tmpl_string> ]

举个栗子,如果小白想通过日志查到某个业务日志的错误率大于5%就触发告警,那么可以配置成这样:

groups:
- name: should_fire
rules:
- alert: HighPercentageError
expr: |
sum(rate({app="foo", env="production"} |= "error" [5m])) by (job)
/
sum(rate({app="foo", env="production"}[5m])) by (job)
> 0.05
for: 10m
labels:
severity: page
annotations:
summary: High request latency

当告警事件产生时,我们在alert-manager上就能收到该事件的推送。

Ruler用途

  • 还没用metrics做应用监控告警时

对于有些业务可能没有暴露自己程序运行时的metrics时,这个时候我们可以借助查询日志的方法去构建相关的指标告警是比较容易的。比如上面提到的应用错误率的告警。

  • 黑匣子监控

对于完全不受我们控制的应用(开源服务或者三方闭源产品),在他们不提供监控指标时,我们采用查询日志指标的方式不失为一个快速的方法。

下面这个就是某大佬利用nginx日志和logQL做的监控和告警大盘,简直不要太炫酷。

  • 响应应用的事件

对于有些应用的特殊的事件,我们也可以利用Loki的ruler来做相关的通知,比如检查日志中的base auth认证泄漏事件

- name: credentials_leak
rules:
- alert: http-credentials-leaked
annotations:
message: "{{ $labels.job }} is leaking http basic auth credentials."
expr: 'sum by (cluster, job, pod) (count_over_time({namespace="prod"} |~ "http(s?)://(\\w+):(\\w+)@" [5m]) > 0)'
for: 10m
labels:
severity: critical
  • High-Cardinality高基告警

看过小白之前《Loki最佳实践》的同学知道,在Loki中high-cardinality会严重拖慢查询效率。这部分查询会在接下来的LogQL v2语法中实现。


往期推荐



Loki最佳实践(译)

听说,你的Loki还是单体?(下篇)

听说,你的Loki还是单体?(上篇)

巧用缓存加速Loki查询

Loki和Fluentd的那点事儿

今日实践:Loki丝滑般的数据切换

今日实践:利用Grafana为你的Loki添加告警

关于云原生小白

云原生小白的创号目的是将平日里离大家较远云原生应用以实用的角度展现出来,站在小白的角度来看待和使用云原生,并以每篇文章解决一个实际问题的出发点带领大家走进云原生。


扫描二维码

获取更多精彩

云原生小白


本文分享自微信公众号 - MoeLove(TheMoeLove)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部