前言
容器應用的監控和傳統應用的監控有很大的不同，在本系列的前面幾篇文章中提到了關于自頂向下的傳統監控政策以及在容器中常用的自底向上的反向監控政策與問題以及阿裡雲是如何通過資料鍊路與邏輯鍊路分離的方式解決上述問題的，
文章直達連接配接。
但是基于資料采集的監控對于告警而言，會有很大的時延，特别是對于容器的場景，一旦容器在采集間隔中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: kube-eventer
namespace: kube-system
spec:
replicas: 1
template:
metadata:
labels:
task: monitoring
k8s-app: kube-eventer
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ''
spec:
serviceAccount: admin
containers:
- name: kube-eventer
image: registry.cn-hangzhou.aliyuncs.com/acs/kube-eventer-amd64:v1.0.0-d9898e1-aliyun
imagePullPolicy: IfNotPresent
command:
- /kube-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，有興趣的開發者可以一同參與。