前言
監控是保障系統穩定性的重要組成部分，在Kubernetes開源生态中，資源類的監控工具與元件百花齊放。除了社群自己孵化的
metrics-server
，還有從
CNCF
畢業的
Prometheus
等等，開發者可選的方案有很多。但是，隻有資源類的監控是遠遠不夠的，因為資源監控存在如下兩個主要的缺欠：
- 監控的實時性與準确性不足
大部分資源監控都是基于推或者拉的模式進行資料離線，是以通常資料是每隔一段時間采集一次，如果在時間間隔内出現一些毛刺或者異常，而在下一個采集點到達時恢複，大部分的采集系統會吞掉這個異常。而針對毛刺的場景，階段的采集會自動削峰，進而造成準确性的降低。
- 監控的場景覆寫範圍不足
部分監控場景是無法通過資源表述的，比如Pod的啟動停止，是無法簡單的用資源的使用率來計量的，因為當資源為0的時候，我們是不能區分這個狀态産生的真實原因。
基于上述兩個問題，Kubernetes是怎麼解決的呢？
事件監控-監控的新次元
Kubernetes作為雲原生的平台實作，從架構設計上将接口與實作做到了完整的解耦和插拔，以狀态機為整體的設計原則，通過設定期望狀态、執行狀态轉換、檢查并補償狀态的方式将資源的生命周期進行接管。
狀态之間的轉換會産生相應的轉換事件，在Kubernetes中，事件分為兩種，一種是Warning事件，表示産生這個事件的狀态轉換是在非預期的狀态之間産生的；另外一種是Normal事件，表示期望到達的狀态，和目前達到的狀态是一緻的。我們用一個Pod的生命周期進行舉例，當建立一個Pod的時候，首先Pod會進入Pending的狀态，等待鏡像的拉取，當鏡像錄取完畢并通過健康檢查的時候，Pod的狀态就變為Running。此時會生成Normal的事件。而如果在運作中，由于OOM或者其他原因造成Pod宕掉，進入Failed的狀态，而這種狀态是非預期的，那麼此時會在Kubernetes中産生Warning的事件。那麼針對這種場景而言，如果我們能夠通過監控事件的産生就可以非常及時的檢視到一些容易被資源監控忽略的問題。
一個标準的Kubernetes事件有如下幾個重要的屬性，通過這些屬性可以更好地診斷和告警問題。
- Namespace：産生事件的對象所在的命名空間。
- Kind：綁定事件的對象的類型，例如：Node、Pod、Namespace、Componenet等等。
- Timestamp：事件産生的時間等等。
- Reason：産生這個事件的原因。
- Message: 事件的具體描述。
- 其他資訊
通過事件的機制，我們可以豐富Kuernetes在監控方面的次元和準确性，彌補其他監控方案的缺欠。
kube-eventer v1.0.0的釋出與開源
針對Kubernetes的事件監控場景，Kuernetes社群在Heapter中提供了簡單的事件離線能力，後來随着Heapster的廢棄，相關的能力也一起被歸檔了。為了彌補事件監控場景的缺失，阿裡雲容器服務釋出并開源了kubernetes事件離線工具
kube-eventer
。支援離線kubernetes事件到釘釘機器人、SLS日志服務、Kafka開源消息隊列、InfluxDB時序資料庫等等。
在本次正式釋出的v1.0.0的版本中，作了如下功能的增強。
- 釘釘插件支援Namespace、Kind的過濾
- 支援與NPD插件的內建與部署
- 優化SLS插件的資料離線性能
- 修複InfluxDB插件啟動參數失效的問題
- 修複Dockerfile的安全漏洞
- 以及其他共11項功能修複
典型場景分析：
- 使用釘釘進行事件告警
- 使用SLS進行事件告警
- 結合NPD進行異常檢測與事件告警 ,此外使用容器服務的開發者可以直接用應用目錄中的 Helm Chart 進行部署。
項目開源位址：
https://github.com/AliyunContainerService/kube-eventer