從大數據的角度來談談運維監控這件事兒
小清新同學，負責百度云監控產品規劃及設計，具備多年監控領域產品經驗。
干貨概覽
做運維的人對監控這件事兒都太熟悉了，但是對于監控這么一件老生常談的事兒，我們今天換個角度，從大數據的角度來看看有什么新的發現。
為什么要從大數據的角度來看監控這件事兒呢？首先，以大家最熟悉的服務器監控為例，雖然原理很簡單，但從數據角度來看，其仍是一個典型且完整的數據采集（監控數據采集）、分析（報警）和可視化（趨勢圖、儀表盤）處理過程。
其次，監控領域需要關心的數據不僅僅是服務器監控數據，還包含各種角度、各種來源的數據，如日志數據、網絡通信數據等，數據呈現種類多、體量大和時效性要求高的特點，符合典型的大數據基本特征。
Gartner在2016年第一次提出AIOps概念時，AI代表了Algorithmic（算法），算法的基石正是海量的數據，在2017年將AI含義改為Artificial Intelligence（人工智能）后，同樣需要海量的數據進行處理和學習。我們從下文的Gartner描繪的AIOps平臺架構中同樣能看到數據對于AIOps、對于運維、對于監控的重要性。
我們從數據來源的角度對監控數據進行分類，比較常用的幾種數據來源如下：
-
機器數據，常用指數★★★★★，獲取難度★☆☆☆☆
-
日志數據，常用指數★★★★☆，獲取難度★★★☆☆
-
網絡通信數據，常用指數★☆☆☆☆，獲取難度★★★★★
-
撥測數據，常用指數★★★★☆，獲取難度★☆☆☆☆
-
Agent代理數據，常用指數★★☆☆☆，獲取難度★★★★☆
-
用戶行為數據，常用指數★★★☆☆，獲取難度★★☆☆☆
指數僅供參考
這么多種數據來源，各有什么特點和用途呢？接下來我們詳細聊一下：
機器數據
機器數據是指服務器、網絡設備等硬件或虛擬硬件運行過程中產生的狀態數據，往往有對應的協議或規范，例如SNMP、IPMI、WMI等。通過機器數據可以準確的掌握業務承載平臺的基本運行狀態，例如CPU、內存、磁盤等資源的使用情況和網絡流量情況，是運維監控領域最常用的數據來源，各類開源或商業監控產品對此類數據的處理也大同小異，例如Zabbix、Nagios等。
云計算時代，同樣離不開機器數據，雖然用戶不用再關心底層物理設備的運行狀態，但云廠商提供的各類云服務器、網關、負載均衡等虛擬設備同樣會產生大量機器數據，需要用戶時刻關注，例如云服務器的資源使用情況、帶寬的使用情況、網關的負載情況等。
做好機器數據的監控可以說是做好運維監控的第一步，但僅僅有機器數據是不夠的，因為機器數據存在與業務運行狀態脫節的問題，機器運行平穩、資源充足并不能夠代表業務運行正常，這就需要我們去豐富自己的監控數據來源，各位看官請往下看。
日志數據
日志數據是指應用程序、中間件和機器等在運行過程中由事件觸發而產生的文本類數據，數據格式靈活多樣。
日志數據的應用場景非常廣泛，上到業務指標分析，下到Bug追蹤定位，是監控領域的全能選手。但由于日志數據的靈活性，要想利用好日志數據，必須先想好監控什么，再通過制定日志規范獲取到需要的數據。日志數據的采集和分析最常用的開源方案就是ELK Stack了，可以說已經形成了一定的行業標準。
網絡通信數據
網絡通信數據是指通過抓包獲取到的設備間網絡通信數據，例如兩臺服務器之間存在網絡通信，通過抓包分析可以詳細的了解兩臺服務器之間通信的端口、協議、數據量甚至內容。常用的方式是通過硬件設備將網絡流量進行鏡像，對鏡像數據進行分析，以避免干擾業務數據的正常流轉。
網絡通信數據非常全面，只要有網絡通信理論上就能夠抓取到詳細的數據，而不需要日志數據那樣提前制定好數據輸出規則。想象一下你在管理一個交易系統，不需要吐任何日志就可以獲取到每一筆交易的詳細情況，而且這種數據獲取方式還不會影響到應用的運行，是不是很爽。
但是網絡通信數據的利用是較少的，難度也較大，小編私以為主要是由于網絡相關的運維和業務相關的運維往往是不同的Team在負責，不同運維團隊的關注點和側重點不同造成的。網絡運維團隊更加關心網絡本身的穩定性，對業務的理解不是非常深入，即使通過抓包拿到詳細數據，也很難進行詳細的分析。而業務相關的運維和研發團隊對網絡又缺乏完全的掌控，對網絡的理解也不夠深刻。
此外，網絡通信數據也有其局限性，一些業務事件可能不會產生網路通信，也就沒有對應的數據，網絡通信的數據包解析需要非常清楚應用層的規則，甚至很多數據被進行了加密，這都增大了網路通信數據的利用難度。
目前小編暫時沒有看到成熟的圍繞網絡通信數據采集和分析的開源解決方案，聊以慰藉的只有Wireshark這樣的工具型產品了。商業解決方案方面倒是有很多不錯的廠商，感興趣的同學可以百度一下Gartner NPMD了解，NPMD是指Network Performance Monitoring and Diagnostics。
撥測數據
撥測數據是指使用探測點，通過HTTP、Ping、TCP等多種協議對監控目標進行探測產生的數據，《站點監控 | 網站健康檢查的外科醫生》一文中提到網站監控數據就屬于撥測數據的一種。
撥測這個詞最早源于電話通信網絡，通信人員在建設好電話網絡后需要撥一個電話來測試是否正常，這種主動式監控方式就稱為撥測了。
對于IT業務系統，撥測采用的探測點可以在公網，也可以在業務系統內網，不同位置的探測點起到的作用是不同的。公網探測點主要關注業務系統的網絡出口質量、運營商網絡質量和CDN質量，而內網探測點主要關注的是業務或各個業務模塊的可用性及性能狀態。
內網探測點的搭建非常簡單，幾行腳本加上一些開源組件很快就能獲取到撥測數據。但公網探測點需要在公網部署大量的服務器作為探測點，公網服務器部署會帶來大量的運維成本和商務成本，各位同學可以考慮使用商業解決方案，百度云監控BCM（Baidu Cloud Monitor）的站點監控功能就能很好的滿足公網環境下的撥測需求。
Agent代理數據
Agent代理數據是指通過字節碼增強等技術來獲取應用運行過程中的各類數據，與日志數據的最大區別在與其不需要在應用程序的源代碼中添加數據的輸出邏輯，而是在應用程序的編譯或運行環節去動態的指定數據輸出邏輯，其形式上也可以輸出為日志，但與一般的日志數據在原理和靈活度上有著本質的區別。
Agent代理數據最常用的場景就是應用性能管理APM（Application Performance Management）了，通過Agent代理數據可以獲取到應用運行過程中的事務執行過程，包括外部調用、數據庫調用、分布式調用追蹤、代碼執行耗時等，而這一切都不需要你去修改原有的應用程序。典型的開源方案是針對Java應用程序監控的Pinpoint。
用戶行為數據
用戶行為數據是指通過在用戶終端進行埋點獲取到的用戶行為數據，例如在網頁中通過JS埋點獲取到的頁面訪問情況和在APP中通過SDK埋點獲取到的各交互頁面和控件的使用情況。
用戶行為數據除了幫助運營同學進行用戶分析，還可以幫助運維的同學更加準確的了解業務系統的最終實際表現，例如哪里的用戶出現了訪問緩慢、哪些業務模塊用戶量出現了突降，這些數據能夠讓你站在結果的角度去分析業務系統還有哪里可以優化，也能夠在問題僅僅影響一小部分用戶時就能夠及時發現，第一時間干預。
總 結
說了這么多種來源的數據，我們來簡要總結一下：
結合各種來源類型的數據，我們可以根據業務監控需求構建出適合自己業務系統的監控方案來，你有沒有發現以前沒有關注過的數據來源呢？趕快進一步深入了解一下，看看能不能解決你的痛點吧。
