對于服務(wù)器的監(jiān)控同樣也是從狀態(tài)、性能與容量這幾個維度入手。雖然SNMP也可以用于服務(wù)器監(jiān)控，但相對于agent主動上報指標(biāo)與數(shù)據(jù)會少很多。
服務(wù)器的狀態(tài)監(jiān)控主要包含服務(wù)器是否ping的通、agent上報是否超時與電源運行狀態(tài)等等。對于性能與容量這兩類維度，主要依賴當(dāng)前OS的數(shù)據(jù)捕獲，一般來說對于服務(wù)器監(jiān)控來說在通用場景下主要關(guān)注CPU、內(nèi)存、流量與包量這四個指標(biāo)即可，但是別的指標(biāo)也建議盡量捕獲。
單個監(jiān)控對象的數(shù)據(jù)豐富了會有如下好處：避免對象的監(jiān)控盲點不同的監(jiān)控數(shù)據(jù)點可以部分對應(yīng)出該服務(wù)器所承載的業(yè)務(wù)特性指標(biāo)，例如存儲類業(yè)務(wù)也會關(guān)注disk_total_read、svctm_time_max、await_time_max等等系統(tǒng)指標(biāo)生產(chǎn)的數(shù)據(jù)足夠豐富能夠催生出更加豐富的運維數(shù)據(jù)消費場景。服務(wù)器監(jiān)控相對是很標(biāo)準(zhǔn)的監(jiān)控模型，針對于物理服務(wù)器與虛擬機都有共性指標(biāo)。這部分主要做到采集的數(shù)據(jù)豐富與上報的準(zhǔn)確性(算法準(zhǔn)確)。 對于運維監(jiān)控的告警信息，應(yīng)該如何分析，或者說應(yīng)該從哪些方向去分析呢？IT運維監(jiān)控管理方案
在信息系統(tǒng)的生命周期中，一般系統(tǒng)建設(shè)的時間大約為一年，而系統(tǒng)使用運維的時間大約四到七年或更長，因此，業(yè)界提出了“三分建設(shè)，七分管理”的運維監(jiān)控管理。經(jīng)過大致兩輪的信息化建設(shè)，企業(yè)信息化將逐步趨于成熟，后續(xù)信息化工作的重點之一便是做好系統(tǒng)的運維工作，保障系系統(tǒng)平穩(wěn)運行，支撐業(yè)務(wù)發(fā)展。
信息保障部門日常運行管理條塊分割，網(wǎng)絡(luò)、應(yīng)用、IT基礎(chǔ)環(huán)境等資源需要不同技能分工人員，在不同時段值守，當(dāng)網(wǎng)絡(luò)設(shè)備發(fā)生變化時，無法迅速的適應(yīng)。各類業(yè)務(wù)應(yīng)用系統(tǒng)缺乏針對性的管理平臺，單從網(wǎng)元和資源個體進行管理的角度無法解決業(yè)務(wù)系統(tǒng)的監(jiān)控要求，因為業(yè)務(wù)系統(tǒng)是由多個關(guān)聯(lián)資源及其關(guān)聯(lián)關(guān)系組成，一旦業(yè)務(wù)系統(tǒng)出現(xiàn)運行過慢、無法登錄、應(yīng)用報錯等問題時，難以排查具體的故障點，從而影響業(yè)務(wù)系統(tǒng)故障恢復(fù)，也不利于業(yè)務(wù)系統(tǒng)的性能調(diào)優(yōu)，造成單位IT資源與IT管理人員的“雙高”負(fù)荷運轉(zhuǎn)。沒有統(tǒng)一的實時監(jiān)控IT運維是依托經(jīng)驗式、補救式的事后運維。同樣的IT故障引發(fā)大范圍報障，需要通過監(jiān)控鎖定故障源合并事件；同樣的IT故障在缺乏監(jiān)控數(shù)據(jù)描述和處置經(jīng)驗的支撐時，擅長不同技能的運維工程師處理效率有天壤之別；同樣的IT故障高頻復(fù)發(fā)，需要監(jiān)控的分析優(yōu)化資源配置。 國產(chǎn)運維監(jiān)控產(chǎn)品排名不可錯過的運維監(jiān)控干貨！
遇到多集群場景問題
多達(dá)上百個集群數(shù)，而有些業(yè)務(wù)系統(tǒng)擁有多個集群，其多集群場景特點有：
服務(wù)發(fā)現(xiàn)隔離：Prometheus的服務(wù)發(fā)現(xiàn)機制無法發(fā)現(xiàn)多個集群的被監(jiān)控對象；
網(wǎng)絡(luò)隔離：跨集群可能存在連通性問題；
業(yè)務(wù)需求：業(yè)務(wù)系統(tǒng)可能需要跨集群聚合數(shù)據(jù)。
只用Prometheus能解決嗎？
Prometheus本身只支持單機部署，沒有自帶支持集群部署，對于集群化和水平擴展，官方和社區(qū)都沒有銀彈，需要合理選擇VictoriaMetrics、Thanos等開源方案或自研方案。Prometheus的存儲空間也受限于單機磁盤容量，磁盤容量決定了單個Prometheus所能存儲的數(shù)據(jù)量，數(shù)據(jù)量大小又取決于被采集服務(wù)的指標(biāo)數(shù)量、服務(wù)數(shù)量、采集速率以及數(shù)據(jù)過期時間。在數(shù)據(jù)量大的情況下，我們可能就需要做很多取舍，比如丟棄不重要的指標(biāo)、降低采集速率、設(shè)置較短的數(shù)據(jù)過期時間等。
中間件和數(shù)據(jù)庫組件監(jiān)控：中間件和數(shù)據(jù)庫組件都統(tǒng)一提供sidecar模式部署的exporter進行指標(biāo)采集，并配置監(jiān)控告警。如果不是集群納管的數(shù)據(jù)庫，也可以開發(fā)自定義exporter（kingbase、greatdb等國產(chǎn)數(shù)據(jù)庫都走這個方式），也可以開發(fā)指標(biāo)推到Prometheus的pushgateway（polardb國產(chǎn)數(shù)據(jù)庫走這個方式），還可以配置Prometheus去拉取各組件的metrics（etcd等中間件有提供標(biāo)準(zhǔn)的metrics）。
各業(yè)務(wù)集群怎么部署監(jiān)控組件各業(yè)務(wù)集群都單獨部署Prometheus和grafana；在集群各節(jié)點部署有kubelet客戶端和demonset模式的node-exporter；在集群管理節(jié)點部署Deloyment模式的kube-state-metrics；而k8s的管理組件kube-scheduler、control-manager、etcd自帶metrics，不需要部署任何采集工具，而是在Prometheus的配置文件中配置各組件的metrics地址獲取指標(biāo)數(shù)據(jù)；中間件和數(shù)據(jù)庫組件內(nèi)帶有Sidecar模式的xxx-exporter（比如mysql-exporter），部署中間件和數(shù)據(jù)庫時就開始收集監(jiān)控數(shù)據(jù)。 Argus運維監(jiān)控系統(tǒng)Zabbix Agent 協(xié)議 Java實現(xiàn)， 實現(xiàn) JDBC 協(xié)議采集。
統(tǒng)一運維監(jiān)控平臺，說到底本質(zhì)上也是一個監(jiān)控系統(tǒng)，監(jiān)控的基本能力是必不可少的，回歸到監(jiān)控的本質(zhì)，先梳理下整個監(jiān)控體系：①監(jiān)控系統(tǒng)的本質(zhì)是通過發(fā)現(xiàn)故障、解決故障、預(yù)防故障來為了保障業(yè)務(wù)的穩(wěn)定。②監(jiān)控體系一般來說包括數(shù)據(jù)采集、數(shù)據(jù)檢測、告警管理、故障管理、視圖管理和監(jiān)控管理6大模塊。而數(shù)據(jù)采集、數(shù)據(jù)檢測和告警處理是監(jiān)控的小閉環(huán)，但如果想要真正把監(jiān)控系統(tǒng)做好，那故障管理閉環(huán)、視圖管理、監(jiān)控管理的模塊也缺一不可。一個集運維監(jiān)控、運維自動化、運維安全合規(guī)、運維成本管控、運維協(xié)同等能力屬性的大一統(tǒng)平臺，是比較好解。系統(tǒng)一體化運維監(jiān)控管理平臺
Argus運維監(jiān)控系統(tǒng)數(shù)據(jù)采集與業(yè)務(wù)分析 展現(xiàn)分離架構(gòu)。IT運維監(jiān)控管理方案
Flow是一種數(shù)據(jù)交換方式，其工作原理是：
Flow利用標(biāo)準(zhǔn)的交換模式處理數(shù)據(jù)流的第1個IP包數(shù)據(jù)，生成Flow緩存，隨后同樣的數(shù)據(jù)基于緩存信息在同一個數(shù)據(jù)流中進行傳輸，不再匹配相關(guān)的訪問控制等策略，F(xiàn)low緩存同時包含了隨后數(shù)據(jù)流的統(tǒng)計信息。
一個Flow流定義為在一個源IP地址和目的IP地址間傳輸?shù)膯蜗驍?shù)據(jù)包流，且所有數(shù)據(jù)包具有共同的傳輸層源、目的端口號。
相對于會話(“Session”)而言，“Flow”具備更細(xì)致的標(biāo)識特征，在傳統(tǒng)的TCP/IP五元組的基礎(chǔ)上增加了一些新的域值，至少包括以下幾個字段：
|源IP地址|目的IP地址|源端口|目的端口|IP層協(xié)議類型|ToS服務(wù)類型（dscp）|輸入物理端口（ifindex）|
以上七個字段可以唯1地確定任意一個數(shù)據(jù)包屬于哪個特定的Flow。
換而言之，任何一個字段出現(xiàn)了差異都意味著一個新Flow的發(fā)生。對于Flow的分析展示同樣也是要基于多維度的：
IP(目的與源)、port(目的與源)、業(yè)務(wù)、網(wǎng)絡(luò)架構(gòu)、城市、IDC等。
具體所需的維度依賴于自己的業(yè)務(wù)場景。Flow是廠商的私有協(xié)議，業(yè)界也有多種的Flow格式。例如CISCO、華為、juniper等等的主流廠商的Flow也是均有一定差異性與優(yōu)劣的，常用的有NetFlow與SFlow。所以這部分的后臺能力是需要有異構(gòu)。 IT運維監(jiān)控管理方案
上海觀縱科技有限公司總部位于上海市奉賢區(qū)望園南路1288弄80號1904、1909室，是一家一般項目:技術(shù)服務(wù)、技術(shù)開發(fā)、技術(shù)咨詢、技術(shù)交流、技術(shù)轉(zhuǎn)讓、技術(shù)推廣;軟件開發(fā);人工智能基礎(chǔ)軟件開發(fā);人工智能應(yīng)用軟件開發(fā);數(shù)據(jù)處理服務(wù);信息技術(shù)咨詢服務(wù);信息系統(tǒng)集成服務(wù):信息系統(tǒng)運行維護服務(wù);計算機系統(tǒng)服務(wù);軟件銷售;計算機軟硬件及輔助設(shè)備批發(fā);計算機軟硬件及輔助設(shè)備零售;電子產(chǎn)品銷售;通信設(shè)備銷售;通訊設(shè)備銷售;咨詢策劃服務(wù);市場調(diào)查(不含涉外調(diào)查);廣告制作;廣告發(fā)布;廣告設(shè)計、代理;會議及展覽服務(wù);貨物進出口。(除依法須經(jīng)批準(zhǔn)的項目外，憑營業(yè)執(zhí)照依法自主開展經(jīng)營活動) 許可項目:建筑智能化系統(tǒng)設(shè)計;建設(shè)工程施工;網(wǎng)絡(luò)文化經(jīng)營;互聯(lián)網(wǎng)信息服務(wù)。(依法須經(jīng)批準(zhǔn)的項目，經(jīng)相關(guān)部門批準(zhǔn)后方可開展經(jīng)營活動，具體經(jīng)營項目以相關(guān)部門批準(zhǔn)文件或許可證件為準(zhǔn))的公司。公司自創(chuàng)立以來，投身于webfunny前端監(jiān)控，webfunny前端埋點，全鏈路應(yīng)用性能監(jiān)控，Argus-IT運維監(jiān)控，是傳媒、廣電的主力軍。觀縱科技致力于把技術(shù)上的創(chuàng)新展現(xiàn)成對用戶產(chǎn)品上的貼心，為用戶帶來良好體驗。觀縱科技創(chuàng)始人姜應(yīng)偉，始終關(guān)注客戶，創(chuàng)新科技，竭誠為客戶提供良好的服務(wù)。