Grafana 邮件告警配置

1、grafana-server 配置 smtp 服务器

2、配置邮件通知方式

保存并发送测试邮件，配置完成

3、Linux 内存告警配置

问题：Template variables are not supported in alert queries

解决办法：单独配置个告警的视图，用正则匹配出所有的主机 或者 每台主机单独一个查询语句

完成状态

测试内存告警的邮件

参考： https://grafana.com/docs/alerting/rules/

晚上收到服务接口电话告警，第一时间通过prometheus查看服务耗时却正常。这就奇怪了，为了确保告警程序没有问题，不是误报。登录服务器查看告警程序的日志，通过日志发现确实是接口调用频繁超时引起的告警。因为告警程序部署在阿里云，而服务部署在k8s。我们的告警逻辑是通过告警程序调用部署在k8s服务接口，如果接口超时超过一定的次数就告警。因为告警程序和服务部署在不同的机房，于是认为是网络抖动引起的，因为前几天就发送过k8s网络组建出现问题导致服务调用耗时突然变高。后面同事去向运维确定下是否k8s的nginx-ingress-controller是否出现问题，后面运维同事确认是因为k8s nginx-ingress-controller在新的扩容机器出问题了。一开始不太明白为什么nginx-ingress-controller出现问题会引起服务耗时很高，后面自己缕了下调用关系。因为我们还有邮件告警，邮件告警是监听nginx的error日志来告警，邮件内容告警的内容都是status 504，504错误表示nginx调用服务出问题了。那么接下来只需要找到服务方是谁就可以了。而我们的nginx又会调用k8s ingress controller的nginx，nginx-ingress-controller进而调用部署在k8s的服务，整个调用链路是这样的。

前端接口请求->lvs->阿里云nginx->nginx-ingress-controller->service

邮件告警内容是阿里云nginx报出来的，显示status504.

所以下一步需要排查k8s ingress controller和我们的服务本身有无问题。

通过监控指标，我们排查了服务本身正常，那么可以确定是nginx-ingress-controller出了问题，后面排查确实是一个nginx-ingress-controller的node节点出问题导致。

总结

排查问题要有思路，根据关键信息去排查问题事半功倍。比如这次邮件告警提示的status 504，顺着这个思路去排查很快可以定位问题。

---