如何分析CMDB軟件

這篇文章將為大家詳細講解有關如何分析CMDB軟件，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

前述:

    0.硬件CMDB,即面向設備資源的資產(chǎn)管理,面向運維人員鐘情于此.

     軟件CMDB,面向業(yè)務資源的配置管理,類似業(yè)務信息管理平臺, 開發(fā)、PE和測試人員更加關心此處.

    1.硬件CMDB各個公司都在建設(程度不一),軟件CMDB(業(yè)務信息管理平臺)系統(tǒng)化管理維護更少.

    2.運維人員鐘情硬件CMDB,對業(yè)務信息管理也只是籠統(tǒng)維護,遠遠沒有到達基于應用項目的業(yè)務維護,監(jiān)控力度只是系統(tǒng)和服務層面).

    3.開發(fā)人員開發(fā)任務繁重,沒有精力提交應用業(yè)務信息,結果.....大家都很忙,可是開發(fā)出什么鬼呀,經(jīng)常被市場同事投訴(真實經(jīng)歷).

    4. 當然開發(fā)肯定有需求分析和項目規(guī)劃, 可是必須讓維護人員(運維)了解和維護相關的業(yè)務應用項目.

    5. 溝通很重要, 運維人員不單單被動的維護, 以運營的手段對待項目.

困惑:

    1.涉及到微服務的開發(fā)需要了解服務部署在哪時,當前實例數(shù)和資源調(diào)度情況,更別說相關應用的日志和監(jiān)控數(shù)據(jù).

    2.運維人員進行報警巡檢或性能分析或添加監(jiān)控,某些服務出現(xiàn)問題(訪問出錯|服務報警|應用上線和下線回收),不知道找

        哪些相關開發(fā)和測試人員進行溝通處理, 尤其優(yōu)化某個子項目服務組, 確認影響故障域和風險評估.

    3.大量應用上線,特別是容器和微服務化, 導致業(yè)務項目更加復雜, 系統(tǒng)<->服務<->應用數(shù)據(jù)串更新頻繁,傳統(tǒng)手段無法維護.

    4.對于某些爆發(fā)性(廣告秒投項目)或者彈性伸縮應用項目,應用業(yè)務資源使用情況更加需不同人員知曉.

        最近TW業(yè)務推廣,此項目資源是否充足,以便進行擴充; 結果突發(fā)專線跑滿,影響到其它業(yè)務,原來就是推廣業(yè)務造成, 臨時追加帶寬.

    5.反正很多都是口口相傳,只有專門人員知曉,人員溝通成本非常高,知情度低也會影響工作效率.能不能提供一個便捷平臺,讓開發(fā)、

        運維、測試人員更加高效處理應用項目業(yè)務.

應用業(yè)務配置管理-大圖

應用業(yè)務配置管理系統(tǒng)相關資源(系統(tǒng)層、宿主、容器、服務、服務組、應用項目)關聯(lián),以及對應監(jiān)控系統(tǒng)關系.

部分成果展示:

1. 面向業(yè)務資源配置管理, 全部隸屬于'應用及服務'下.

2.服務器系統(tǒng)管理,  OS系統(tǒng)作為應用及服務的基礎資源.

3. 基于硬件服務器維護(類似硬件CMDB)， 基于服務器系統(tǒng)維護, 基于應用項目維護, 大約這三個階段.暫時到達服務器系統(tǒng)到應用項目之間, 監(jiān)控系統(tǒng)也是基于服務器系統(tǒng), 作為運維人員更加需要此切點.

4. docker宿主節(jié)點, 專門拆分出來.

5. 宿主節(jié)點和容器實例拓撲圖.

適用場景和環(huán)境: (https://github.com/tm-roamer/ctopo/)

(1)適用于監(jiān)控網(wǎng)絡ip節(jié)點互聯(lián)關系的場景

(2)適用于社交網(wǎng)絡的群組互聯(lián)訪問關系

6. 容器實例.

7. 應用項目

8. 有些服務組模塊被多應用調(diào)用, 反正需要量化區(qū)分服務資源,在應用和服務間增加服務組層.

微服務項目也可以在此處添加, 定義為應用則太大, 定義為服務又太小, 暫時此處.

9. 應用服務

暫時不寫. 服務注冊和服務發(fā)現(xiàn), 類似服務治理吧.

容器服務 基于 consul+register 作為 服務注冊 發(fā)現(xiàn)及健康檢查中心.

10. 我的小目標.

只知道這些服務器系統(tǒng)資源正常, 服務也正常, 這些數(shù)據(jù)都太片面, 獨立無法關聯(lián)起來.

監(jiān)控需求(貼近業(yè)務,告警合并壓縮), 非常需要此業(yè)務配置管理系統(tǒng).

告警合并壓縮, 某個項目故障,可能多方位報警, 需要挑選出更加上層報警上報, 需要知道關系鏈.

####################################################################

如何標識資源:

硬件設備-Asset(X86服務器、小型機、交換路由設備、防火墻、機架等)最終選用SN進行唯一標識,device_id用于存放設備編碼(條形碼/二維碼標簽),

name則為設備名稱(X86服務器則為主機名, 交換設備則為設備名).  服務器業(yè)務IP和管理IP會存放在Asset-server,  交換機管理IP存放在Asset-switch.

####硬件設備不一定有OS系統(tǒng),特別是購買騰訊云和阿里云VM主機,硬件設備肯定就不用提供, 所以造成Asset-AgentInfo拆分.

主機信息-AgentInfo(kvm、vm、hwvm、X86服務器系統(tǒng))必須存在OS(linux|windows|unix),安裝系統(tǒng)初始化同時需要安裝agent.  最終使用hostname

作為唯一標識, agent_ip使用映射IP(hostname -i). 剛開始使用IP標識, 居然有些系統(tǒng)居然有四種IP(私網(wǎng)|公網(wǎng))且沒有合法(hostname -i), 最后用回hostname.

####遇到過硬件服務器系統(tǒng)同時安裝KVM和Docker,kvm宿主機和依附vm都存放在AgentInfo(可以安

####裝agent), 可是主機系統(tǒng)和宿主節(jié)點屬性不一致, DockerNode引擎版本、network、storage、

####image,反正就要拆. 有時購買云供應商容器服務,無法提供AgentInfo,對接加入維護使用,也是拆分

####的原因之一;  對接授權和監(jiān)控和代碼發(fā)布應用, 方便以后松散對接.

宿主節(jié)點-DockerNode, node_id用于主健(用于它用); host_on為可選,用于對接主機系統(tǒng); 最終使用docker_name作為唯一標識.

####

容器實例-Container, node_id用于主健(用于它用); node_on和name最終作為唯一標識.

####不同宿主節(jié)點的容器實例name有可能一致(反正當前情況是這樣);生命周期特別短,標識ID和IP地

####址經(jīng)常變,暫時選用node_on和name聯(lián)合識別.

資源收集方式和更改通知.

服務器管理信息收集:

        手動錄入: 通過網(wǎng)頁進行手動填寫信息.

        Agent自動匯報: 在系統(tǒng)OS同時安裝Agent代理,進行數(shù)據(jù)收集和匯報.

        中繼自動匯報:  例如華為fushion cute私有云, 可以通過相關API讀取VM相關信息, 直接入庫.

宿主節(jié)點和容器實例:

        Agent自動匯報: 主要在宿主機器通過docker info|docker inspect進行數(shù)據(jù)收集和錄入.

        中繼自動匯報:  某個第三方平臺,通過API進行信息入庫.

服務管理:

        手工錄入:  非常不推薦, 針對非規(guī)范化和量少的服務.

        Agent錄入: 服務必須規(guī)范化, 服務安裝部署時進行服務自動添加, 一般針對傳統(tǒng)服務.

        consul服務發(fā)現(xiàn): 特別是針對consul和register服務,對容器服務非常有用.

服務組管理:

        一般通過nginx和haproxy進行分發(fā)管理, 或者其它方式.

        haproxy可以通過狀態(tài)API頁面讀取service_cluster和相關服務, 方便自動入庫.

更改通知:

    以上資源變動, 最好能對接到監(jiān)控系統(tǒng), 讓相關人員了解, 解放我們雙手.

關于如何分析CMDB軟件就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。