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和相關服務, 方便自動入庫.

更改通知:

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

參考鏈接:

http://blog.csdn.net/younger_china/article/details/52243759

http://blog.csdn.net/yeasy/article/details/47749725

http://blog.csdn.net/zhangjun2915/article/details/44080453

http://blog.csdn.net/gsying1474/article/details/51773391

https://gliderlabs.com/registrator/latest/user/quickstart/

http://blog.csdn.net/daiyudong2020/article/details/53559008

http://blog.csdn.net/yeasy/article/details/47749725

http://dockone.io/article/272

http://www.techweb.com.cn/network/system/2016-01-28/2270190.shtml

http://www.cnblogs.com/wintersun/p/6747355.html

http://blog.csdn.net/u010246789/article/details/51871051

http://blog.51cto.com/renyongfan/1827797

1.5 運維平臺之軟件CMDB