監控系統必備基礎知識第一篇

監控基礎

1. 爲何須要監控

監控如同切脈診斷，是技術人員先於用戶發現問題的最佳手段。完善的監控系統可以引導技術人員快速定位問題並解決,能夠將系統的問題扼殺於萌芽狀態。完善的監控系統，是技術人員指揮若定的強有力保障。咱們應創建完善的監控體系.監控系統能夠貫穿於移動端、前端、業務服務端、中間件、應用層、操做系統等，***到IT系統的各個環節。

2. 監控要達到的效果
   • 趨勢分析：長期收集並統計監控樣本數據，對監控指標進行趨勢分析。例如，經過分析磁盤的使用空間增加率，能夠預測什麼時候須要對磁盤進行擴容。
   • 對照分析：隨時掌握系統的不一樣版本在運行時資源使用狀況的差別，或在不一樣容量的環境下系統併發和負載的區別。
   • 告警：當系統即將出現故障或已經出現故障時，監控能夠迅速反應併發出告警。這樣，管理員就能夠提早預防問題發生或快速處理已產生的問題，從而保證業務服務的正常運行。
   • 故障分析與定位：故障發生時，技術人員須要對故障進行調查和處理。經過分析監控系統記錄的各類歷史數據，能夠迅速找到問題的根源並解決問題。
   • 數據可視化：經過監控系統獲取的數據，能夠生成可視化儀表盤，使運維人員可以直觀地瞭解系統運行狀態、資源使用狀況、服務運行狀態等.
3. 五層輕量監控體系

監控系統分爲端監控、業務層監控、應用層監控、中間件監控、系統層監控這5層。

• 端監控：針對用戶在體驗上能夠感知的對象進行監控，如網站、App、小程序等。在移動客戶端的系統中，端監控的對象主要有H五、小程序、Android系統、iOS系統等，完善的端監控能夠反饋地域、渠道、連接等多維度的用戶體驗信息；用戶終端爲傳統的Web頁面時，端監控仍會圍繞用戶體驗採集數據，好比頁面打開速度（測速）、頁面穩定性（JS）和外部服務調用成功率（API），這3個方面的數據反映了Web頁面的健康度.
• 業務層監控：對於業務層，可按需深度定製監控系統，實現對業務屬性的監控告警功能，生成業務數據監控大盤。好比用戶訪問QPS、DAU日活、轉化率、業務接口（如登陸數、註冊數、訂單量、支付量、搜索量）等都是常見的監控對象.
• 應用層監控：主要是對分佈式應用和調用鏈應用的性能進行管理和監控，如對Spring Boot、JVM信息、服務鏈路、Dubbo等應用在進行諸如RPC調用、Trace鏈路追蹤動做時產生的數據進行監控。
• 中間件監控：監控的主要對象是框架自身的埋點、延遲、錯誤率等。這裏的中間件包括但不限於消息中間件（RabbitMQ、Kafka、RocketMQ等）、數據庫中間件（MySQL、Oracle、PostgreSQL、TIDB、PolarDB等）、數據庫鏈接池中間件（HikariCP、Druid、BoneCP等）、緩存中間件（Redis、Memcached等）和Web服務中間件（Tomcat、Jetty等）。
• 系統層監控：如何對系統層進行監控. 主要包含CPU、Load、內存、磁盤I/O、網絡相關參數、內核參數、ss統計輸出、端口、核心服務的進程存活狀況、關鍵業務進程資源消耗、NTP offset採集、DNS解析採集等指標。這些均可以做爲對系統層監控的關鍵指標。另外，網絡監控也是系統監控中很重要的部分，對交換機、路由器、防火牆、***進行的監控都屬於網絡監控的範疇，內網和外網的丟包率、網絡延遲等也都是很重要的監控指標。

Zabbix是針對系統層的監控系統.

ELK（Elasticsearch+Logstash+Kibana）主要是作日誌監控的

Prometheus和Grafana能夠實現對端、業務層、應用層、中間件、系統層進行監控，所以Prometheus是打造一站式通用監控架構的最佳方案之一.

• 監控功能
• 可觀察性
• 數據分析

監控是爲技術人員和業務人員提供服務的

目的是經過監控系統瞭解技術應用或運行的環境情況，並檢測、洞察、診斷、解決因環境引起的故障或潛在風險.

概念解析

• SPM（Super Position Model）全稱超級位置模型，是Web端Aplus日誌體系和App端UserTrack日誌體系共同使用的重要規範。SPM的做用相似於IP地址，能夠直接定位前端控件區塊。阿里的SPM位置編碼由A.B.C.D四段構成，其中A表明站點/業務，B表明頁面，C表明頁面區塊，D表明區塊內的點位。
• SCM（Super Content Model）全稱超級內容模型，是一種與業務內容一塊兒下發的埋點數據，用來惟一標識一塊內容。在客戶端埋點時，將SCM編碼做爲埋點的參數上傳給UT服務器，SCM編碼也採用含義與SPM相同的A.B.C.D格式。
• 黃金令箭，即用戶在頁面上進行交互行爲觸發的一個異步請求，用戶按照約定的格式向日志服務器發送請求，展示、點擊、等待、報錯等均可以做爲交互行爲。規則爲/goldenkey_xxx，其中x爲一串數字，用於標識某個具體的交互事件。

  監控架構分類

1. 監控三要素

• Metrics的特色是可聚合（Aggregatable），它是根據時間發生的能夠聚合的數據點。通俗地講，Metrics是隨着時間的推移產生的一些與監控相關的可聚合的重要指標（如與Counter計數器、Historgram等相關的指標）。
• Logging是一種離散日誌（或稱事件），分爲有結構的日誌和無結構的日誌兩種。
• Tracing是一種爲請求域內的調用鏈提供的監控理念。

其中CapEx表明搭建的投入成本，OpEx表明運維成本，Reaction表明監控手段的響應能力，Investigation表明查問題的有效程度。通常來講，Metrics和HealthCheck對於監控告警很是有幫助，Metrics、Tracing和Logging對於調試、發現問題很是有幫助。

Prometheus是基於Metrics的監控系統，具備投入成本（CapEx）中等、運維成本（OpEx）低、響應能力（Reaction）高等特色

在業務開發中，經過查日誌的方式就能定位到系統存在問題，經過Tracing模式能夠查到鏈路上出現問題的環節.

進行監控告警時，HealthCheck是運維團隊監測應用系統是否存活、是否健康的最後一道防線，這是必須引發重視的一道防線。HealthCheck在微服務中經過對一個特定的HTTP請求進行輪詢實現監控。經過對這個請求進行輪詢，不但能夠獲得微服務的監控狀態，還能夠獲得相關中間件如MQ、Redis、MySQL、配置中心等的健康狀態。監控告警的優先級依然是Metrics監控最高，HealthCheck最低。

MDD思想:從指標到洞察力

1.MDD思想綜述

MDD（Metrics-Driven Development）主張整個應用開發過程由指標驅動，經過實時指標來驅動快速、精確和細粒度的軟件迭代。指標驅動開發的理念，不但可讓程序員實時感知生產狀態，及時定位並終結問題，並且能夠幫助產品經理和運維人員一塊兒關注相關的業務指標.

MDD的關鍵原則

* 將指標分配給指標全部者（業務、應用、基礎架構等）。
* 建立分層指標並關聯趨勢。
* 制定決策時使用的指標。

MDD則主張將上線、監控、調試、故障調查及優化等歸入設計階段，而不是等到實施後才補充。相對於經過制定各類複雜、嚴格的研發規定，以及開無數的評審、研討會議來確保軟件的安全發佈、穩定運行，MDD理念的特別之處在於應用程序自己。在MDD理念下，採集必要的監控信息，經過持續交付方式進行快速迭代並進行反饋和修正，全部決定都是基於對不斷變化的狀況的觀察作出的。在軟件的設計初期就包括Metrics設計，設計一套規則來評價系統的穩定性、健康狀態，並監控其餘考覈目標，將這些做爲服務自己的KPI。所以，經過應用MDD理念，可將Dev與Ops之間或多個Dev團隊之間出現的責任博弈降至最低，甚至使矛盾徹底消失，這也有利於團隊穩定發展。所以，MDD能夠用於決策支持、預測趨勢、測試系統的補充、關聯性分析等。依照MDD的理念，在需求階段就能夠考慮設置關鍵指標監控項，隨着應用的上線，經過指標瞭解系統狀態，經過對現狀的可視化和具體化，幫助用戶對將來進行規劃和預測，進而實現業務改善。傳統模式中，Dev和Ops是割裂的，而MDD是DevOps文化的紐帶，對於敏捷開發、持續集成、持續交付，以及各個職能崗位提高DevOps意識有很大的幫助。

MDD理念的監控分層主要有3種

* Infrastructure/System Metrics：如服務器狀態、網絡狀態、流量等。
* Service/Application Metrics：如每一個API耗時、錯誤次數等，能夠分爲中間件監控、容器監控（Nginx、Tomcat）等
* Business Metrics：運營數據或者業務數據，好比單位時間訂單數、支付成功率、A/B測試、報表分析等.

2. 指導實踐的3大監控方法論
   • Google的四大黃金指標
   • 延遲（Latency）：服務請求所需耗時，例如HTTP請求平均延遲。須要區分紅功請求和失敗請求，由於失敗請求可能會以很是低的延遲返回錯誤結果。
   • 流量（Traffic）：衡量服務容量需求（針對系統而言），例如每秒處理的HTTP請求數或者數據庫系統的事務數量。
   • 錯誤（Errors）：請求失敗的速率，用於衡量錯誤發生的狀況，例如HTTP 500錯誤數等顯式失敗，返回錯誤內容或無效內容等隱式失敗，以及由策略緣由致使的失敗（好比強制要求響應時間超過30ms的請求爲錯誤）。
   • 飽和度（Saturation）：衡量資源的使用狀況，例如內存、CPU、I/O、磁盤使用量（即將飽和的部分，好比正在快速填充的磁盤）。
   • Netflix的USE方法

USE是Utilization（使用率）、Saturation（飽和度）、Error（錯誤）的首字母組合.

主要用於分析系統性能問題，能夠指導用戶快速識別資源瓶頸及錯誤

* **使用率**：關注系統資源的使用狀況。這裏的資源主要包括但不限於CPU、內存、網絡、磁盤等。100%的使用率一般是系統性能瓶頸的標誌。
* **飽和度**：例如CPU的平均運行排隊長度，這裏主要是針對資源的飽和度（注意，不一樣於四大黃金指標）。任何資源在某種程度上的飽和均可能致使系統性能的降低。
* **錯誤**：錯誤數。例如，網卡在數據包傳輸過程當中檢測到以太網絡衝突了14次

• Weave Cloud的RED方法

RED方法是Weave Cloud基於Google的4個黃金指標再結合Prometheus及Kubernetes容器實踐得出的方法論，特別適用於對雲原生應用以及微服務架構應用進行監控和度量。在四大黃金指標的原則下，RED方法能夠有效地幫助用戶衡量雲原生以及微服務應用下的用戶體驗問題。RED方法主要關注如下3種關鍵指標。

* **(Request）Rate**：每秒接收的請求數。
* **(Request）Errors**：每秒失敗的請求數。
* **(Request）Duration：**每一個請求所花費的時間，用時間間隔表示。

上述三大監控理論的最佳實踐是：在遵循Google四大黃金指標的前提下，對於在線系統，結合RED方法和緩存命中率方式進行監測；對於離線系統或者主機監控，以USE方法爲主進行監測；對於批處理系統，能夠採用相似Pushgateway的形式進行監控。

監控系統選型分析

1. 黑盒監控和白盒監控

監控系統必須支持探針（Probing）和內省（Introspection）。

• 黑盒監控，對應探針的概念，常見的有HTTP探針、TCP探針等，能夠在系統或者服務發生故障時快速通知相關人員進行處理。探針位於應用程序的外部，經過監聽端口是否有響應且返回正確的數據或狀態碼等外部特徵來監控應用程序。Nagios就是一個主要基於黑盒/探針的監控系統。
• 白盒監控，對應內省的概念，經過白盒可以瞭解監控對象內部的實際運行狀態，經過對監控指標的觀察可以預判可能出現的問題，從而對潛在的不肯定因素進行優化。白盒監控能夠直接將事件、日誌和指標發送到監控工具，它具備比黑盒監控更豐富的應用程序上下文信息。MDD理念主要對應的就是基於白盒的監控系統。
  2. 監控檢查的兩種模式-拉取和推送

監控系統執行監控檢查的模式主要有拉取（Pull）和推送（Push）兩種.

• 拉取模式（簡稱拉模式）
  • 概念:是一種從監控對象中經過輪詢獲取監控信息的方式。拉模式更多拉取的是採樣值或者統計值，因爲有拉取間隔，所以並不能準確獲取數值狀態的變化，只能看到拉取間隔內的變化，所以可能會產生一些毛刺現象，須要進一步進行數據處理。監控和性能測試更關注p95/p99位的緣由就是存在長尾效應。數據採集過程當中對數據進行的定義、採樣、去尖刺等處理操做也是很是重要的.
  • 優勢:告警能夠按照策略分片，告警模塊只須要拉取本身須要的數據，且能夠完美支持聚合場景；拉模式的缺點在於監控數據體量很是龐大，對存儲有較高的要求，實戰中可能還須要考慮數據的冷熱分離.
• 推送模式（簡稱推模式)
  • 概念:是應用程序基於事件主動將數據推向監控系統的方式
  • 優勢:實時性好，一旦觸發一個事件就能夠馬上收集發送信息.
  • 缺點:因爲事件的不可預知性，大量的數據推送到監控系統，解析和暫存會消耗大量的內存，這可能對監控的進程產生影響。因爲消息是推送過來的，因此主動權在推送方。在這種模式下，因爲網絡等遲遲沒有獲得確認，因此在ack等狀況下很容易形成數據重複。這是由於推模式在進行推送中，若是發送失敗，爲了防止內存撐爆，系統會將數據持久化到文件或者隊列。所以採用推模式時，若產生了重複數據，就須要進行去重等操做.
• Prometheus和zabbix分別採用的模式
  • Prometheus在收集數據時，主要採用拉模式（服務端主動去客戶端拉取數據），固然它也支持接收推送到Pushgateway的事件；
  • 以Zabbix爲表明的傳統監控系統採用推模式（客戶端發送數據給服務端）。拉模式在雲原生環境中有比較大的優點，緣由是在分佈式系統中，必定是有中心節點知道整個集羣信息的，那麼經過中心節點就能夠完成對全部要監控節點的服務發現，此時直接去拉取須要的數據就行了；推模式雖然能夠省去服務發現的步驟，但每一個被監控的服務都須要內置客戶端，還須要配置監控服務端的信息，這無形中加大了部署的難度
    3. 監控系統選型分析
    4. 功能維度: 直接決定了可否實現開箱即用，從而縮短項目週期、下降成本等

2. 性能維度: 性能是根據當前業務量作技術評估的一個重要因素.
   • Zabbix:
     • MySQL寫入瓶頸: Zabbix使用MySQL來存放監控歷史數據
     • Zabbix有些數據採集會經過服務器端主動探測(拉取)的方式，當目標機器量大了以後，拉任務也常常出現積壓.
   • Prometheus
     • 面對海量的監控數據和性能壓力，阿里使用了聯邦（Federation）的架構將監控壓力分擔到多個層次的Prometheus並實現全局聚合。在聯邦集羣中，每一個數據中心部署單獨的Prometheus，用於採集當前數據中心監控數據，並由一箇中心的Prometheus負責聚合多個數據中心的監控數據
     • 針對每一個集羣的OS指標（如節點資源CPU、內存、磁盤等水位以及網絡吞吐）、元集羣以及用戶集羣K8S master指標（如kube-apiserver、kube-controller-manager、kube-scheduler等）、K8S組件（如kubernetes-state-metrics、cadvisor）、etcd指標（如etcd寫磁盤時間、DB size、Peer之間吞吐量）等，架構被分層爲監控體系、告警體系和展現體系3部分。監控體系按照從元集羣監控向中心監控匯聚的角度，呈現爲樹形結構，其能夠細分爲3層：
       • 邊緣Prometheus：爲了有效監控元集羣K8S和用戶集羣K8S的指標，避免網絡配置的複雜性，將Prometheus下沉到每一個元集羣內。
       • 級聯Prometheus：級聯Prometheus的做用在於匯聚多個區域的監控數據。級聯Prometheus存在於每一個大區域，例如中國區，歐洲美洲區、亞洲區。每一個大區域內包含若干個具體的區域，例如北京、上海、東京等。隨着每一個大區域內集羣規模的增加，大區域能夠拆分紅多個新的大區域，並始終維持每一個大區域內有一個級聯Prometheus，經過這種策略能夠實現靈活的架構擴展和演進。
       • 中心Prometheus：中心Prometheus用於鏈接全部的級聯Prometheus，實現最終的數據聚合、全局視圖和告警。爲提升可靠性，中心Prometheus使用雙活架構，也就是在不一樣可用區佈置兩個Prometheus中心節點，都鏈接相同的下一級Prometheus。
3. 數據存儲:
   • Zabbix採用關係數據庫保存
   • Open-Falcon採用RDD數據存儲,也加入了一致性Hash算法分片數據，而且能夠對接到OpenTSDB.
   • Prometheus自研了一套高性能的時序數據庫，在V3版本能夠達到每秒千萬級別的數據存儲，經過對接第三方時序數據庫擴展歷史數據的存儲。
4. 服務發現
   • Prometheus的動態發現機制
5. 運維管理
   • Zabbix:
     • Zabbix管理成本高昂
     • Zabbix易用性問題: Zabbix的模板是不支持繼承的，機器分組也是扁平化的，監控策略不容易複用。Zabbix要採集哪些數據，是須要在服務器端作手工配置的
   • 運維管理還須要考慮到Web功能、畫圖展現、默認監控等
   • 微服務監控有四大難點
     • 配置難。監控對象動態可變，沒法進行預先配置
     • 融合難。監控範圍很是繁雜，各種監控難以互相融合
     • 排查難。微服務實例間的調用關係很是複雜，故障排查會很困難
     • 建模難。微服務架構仍在快速發展，難以抽象出穩定的通用監控模型
6. 開發語言
   • Go語言憑藉簡單的語法和優雅的併發, 在雲原生場景使用普遍.
   • Go語言的應用方向:
     • 服務器編程
     • 腳本編程
     • 網絡編程
     • 雲平臺
7. 社區力度和生態發展
8. 誤區探討
   • 監控選型時切忌一味地追求性能或者功能，性能能夠優化，功能能夠二次開發。若是要在功能和性能方面作一個抉擇的話，那麼首選性能，由於整體上來講，性能優化的空間沒有功能擴展的空間大。然而對於長期發展而言，生態又比性能以及功能都重要。
   • 監控系統選型還有一個標準，就是儘可能貼合團隊的自身技術體系棧.沒有最好的，只有最合適的
   • 盲目追新並非監控選型的態度，專業的監控架構是綜合實際使用狀況去作設計、作規劃的，能夠根據實際狀況結合使用多種監控.

     參考連接和書籍

• Prometheus雲原生監控:運維和開發實戰:https://weread.qq.com/web/reader/23d328c072106cb723d1641k16732dc0161679091c5aeb1