360容器平臺監控實踐

背景

360 在做容器化平臺之前，有一個基於小米開源的 Open-Falcon 進行二次開發的老監控系統 (Wonder)，這個系統承攬了公司所有的物理機和虛擬機器的監控任務。隨著容器技術的普及，以容器的方式在建立應用時，由於 Kubernetes 容器編排系統部署的服務具有彈性擴容的特性，而老的監控系統無法感知這些動態建立的服務，已經不適合容器化的場景，所以 360 團隊就搭建了一套可以支援服務發現的新監控系統。

目前 360 一共有 5 個 Kubernetes 線上叢集，分佈在北京上海和深圳，此外還有一些 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 就可以。這樣做的好處:

1. 過濾掉上層不關心的監控資料，減輕資料儲存的壓力。

2. 對各個機房的資料進行聚合，並統一對外提供統一的報警，檢視查詢介面。

3. 由於 promethues 例項執行在本地，本地的磁碟空間有限，預設只保留最近 15 天的監控資料，但是想查詢最近一個月，或者半年的資料，這個需求是做不到的。所以將 prometheus 的資料又入到了遠端儲存 InfluxDB 一份，用於資料的查詢使用。

Prometheus 的報警基於配置檔案形式的。這種情況下，基礎性指標可以產品化。360 團隊定製了配置模版，使用者只需要填具體的監控值就可以了。

針對業務監控，使用者需要學習 Prometheus 的 promQL，這是由於不同的業務監控的需求不同，沒有辦法給業務統一的產品化服務，只能按業務自己制定報警規則去下發報警。

對於自定義業務，讓業務自己寫告警，統一的配置檔案會上報到 QConf。執行在兩臺 Prometheus 機器上 Agent 會實時的 watch 配置中心 (Qconf) 是否有新的配置生成，如果存在則會 Pull 報警規則，並 reload Prometheus 例項。

為什麼要使用開源系統

一般公司都有自研的監控系統，大多數監控系統都是基於開源專案開發的。為什麼 360 要使用 Prometheus？

1. 在 K8s 大規模使用的今天，整個容器雲的生態推薦使用 Prometheus。

2. 節省人力成本。公司開發一套監控系統需要投入人力，如果後期開發人員流失，後期的維護是個大問題。但是使用開源監控系統，在社群活躍的情況下專案也有保證，並且我們也會在使用過程中回饋社群。

360 容器平臺監控系統演進方向

目前的監控系統整體架構對於容器平臺來說可擴充套件性比較好。未來隨著叢集規模不斷擴大，單個叢集只有一個 Prometheus 例項要處理的 Job 數量爆發時，Prometheus 的效能就會變差。這個時候可以針對不同的任務型別，在一個叢集裡部署多個 Prometheus，每一個 Prometheus 只關心自己的任務，可控性會大大提升，同時整個架構的橫向擴充套件比較方便。

另外 Prometheus 存在持久化的問題，未來還需要對 Prometheus 進行資料遠端儲存（在上面的架構圖中使用的虛線標註部分）。

除了資料，360 也在探索 AIOps，可以對監控系統收集到的資料進行處理，探索故障定位和根因分析等。

普通團隊如何構建監控系統？

360 監控團隊認為，公司的監控系統要根據公司的規模和業務場景來定，不可能一套方案直接拿來就直接使用。

對於使用公有云並且規模較小的公司，公有云本身就有監控系統。如果公司自己有伺服器，但是量不大，簡單搭建一個小型 HA 的監控系統就完全可以滿足監控的需求了。架構的演變是隨著業務規模的增長而不斷的演變改進的。這時就需要根據具體的情況，去選擇適合自己平臺的架構方案。

作者簡介

王希剛

目前在 360 做運維開發工作, 有著多年 PaaS 設計及開發經驗，對 Kubernetes，Docker 等有較深入的研究。目前主要負責 360 HULK 容器雲平臺的研發工作。