前言 本文可能不會詳細記錄每一步實現的過程，但一定程度上可以引領小伙伴走向更開闊的視野，串聯每個環節，呈現予你不一樣的效果。 業務規模 8個平臺 100+台伺服器 10+個集群分組 微服務600+ 用戶N+ 面臨問題 隨著分散式微服務容器技術的發展，傳統監控系統面臨許多問題： 容器如何監控 微服務如 ...
前言
本文可能不會詳細記錄每一步實現的過程，但一定程度上可以引領小伙伴走向更開闊的視野，串聯每個環節，呈現予你不一樣的效果。
業務規模
- 8個平臺
- 100+台伺服器
- 10+個集群分組
- 微服務600+
- 用戶N+
面臨問題
隨著分散式微服務容器技術的發展，傳統監控系統面臨許多問題：
- 容器如何監控
- 微服務如何監控
- 集群性能如何進行分析計算
- 如何管理agent端大量配置腳本
這些都是傳統監控所要面臨的棘手問題，那麼如何解決當前遇到的問題，GPE橫空出世，後面會重點分析。
系統監控
- 目標群體：系統日誌、伺服器、容器、系統軟體運行指標
- 日誌架構：ELK (Elasticsearch+Logstash+Kibana+Redis)
- 監控架構：GPE (Grafana+Prometheus+Exporter+Consul)
- 報警方式：郵件、簡訊、釘釘以及自定義webhook，監控中心7x24小時
ELK日誌
隨著分散式微服務的盛行，功能模塊的拆分細化，無論對於開發還是運維，日誌的重要性都是不言而喻的，但是如何存儲分析定位查看日誌，一百個公司可能會有兩百種做法。有的很少記錄日誌，有的日誌等級都不分，有的寫入文本然後就不管不問了，有的向MySql資料庫一扔也沒有了下文，等到用戶投訴或者被髮現問題，才會翻一翻。
那麼如何正確優雅的記錄日誌呢？相信大家對於ELK並不陌生，可能不少小伙伴都接觸過，對於中小型互聯網創業公司來說，使用ELK搭建日誌分析系統的確是一個不錯的選擇。
架構圖
核心組件
ELK由Elasticsearch、Logstash和Kibana三劍客組成，當然了以上是最基本的組件，為了使的架構流程更加豐滿，我們加入了Redis做緩衝隊列，配置了sendmail做異常日誌告警。
ElasticSearch
ElasticSearch是一個基於Lucene的搜索伺服器。它提供了一個分散式多用戶能力的全文搜索引擎，基於RESTful web介面。它的特點有：分散式，零配置，自動發現，索引自動分片，索引副本機制，restful風格介面等。
Logstash
Logstash數據分析工具，它可以對系統生成的的日誌進行採集、分析，存儲。2013 年，Logstash 被 Elasticsearch 公司收購，ELK Stack 正式成為官方用語。
kibana
Kibana是一個開源的分析與可視化平臺，用來搜索、查看存儲在Elasticsearch索引中的數據。
工作流程
- logstash(shipper) 實時監控並過濾收集每個服務的日誌信息
- logstash(shipper) 把收集來的日誌(INFO 、DEBUG 、RROR 、WARN等)分別發送到Redis
- logstash(indexer) 按照日誌分類分別從Redis讀取日誌信息併發送給ElasticSearch
- logstash(indexer) 過濾出RROR日誌通過郵件或者其它webhook方式告警開發運維人員
- Kibana讀取ElasticSearch數據結合自定義搜索進行頁面展示
GPE監控
ELK主要收集分析預警的是我們平臺系統中各個服務的業務日誌，一般通過日誌組件(log4j 、log4j2 、logback)來收集並寫入文本。但是對於系統本身以及一些應用軟體的監控預警，這套方案顯然是不合適的，這裡推薦一下GPE三劍客，當然了GPE是我自己意淫出來的組合。
架構圖
核心組件
Grafana、Prometheus、Exporter(一系列插件)，自定義的三劍客，當然了為了使得整合監控程式更加流暢完整，我們加入了註冊中心Consul做服務發現，實現動態添加服務，使用郵件、釘釘以及webhook實現異常告警。
GPE組件只是其中的一種實現方式罷了，Grafana配合InfluxData提供Telegraf也可以收集很多Metrics，實現更為豐富的大屏監控預警。
Grafana
Grafana 是一個開箱即用的可視化工具，具有功能齊全的度量儀錶盤和圖形編輯器，有靈活豐富的圖形化選項，可以混合多種風格，支持多個數據源特點。
Prometheus
Prometheus是一個開源的服務監控系統，它通過HTTP協議從遠程的機器收集數據並存儲在本地的時序資料庫上。
- 多維數據模型（時序列數據由metric名和一組key/value組成）
- 在多維度上靈活的查詢語言(PromQl)
- 不依賴分散式存儲，單主節點工作.
- 通過基於HTTP的pull方式採集時序數據
- 可以通過push gateway進行時序列數據推送(pushing)
- 可以通過服務發現或者靜態配置去獲取要採集的目標伺服器
- 多種可視化圖表及儀錶盤支持
如架構圖所示，Prometheus通過安裝在遠程機器上的exporter來收集監控數據。
Consul
Consul有多個組件，但是整體來看，它是你基礎設施中用於發現和配置服務的一個工具。它提供如下幾個關鍵功能：
- 服務發現： Consul的某些客戶端可以提供一個服務，例如api或者mysql，其它客戶端可以使用Consul去發現這個服務的提供者。使用DNS或者HTTP，應用可以很容易的找到他們所依賴的服務。
- 健康檢查： Consul客戶端可以提供一些健康檢查，這些健康檢查可以關聯到一個指定的服務（服務是否返回200 OK），也可以關聯到本地節點（記憶體使用率是否在90%以下）。這些信息可以被一個操作員用來監控集群的健康狀態，被服務發現組件路由時用來遠離不健康的主機。
- 鍵值存儲： 應用可以使用Consul提供的分層鍵值存儲用於一些目的，包括動態配置、特征標記、協作、leader選舉等等。通過一個簡單的HTTP API可以很容易的使用這個組件。
- 多數據中心： Consul對多數據中心有非常好的支持，這意味著Consul用戶不必擔心由於創建更多抽象層而產生的多個區域。
Consul被設計為對DevOps群體和應用開發者友好，他非常適合現代的、可伸縮的基礎設施。
工作流程
- Exporter組件註冊到Consul註冊中心
- Prometheus拉取Consul註冊中心的servers
- Exporter組件獲取伺服器或者系統軟體的metrics
- Grafana配置Prometheus數據源獲取其採集數據結合自定義面板實現監控大屏
- Grafana通過設置Alerting實現監控預警
小結
如文章開頭所述，本文並沒有一步步詳細記錄安裝使用教程，這些教程網上都有，即使有坑，相信作為程式員的你也能夠解決。不才，在這裡只是拋磚引玉，希望各位小伙伴可以學到更多知識。
還記得許多年前的春天，那時網站還都是靜態頁面，沒有圖片也沒有絢麗的效果，沒有24小時服務的客服，可當初程式員是那麼快樂，雖然只有網頁三劍客，在網上、在指尖、在BBS中，揮灑著自己的青春熱血，如果有一天 我老無所依，請把我留在 在那互聯網浪潮里。
現如今，隨著雲計算、分散式、微服務的盛行，程式員的你是否已經疲倦與自己的CURD，是否已經不屑於與產品汪扯皮，來來來，返回頂部小伙伴們再看看一遍，誰說程式員全部的時間都要敲代碼，是時候需要去需找自己的另一片天空了。
聲明：部分文字介紹來源於網路。
