資產管理總結

1、設計初衷

　　第一，傳統的資產管理通常都是經過人爲手動維護一個excel表，這樣，當一臺服務器的任何資產出現了變動，都須要人力去記錄一下。並且，有時候容易忘記本身究竟是否已經作了變動記錄，這樣就使得變動記錄表信息愈來愈不許確，統計資產就變得至關的麻煩，這是設計初衷其一。　　

　　第二，隨着公司部門的增多，每一個部分都有本身消費狀況，若是人爲的統計，不免也會出現上述的錯誤，爲了解決上述的問題，咱們也須要這樣一個資產管理來實時更新各個部門的平常開銷，這是設計初衷其二。

　　第三，平常生產過程當中，各個部分有時候會進行數據的交互。若是每一個部分都以本身的方式將數據傳遞給開發人員，這樣無疑是增大了他們的工做壓力，所以，設計一個資產管理系統，是一個不錯的選擇。

　　基於上述三點，咱們討論出了一套解決上述問題的方案。即，設計一個管理資產的系統，全部須要錄入的數據，都傳遞到該系統中，進入保存，一旦須要使用，咱們能夠經過接口，可以迅速的調用數據，也能實時觀測各個數據的變化。

2、設計目標

　　1.實現自動採集服務器資產信息

　　2.實現報表功能

　　3.統一API接口，便於給其餘部門提供數據

3、項目架構

　　整個項目分爲三個部分：

　　資產採集部分、API接口部分、後臺管理部分。

　　項目大體示意圖以下：

　　　　　　　　　　

 

　　經過API接口獲取服務器傳來的資產信息，而後保存入庫。後臺從數據庫中取出數據，而後展現到頁面上，便於統計與分析。

　　整個項目共由三人完成，1個運維人員，負責提供運維方面的知識以及提供需求；2個開發人員，負責數據錄入以及後臺頁面數據的展現。

　　整個項目數據設計以下：

　　　　　　　　

　　　　其中關係：

　　　　　　Disk，NIC,Memory與Server是FK關係

　　　　　　IDC，BusinessUnit與Server是FK關係，Tags與Server是M2M關係

　　　　　　UserGroup與BusinessUnit是FK關係，UserGroup與UserProfile是M2M關係，AdminInfo與UserProfile是o2o關係。

　　　　　　其中還有記錄變動信息表和錯誤日誌表。

4、涉及技術點

　　資產採集部分

• 複用Django-middleware實現高擴展性，可插拔式的配置文件。
• 複用Django用戶配置與默認配置實現思路 
• 兼容三種採集方式
  • Agent代理方式（原理：在每一臺服務器中都會存在一份腳本文件，在該服務器端執行了命令之後，將數據進行處理之後，而後經過requests.post發送到API接口,該接口將數據保存至數據庫,供後臺管理人員進行動態維護。）
  • SSH方式（腳本文件存放在中控機上,由中控機來控制哪臺機器應該採集信息.若是中控機發送了一個採集命令,而後命令到達目標主機，該主機執行該命令，而後將結果返回給中控機,最後由中控機將數據返回給api進行保存入庫.）
  • SaltStack（在master主機上執行salt 'c1.com' cmd.run '命令',而後master主機會自動連入對應的主機,而後目標主機執行該命令，將命令的結果返回給master.）
• requests發送客戶端採集數據
• 使用線程池，實現多線程採集
• traceback記錄採集錯誤日誌
• paramiko模塊-基於SSH連接遠程主機並執行命令

　　API部分

• 獲取今日未採集主機
自定義api驗證機制(基於tornado簽名cookie實現)
• 時間規則
• 加密字符串規則 
• 訪問次數規則
• 實現容許臨時修改主機名
  • 針對物理機（sn，物理機惟一，以此做爲統計惟一）
  • 針對物理機+虛擬機（hostname,前提先定義規則，主機名不容許重複）
• 日誌變動記錄

　   後臺管理

• 自定義CURD插件

5、設計難點

1. 在採集資產的時候，是否應該把虛擬主機看成資產採集。若是看成資產，以何種標誌做爲採集的惟一標識符？　　
2. python事務+反射實現查看變動記錄。
3. API認證

6、補充

　　1.三種採集方式流程敘述

　　　Agent代理模式

　　　流程圖：

　　　　　　　　　　

　　敘述：

　　在每一臺服務器中都會存在一份腳本文件，在該服務器端執行了命令之後，將數據進行處理之後，而後經過requests.post發送到API接口,該接口將數據保存至數據庫,供後臺管理人員進行動態維護。

　　模式優勢：速度快
　　模式缺點：agent太多,影響系統性能
　　使用範圍:大型公司

　　SSH模式(Ansible或Fabric)

　　流程圖

　　　　　　　　

　　敘述

　　　　腳本文件存放在中控機上,由中控機來控制哪臺機器應該採集信息.若是中控機發送了一個採集命令（經過ssh遠程連接）,而後命令到達目標主機，該主機執行該命令，而後將結果返回給中控機,最後由中控機將數據返回給api進行保存入庫。

　　優勢：無agent代理，提升了系統性能
　　缺點：速度慢
　　適用範圍:小型公司

　　基於第三方工具(SALT-STACK)

　　流程

　　　　　　

　　敘述

　　在master主機上執行salt 'c1.com' cmd.run '命令',而後master主機會自動連入對應的主機,而後目標主機執行該命令，將命令的結果返回給master.master內部維護兩個隊列,若是master須要某個主機執行命令，那麼它會將命令放在執行命令隊列中而slave主機則等待執行隊列中的消息，一旦其中有命令，就取出命令看是否是本身要執行的.而執行的結果將會放入到返回消息隊列中,而後Master再去消息隊列中取出消息,返回給api.