报警规则
现在我们只是把 AlertManager 容器运行起来了，也和 Prometheus 进行了关联，但是现在我们并不知道要做什么报警，因为没有任何地方告诉我们要报警，所以我们还需要配置一些报警规则来告诉我们对哪些数据进行报警。
警报规则允许你基于 Prometheus 表达式语言的表达式来定义报警报条件，并在触发警报时发送通知给外部的接收者。
同样在 Prometheus 的配置文件中添加如下报警规则配置：
rule_files:
- /etc/prometheus/rules.yml其中 rule_files 就是用来指定报警规则的，这里我们同样将 rules.yml 文件用 ConfigMap 的形式挂载到 /etc/prometheus 目录下面即可，比如下面的规则：（alert-rules.yml）
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-config
namespace: kube-mon
data:
prometheus.yml: |
global:
scrape_interval: 15s
scrape_timeout: 15s
evaluation_interval: 30s # 默认情况下每分钟对告警规则进行计算
alerting:
alertmanagers:
- static_configs:
- targets: ["alertmanager:9093"]
rule_files:
- /etc/prometheus/rules.yml
...... # 省略prometheus其他部分
rules.yml: |
groups:
- name: test-node-mem
rules:
- alert: NodeMemoryUsage
expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 20
for: 2m
labels:
team: node
annotations:
summary: "{
{$labels.instance}}: High Memory usage detected"
description: "{
{$labels.instance}}: Memory usage is above 20% (current value is: {
{ $value }})"上面我们定义了一个名为 NodeMemoryUsage 的报警规则，一条报警规则主要由以下几部分组成：
alert：告警规则的名称expr：是用于进行报警规则 PromQL 查询语句for：评估等待时间（Pending Duration），用于表示只有当触发条件持续一段时间后才发送告警，在等待期间新产生的告警状态为pendinglabels：自定义标签，允许用户指定额外的标签列表，把它们附加在告警上annotations：指定了另一组标签，它们不被当做告警实例的身份标识，它们经常用于存储一些额外的信息，用于报警信息的展示之类的
for 属性:
这个参数主要用于降噪，很多类似响应时间这样的指标都是有抖动的，通过指定
Pending Duration，我们可以过滤掉这些瞬时抖动，可以让我们能够把注意力放在真正有持续影响的问题上。
为了让告警信息具有更好的可读性，Prometheus 支持模板化 label 和 annotations 中的标签的值，通过 $labels.变量 可以访问当前告警实例中指定标签的值，$value 则可以获取当前 PromQL 表达式计算的样本值。
为了方便演示，我们将的表达式判断报警临界值设置为 20，重新更新 ConfigMap 资源对象，由于我们在 Prometheus 的 Pod 中已经通过 Volume 的形式将 prometheus-config 这个一个 ConfigMap 对象挂载到了 /etc/prometheus 目录下面，所以更新后，该目录下面也会出现 rules.yml 文件，所以前面配置的 rule_files 路径也是正常的，更新完成后，重新执行 reload 操作，这个时候我们去 Prometheus 的 Dashboard 中切换到 alerts 路径下面就可以看到有报警配置规则的数据了：
页面中出现了我们刚刚定义的报警规则信息，而且报警信息中还有状态显示，一个报警信息在生命周期内有下面 3 种状态：
pending: 表示在设置的阈值时间范围内被激活了firing: 表示超过设置的阈值时间被激活了inactive: 报警规则没有得到满足或者已经过期（还没触发或者已经修复）
这里的 pending 状态是说报警规则已经得到满足了，但是持续时间还不够，这里的持续时间是通过配置文件中的 for 来设置的，如果没有设置，那么就不存在 pending 状态，而是报警规则一得到满足就会发送报警，如果设置了这个字段，那么就会进入 pending 状态，并且在持续时间足够的时候，才会发送出去。
同时对于已经 pending 或者 firing 的告警，Prometheus 也会将它们存储到时间序列 ALERTS{} 中。当然我们也可以通过表达式去查询告警实例：
ALERTS{alertname="<alert name>", alertstate="pending|firing", <additional alert labels>}
样本值为1表示当前告警处于活动状态（pending 或者 firing），当告警从活动状态转换为非活动状态时，样本值则为 0。
我们这里的状态现在是 firing 就表示这个报警已经被激活了，我们这里的报警信息有一个 team=node 这样的标签，而最上面我们配置 alertmanager 的时候就有如下的路由配置信息了：
routes:
- receiver: email
group_wait: 10s
match:
team: node
所以我们这里的报警信息会被 email 这个接收器来进行报警，我们上面配置的是邮箱，所以正常来说这个时候我们会收到一封如下的报警邮件：
我们可以看到收到的邮件内容中包含一个 View In AlertManager 的链接，我们同样可以通过 NodePort 的形式去访问到 AlertManager 的 Dashboard 页面：
☸ ➜ kubectl get svc -n kube-mon
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
alertmanager NodePort 10.98.1.195 <none> 9093:31194/TCP 141m
然后通过 <任一Node节点>:31194 进行访问，我们就可以查看到 AlertManager 的 Dashboard 页面，在这个页面中我们可以进行一些操作，比如过滤、分组等等，里面还有两个新的概念：Inhibition(抑制) 和 Silences(静默)。
Inhibition：如果某些其他警报已经触发了，则对于某些警报，Inhibition 是一个抑制通知的概念。例如：一个警报已经触发，它正在通知整个集群是不可达的时，Alertmanager 则可以配置成关心这个集群的其他警报无效。这可以防止与实际问题无关的数百或数千个触发警报的通知，Inhibition 需要通过上面的配置文件进行配置。Silences：静默是一个非常简单的方法，可以在给定时间内简单地忽略所有警报。Silences 基于 matchers 配置，类似路由树。来到的警告将会被检查，判断它们是否和活跃的 Silences 相等或者正则表达式匹配。如果匹配成功，则不会将这些警报发送给接收者。