經過長時間的實習和總結，咱們發現效勞器運營的大數據有以下四個特色，由淺入深，分別是：1）Volume數據體量無窮，特別是騰訊有海量的效勞器，歸納起來，數據量能夠到PB等級，需要大容量、高性能的存儲技能，剖析的算法也需要最優化；2）Variety數據類型眾多，觸及許多的運轉日志、部件狀況、出產鏈運營、環境變量等，常常要抽絲剝繭，才干找到有用的數據；3）Value 價值無窮，但并不是每個數據都有價值，需要經過清潔和加工處置后，其發作的作用才干閃現，以機房環境溫度告警為例，數百萬條溫度的信息，經過剖析比照后，才有能夠發現溫度反常；4）Velocity數據需要疾速處置，特別是告警類的運用，時效性是十分重要的。

下面講講咱們是怎樣搜集和存儲效勞器運營數據的，給我三分鐘，給你一個英俊又有養分的答案！

運營體系架構

關于海量效勞器的辦理，咱們建立了一套功用強壯的運營剖析體系，從效勞器的帶內和帶外搜集了悉數的靜態屬性和動態運轉數據，對效勞器的每個關節進行的全方位的數據搜集和監控。猶如咱們平常體檢，把心、肝、脾、肺、腎，乃至每個毛孔，都進行了查看。體系架構如下圖所示。

存儲和剖析

數據搜集起來后，除了一部分實時的數據存在本地數據庫，簡直悉數的歷史數據都會存儲在公司級的數據渠道中。這個數據渠道供給了豐富的東西體系，功用悉數，涵蓋了數據存儲、剖析、實時核算等。例如，TPG是依據postgreSQL的數據庫，用于寄存TDW（Tencent distributed Data Warehouse騰訊分布式數據倉庫）離線剖析后的成果數據，便于體系調用（如效勞器利用率剖析,毛病剖析、效勞器生命周期等出產數據）；Hbase依據No SQL，萬億級的分布式、有序數據存儲，用于寄存剖析后的成果數據（如溫度功耗剖析成果數據）。全體的架構如下圖所示。

大數據的四個實習

大數據的規劃剖析，決議計劃者和開發者首要要從事務驅動的視點，挑選數據出產的事務場景，即要估計數據剖析得到的成果能帶來哪些效益。依據公司效勞器運營的特色，咱們在以下四個場景做了大數據的剖析和運用，給實踐的運營帶來的實實在在的好處。

硬盤毛病猜測

硬盤是效勞器硬件毛病率最高的一個部件，假如能提早猜測到硬盤毛病，對事務體會、完善備件辦理都有莫大的收益。這也是根底架構運營在經歷主動化、流程化后，需要進一步進步運營功率、下降運營本錢的天然需要。

觸及硬盤的運營數據包含事務IO數據、硬盤內部的SMART和硬盤運轉的環境變量數據(溫度和濕度)。當前，運營體系對IO數據是每小時搜集一次，SMART數據每三小時搜集一次，溫度和濕度每半小時搜集一次，這些數據算計起來每天的記載數上億條。硬盤毛病猜測，適宜運用分類算法，咱們運用了當前較為盛行的SVM分類算法，輔以適宜的核函數來加快學習核算的功率。

經過了一年多時間的實習，走了不少彎路，也碰到了許多坑，在硬盤毛病標準斷定、事務IO分類定義等方面吃了不少的虧，咱們在依據SMART數據做的毛病猜測，到達了令人滿意的作用。在實踐運營環境中驗證的成果如下：準確率precision到達98%，猜測時間leadtime的全體偏差不超越2天。

需要要點指出的是，咱們做的猜測成果，除了training期間用歷史數據外，驗證的進程是用現網的實時數據來進行的。即是說，經過SVM算法得到的猜測模型后，咱們是用最新搜集的實時數據輸入到模型中，得到的ok和fail兩種猜測成果，在3天、7天、14天后再對猜測的成果進行驗證。這個比傳統的猜測方法（練習和驗證都是運用歷史數據），對現網運用的價值大大進步了。當前在現網環境中，首要的落地場景包含：1）猜測出來的成果，經過運營流程，對BG事務提早宣布預警，以進步事務運維功率 2）依據猜測出來的大規模硬盤毛病，對備件進行有用辦理。

效勞器利用率剖析

騰訊的事務類型和機型都相當多，機器分配給事務后，運用的狀況如何？咱們需要盯梢效勞器的利用率狀況，下圖是某事務某機型磁盤IO的利用率核算剖析圖。剖析進程如下：存儲類機型，看到一段時間核算出來的IO的利用率并不高，并且是寫少讀多的運用，是不是能夠考慮運用IOPS相對不高的賤賣硬盤？仍是事務的架構存在優化的空間？

效勞器利用率剖析給運營帶來的好處在于：1）聯絡事務模型，發現事務運用效勞器的短板，在發現并批改體系架構缺點的一同，進步全體利用率；2）對機型選型的優化，例如關于磁盤容量運用率不高的機型，在后續的機型定制中削減硬盤的數量。

毛病率剖析

效勞器毛病剖析對效勞器的各個部件的毛病率都做了剖析和監控，包含1）生成月度毛病率報表；2）毛病率反常的實時監控和主動告警；3）剖析外部條件與毛病率的聯絡；4）與OS的軟件告警信息聯動起來，及時發現效勞器的亞健康狀況。

上圖是某效勞器硬件近來幾周的毛病率核算信息。按部件給出各個機型的毛病率狀況，及時發現批次性毛病并給出告警

環境監控

2013年8月，華東地區遭受稀有的高溫氣候，許多機房空調制冷扛不住了，頻頻發作效勞器高溫重啟的事情。假如能把機房環境溫度有用的監控起來，咱們就能在發現反常時宣布高溫告警，提早采納措施。對效勞器入風口溫度進行搜集和監控是一個較為有用的計劃。

上圖顯現效勞器入風口溫度改變的反常狀況，經過數據的規整和誤差批改，發作了高溫告警。經過主動化流程，及時知會到機房現場負責人。

一些考慮

不要被數據誤導

人們很簡單被大數據忽悠。在許多場合咱們都談了大數據強壯的功用和夸姣的將來，以為能夠處理許多社會問題，乃至猜測將來。不管大數據如何奇特，若試圖用大數據引領將來只會誤入歧途，由于大數據背后本就存在著“先天不足”：從本質上看，大數據最大的缺點就在于試圖以斷定去“推翻”混沌與不斷定性。之前咱們做硬盤毛病猜測，直觀的以為硬盤的讀寫壓力對硬盤老化和毛病是有直接聯絡的，但經過剖析，發現事務運用硬盤的隨機性太大了，硬盤呼應IO的形式也許多變，關于事務的IO讀寫份額、塊巨細等，有太多的不斷定性，即是前面說的混沌，致使前面依據IO做的猜測成果十分差勁。本來這兒要說的即是，當前這個期間，依托大數據來輔導效勞器運營，不靠譜，效勞器運營智能化遠遠沒有到達。這兒仍是要靠運營和開發人員的思想和腦筋，把主動化運營先做好。

數據質量的把控

數據的質量和字段規范性對后面剖析作用的影響很大。但事務開發所設計的數據不是為了運營剖析而效勞的，許多狀況下都是為了功用開發而存在，假如能夠在體系構建初期進行介入，本來可用避免許多清潔作業，數據可直接投入剖析運用。這兒開發人員和數據剖析的人員存在一個gap，假如對數據在體系設計中遇上各種束縛的話，開發人員會覺得很苦楚，開發功率十分低；而數據剖析人員卻覺得假如數據能做到東西級定制，即是連數據的表字段的名稱，注釋，連內部聯絡，都是由體體系一生成，這樣搜集完滿的。

后來，咱們內部經過一段時間的評論和磨合，構成的一致。咱們做的是運營體系，歸根到底是為運營效勞的，而數據剖析是運營的一個重要功用。所以沒有辦法，這個問題仍是需要開發期間來處理，開發人員只能克服了。

對大數據將來的想象

精細化的傳感器

關于效勞器上傳感器的設計，互聯網公司有特別的需要，對上游硬件廠商的依靠是比較高的。騰訊有許多的效勞器運營數據，十分期望能夠跟業界一同在數據、資本、算法等各個維度能夠同享，尋求更多進步運營功率的途徑。這兒的傳感器也能夠從廣義上來打開，除了效勞器物理上的sensor不斷增加，在效勞器各個運營環節都能夠在流程中加入各種搜集代碼，把效勞器布置、搬家、退役等每個細小的過程都照實的記載下來。運營體系的不斷優化將使“傳感器”體積微型化，它將出現在出產的每一個旮旯，為運營決議計劃供給更科學的數據支持。

數據效勞即開即用

跟著數據的逐步完善和開放，互聯網和公司都將建立起完善的大數據效勞根底架構及商業化形式，從數據的存儲、發掘、辦理、核算等方面供給一站式效勞，將各行各業的數據孤島打通互聯。并且數據運用的生態體系也將變得十分老練，乃至出現用戶與數據效勞商之間的算法供給商，他們有專業領域內的高手人才，經過數據發掘的方法，尋覓事物間的聯絡。用戶只需將其原始數據導入，供給商很快的就能在線的將剖析成果回來，如水和電相同，即開即用。
          TAG :機房監控 機房監控系統 機房環境監控 來源：http://m.28ut.com