分散式的nagios

Michael_DD發表於2014-09-12
分散式的nagios


分散式的nagios,很多人都在講,也有很多人在用,或者打算用。我寫這個帖子,並不是想寫一個教程,分散式nagios的配置很簡單,沒必要寫什麼教 程,只是單純的一些想法的交流,二來nagios的分散式有很多種理解,也有很多種實現方式,我只是寫我比較感興趣的那幾種而已。 

1、什麼時候需要用分散式的nagios? 

   因為各種各樣的原因,用一臺nagios無法滿足監控的需求,或許你要監控的叢集在兩個機房,相隔很遠,互不相通;或許你監控的機器太多,覺得一臺 nagios撐不住;或許是其他的原因,總之你必須要兩個,或者兩個以上的nagios才能滿足你的監控需求,這個時候,如果你選擇nagios的話,那 就要做分散式nagios的配置了。 

2、什麼才算分散式的nagios?

   單純的配幾個nagios,而不做其他任何的工作,這樣的配置個人覺得不是很好,如果你有兩臺三臺,那還湊合,你可以開三個web頁面,分別看著三個 nagios,也可以維護一張列表,當監控配置變更的時候到三臺nagios上去做,但是一旦監控機器多起來,比如十臺八臺,這個時候,當你需要定位一個 錯誤都要翻開很多很多的web頁面去看,就不是很爽了。 
   因此,個人對分散式nagios的理解主要有以下幾個方面:
   1、分散式檢測。這個是最基本的,配分散式主要就是要每個監控機對自己所管理的一個範圍內的物件進行監控。 
   2、集中式展現。我覺得這個是必須的,當機器多起來的時候,確實需要一個集中式的展示頁面,避免我們有3臺nagios就要開3個web頁面,有10個nagios要開10個web頁面。 
   3、集中式控制。當我們對單臺機器做一些監控方面的變更的時候,比如開關報警、提交檢測結果、重新傳送報警,最好能統一的做,而不應該跑好多地方去找。 
   4、集中式配置。更改配置,也應該是在一起,然後分發到各臺分散式的nagios監控機上。 
   5、分散式報警。報警任務需要分發到各個分散式的監控機上,以免當出現意外情況,比如內部網路突然斷掉,無法登上那臺機器,或者那臺機器的檢查結果無法回來的時候也能進行正常的報警。 
   6、最重要的一點:儘量避免分散式。如 果你可以避免配置分散式的nagios,那就儘量避免它!nagios是一款很高效的軟體,我用了半年多,每次感覺它撐不住了,但是每次結果都發現不是 nagios本身的問題,而是我自己配置的問題。不論是哪種分散式實現方式,對於nagios來講都是一種效能上的損耗。而且,能用一臺機器解決的事情, 為何要用兩臺呢? 

   總而言之,我們配置的目的,就是很多臺nagios在跑,但是需要給人一種感覺,那就是我們總共只有一臺nagios在工作。 

3、怎樣實現上一問所說的分散式? 

   具體實現方法有很多,我列舉我知道的,歡迎大家補充: 

   方法1、使用nagios的被動檢測。 

   這是最簡單的辦法,分散式的nagios利用ocsp選項,將檢查的結果透過nsca提交到一臺總的監控機上,總的監控機也配置nagios,但是自己並 不會進行host或者service的檢測,所有的檢測結果都透過nsca從分散式的nagios獲取。實現簡單,但是效果最差。 

   a、被動檢測結果是透過nagios.cmd檔案進行提交的,而管道方式的資料傳送是一種很低效的方式,而且預設的cmd快取只有4096行,當然這個值 我們可以配置的很大,但是勢必會影響回收檢查結果的速度。如果設定的太小,那就會有很多檢查結果無法回收。而且,所有web頁面傳回來的命令也是走的 nagios.cmd,我們會發現在做了某些操作的時候,很久才會生效,甚至根本沒有生效。

   b、集中式的控制需要另外實現,如果報警的功能是在分散式的nagios上實現的,那要控制它就得另外實現。但是如果要在集中式的那臺機器上報警,也不是不可以,但是上面的問題就會很突出,萬一回收結果溢位被丟棄,那它的報警永遠發不出去了。

   c、集中式配置,也需要另外實現。 

   方法2、使用ndo,統一入庫之後再集中展示。

   一個比較好的解決方案,那就是centreon,centreon是用php和perl寫的,利用到了ndo。具體方法是,centreon自己把監 控的節點都配好了,存在它的資料庫裡,然後將這些配置匯出成為nagios的配置檔案,然後啟動nagios,利用ndo將檢查結果入到資料庫 中,centreon再讀這個庫來進行展示。 

   這算是個比較完美的解決方案了,集中控制,集中展現,集中配置,分散式檢測和報警都實現了,而且還附送rrd繪圖和報表的功能,但是,還是有些地方需要注意的: 

   a、配置很麻煩。我只能說配置很麻煩,依賴的東西很多,php、mysql、ndo、還有很多perl的lib,而且有些指令碼在安裝好以後可能是無法執行的,會丟擲大量的錯誤,需要你一個一個去排查,必要的時候還需要改寫指令碼。如果你對nagios很熟悉,對perl,php,rrdtool,mysql都有所瞭解,那建議你用centreon;如果不是,還是請多考慮下,很多情況下都是配著配著就卡在一個地方,再也下不去了。 

   b、ndo入庫的問題。nagios是款很高效的軟體,如果你看過它的原始碼的話,相信會有這種感觸。他從頭到尾的實現都在避免任何可能遇到的瓶頸,所以他 刻意繞開了資料庫,在硬碟讀寫和等待檢查結果兩者中取了個很適合的平衡點,它儘量讓自己的效能完全取決於處理器的處理能力,而不是低速的硬碟、網路和它無 法預知的plugin。這讓我覺得,不論是使用ndo,還是使用被動檢測,都會對它的效能造成很大的影響。我曾經遇到過這種事情,我的nagios被低速的資料庫拖垮,last_check時間平均分佈在一個小時的時間段裡…… 

   方法3、靠自己。 
           
   完全靠自己來實現,在linux下,這是完全可行的,所有的效能都在自己的掌控中,這種感覺是很奇妙的,而且難度並沒有想象的那麼大。

   a、集中展示 

   集中展示是靠nagios的cgi來實現的。nagios的cgi展示的時候要讀取幾個檔案,主配置檔案 nagios.cfg;objects.cache檔案,存放nagios的物件資訊;status.dat檔案,存放狀態資訊。我們只要提供給它這三個 檔案,它就會把我們需要的結果乖乖的展示出來。

    主配置檔案不說,objects.cache這個檔案,可以 透過nagios -pv nagios.cfg來生成objects.precache,它會讀取所有object的配置檔案生成一個包含所有object配置的檔案。然後直接 mv到objects.cache就可以。

    status.dat這個檔案可以透過各種手段來生成,用nfs 也好,scp也好,或者別的辦法,定時的把分散式nagios的status.dat收集到主nagios上,然後透過一個指令碼將這些檔案中包含的狀態信 息綜合到一個status.dat 裡。本來nagios透過status.dat的展示就是非同步的展示,我們再做一次非同步,展示的時間可能不是很及時,但是nagios畢竟是以報警為主 的,一般來講,等你收到了報警的時候,再上去看web頁面那應該早展示出來了。 

    這樣,我們就完成了一次欺騙,我們欺騙了nagios的cgi,讓它以為,這臺機器上確實有一個nagios在後臺跑著,但是實際上這只是一種錯覺而已。而且,非同步的工作,對nagios本身的效能影響最小。

    b、集中配置 

    集中配置其實也沒什麼難點,既然這臺機器要生成你所有需要的object的總配置檔案,那這臺機器上就需要有所有的object的配置,你可以透過各種辦法,scp,svn,將這些配置檔案分發到各個分散式的nagios上,然後ssh過去重啟一下,這些都是可以固化到一個指令碼里實現的,object的配 置檔案可以按照分散式nagios的不同放在不同的資料夾下,到時候只要複製這個資料夾過去就可以了。

    c、集中控制 

    集中控制是這個方案中最麻煩的一點,nagios的控制,是透過cmd.cgi寫nagios.cmd來實現的,你有多個nagios,就有很多的 nagios.cmd,首先我們要知道需要寫哪個cmd檔案,然後我們要想辦法把控制資訊寫到這個cmd檔案上去,更頭疼的是這些個檔案分佈在不同的機器 上,也許相隔很遠。但是辦法總是有的,幸好我是在linux下,呵呵。我的辦法還是採用nagios自帶的cgi實現,就是cmd.cgi,我先判斷,我 操作的host或者service是在哪個nagios上,然後我訪問它的cmd.cgi就可以了。

    首先,我們需要一張列表,我們至少要明白,在哪個nagios上跑了哪些host和service,這樣,當我們做出控制的時候,就可以先讀取這張列表, 知曉我們需要到哪臺機器上做控制。這個列表可以放在配置分發指令碼中實現,每次配置改動,就重新生成。當然,這個是需要一些自己定義的規範,規範不一樣,腳 本也不一樣。

    然後,我們要讓主nagios上的cgi讀取這個檔案,呼叫cmd.cgi的是extinfo.cgi,我們需要做一些原始碼上的改動,當它呼叫 cmd.cgi的時候,就先讀取列表檔案,知曉了它要操作的物件所屬的nagios主機名,或者ip地址,總之是一個標識,然後,將這個標識表現在呼叫的 url中。

    接下來,就是apache乾的活了,透過這個標識的不同,來進行重定向,將cmd.cgi重定向到和它相對應的主機上,這樣控制就實現了。對於沒有外網地 址的nagios,可以利用apache的反向代理或者其他。這就不屬於我們討論的範圍了。 

    這種辦法,靈活性很高,我們可以選擇我們喜歡的方式,而且刻意繞過了資料庫,對nagios本身的效能基本上沒什麼影響,如果nagios的log對你很 重要的話,可以選擇讓各個nagios每天滾一次日誌,然後每天晚上將log收集起來,合併成一個nagios日誌,這樣nagios的日誌分析工具也可 以用了

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29500582/viewspace-1268609/,如需轉載,請註明出處,否則將追究法律責任。

相關文章