為什么80%的碼農都做不了架構師？>>> ??

【編者按】監控系統對于云平臺的維護團隊起著至關重要的作用。Docker的出現對整個生態系統產生了巨大的印象，如何對短暫存在的Docker容器進行監控是本文中實踐要證明的主要問題。

?

繼上一篇文章CaaS環境實踐經驗總結（一）：ELK Stack部署，做了對log的處理后（上一篇文章只是一個PoC，離真正的可以放在生產環境上的log管理系統還有很長的一段距離），作者將目光轉向了監控系統。

?

以下為原文：

?

監控系統對于運維團隊的重要性我想大家應該都了解，個人理解一個便于使用的監控系統包括以下幾個特點：

?

統一的界面管理，清晰的dashboard – 沒有人想打開1000個瀏覽器頁面去監控1000個服務

快速定位出問題的服務 – 此處包括與告警系統的集成以及快速定位感興趣的機器或服務（filtering）

定制自己感興趣的組合

能自動應對監控目標的擴容，無需手動添加新的機器或服務

?

我們現在使用的監控系統（xymon）是一個面向服務器的監控系統，能很好的服務那些長期存在的物理機或者虛擬機，但是對于短暫存在的容器就會遇到很多問題，所以需要轉向一個面向服務的監控系統。有了以上需求，我決定使用一下Prometheus。

?

目前大多數監控系統都是使用客戶端推送的方式，即監控程序收集監控數據之后推送到一個集中管理的監控服務器。與之相反，Prometheus采用了定期輪訓的方式，Prometheus服務器定期輪訓監控目標，希望通過監控目標的HTTP接口獲取數據。由于我并沒有把Prometheus放到一個真正的集群中做測試，所以這兩種方式的優劣我目前還沒法提供詳細的數據。

?

選定目標之后，我就開始把Prometheus部署到我的測試目標靈雀云上。可能有人看到這里就準備關閉此頁，原因可能如下：Prometheus已經做了容器化，把容器毫無差異的部署到不同的平臺正式容器化所帶來的優勢，以下內容應該毫無新意。在我開始做之前我也是這個想法，所以我給自己半小時的時候部署。但真正當我開始做的時候，我才發現如下問題：

?

Prometheus需要通過unix domain socket與docker daemon通信獲得當前運行的所有docker container，這在一個共有云CaaS平臺上是無法實現的。因為同一臺主機上的docker daemon可能服務于不同的客戶，而且同一個客戶的多個docker container也可能部署在多臺主機上

Prometheus需要通過cgroup獲取當前contaienr的metrics，此方法在共有云CaaS上同樣無法實現，原因跟上一條相同。

?

所以對于共有云CaaS來說，我需要自定義Prometheus exporter來獲取1）本用戶的所有docker container 2）此container的metrics。靈雀云提供了API獲取當前用戶的所有服務，每個服務的實例以及每個實例的metrics，更方便的是靈雀云開源的基于python的API。在此實驗中，我直接調用了alaudacli庫以及prometheus_client庫實現自己的exporter。具體代碼可在github找到。

?

在部署服務的時候需要添加環境變量ALAUDA_USERNAME以及ALAUDA_PASSWORD用于認證

?

def?alauda_login(username,?password,?cloud='cn',?endpoint='https://api.alauda.cn/v1/'): alaudacli.commands.login(username,?password,?cloud,?endpoint)

?

登錄成功之后即可獲取當前用戶的所有服務，其中namespace為用戶名。

?

def?alauda_service_list(namespace): service_list?=?alaudacli.service.Service.list(namespace,?1) return?service_list

?

靈雀云的每一個服務可以有多個實例做負載均衡，而metrics是針對每一個實例統計的，所以下一步需要獲取每一個服務的實例。

?

def?alauda_instance_list(namespace,?name): service_inst?=?alaudacli.service.Service.fetch(name,?namespace) instances?=?service_inst.list_instances() instance_list?=?[] for?data?in?instances: instance?=?json.loads(data.details) instance_list.append(instance) return?instance_list

?

最后一步就是獲取每個實例的統計數值了，此API在alaudacli當中沒有實現，所以我直接調用alauda開放的API獲取。

?

def?alauda_get_instance_metrics(namespace,?name,?instance_uuid,?start_time,?end_time,?interval): service_inst?=?alaudacli.service.Service.fetch(name,?namespace) url?=?service_inst.api_endpoint?+?'services/{0}/{1}/instances/{2}/metrics?start_time={3}&end_time={4}&point_per_period={5}'.format(service_inst.namespace,?service_inst.name,?instance_uuid,?start_time,?end_time,?interval) r?=?requests.get(url,?headers=service_inst.headers) if?r.text:data?=?json.loads(r.text)return?data else:return?None

?

得到了感興趣的數據之后就可以把這些數據暴露給prometheus服務器以便查詢（此處偷懶只把CPU和memory的數據拿出來了：））。這里要注意的是申明的每一個統計對象都是設置了label以便在prometheus上做filtering和grouping。

?

g_cpu_usage?=?Gauge("cpu_cumulative_usage",?"CPU?Cumulative?Usage",?["service",?"instance"]) g_cpu_utilization?=?Gauge('cpu_utilization',?"CPU?utilization",?["service",?"instance"]) g_memory_usage?=?Gauge('memory_usage',?"Memory?Usage",?["servie",?"instance"]) g_memory_utilization?=?Gauge('memory_utilization',?"Memory?Utilization",?["service",?"instance"])

?

把serviceexporter服務部署到靈雀云上即可通過瀏覽器獲取當前運行的所有服務的統計數據。

?

?

最后需要部署Prometheus服務，此鏡像是基于prom/prometheus官方鏡像修改之后的鏡像。因為Prometheus服務器定期輪訓監控對象的API，所以prometheus需要知道監控對象的IP地址以及端口。修改之后的鏡像可以通過服務鏈接（link）獲取到serviceexporter服務的IP地址以及端口。（此處偷懶沒通過link的方式，而是直接把serviceexpoter服務的IP地址和端口寫死了。。。）。

?

通過訪問Prometheus服務器的UI可以得到每個服務圖形化的統計數據。

?

?

可以通過設置filtering只看kibana服務的統計

?

?

可以通過sum函數將多個kibana實例統計合并

?

?

通過以上部署，我可以在統一的UI監控所有運行在靈雀云上的服務，并且設置相應的閾值報警（此實驗中未涉及），我可以定制自己感興趣的dashboard，快速定位可能出現問題的服務。

?

本實驗只是一個PoC的目的，離真正的生產環境還有距離，歡迎大家提供更多意見以及解決方案。

?

作者簡介：杜航，Websense云基礎架構組開發經理，專注于Openstack和Docker。

轉載于:https://my.oschina.net/alauda/blog/476959

總結

以上是生活随笔為你收集整理的CaaS环境下实践经验总结（二）：监控系统部署的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。