如何分析CMDB軟件

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

前述:

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

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

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

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

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

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

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

困惑:

    1.涉及到微服務的開發需要了解服務部署在哪時,當前實例數和資源調度情況,更別說相關應用的日志和監控數據.

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

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

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

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

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

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

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

應用業務配置管理-大圖

應用業務配置管理系統相關資源(系統層、宿主、容器、服務、服務組、應用項目)關聯,以及對應監控系統關系.

部分成果展示:

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

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

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

4. docker宿主節點, 專門拆分出來.

5. 宿主節點和容器實例拓撲圖.

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

(1)適用于監控網絡ip節點互聯關系的場景

(2)適用于社交網絡的群組互聯訪問關系

6. 容器實例.

7. 應用項目

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

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

9. 應用服務

暫時不寫. 服務注冊和服務發現, 類似服務治理吧.

容器服務 基于 consul+register 作為 服務注冊 發現及健康檢查中心.

10. 我的小目標.

只知道這些服務器系統資源正常, 服務也正常, 這些數據都太片面, 獨立無法關聯起來.

監控需求(貼近業務,告警合并壓縮), 非常需要此業務配置管理系統.

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

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

如何標識資源:

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

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

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

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

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

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

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

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

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

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

####

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

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

####址經常變,暫時選用node_on和name聯合識別.

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

服務器管理信息收集:

        手動錄入: 通過網頁進行手動填寫信息.

        Agent自動匯報: 在系統OS同時安裝Agent代理,進行數據收集和匯報.

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

宿主節點和容器實例:

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

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

服務管理:

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

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

        consul服務發現: 特別是針對consul和register服務,對容器服務非常有用.

服務組管理:

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

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

更改通知:

    以上資源變動, 最好能對接到監控系統, 讓相關人員了解, 解放我們雙手.

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