前言
容器应用的监控和传统应用的监控有很大的不同，在本系列的前面几篇文章中提到了关于自顶向下的传统监控策略以及在容器中常用的自底向上的反向监控策略与问题以及阿里云是如何通过数据链路与逻辑链路分离的方式解决上述问题的，文章直达连接。
但是基于数据采集的监控对于告警而言，会有很大的时延，特别是对于容器的场景，一旦容器在采集间隔中Panic后被拉起，那么很有可能会造成对异常的告警静默。那么对于这种场景改通过什么方式来解决呢？在传统的应用中是通过接入层检测或者定期检测的方式进行保活，这种方式在Kubernetes中一样也可以通过配置来实现，那么怎么将这些内容通过告警的方式进行通知呢？
在回答这个问题之前，我们首先要先讲一下Kubernetes中的状态机制，在Kubernetes中有针对于不同场景的抽象，例如Deployment表示普通的部署、StatefulSet表示有状态的服务，DaemonSet表示在每个节点运行的后台服务等等，每个不同的抽象都可以通过相应的Yaml语法进行描述，当开发者将Yaml提交给Kubernetes后，相应的变更逻辑就会进行执行。如果此时我们通过Dashboard查看刚才我们不是的Yaml文件时，我们会发现，其中有很多的字段并不是原本就存在的，而是后来通过Kubernetes内部添加上的。例如：
值得特别关注的是status这个字段，这个字段中包含了当前抽象的各种状态，以及目前预置的支持的状态条件。如果状态条件的status字段为True，那么说明此时处在当前的状态。例如此例中，这个Deployment就处在Available和Progressing两个状态。这种机制有一个非常好的用途，当我们发现当前抽象异常的时候，可以通过查看status的内容来判断大致的问题进而进行解决。
有了这个机制，我们还需要的就是如何快速感知到状态的异常并进行处理。在Kubernetes中针对这个问题，提供了事件的机制，将事件和抽象进行绑定，将状态对应的影响和事件的类型进行分类，比如常规事件的类型是Normal而异常类型的事件为Warning。也就是说，一旦集群中出现了Warning类型的事件，那么此时就需要开发者接入进行甄别是否需要手动介入进行处理。
那么如何实时的获取集群中的异常事件呢？对于这种实时性较强的告警策略而言，ChatOps或许是最佳的方式，大部分阿里云容器服务的开发者都会有自己的钉钉群，将事件同步到群中即可实现故障的快速处理。
具体的操作步骤如下：
1.在钉钉群中加入钉钉机器人，并拷贝记录下webhook地址
2.在容器服务控制台中下发eventer组件
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: eventer
namespace: kube-system
spec:
replicas: 1
template:
metadata:
labels:
task: monitoring
k8s-app: eventer
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ''
spec:
serviceAccount: admin
containers:
- name: eventer
image: registry.cn-hangzhou.aliyuncs.com/acs/eventer:v1.6.0
imagePullPolicy: IfNotPresent
command:
- /eventer
- --source=kubernetes:https://kubernetes.default
- --sink=dingtalk:[your_webhook_url]&label=[your_cluster_id]&level=[可选参数:Normal或者Warning，默认值为：Warning]3.部署成功后30s，eventer即开始生效，当事件等级超过阈值等级的时候即可收到如下告警。
最后
由于eventer属于kubernetes的Heapster项目，Heapster项目目前被官方列入deprecated阶段，但是这并不妨碍eventer成为Kubernetes实时告警中的唯一选择，包含钉钉告警的代码仓库地址：https://github.com/AliyunContainerService/heapster，有兴趣的开发者可以一同参与。