工具供應商希望能夠以更少、更有效的輕量級監(jiān)控工具來監(jiān)控整個環(huán)境，據研究副總裁JonahKowall在出席Gartner公司的IT基礎架構和運營管理峰會的統(tǒng)一管理討論期間表示。

　　如下，我們將分析傳統(tǒng)性能監(jiān)測工具的局限性及下一代統(tǒng)一監(jiān)控工具潛在的優(yōu)勢。

　　傳統(tǒng)性能監(jiān)控工具的缺點

　　每家企業(yè)都在使用軟件工具來測量性能。這其中包括應用程序性能監(jiān)控(APM)，網絡性能管理(NPM)，服務器性能管理，存儲性能管理以及數據中心的其他元素。但是，傳統(tǒng)的工具給IT設計師和架構師們帶來了一系列難以克服的問題。

　　例如，APM，是用戶體驗和應用程序為企業(yè)提供的服務質量的一個重要指標。但傳統(tǒng)的APM工具分散在數據中心的各處，可能無法為企業(yè)IT領導們提供他們所需要了解的可用信息。

　　通常，它們是帶來麻煩最多的工具。許多企業(yè)依靠筒倉執(zhí)行其核心任務，如服務器，網絡，存儲，甚至虛擬化管理。由于大多數工具都是基于專有軟件，他們通常不能整合或共享數據，從而限制了孤島筒倉之間的視覺角度。

　　而工具的數量是成倍增長的，因為每個功能分區(qū)都會引入了新的軟件工具。

　　kowall在現場抽查了與會人員，發(fā)現40%的受訪者所在的企業(yè)均依賴6到10款不同的工具來監(jiān)控他們的環(huán)境。

　　數據收集方法帶來了另一個問題。代理是最為普遍的從監(jiān)測要素查詢數據的方法，但代理會影響性能，而且較舊的代理可以成為攻擊的潛在媒介。這兩個因素經常被忽略，因為數據中心的架構缺乏一個連貫的計劃，以適應或維持監(jiān)控代理。不過，有供應商鎖定的元素，因為許多工具供應商繼續(xù)在推動基于代理的數據收集和傳遞。

　　但這些抱怨并不能解決現代IT企業(yè)不斷變化的現實問題。企業(yè)的孤島筒倉不再是靜態(tài)的，而應用程序也越來越相互依存和動態(tài)。例如，應用程序可能會依賴于數據庫或其他應用程序，并可能隨著用戶需求的變化需要大規(guī)模計算。這樣，配置應用程序就會涉及到網絡，更大的存儲，服務器等之間的相互依存。

　　應用監(jiān)控必須更好地收集和報告數據在一個廣闊的數據中心功能區(qū)的情況——但同時也需要施以較少的需求和更有效的操作環(huán)境。

　　統(tǒng)一的監(jiān)測獲得長足的進展

　　統(tǒng)一的性能監(jiān)控的理念已經在監(jiān)測工具供應商和用戶之間獲得了廣泛的好評。我們的目標是提供一個簡單且具有成本效益的工具，能夠跨功能區(qū)自動實現優(yōu)越的監(jiān)控水平，同時沒有代理的陷阱。

　　統(tǒng)一的監(jiān)控可以利用應用程序編程接口(API)，現在可查詢系統(tǒng)以收集和報告范圍日益擴大的信息，Kowall說。如此高的水平的工具也可以洞察連接系統(tǒng)，以便更好地發(fā)現和拓撲分析。一些統(tǒng)一的監(jiān)測工具也可以執(zhí)行日志文件分析來關聯事件，并在設備復雜的環(huán)境進行數十個甚至上百個故障排除。

　　這一的影響是顯著的。考慮到一臺虛擬機(VM)哪怕中斷短短幾分鐘，但監(jiān)測新的VM往往需要人工手動安裝代理，以及昂貴的許可和配置添加虛擬機的監(jiān)視范圍的耗時成本。理想的統(tǒng)一監(jiān)控能夠發(fā)現和應對新的虛擬機，自動使用現有的API，不需要再安裝軟件，很少(如果有的話)進行設置。

　　統(tǒng)一監(jiān)控工具的供應商隊伍在不斷發(fā)展壯大。特別是一些成熟的供應商已經在生產輕巧，API驅動的監(jiān)控，以及日志文件的分析能力。Kowall指出，包括AccelOps公司，CATechnologies公司，Centerity系統(tǒng)公司，GroundWorkInc.公司，Ipswitch公司，Kaseya，ManageEngine，ScienceLogic公司，SolarWinds公司和Zenoss公司等供應商均采用日志文件分析包括惠普，IBM，Elasticsearch，VMware，Splunk公司和SumoLogic。

　　統(tǒng)一性能監(jiān)控增長帶來的煩惱

　　雖然統(tǒng)一監(jiān)控為企業(yè)帶來的好處越來越多，但該技術沒有完全準備好取代所有其他的APM或NPM工具。當然，采用統(tǒng)一管理肯定可以降低工具的總數量，大大降低舊的傳統(tǒng)工具的負擔和風險，同時配合企業(yè)精心挑選的APM和NPM產品，作為補充，Kowall說。

　　例如，設計用于測量最終用戶體驗，并提供早期問題預警的應用性能的工具可能會繼續(xù)依賴于定制，代理驅動的工具。這是因為代理可以容忍中斷連接，悄悄地收集數據，當連接可用時與集中收集的服務器共享。

　　基于API的監(jiān)控工具不會很快消失。企業(yè)也可以繼續(xù)像監(jiān)控關鍵業(yè)務交易一樣使用其他工具監(jiān)控，實施復雜的故障排除，性能調整和容量規(guī)劃等具體任務。

　　對于統(tǒng)一監(jiān)控工具而言，一個持續(xù)的挑戰(zhàn)在于對API的依賴需要其他軟件供應商在他們的產品開發(fā)和測試方面做更多的工作。盡管有著很好的前景，但沒有統(tǒng)一的標準就不能保證一套API套件是合適可用的，某些監(jiān)控功能可能根本無法使用或無法實現跨異構平臺的一致性。

　　數據中心企業(yè)所面臨的承諾和陷阱是非常明確的。引入一款統(tǒng)一的監(jiān)測工具已被證明是需要精心策劃的項目，并需要針對不同的產品路線圖進行大量的測試，因為其可能會影響API的可用性。只有這樣，你才能在您的數據中心推出統(tǒng)一的性能監(jiān)控。