Prometheus 监控 Kubernetes Job 资源误报的坑

昨天在 Prometheus 课程辅导群里面有同学提到一个问题,是关于 Prometheus 监控 Job 任务误报的问题,大概的意思就 CronJob 控制的 Job,前面执行失败了,监控会触发报警,解决后后面生成的新的 Job 可以正常执行了,但是还是会收到前面的报警:

问题描述

这是因为一般在执行 Job 任务的时候我们会保留一些历史记录方便排查问题,所以如果之前有失败的 Job 了,即便稍后会变成成功的,那么之前的 Job 也会继续存在,而大部分直接使用 kube-prometheus 安装部署的话使用的默认报警规则是kube_job_status_failed > 0,这显然是不准确的,只有我们去手动删除之前这个失败的 Job 任务才可以消除误报,当然这种方式是可以解决问题的,但是不够自动化,一开始没有想得很深入,想去自动化删除失败的 Job 来解决,但是这也会给运维人员带来问题,就是不方便回头去排查问题。下面我们来重新整理下思路解决下这个问题。

[阅读全文]

使用 Loki 进行日志监控和报警

对于生产环境以及一个有追求的运维人员来说,哪怕是毫秒级别的宕机也是不能容忍的。对基础设施及应用进行适当的日志记录和监控非常有助于解决问题,还可以帮助优化成本和资源,以及帮助检测以后可能会发生的一些问题。前面我们介绍了使用 EFK 技术栈来收集和监控日志,本文我们将使用更加轻量级的 Grafana Loki 来实现日志的监控和报警,一般来说 Grafana Loki 包括 3 个主要的组件:Promtail、Loki 和 Grafana(简称 PLG),最为关键的是如果你熟悉使用 Prometheus 的话,对于 Loki 的使用也完全没问题,因为他们的使用方法基本一致的,如果是在 Kubernetes 集群中自动发现的还具有相同的 Label 标签。

[阅读全文]