自動化運維體系下的Agent概念，場景及實現

1 概念

我的理解，運維的核心是時時維護好目標機器（服務器、網絡設備、系統軟件等）使之與業務需要相適應，而自動化運維就是將運維的一系列步驟自動化。在所有步驟過程中，維護目標機一般都通過掛載在機器上的agent來實現，它是目標機上的一個口子，一個管道，讓目標機完整的融入運維整個生態里。

既然我們使用Agent來維護目標機，那這些維護工作，即Agent的主要工作有哪些呢？可以想到的有：

• 接受下發資源：比如下發腳本，配置文件，應用程序，庫。
• 執行本機任務：定時，不定時的執行一些任務，比如收集機器軟硬件信息等，啟停服務，日志分析等。
• 網絡服務：比如掃描與此目標機相連的網絡設備，推送數據，提供類似HTTP服務供管理工具pull數據。
• 其它自定義服務。

如果做一個適應不同運維環境的Agent，在此稱之為Uniagent(Unique agent)，它必須提供除上面agent功能之外的一些基礎功能，方便自動化運維：

1. 跨平台：支持主流的操作系統如Windows，各種Linux，Unix等。
2. 核心服務+擴展支持：Uniagent是一個容器，里面內置一些常見的服務，比如執行腳本（perl，python，shell，bat），輪詢SNMP網絡設備，分析日志等。這里的服務是以模塊（module)的形式存在的。因為環境的不可預見，Uniagent必須提供SDK，方便具體環境的人開發對應的module，然后載入Uniagent。
3. 管控中心：Agent必須接受某一個管理，這里稱之為Agent Manager，用來收集Agent狀態，並反映到一個名為Manager Console的Web應用上來。方便運維人員在Console上下發各種指令，比如安裝，卸載服務（模塊），啟停，安裝軟件，更改配置等。

這里我特別強調Uniagent，因為在大一點的公司里面，部門，產品項目眾多，運維監控人員也眾多，還不統一，在同一目標機上安裝很多agent的形式大量存在，弊端很多。Uniagent的一個很重要的目標是在被運維的目標機上有且僅有一個Agent。

2 場景

下面以一個監控的場景來描述Uniagent的生命周期。此場景定義了一個從無到有的目標機被監控內存使用狀況。

整個工作過程如下描述：

1. 申請一台目標機，安裝某個應用，並監控之。這個目標機在交給開發者部署應用的時候是是一台“ready to use“的機器，也就是說系統，IP，配置等ok且Uniagent已經預裝，同時此機器的基本硬件信息，系統+版本已經在機器信息查詢系統(以后簡稱MQS)里面備案。
2. 目標機啟動，Uniagent會向Master查詢注冊機（也就是Agent Manager，后面簡稱AM)，這里Master是一個域名唯一的服務器（或服務器列表，VIP/LVS后）。Master根據Uniagent匯報上來的信息，主要是IP信息，然后根據某些策略（比如IDC機房策略），分配給其一個Agent Manager的IP。Uniagent向AM注冊成功。至於Master是怎么知道有哪些Agent Manager和策略，應該有另一個系統來維護。
3. Uniagent向AM發送心跳和其它信息，AM將此信息定時刷新到數據庫(DB)中。
4. 運維人員通過Manager Console(后簡稱MC)查詢數據庫，可以看到某個AM下維護的Uniagent列表，每個目標機的狀態，系統信息， Agent Module列表等。因為運維人員要監測內存使用情況，在假定執行腳本服務（正常情況下是內置，這里為使上下文簡單且完整，這個服務或Module我們暫且稱之為EXESCRIPT）沒有被安裝的情況下，向AM下達安裝EXESCRIPT模塊的安裝命令。
5. AM在基於Uniagent送上來的目標機系統信息，結合MQS系統，在DB中找到合適的版本，對Uniagent進行EXESCRIPT模塊下發。舉個例子，假設目標機是Windows，發的可能是exescript.dll；如果是Linux，發的就是exescript.so。
6. Uniagent向AM回報更新過后的模塊信息，注意這時EXESCRIPT的子進程已經啟動，已經可以提供服務了。運維人員會看到模塊下發成功，他手上有一個perl腳本meminfo.pl存儲在資源中心(后稱RC)，且通過MC能看到。他決定將這個meminfo.pl文件通過AM下發到其下所有目標機。
7. Uniagent收到資源meminfo.pl的下發請求，並交給EXESCRIPT存放在EXESCRIPT模塊知曉的某一文件目錄。每個資源在都有一個唯一的相對地址，比如 /sys/mem/x86/meminfo.pl，結合EXESCRIPT的腳本存放目錄才是一個可定位的絕對路徑。
8. AM被監控系統SPY下發一個監控任務，即定時的掃描腳本meminfo.pl，此任務被下發到Uniagent，開啟一個調度器定時的執行腳本，所產生的結果發送到Monitor。怎么知道發送到那個Monitor? 見 第 9 步。
9. Uniagent往Master查詢Monitor（這個跟監控有關的數據消費者是monitor，比如跟portal有關的可能就是collector，Master會根據模塊信息決定有哪些數據消費者），Uniagent連接上Monitor A和Monitor B，持續的將數據發到指定位置，這個數據傳送協議，為統一，很可能采用HTTP POST。

當然，上面描述的只是安裝，采集行為。對於完整的系統來說，還有任務的停止，模塊的卸載，資源的刪除等。上圖所有的元素中，只有監控系統SPY和Monitor屬於應用方，其它都需要開發或者提供(比如RC和MQS都必須提供），才能讓Uniagent這個自動化過程運行起來。

3 實現

Uniagent雖然體積不能太大，但是提供容器功能，需要使用有較好抽象能力的語言，我建議采用C++來實現，因為：

1. 語言特性：C++本身是標准，跨平台，支持高級數據結構和模塊化編程，錯誤異常處理。
2. 眾多的庫：比如STL，BOOST，Protobuf，對於Uniagent日常的系統任務，操作系統的SDK提供豐富的庫讓實現更簡單。
3. 跨語言：所有可實現多種語言接口的組件庫都基於C++實現，比如COM，XPCOM，Corba等，這為以后Uniagent實現跨語言編程提供了基礎支持。

能夠支持C++的構建系統很多，比如automake，scons，cmake, nmake(MS build，即visual studio的那個），其中cmake具有良好的“原生”特性，即適配系統本身的構建系統，比如在windows上生成visual studio solution文件。還有cmake也經過大型項目如KDE4的實踐。在Linux也有KDevelop這個cmake加C++的大殺器開發工具。

Uniagent的動態模塊機制基於操作系統的DL(Dynamic Loading)即動態庫加載，它在類Unix和Windows上都有實現，由於兩類操作系統的二進制格式不一樣，實現機制不盡相同，但Uniagent需要的功能已經足夠。

因為要提供SDK，所以Uniagent的容器開發也得是庫+殼的模式，類似於Apache和APR的關系，初期兩個必須分開，這樣庫就可以包含在SDK中供其它模塊開發者使用。

參考實現： 

https://github.com/lifesting/uniagent