目錄
3、Kubernetes容器應用監控方案——Prometheus+Grafana監控系統
業務高速發展，服務質量（QoS）與系統服務等級協議（SLA）指標如何得以保障呢？全方位立體式監控，一站式服務，助力企業快速發現並定位問題，提升服務質量，達到服務高可用指標。
從監控歷程看，大概分爲一下幾部分：
1、傳統應用監控
由於開放式平臺標準化產品的特點，通過使用IBM tivoli、HP OpenView、Oracle EM等標準化的商用監控產品，數據中心能夠方便快捷地實現面向主機、服務器、網絡、存儲、環境動力、操作系統、數據庫、中間件等標準化軟硬件產品的監控，並實現了各個專業的監控事件和容量性能數據的集中展現和處理。
以下是中間件監控視圖（Redis、Mysql等）
2、業務應用監控，簡稱SSM
SSM是指對關鍵業務應用的監測和優化，提高業務應用的可用性和可靠性指標，在提供更優質服務的前提下，降低運維的投入和工作量，爲用戶帶來更多的商業利益和客戶體驗。
業務運維，實現業務和ID的雙向驅動。從業務視角實時感知業務系統運行狀態，確保業務連續性，持續提升業務效能。業務監控的核心價值主要體現在以下幾方面：
- 監控業務表現
- 確保業務連續性
- 全渠道業務管控
- 完善數字化KPI
如何實現業務監控，業務監控指標是關鍵。Four Golden Signals是Google針對大量分佈式監控的經驗總結，4個黃金指標可以在服務級別幫助衡量終端用戶體驗、服務中斷、業務影響等層面的問題。主要關注與以下四種類型的指標：延遲，通訊量，錯誤以及飽和度。
延遲：服務請求所需時間。
記錄用戶所有請求所需的時間，重點是要區分成功請求的延遲時間和失敗請求的延遲時間。 例如在數據庫或者其他關鍵禍端服務異常觸發HTTP 500的情況下，用戶也可能會很快得到請求失敗的響應內容，如果不加區分計算這些請求的延遲，可能導致計算結果與實際結果產生巨大的差異。除此以外，在微服務中通常提倡“快速失敗”，開發人員需要特別注意這些延遲較大的錯誤，因爲這些緩慢的錯誤會明顯影響系統的性能，因此追蹤這些錯誤的延遲也是非常重要的。
通訊量：監控當前系統的流量，用於衡量服務的容量需求。
流量對於不同類型的系統而言可能代表不同的含義。例如，在HTTP REST API中, 流量通常是每秒HTTP請求數；
錯誤：監控當前系統所有發生的錯誤請求，衡量當前系統錯誤發生的速率。
對於失敗而言有些是顯式的(比如, HTTP 500錯誤)，而有些是隱式(比如，HTTP響應200，單實際業務流程依然是失敗的)。
對於一些顯式的錯誤如HTTP 500可以通過在負載均衡器(如Nginx)上進行捕獲，而對於一些系統內部的異常，則可能需要直接從服務中添加鉤子統計並進行獲取。
飽和度：衡量當前服務的飽和度。
主要強調最能影響服務狀態的受限制的資源。 例如，如果系統主要受內存影響，那就主要關注系統的內存狀態，如果系統主要受限與磁盤I/O，那就主要觀測磁盤I/O的狀態。因爲通常情況下，當這些資源達到飽和後，服務的性能會明顯下降。同時還可以利用飽和度對系統做出預測，比如，“磁盤是否可能在4個小時候就滿了”。
摘自作者：奚落大神
3、Kubernetes容器應用監控方案——Prometheus+Grafana監控系統
目前對於kubernetes的主流監控方案主要有以下幾種：
Heapster+InfluxDB+Grafana
每個K8S節點的Kubelet內含cAdvisor，暴露出API，Heapster通過訪問這些端點得到容器監控數據。它支持多種儲存方式，常用的是InfluxDB。這套方案的缺點是數據來源單一、缺乏報警功能以及InfluxDB的單點問題，而且Heapster也已經在新版本中被deprecated(被metrics server取代)了。這種實現方案的詳細介紹請見這篇文章。
Metrics-Server+InfluxDB+Grafana
k8s從1.8版本開始，CPU、內存等資源的metrics信息可以通過 Metrics API來獲取，用戶還可以通過kubectl top直接獲取這些metrics信息。Metrics API需要部署Metrics-Server。
各種Exporter+Prometheus+Grafana
通過各種export採集不同維度的監控指標，並通過Prometheus支持的數據格式暴露出來，Prometheus定期pull數據並用Grafana展示，異常情況使用AlertManager告警。本方案下文詳細敘述。
原文鏈接：https://blog.csdn.net/liukuan73/article/details/78881008
Prometheus可以做什麼
-
在業務層用作埋點系統
Prometheus支持各個主流開發語言（Go，java，python，ruby官方提供客戶端，其他語言有第三方開源客戶端）。我們可以通過客戶端方面的對核心業務進行埋點。如下單流程、添加購物車流程。 -
在應用層用作應用監控系統
一些主流應用可以通過官方或第三方的導出器，來對這些應用做核心指標的收集。如redis,mysql。 -
在系統層用作系統監控
除了常用軟件， prometheus也有相關係統層和網絡層exporter,用以監控服務器或網絡。 -
集成其他的監控
prometheus還可以通過各種exporte，集成其他的監控系統，收集監控數據，如AWS CloudWatch,JMX，Pingdom等等。
4、基於Pinpoint應用性能監控
基於端到端交易鏈路細化追蹤分析代碼及SQL執⾏性能，提供應用拓撲及代碼層事務追蹤。
-
端到端業務系統拓撲
-
分佈式跨應用交易追蹤
-
代碼級性能問題診斷
-
輕便智能的採集探針
5、NPM網絡性能監控
6、微服務的全鏈路監控（Google Dapper）
隨着微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務。互聯網應用構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千臺服務器，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題。
- 請求到來生成一個全局TraceID，通過TraceID可以串聯起整個調用鏈，一個TraceID代表一次請求。
- 除了TraceID外，還需要SpanID用於記錄調用父子關係。每個服務會記錄下parent id和span id，通過他們可以組織一次完整調用鏈的父子關係。
- 一個沒有parent id的span成爲root span，可以看成調用鏈入口。
- 所有這些ID可用全局唯一的64位整數表示；
- 整個調用過程中每個請求都要透傳TraceID和SpanID。
- 每個服務將該次請求附帶的TraceID和附帶的SpanID作爲parent id記錄下，並且將自己生成的SpanID也記錄下。
- 要查看某次完整的調用則 只要根據TraceID查出所有調用記錄，然後通過parent id和span id組織起整個調用父子關係。
7、智能監控（AI、人工智能、大數據）
AIOPS實現IT運維智能化，充分利用AI和大數據技術，構建智能化運維管控模型，自動識別業務問題，簡化運維操作複雜度，持續改善業務健康狀況。
高性能日誌分析（DOLA）
基於大數據與AI，實現離散日誌數據的統一採集、處理、檢索、模式識別以及可視化分析。
智能超市、黑科技智能校服、智能交通、智能監獄等
參考文獻：
