監(jiān)控是集群管理的核心任務(wù)。監(jiān)控?cái)?shù)據(jù)可用于調(diào)度任務(wù)、負(fù)載平衡、向管理員報(bào)告軟硬件故障，并廣泛地控制系統(tǒng)使用情況。監(jiān)控信息必須在不影響集群性能的情況下獲得。本文將討論使用/proc文件系統(tǒng)和Java來獲得監(jiān)控?cái)?shù)據(jù)的方法。

Java在Linux集群中的應(yīng)用

Java技術(shù)為集群管理開發(fā)者提供了許多解決問題的辦法。Java是動(dòng)態(tài)、靈活、可移植的，這些不尋常的特征使得它成為了在異構(gòu)網(wǎng)絡(luò)及平臺上構(gòu)造集群管理的理想基礎(chǔ)。

Java具有廣泛的例程庫，很容易處理IP協(xié)議，如TCP、UDP，并可在multi-homed主機(jī)上進(jìn)行網(wǎng)絡(luò)程序設(shè)計(jì)，用它創(chuàng)建網(wǎng)絡(luò)連接比用C或C＋＋更容易。通過Java本地接口（JNI），運(yùn)行在Java 虛擬機(jī)（JVM）內(nèi)的Java代碼能夠與用其它語言編寫的應(yīng)用及庫文件相互操作并匯編。

在構(gòu)造集群監(jiān)控和管理時(shí)，Java早已是一個(gè)可選的語言。然而，Java語言通常只被用于系統(tǒng)的前端或集群主機(jī)部分，而將用C 語言編寫的守護(hù)進(jìn)程安裝在集群結(jié)點(diǎn)上。盡管Java程序設(shè)計(jì)語言提供了許多優(yōu)點(diǎn)，但是，對于高性能集群監(jiān)控，Java能夠有效地替換運(yùn)行在每個(gè)結(jié)點(diǎn)上的C 語言守護(hù)進(jìn)程嗎？這將是本文討論的重點(diǎn)。

高性能監(jiān)控

監(jiān)控Linux集群工具傳統(tǒng)上以秒為測量頻率來提供有限量的數(shù)據(jù)。而高性能集群監(jiān)控被定義為“以intrasecond為測量頻率，從結(jié)點(diǎn)有效地采集數(shù)據(jù)的能力”。當(dāng)涉及較大集群時(shí)，監(jiān)控軟件的低效率問題就變得更加嚴(yán)重，這是因?yàn)樗\(yùn)行的應(yīng)用軟件必須互相協(xié)調(diào)或共享全局資源。

在一個(gè)結(jié)點(diǎn)上的阻隔沖突（Interference）能影響其它結(jié)點(diǎn)上作業(yè)的運(yùn)行。例如，一個(gè)MPI作用需要與所有參與的結(jié)點(diǎn)同步。一種解決辦法是收集少量的數(shù)據(jù)，并以小頻率傳輸。然而，如果是高性能監(jiān)控，這種解決辦法是不可接受的，因?yàn)橛休^重利用率的集群應(yīng)該被頻繁持續(xù)地監(jiān)控。本地作業(yè)調(diào)度器必須能夠基于資源使用情況做快速?zèng)Q策。管理員經(jīng)常希望收到緊急事件的立即通知，并希望觀察到歷史趨勢數(shù)據(jù)，如果集群不能被頻繁持續(xù)地監(jiān)控，那么這些要求是不可能實(shí)現(xiàn)的。因此，必須采取一些措施，如使用更有效的算法、增加傳輸?shù)牟⑿行浴⑻岣邆鬏攨f(xié)議及數(shù)據(jù)格式的效率、減少冗余等。

在跟蹤運(yùn)行中的資源使用情況時(shí)，壓縮Profiling應(yīng)用有助于調(diào)試程序或優(yōu)化程序。對一個(gè)給定的應(yīng)用而言，像存儲(chǔ)器、網(wǎng)絡(luò)、CPU這樣動(dòng)態(tài)資源的使用可能快速地改變著，為了能夠觀察應(yīng)用是怎樣使用這些資源的，一種可能的辦法是使用高頻率的監(jiān)控。

即使用戶對高頻率監(jiān)控沒有興趣，如果算法是有效的，不管監(jiān)控頻率是多少，它也將消費(fèi)很少的資源。在異構(gòu)集群中這種效率將更重要，用戶的作業(yè)可以被分散到較快的及較慢的結(jié)點(diǎn)上，慢的結(jié)點(diǎn)需要全部CPU來跟上較快的結(jié)點(diǎn)并與之同步。一個(gè)監(jiān)控程序花費(fèi)在較慢結(jié)點(diǎn)上的CPU時(shí)間是作業(yè)的關(guān)鍵路徑。

監(jiān)控階段

集群監(jiān)控主要消耗CPU周期與網(wǎng)絡(luò)帶寬這兩個(gè)重要資源。然而，資源消費(fèi)問題與這兩個(gè)資源是根本不同的。CPU利用問題對結(jié)點(diǎn)而言是完全本地化的問題，可通過創(chuàng)建有效的收集與合并算法來解決。網(wǎng)絡(luò)帶寬是共享資源，是規(guī)模問題，可以通過最小化網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量來解決。

為了解決這兩個(gè)問題，我們將集群監(jiān)控分為三個(gè)階段：收集、合并、傳輸。收集階段負(fù)責(zé)從操作系統(tǒng)裝載數(shù)據(jù)、分析數(shù)據(jù)值，并存儲(chǔ)數(shù)據(jù)。合并階段負(fù)責(zé)將來自多個(gè)數(shù)據(jù)源的數(shù)據(jù)合在一起，決定數(shù)據(jù)值是否改變并過濾它們。傳輸階段負(fù)責(zé)壓縮并傳輸數(shù)據(jù)。本文集中討論Linux集群監(jiān)控的收集階段。

1．收集階段

Linux有幾種方法來進(jìn)行系統(tǒng)統(tǒng)計(jì)，每種方法都各有其優(yōu)缺點(diǎn)。

◆ 使用現(xiàn)有的工具

標(biāo)準(zhǔn)及非標(biāo)準(zhǔn)工具能執(zhí)行一個(gè)或多個(gè)收集、合并及傳輸階段，如rstatd或SNMP工具，然而標(biāo)準(zhǔn)的rstat后臺程序提供的信息是有限的，速度慢而且效率低。

◆ 內(nèi)核模塊

幾個(gè)系統(tǒng)監(jiān)控工程利用內(nèi)核模塊來存取監(jiān)控?cái)?shù)據(jù)。一般情況下，這是很有效的收集系統(tǒng)數(shù)據(jù)的方法。然而這種方法存在的問題是，當(dāng)主內(nèi)核源內(nèi)有其它改變時(shí)，必須保持代碼一致性。一個(gè)內(nèi)核模塊可能與用戶想使用的其它內(nèi)核模塊相沖突。此外，在使用監(jiān)控系統(tǒng)之前，用戶必須獲得或申請模塊。

◆ /proc虛擬文件系統(tǒng)

/proc 虛擬文件系統(tǒng)是一個(gè)較快的、高效率執(zhí)行系統(tǒng)監(jiān)控的方法。使用/proc的主要缺點(diǎn)是必須保持代碼分析與/proc 文件格式改變的同步。事實(shí)表明，Linux內(nèi)核的改變比/proc 文件格式的改變要更頻繁，所以，用/proc虛擬文件系統(tǒng)比用內(nèi)核模塊存在的問題要少。

◆ 混合系統(tǒng)

某些監(jiān)控系統(tǒng)采用混合方式，用內(nèi)核模塊收集數(shù)據(jù)，用/proc虛擬文件系統(tǒng)作為數(shù)據(jù)接口。

2．合并階段

合并階段的實(shí)現(xiàn)可以在結(jié)點(diǎn)上、集群管理的主機(jī)上，或者分布在兩者上。考慮到效率，我們只采用在結(jié)點(diǎn)上的合并。原因在于結(jié)點(diǎn)是監(jiān)控?cái)?shù)據(jù)的收集器與提供者。兩個(gè)或多個(gè)同時(shí)的數(shù)據(jù)請求不會(huì)引起兩次操作系統(tǒng)調(diào)用來收集數(shù)據(jù)，而是將第一次請求獲得的數(shù)據(jù)緩存，并可以提供給第二次請求調(diào)用。這種方法減少了操作系統(tǒng)的負(fù)擔(dān)，提高了監(jiān)控系統(tǒng)的響應(yīng)性。合并階段也可以用于將多個(gè)數(shù)據(jù)源的數(shù)據(jù)以相互獨(dú)立的收集速率結(jié)合，因?yàn)椴⒉皇撬械臄?shù)據(jù)都以同樣的速度改變，或者需要以同樣的速率收集。

使用在結(jié)點(diǎn)層上合并的另一個(gè)原因是，減少了包括傳輸在內(nèi)的信息量。許多/proc文件既包含動(dòng)態(tài)數(shù)據(jù)也包含靜態(tài)數(shù)據(jù)。刪除最近一次傳輸后沒有改變的值，一個(gè)結(jié)點(diǎn)發(fā)送的數(shù)據(jù)量可以大大地減少。合并不僅除去了不經(jīng)常改變的動(dòng)態(tài)值的傳輸，也解決了從不改變的靜態(tài)值的傳輸。

3.傳輸階段

監(jiān)控?cái)?shù)據(jù)幾乎總是按一個(gè)層次結(jié)構(gòu)組織起來。傳輸階段的任務(wù)就是將層次數(shù)據(jù)進(jìn)行有效的編碼，形成一種能高效傳輸?shù)臄?shù)據(jù)格式。Java擁有的文件格式是存儲(chǔ)層次數(shù)據(jù)的有效方法，并且用提供的Java APIs很容易完成。S-Expressions已經(jīng)被認(rèn)為是傳輸這種數(shù)據(jù)的另一個(gè)有效的方法。

關(guān)于傳輸監(jiān)控?cái)?shù)據(jù)普遍討論的問題是，數(shù)據(jù)應(yīng)該按二進(jìn)制編碼還是按文本格式編碼。二進(jìn)制數(shù)據(jù)更容易壓縮，因此也能更有效地傳輸。但是，當(dāng)采用/proc文件系統(tǒng)時(shí)，監(jiān)控?cái)?shù)據(jù)通常以人們易讀的格式存儲(chǔ)。在傳輸之前，將數(shù)據(jù)轉(zhuǎn)換為二進(jìn)制格式將需要更多的處理資源與時(shí)間。以文本格式保留收集的數(shù)據(jù)，結(jié)點(diǎn)資源能被用于更多非監(jiān)控性的相關(guān)工作。#p#

采用文本格式的數(shù)據(jù)將提供如下額外的益處：

◆ 平臺獨(dú)立性

當(dāng)監(jiān)控異構(gòu)集群時(shí)，機(jī)器之間數(shù)據(jù)字節(jié)指令的配置不是永遠(yuǎn)相同的。文本格式的使用在代碼方面解決了這個(gè)問題，而且體系結(jié)構(gòu)獨(dú)立不會(huì)影響更多的處理需求。

◆ 易讀的格式

文本數(shù)據(jù)能以人們易讀的格式進(jìn)行組織。如果需要的話，這種特征能容易地進(jìn)行程序調(diào)試或允許用戶觀看數(shù)據(jù)流。

◆ 有效壓縮

數(shù)值數(shù)據(jù)的文本表示由來自10個(gè)字節(jié)集中的字符組成，而不是二進(jìn)制下的256個(gè)字節(jié)集。它們產(chǎn)生的數(shù)字及模式的相對頻率允許有效地使用基于壓縮算法的字典及熵（平均信息量）。

/proc虛擬文件系統(tǒng)

/proc虛擬文件系統(tǒng)（也叫procfs）是Unix操作系統(tǒng)所使用的虛擬文件系統(tǒng)的Linux實(shí)現(xiàn)，包括Sun Solaris、LinuxBSD。在/proc開始時(shí)，它以一個(gè)標(biāo)準(zhǔn)文件系統(tǒng)出現(xiàn)，并包含與正在運(yùn)行的進(jìn)程IDs同樣名字的文件。然而，在/proc中的文件不占用磁盤空間，它們存在于工作存儲(chǔ)器（內(nèi)存）中。/proc最初的目的是便于進(jìn)程信息的存取，但是現(xiàn)在，在Linux中，它可被內(nèi)核的每一部分使用來報(bào)告某些事情。

在/proc文件系統(tǒng)提供的成百上千的值當(dāng)中，我們將集中考慮集群監(jiān)控所需的最小集，它們包括：

◆ /proc/loadavg：包含系統(tǒng)負(fù)載平均值；

◆ /proc/meminfo：包含存儲(chǔ)管理統(tǒng)計(jì)量；

◆ /proc/net/dev：包含網(wǎng)卡度量；

◆ /proc/stat：包含內(nèi)核統(tǒng)計(jì)量；

◆ /proc/uptime：包含總的系統(tǒng)正常工作時(shí)間及空閑時(shí)間。

每個(gè)文件提供的值的數(shù)量是不同的。這些文件的完整有效值列表如下。

◆ /proc/loadavg提供以下數(shù)據(jù)：

1. 1秒鐘平均負(fù)載；
2. 5秒鐘平均負(fù)載；
3. 15秒鐘平均負(fù)載；
4. 總作業(yè)數(shù)；
5. 正在運(yùn)行的作業(yè)總數(shù)。

◆ /proc/meminfo提供的存儲(chǔ)器信息包括：

1. 活動(dòng)存儲(chǔ)器；
2. 不活動(dòng)存儲(chǔ)器；
3. 緩沖存儲(chǔ)器；
4. 高速緩沖存儲(chǔ)器；
5. 總的自由存儲(chǔ)器；
6. 總的高位存儲(chǔ)器；
7. 自由高位存儲(chǔ)器；
8. 總的低位存儲(chǔ)器；
9. 自由低位存儲(chǔ)器；
10. 共享存儲(chǔ)器；
11. 交換存儲(chǔ)器；
12. 交換高速緩沖存儲(chǔ)器；
13. 交換自由存儲(chǔ)器；
14. 總存儲(chǔ)器。

◆ /proc/net/dev中包括每個(gè)網(wǎng)卡的如下數(shù)據(jù)：

1. 接收到的字節(jié)；
2. 接收到的壓縮字節(jié)；
3. 收到的誤碼數(shù)；
4. 收到的漏失誤碼；
5. 收到的FIFO誤碼；
6. 收到的幀誤碼；
7. 收到的多播誤碼；
8. 收到的總包數(shù)；
9. 已傳輸?shù)淖止?jié)；
10. 已傳輸?shù)膲嚎s字節(jié)；
11. 傳輸誤碼總數(shù)；
12. 傳輸載波誤碼；
13. 傳輸沖突誤碼；
14. 傳輸漏失誤碼；
15. 傳輸FIFO誤碼；
16. 傳輸?shù)目偘鼣?shù)。

◆ /proc/stat提供：

1. 引導(dǎo)時(shí)間；
2. 上下文切換數(shù)量；
3. 中斷總量；
4. 進(jìn)頁面總數(shù)；
5. 出頁面總數(shù)；
6. 進(jìn)程總數(shù)；
7. 換入總數(shù)；
8. 換出總數(shù)；
9. 合計(jì)CPU空閑時(shí)間；
10. 合計(jì)CPU nice時(shí)間；
11. 合計(jì)CPU系統(tǒng)時(shí)間；
12. 合計(jì)CPU用戶時(shí)間。
13. 同時(shí)提供對每個(gè)CPU的:
14. 單個(gè)CPU空閑時(shí)間；
15. 單個(gè)CPU nice時(shí)間；
16. 單個(gè)CPU系統(tǒng)時(shí)間；
17. 單個(gè)CPU用戶時(shí)間。

以及對每個(gè)磁盤驅(qū)動(dòng)器的如下數(shù)據(jù)：

1. 單個(gè)磁盤塊讀；
2. 單個(gè)磁盤塊寫；
3. 單個(gè)磁盤I/O總數(shù)；
4. 單個(gè)磁盤I/O讀；
5. 單個(gè)磁盤I/O寫。

◆ /proc/uptime中包括：

1. 系統(tǒng)總工作時(shí)間；
2. 系統(tǒng)總空閑時(shí)間。

值得注意的是，每次某個(gè)/proc被讀時(shí)，一個(gè)句柄函數(shù)都被內(nèi)核或特有模塊調(diào)用,來產(chǎn)生數(shù)據(jù)。數(shù)據(jù)在運(yùn)行中產(chǎn)生，不管是讀一個(gè)字符還是一個(gè)大的字塊，整個(gè)文件都將被重建。這對效率是至關(guān)重要的一點(diǎn)，因?yàn)槭褂?proc的任何系統(tǒng)監(jiān)控器將吞下整個(gè)文件，而不是一點(diǎn)一點(diǎn)地處理它。

Java提供了豐富的文件I/O類集，包括基于類的流、基于類的塊設(shè)備，以及J2SDK 1.4提供的新的I/O庫。實(shí)驗(yàn)表明，一般而言，對基本的塊讀寫文件操作，用RandomAccessFile類進(jìn)行I/O是最佳的。例如，塊讀文件操作如下：

mFile = new RandomAccessFile( "/proc/meminfo", "r" );

//以讀方式打開文件

mFile.read( mBuffer ); //讀文件塊

結(jié)論

本文討論了如何將Java語言有效地用于Linux集群結(jié)點(diǎn)上的高性能監(jiān)控。在程序設(shè)計(jì)中，要注意以下方面：

◆ 采用/proc文件系統(tǒng)；

◆ 以塊形式讀/proc文件，而不是以行或字符形式；

◆ 在讀文件期間保持文件打開；

◆ 消除不必要的數(shù)據(jù)轉(zhuǎn)換；

◆ 在結(jié)點(diǎn)上合并數(shù)據(jù)；

◆ 以壓縮形式傳輸數(shù)據(jù)；

◆ 注意與性能問題相關(guān)的語言或庫。

對高性能監(jiān)控而言，內(nèi)核模塊不是必要條件，這點(diǎn)很重要，因?yàn)樗贚inux版本和分類之間提供了很大程度的可移植性，在監(jiān)控器實(shí)現(xiàn)語言上有很多的選擇。但是，/proc文件系統(tǒng)的性能卻很依賴內(nèi)核代碼的效率，因此，適當(dāng)?shù)乩斫庥嘘P(guān)的機(jī)制將對以任何語言編寫的監(jiān)控器性能有非常大的影響。

【編輯推薦】

1. 服務(wù)器監(jiān)控百家談：趨勢分析是關(guān)鍵
2. Linux集群原理與安裝配置匯總
3. 全面解析Linux集群技術(shù)的要點(diǎn)
4. 全面講述linux集群負(fù)載均衡
5. “懶惰”Linux集群管理員的11個(gè)秘訣