當CMDB趕上Zabbix,工程師的幸福感提高?

本文來自OneOaaS微信公衆號，http://url.cn/2HSrHMj

        在Zabbix的使用過程當中，自動發現(network discovery & low level discovery)堪稱監控的運維利器。配置一個發現規則，便可將全部的機器歸入監控。這種自動化的能力，能夠秒殺一大片監控系統。那麼，這種自動化能力是否是就足夠了呢，或者說是否是適用於全部的場景？在OneOaaS看來，未必均可以知足，(OneOaaS是Zabbix的合做夥伴，而且推出了本身的監控大屏解決用戶的Zabbix使用問題)。但從咱們大量用戶的使用場景來看，一個沒有CMDB的運維環境中，而只依靠Zabbix監控系統，實難擔當資產管理的大任,對維護監控系統的人員壓力太大。

        那麼，讀者可能要問了。到底是以監控系統爲主，仍是以CMDB爲主？OneOaaS給出的建議是，在規模較小，業務環境不復雜的狀況下，能夠以監控系統爲主，但規模較大，變化較快，必須以CMDB爲主。

       在Zabbix監控的第一次添加的時候，設備的角色，每每不能當即定義，或者是，設備的用途還沒有徹底劃分，業務也還沒有運行。因此，即便這個時候有了自動發現，也是英雄無用武之地也。或者說機器今天這種用途，明天那種用途，Zabbix的維護真的是個頭疼的事情（朝令夕改，你到底煩不煩呀？），爲此呢，現年來出現某些以客戶端主動push數據爲主的監控系統。即服務端無需關心客戶的任何配置，數據進來就寫入。再者加上tag標記，讓設備的用途（角色）自動更新。此時的監控系統，在大規模環境的使用上，已經超越了Zabbix，解決了這種用戶的痛點。但這種系統的監控功能未必有Zabbix那麼強（畢竟能同時提供Agent、SNMP、IPMI、JMX、WEB、SSH、TELNET、擴展監控腳本，而且能自定義的開源監控系統真的不是不少）。雖然zabbix 3.2也引入了tag的技術，但要達到這種效果，還得有一段路程要走。

       說了這麼多，那麼CMDB在何時能夠用呢？

       就目前來看，一個有序的IT組織，必然須要一個統一的資產管理平臺，全部的系統，都以CMDB爲核心，如機器上線，則自動註冊到CMDB，業務變動，自動註冊到CMDB，角色變動，停機維護，也同時變動CMDB，此時，監控系統只須要維護好相應的規則，便可讓監控的自主添加，從而彌補了主動掃描不夠準確的缺陷。同時，靈活性大大加強。只須要經過CMDB獲取到設備的相關信息和狀態，而後主動更新監控系統，而且糾正之前添加好的，但信息不許確的監控。

     這樣一個過程，將資產的無序狀態，變成了有序狀態。從而讓監控系統實現自主的維護。

     相信使用Zabbix的朋友們深有感覺，監控系統的維護，是個體力活，同時也是個技術活(有同感的請舉手)。維護久了，就算經過API寫一些腳本，實現部分功能的自動化。但仍然是一件比較心累的事情，尤爲是公司人員衆多，多個小組同時維護一套Zabbix監控系統的時候，溝通協調的問題，致使了監控系統出現死角，信息不透明，致使了監控變動不及時。維護量巨大，而大多數的公司，不會讓你一我的專門去維護Zabbix，還得幹些其餘業務價值的活。

     經歷過這些後，你會以爲有一套CMDB是多麼幸福的事情(幸福感每個工程師的追求，以手動操做爲恥)。

     然而，CMDB的建設，也並非一路順風的（風險係數極高，請三思然後行）。

     首先，CMDB是一個資產管理系統，他須要採集全部設備的資產信息，其次，他須要周而復始的更新數據信息，手動操做，不免遺漏，自動操做，又會陷入Zabbix自動發現的尷尬境地。另外，CMDB是一個組織的人員協做和IT資產流轉，生命週期的管理。從設備的上下架到維保，整個生命週期都須要在CMDB裏面體現出來，因此別看CMDB是一個增刪改查的DB，其實每每沒你想的那麼簡單（經歷過的人都有同感）。

     那麼，不少同窗說要自建CMDB，不少公司也這樣作了，然而實際效果如何呢？恐怕未必都造的很是好，本身造的輪子，含着淚都要用。最終的結果就是發現花了很大精力造的CMDB，最終仍是沒法很好的運轉和推廣。

     CMDB每每會被神話，不少人說這個東西很靈，能解決什麼什麼問題，其實當你真正用起來了，你又感受不到他到底與多大價值。這種感受就是，少了你不行，有了你不以爲你真有多重要（此處運維深深的躺槍）。說實話，很難說CMDB的具體價值，但沒有CMDB必定是不行的。CMDB造的很差，必定也是不行的，造的好，帶來的價值是巨大的，造的很差，他必定會帶來負面影響，效率不必定提升。

      CMDB有哪些解決方案呢？開源的，itdb，itop，cmdbuild，ralph等等，商業的BMC，卓豪等。當你用了開源的CMDB後，恐怕不想再用了。那真不是通常的難用。商業的CMDB，成熟完善，但通常定製不太靈活。而後，你可能最終會選擇自建CMDB，回到了開始說的那個循環中了。

      通常CMDB系統，都花了很大精力去造CI(配置管理項，即資源)和自動化建模，可是不是真的好用，這個很難說。是否是能真正的解決你問題，這個也很差說。例如要達到前面和Zabbix結合使用的效果，恐怕還得你本身去造一箇中間環節的輪子才能很好的使用。

     CMDB的實施，通常都須要從領導層的支持，堅決不移的推廣下去，否則，CMDB是件很難進行的事情。由於，沒有人願意往CMDB裏面去更新數據（這是一個公開的祕密）。而要用數據的時候，CMDB裏面未必就有，因此，維護CMDB的活是個不討人喜歡的。

    就目前來看，能有一套即知足CMDB基礎功能的，又能夠與Zabbix，發佈系統，業務系統相結合的CMDB，纔是用戶真正想要的CMDB系統。

    整體來講，想要讓Zabbix使用的更好，你是須要結合CMDB的，也須要結合一些自動化工具。若是有那麼一天，Zabbix和這幾個工具更好的整合了，那麼維護Zabbix的活，將會輕鬆不少。固然，OneOaaS從官方瞭解到的，Zabbix並無這些打算呀。因此，暫時只能你們本身造輪子吧。 或者有一天，讓OneOaaS來爲你造輪子。

    如想了解更多關於OneOaaS的信息，請訪問官方網站，或者是請加oneoaas6爲好友，微信搜索oneoaas6詳聊。

   你也能夠關注OneOaaS的公衆號

   歡迎關注OneOaaS微信公衆號。獲取更多關於Zabbix和運維工具的資訊。