新版：
设计原则：
1、group_by: ['id','alertname']
每次发来一组告警，这组告警的特点就是拥有相同的id（如果有）和alertname。对于没有id的告警仅以alertname区分，对于有id的告警，则根据结合id和alertname进行区分。
2、策略文件分发
1）初始阶段，在自己的服务器端存一份Defalut.rules。
2）每新建一个Kubernetes集群，就将这份规则拷贝一份，重新在服务器中生成一个[ip]Rules.rules的文件，同时将这个策略文件发送到指定集群中。
注：未来每次对相应集群的策略文件进行修改，都是先在服务器中对相应的[ip]Rules.rules文件进行修改，然后分发到指定集群中，完成对老策略文件的覆盖。
3）分发到相应集群之后，这个策略文件自动更名为PrometheusRules.rules文件（即此时每个集群中的策略文件都可以理解为是这个集群相应的自定义策略文件）。
注：此时更改服务器端的Default.rules文件，会影响到下一个新添加进来的kubernetes集群，之前已添加的集群由于已经生成自定义策略文件，不受Default文件的变化的影响。
4）可以对各集群的自定义策略进行修改，不绑定任何资源默认针对所有资源，绑定资源后那些没绑定的资源便不会再进行告警了。如有Pod1-3，在自定义策略中将Pod相关的指标只绑定Pod1，则Pod2和Pod3便不会再对Pod相关指标进行告警了。
注：对Pod相关指标统一绑定资源（无论是状态指标，还是CPU、内存），而不是每条指标都重新绑资源。
3、告警的接受
通过在alertmanager.yml文件中设置静默，使得在[‘alertname’,‘metricName’]相等的情况下，低等级的告警被高等级的告警抑制。
注1：三种等级的告警共用一个alertname（prometheus允许同一个group中有相同alertname的告警存在）。
注2：每条告警的id由kubernetesIP+pod_name+metricname。同一个告警表达式，不同的等级也是一个id。
注3：两种极端情况分析：
CPU >89% 严重告警
CPU>79% 中等告警
CPU>69% 挠痒痒告警
情况1：先90%，后来降到80%，再降到70%
开始90%，三种等级的告警都触发了，但是中等和挠痒痒告警被规则静默了。只有严重告警被存库了。
降到80%，90%的告警被恢复了，中等和挠痒痒告警被同时触发，其中挠痒痒告警被静默了，中等告警存库。
情况2：先70%，再升到80%，最后90%
开始70%，触发挠痒痒告警并存库。
后来80%，触发中等告警和挠痒痒告警，挠痒痒告警被静默，中等告警存库并覆盖库中原本的挠痒痒告警。
4、告警的恢复
来的恢复对应的id如果在数据库中没有，则不执行任何操作。如果有，则将这条告警恢复。
注：如果一组告警中又有恢复又有告警，则先执行恢复操作。