背景
360在做容器化平臺之前，有一個基於小米開源的Open-Falcon進行二次開發的老監控系(Wonder)，這個系統承攬了公司所有的物理機和虛擬機的監控任務。隨着容器技術的普及，以容器的方式在創建應用時，由於Kubernetes容器編排系統部署的服務具有彈性擴容的特性，而老的監控系統無法感知這些動態創建的服務，已經不適合容器化的場景，所以360團隊就搭建了一套可以支持服務發現的新監控系統。
目前360一共有5個k8s線上集羣，分佈在北京上海和深圳，此外還有一些GPU集羣。
容器平臺構建以後帶來了以下幾個方面的好處：
- 節省資源。傳統一臺物理機只能部署一個實例，虛擬機能部署幾個服務，而使用容器一臺機器上能部署幾十個服務。
- 提高效率。1. 縮短流程。老系統要增加機器需要提前申請，而使用Kubernetes容器平臺只要整個資源池裏有充足的資源，不用提交預算就可以直接使用。2. 彈性擴容。在流量高峯期，容器平臺可以快速擴容；在流量不多的時段，空閒的資源可以處理其他離線任務，對資源的利用率高。
- 高可用。容器平臺可以保證運行的服務數量總是能達到預期。
- 減輕運維負擔。之前所有的部署上線活動都是運維來做。容器平臺上線後，開發人員可以直接在程序完成之後將其製作成鏡像，自己就可以進行部署。
當然任何事情不可能只有好的一面，容器平臺也會帶來相應的難度。容器平臺對服務的調度具有動態性，這就需要監控系統能動態感知服務實例落在哪裏，這是監控工作中的一個難點。
360容器平臺的監控維度
360容器平臺的監控系統對業務的技術指標進行監控，產品是從三個維度進行設計的：
- 容器: 這是最小的粒度。
- Pod: 一個Pod裏面可以有多個容器。
- 應用: 一個應用裏可能會有多個Pod。
除了這些技術指標監控，360容器平臺的監控系統還支持自定義監控。有些業務可能需要在自己的程序裏打點，比如要調第三方接口，查看延時和調用的次數等。大平臺上不同業務對數據的需求不同，爲了達到業務需求，支持自定義監控還是很必要的。新開發的業務可以在自己的程序裏引入Prometheus相關的SDK進行打點，360的容器平臺就會將這些metrics收集上來。
另外，沒有使用Prometheus的老系統在開發時沒有在程序裏打點的功能，這時業務可以針對自己的需求以sidecar的方式在程序的邊緣寫exporter來採集該進程所有的監控數據，exporter以metrics的形式報告給Prometheus，Prometheus進行抓取。
監控系統設計
360容器平臺監控系統架構圖如下：
日誌監控
360容器平臺監控系統的日誌監控使用的是ELK技術棧，但是進行了二次開發。團隊自己寫了 Log controller組件，該組件會實時地watch Kubernetes API Server的Deployment資源對象的狀態變化。當業務在創建應用時，是以Kubernetes deployment 的資源對象來創建的。Log controller會感知到這個資源的創建，知道這個 deployment下有多少Pod已經處於Ready狀態。當Log controller感知到新創建的Pod已經處於Ready狀態以後，會根據用戶在創建Pod時指定的真實日誌收集路徑拼接成它在物理機上的絕對路徑，然後將組裝好的配置並推送到360 自研的配置中心QConf中。
360 在Kubernetes集羣的每個Node節點都會部署一個二次開發的Logstash，該Logstash會定期（每隔十秒或者五秒，時間可配置）去配置中心(Qconf)拉取最新的配置。拉取完配置之後，Logstash會根據最新的配置把相關的的日誌收集到公司的Qbus（對Kafka進行包裝的產品）中，也就是數據已經進入到Kafka了。之後用戶可以在HULK私有云平臺(內部的私有云平臺)開通 ES服務，對日誌進行檢索分析或對其他日誌指定數據進行監控。
數據面板
360容器平臺監控系統的數據面板使用的是Grafana，並對其增加了LDAP用戶認證。可以顯示內存，訪問量，SIO, GPU等監控數據指標。
應用級別基礎監控指標:
Pod 級別基礎監控指標:
容器級別基礎監控指標:
Prometheus的基本原理是通過HTTP協議週期性抓取被監控組件的狀態，任意組件只要提供對應的HTTP接口就可以接入監控。不需要任何SDK或者其他的集成過程。這樣做非常適合做虛擬化環境監控系統，比如VM、Docker、Kubernetes等。輸出被監控組件信息的HTTP接口被叫做exporter 。目前常用的組件大部分都有exporter可以直接使用，比如HAproxy、Nginx、MySQL、Linux系統信息(包括磁盤、內存、CPU、網絡等等)。
報警
報警系統使用的是Prometheus自帶的Alertmanager組件，但是對其進行二次開發，集成了360自己的報警系統(Qalram)，並且可以通過360自己的即時通信工具（藍信）實時接收報警信息，友好方便快捷。
360容器平臺監控系統選型對比
在構建容器平臺的過程中，360團隊對監控系統的幾種常用的開源方案進行過選型對比，主要調研了K8s社區的Heapster（K8s安裝過程中默認安裝的插件）和Prometheus。
Heapster+InlfuxDB+Heapster自帶報警系統的方案有個缺點：它是針對K8s容器級別以及Code級別的技術指標監控，無法實現業務系統數據的監控，可擴展性不太友好，並且當未來數量級大時，不方便擴容。
最後團隊選擇了Prometheus 雲原生監控方案。雖然Prometheus在持久化方面做的還不夠好，但是Prometheus更適合雲原生生態。因爲容器是動態變化的，微服務架構下一個實例的多個副本也是動態變化的，Prometheus的Pull方式更適合動態變化的場景。
Prometheus的應用實踐
高可用
現在由於每個機房的機器數量不算太多，當前的設計方式是在每個機房部署一套Prometheus實例用於抓取目標的監控數據，同時在每個機房的上一層會部署兩套Prometheus來做高可用(HA). 這樣上層的Prometheus只要去下層抓取關心的metrics就可以。這樣做的好處:
- 過濾掉上層不關心的監控數據，減輕數據存儲的壓力。
- 對各個機房的數據進行聚合，並統一對外提供統一的報警，視圖查詢接口。
- 由於promethues實例運行在本地，本地的磁盤空間有限，默認只保留最近15天的監控數據，但是想查詢最近一個月，或者半年的數據，這個需求是做不到的。所以將prometheus的數據又入到了遠程存儲InfluxDB一份，用於數據的查詢使用。
報警
Prometheus的報警基於配置文件形式的。這種情況下，基礎性指標可以產品化。360團隊定製了配置模版，用戶只需要填具體的監控值就可以了。
針對業務監控，用戶需要學習Prometheus的promQL，這是由於不同的業務監控的需求不同，沒有辦法給業務統一的產品化服務，只能按業務自己制定報警規則去下發報警。
對於自定義業務，讓業務自己寫告警，統一的配置文件會上報到QConf。
運行在兩臺Prometheus機器上Agent會實時的watch配置中心(Qconf)是否有新的配置生成，如果存在則會Pull報警規則，並reload Prometheus實例。
爲什麼要使用開源系統
一般公司都有自研的監控系統，大多數監控系統都是基於開源項目開發的。爲什麼360要使用Prometheus？
- 在K8s大規模使用的今天，整個容器雲的生態推薦使用Prometheus。
- 節省人力成本。公司開發一套監控系統需要投入人力，如果後期開發人員流失，後期的維護是個大問題。但是使用開源監控系統，在社區活躍的情況下項目也有保證，並且我們也會在使用過程中回饋社區。
360容器平臺監控系統演進方向
目前的監控系統整體架構對於容器平臺來說可擴展性比較好。未來隨着集羣規模不斷擴大，單個集羣只有一個Prometheus實例要處理的Job數量爆發時，Prometheus的性能就會變差。這個時候可以針對不同的任務類型，在一個集羣裏部署多個Prometheus，每一個Prometheus只關心自己的任務，可控性會大大提升，同時整個架構的橫向擴展比較方便。
另外Prometheus存在持久化的問題，未來還需要對Prometheus進行數據遠程存儲（在上面的架構圖中使用的虛線標註部分）。
除了數據，360也在探索AIOps，可以對監控系統收集到的數據進行處理，探索故障定位和根因分析等。
普通團隊如何構建監控系統？
360監控團隊認爲，公司的監控系統要根據公司的規模和業務場景來定，不可能一套方案直接拿來就直接使用。
對於使用公有云並且規模較小的公司，公有云本身就有監控系統。如果公司自己有服務器，但是量不大，簡單搭建一個小型HA的監控系統就完全可以滿足監控的需求了。架構的演變是隨着業務規模的增長而不斷的演變改進的。這時就需要根據具體的情況，去選擇適合自己平臺的架構方案。
作者簡介
王希剛，目前在360做運維開發工作,有着多年PaaS設計及開發經驗，對Kubernetes，Docker等有較深入的研究。目前主要負責360 HULK容器雲平臺的研發工作。