一、先查網路問題

先要判斷一下你的虛擬機器的網絡卡模式是否是NAt模式，簡單的判斷方法在你的Zabbix server上ping這個虛擬機器。

如果通，那麼看看你本地的網路是否啟用了多播模式。

如果不通查詢本地虛擬機器的網路問題。還有本地pc的防火牆。

二、查系統問題

如果網路沒問題，zabbix有agent客戶端安裝一個試試，你當前是用的discover方式，沒有agent一般掃描不到。當然也可以用Snmp，nrpe都可以。

Zabbix是一個基於WEB介面的提供分散式系統監控以及網路監控功能的企業級開源運維平臺，也是目前國內網際網路使用者中使用最廣的監控軟體。它支援多種採集方式和採集客戶端，有專用的Agent，也可以支援SNMP、IPMI、JMX、Telnet、SSH等多種協議。Zabbix易於管理和配置，其自動發現功能可以大大減輕日常管理的工作量，靈活的告警機制能夠滿足不同使用者在不同情形下的工作需要。

接下來將簡單介紹一下監控系統的實現原理和zabbix系統，以及雲平臺上監控系統的整體架構。

監控系統的實現原理

監控系統的基本模型

監控系統往往需要對物理硬體和應用軟體的效能和引數進行資料彙集，實現集中管理和統一分析。在一個監控系統裡，構成要素大體可以分為兩部分，即資料採集部分（客戶端）和資料儲存分析告警展示部分（伺服器端），這兩部分構成了監控系統的基本模型，如圖1所示。

圖1 監控系統的基本模型

資料採集的工作模式有被動模式（伺服器端到客戶端採集資料）和主動模式（客戶端主動上報資料到伺服器端）。通常，大多數監控系統都可以同時支援這兩種模式。被動模式對伺服器的開銷較大，適合小規模的監控環境，主動模式對伺服器的開銷較小，適合大規模的監控環境。對於一般小規模的監控環境，由於被監控的節點不多，產生的資料也相對較少，監控系統可以採用C/S（Client/Server，客戶端/伺服器端）架構，這種架構適合於規模較小、處於同一地域的環境。對於大規模的監控環境，被監控的節點較多，監控產生的資料和網路連線的開銷就會非常大，而且由於跨地域等多種因素，需要分散式的解決方案，常見的監控方式為C/P/S（Client/Proxy/Server，客戶端/代理端/伺服器端）架構，採用中間代理將會大大提高監控伺服器端的處理速度，從而能支撐構建大型分散式監控的環境。

監控資料的採集、儲存、分析和故障報告是每個監控系統的基本功能，常見的監控系統性能採集指標如表1所示。

監控專案

詳細內容

主機監控

CPU、記憶體、磁碟的剩餘空間/利用率和I/0、SWAP使用率、程序數、負載

網絡卡監控

網絡卡流量，包括流入/流出量和錯誤的資料包數

URL監控

監測指定URL訪問過程中的返回碼、下載時間及檔案大小

應用程式

埠和記憶體使用率、CPU使用率、服務狀態、請求數、併發連線數

資料庫

監測資料庫中指定的表空間、Session數、事務數、死鎖數、緩衝池命中率、當前連線數

日誌

錯誤日誌匹配、特定字串匹配

硬體

溫度、風扇轉速、電壓等

表1 常見效能採集指標

監控系統中比較重要的是告警和故障處理，這對及時解決問題和故障自愈非常重要。在資料採集完成之後，需要對採集到的資料進行分析和處理，判斷是否有異常，是否滿足告警條件等。告警條件通常是根據實際的經驗值、業務需求來設定的，達到告警條件設定的閾值時，則傳送告警資訊給管理人員，由管理人員進行處理。當然，對於有些故障，如果可以由程式自動處理，減少人工干預，可以在一定程度上提高故障的響應速度。

監控系統的一般結構

目前，監控系統最常用的體系結構仍然為C/S結構,即由監控客戶端和監控伺服器組成，大規模分散式監控系統中大多采用階梯式體系結構，即C/P/S結構,下面將簡單介紹這兩種結構，並分析比較它們的效能表現。

· 集中式體系結構

在客戶端/伺服器端結構中，每個客戶端負責收集所在監控節點的資料，以主動或者被動的方式向伺服器端傳送監控資料。伺服器端將採集到的資料存放在資料庫中。集中式體系結構如圖2所示：

圖2 集中式體系結構

· 階梯式體系結構

階梯式體系結構中，每個監控節點安裝監控客戶端，並選定代理節點，代理節點相當於區域性監控伺服器。客戶端監控資料的採集由代理節點完成，然後再將資料傳送到伺服器端。階梯式體系結構如圖3所示：

圖3 階梯式體系結構

從安裝部署方面來說，C/S結構的監控系統的部署會更加容易，但是從可擴充套件性方面來看，集中式結構的監控伺服器負責收集所有的監控資料並進行儲存分析，在網路流量和計算能力的限制下，只能適合於小規模的監控。而有代理節點的監控系統中，代理節點負責從客戶端採集資料，因此伺服器端僅需要從代理節點處採集資料，會大大減輕伺服器端的壓力，具有較強的擴充套件能力。另外，從容錯性方面來說，集中式體系結構的伺服器端負載重，容易造成災難性錯誤，而階梯式結構則由於其分散式的特性，可以將錯誤控制在某個代理節點所在的範圍之內。最後，從延時性方面對比，集中式結構延時較小，階梯式結構的延時性較大。

推拉模式的原理

監控系統中監控資料在監控客戶端和監控伺服器之間的傳輸，主要有推（Push）模式和拉（Pull）模式兩種。這兩種模式的示意圖如圖4所示。

圖4 Push和Pull模

推模式(Push)：是指由監控客戶端主動將監控資料推送給監控伺服器。Push模式的實時性和資料一致性較好，但是效率較低。Push操作的頻率一般由設定好的時間間隔觸發，一旦時間間隔設定不當，可能會造成丟失監控資料的現象，或者是推送的資料過多，前者影響了監控系統的準確性，而後者則增加了通訊開銷。

拉模式（Pull）：是指由監控伺服器端採用輪詢的方式通知客戶端，將被請求的監控資料項傳送給伺服器端。Pull模式的針對性強，能夠滿足個性化需求，並可以減少通訊開銷，但是一致性和實時性一般。如果輪詢的次數頻繁，以及需要輪詢的客戶端較多，則伺服器端的壓力就會變大。

資料傳輸具體選哪種模式，還需要對實時性、準確性、系統開銷等多方面進行綜合的比較。推模式的實時性高，比較適合監控代理中預先設定觸發事件和閾值告警的場景。拉模式中，伺服器需要對客戶端進行週期輪詢，因此比較適合於被監控的節點較少的場景。本文所實現的監控系統採用推模式採集資料，並對不同的監控指標設定不同的採集週期，儘可能的降低採集開銷並提高資料的準確性。

Zabbix系統介紹

1．Zabbix中的主要概念

l Host：一個網路主機，可以是伺服器或者交換機等。

l Host Group：一個邏輯的Host組，這個組對應著相應的Host、Template（監控模版）和使用者組許可權。

l Template：監控模版，包含Application（監控的應用），Item（監控項），Trigger（觸發器），Graph（圖表）等。一個監控模版可以和多個Host或Host Group對應，與其對應的Host就會被按照Template中定義的Item, Trigger, Graph進行監控、閾值判斷和繪圖。

l Item：監控項，定義了監控的型別、Key、儲存的方式、資料清理的方式等。

l Trigger：一個包含邏輯表示式的觸發器，當Server端接收到監控資料時就會呼叫與監控資料Key相關的Trigger進行邏輯判斷，決定Trigger是丟擲“OK”還是“Problem”的狀態。”Problem”的狀態還分為六個等級：Not Classified, Information, Warning, Average, High, Disaster。Trigger與Trigger之間還存在著依賴，能有效解決單點服務的宕機造成所有依賴服務報警的問題。

l Discovery Rule：為一個主機上的不同實體提供了一種自動建立監控項、觸發器和影象的方法。比如主機的磁碟分割槽、網絡卡名稱等，這些監控項都具有不確定性，因此需要使用discovery功能進行自動發現。Discovery的使用過程分為兩步：自動發現特定變數的名稱，然後新增變數的Items。

l Event：事件可分為三類，Trigger的狀態變化、Zabbix的Discovery發現新Host、Zabbix的Agent主動註冊服務。每一個事件都有相應的Action來處理。

l Action：Action包含了執行Action的條件（Condition）和操作（Operation）。操作可以是Send Message和執行Remote Command。

Zabbix特性功能

Zabbix具有常見的商業監控軟體所具備的功能，包括主機的效能監控、網路裝置的效能監控、資料庫的效能監控、多種告警方式、分散式、可擴充套件能力、API等。

1) 資料收集

v 可用、效能檢測

v 支援Agent、SNMP、IPMI、JMX、SSH、Telnet等

v 自定義的檢測

v 自定義收集資料的頻率

v 伺服器端/代理端和客戶端模式

2) 高度可定製的告警

v 傳送通知，可定製包括告警級別、動作升級、收件人和媒體型別

v 通知可以使用全域性宏變數和自定義的變數

v 自動處理功能包括遠端命令的自動呼叫和執行

3)靈活的觸發器

v 可以定義非常靈活的告警閾值和多種高階相關聯的條件

4) 歷史資料的儲存

v 資料儲存在資料庫中

v 歷史資料的儲存週期可以配置

5) 使用模板

v 模板可以分組

v 模板具有可繼承性

6) 網路發現

v 支援自動發現網路裝置和伺服器

v Agent自動註冊

v 支援自動發現（Low level discovery）實現動態監控項的批次監控，內建的自動發現包括檔案系統、網路介面、SNMP OID，可定製自動發現

7) API功能

v 應用API功能可以方便地和其他系統結合

8) 大型環境的支援

v 利用Zabbix-Proxy方式即可輕鬆構建遠端監控

Zabbix的系統架構

Zabbix的通用架構是Client/Server架構，分散式架構為Client/Proxy/Server或Client/Node/Server，Zabbix-Server將採集到的資料持久地存放在資料庫中，然後用前端UI友好的展示給使用者。

C/S監控架構是由Zabbix Server和Agent直接組成，這種架構通常只負責監控一個數據中心。在這種架構下，監控資料的採集由Server和Agent共同完成。資料採集到Server端後，Server端一方面會查詢這個Key是否有對應的Trigger進行閾值處理，如果有則根據Trigger定義的規則進行判斷，並決定是否丟擲相應的Event。Trigger產生的每個Event會由相應的Action去處理，這個Action可以是給管理員傳送報警，也可以是Server端執行遠端呼叫，重啟Client的某個服務。另一方面，Zabbix Server會將採集到的資料按Item中定義的規則儲存到後端的DB。Zabbix的面板會透過Server提供的API去獲取監控資料並進行資料的展現。

C/P/S架構相比C/S架構多出了一個Zabbix Proxy，C/P/S監控架構如圖5所示，Zabbix Proxy的主要應用場景是多資料中心的集中監控。Zabbix Proxy可以看作是一個數據中心的Zabbix Server，但他除了對資料進行快取，並不對資料進行額外的處理。Zabbix Proxy的加入能緩解Zabbix Server的壓力，同時也能解決多資料中心監控的問題。

圖5 C/P/S監控架構

Zabbix的執行流程

當搭建好Zabbix的執行環境後，可以登入Zabbix-Server的Web頁面新增被監控主機，也可以使用API呼叫新增監控主機。然後，為該主機新增監控模板，即配置該主機的監控項。完成主機的新增和配置後，Server端就會定時的主動或被動地獲取Agent端的監控資料，並將獲得的監控資料存放在資料庫中。如果被監控主機設定了Trigger，則在Zabbix-Server每次接收到Items的新資料時，就會對Items的值進行判斷，如果達到Trigger表示式設定的閾值，就會生成一條Event，觸發告警。告警的操作是由Action定義的，Action中定義了告警的條件，以及傳送告警的方式、內容和告警接收人。執行流程如圖6所示。

圖6 Zabbix的執行流程

Zabbix在雲平臺上的架構

雲計算平臺的系統架構如圖7所示，控制節點安裝OpenStack控制節點元件，使用者透過UI管理和使用雲平臺。控制節點採用pacemaker+haproxy實現高可用，HAproxy監聽vip，並將請求轉發至三個控制節點中的任意一個。計算節點安裝OpenStack計算元件和網路元件，建立的雲主機就執行在計算節點上。控制節點和計算節點之間，以及OpenStack各元件之間都是透過網路進行通訊。

圖7 雲計算平臺的系統架構

在該雲平臺上部署的監控系統的整體架構圖如圖8所示，在每一個控制節點上都安裝Zabbix Server程式，但是隻有一個Server處於執行狀態，即Zabbix-Server是單活的。Zabbix Proxy安裝在每一個計算節點上，proxy負責將從Agent端採集到的監控資料，傳送給Server端。Zabbix-Agent安裝在每一個需要被監控的節點（虛擬機器節點和物理機節點）上，負載採集被監控機上的各項指標資訊。

圖8 雲監控系統的整體架構

隨著網際網路的發展，雲計算的使用也越來越得到市場的認可，特別是近幾年來，許多企業都開始將業務從傳統平臺上轉向雲計算平臺。雲計算具有高效的資源管理、動態負載均衡、按需服務、彈性計算等特性，因此，越來越多的網路服務、應用程式開始執行在雲平臺上。

雲平臺的穩定性是雲服務使用者最看重的特性，也是雲服務提供商放在首位的實現目標。因此，不管是對雲服務提供商，還是雲平臺的使用者來說，為雲平臺開發一套監控系統都是非常必要的。雲監控系統能夠幫助使用者實時的瞭解系統資源的使用情況和服務的執行狀態，並且在出現異常時觸發報警，及時地通知相關使用者，甚至可以自動恢復。Zabbix系統是當前最受歡迎的企業級開源監控解決方案，它的功能很多，並且可擴充套件能力強，這都使得Zabbix的系統架構非常適合作為構建自己的監控系統的基礎。

能，但一般不會放在一起。因為VMware比較大，越到後面越大！而我們需要給系統盤充足點的空間。系統執行才會流暢些

Zabbix監控資料主要兩類： 歷史資料：history相關表,history_uint表面查詢裝置監控專案平均值,即儲存監控資料原始數。

如筆者描述：虛擬機器安裝位置並不清楚，舉例兩種情況吧

1. 透過VMware Workstation軟體安裝的虛擬機器

2. 透過VMware vSphere套件中ESXi作業系統，再安裝虛擬機器

zabbix監控虛擬機器

從 Zabbix 2.2.0 開始支援對 VMware 的監控。

支援 VMware vCenter 或 vSphere 版本最低為 4.1。

Zabbix 可以使用 low-level discovery 自動發現 VMware hypervisors 和 虛擬機器，並根據事先定義的主機原型，為這些虛擬機器建立 Host，新增監控。

Zabbix 中預設提供了幾個模板，可以直接用來監控 VMware vCenter 或 ESX hypervisor。

如上，Zabbix獲取虛擬機器或者主機的資訊是透過VMware API。

VMware WorkStation虛擬機器

VMware WorkStation上安裝虛擬機器，一般透過該軟體圖形介面，直觀方便的操作即可。但是要實現自動化的一下操作，我們還是需要了解其API的。VMware針對VMware WorkStation提供了VIX API，可對虛擬機器和作業系統檔案進行自動化的操作。

總結

如上所述，zabbix中提供的模板並不能監控VMware Station上安裝虛擬機器。但是我們可以透過在虛擬機器作業系統安裝agent的方式去監控，比較麻煩點。

別說虛擬機器了，hypervisor esxi、物理機磁碟、溫度、電壓、主機板所有東西都可以監控，而且都可以上生產。

看了一堆回答，感覺真慘不忍睹，你們都沒明白提問者問的是啥。

首先他問的是監控 vmware workstation 裡的redhat6.5，並不是什麼esxi之類的。

你們題目都沒看清楚，就在那瞎說。如果要監控vmware workstation裡的虛擬機器，首先需要讓你的網路跟你的Zabbix Server連上，不管是server直接連到宿主機裡的虛擬機器，還是虛擬機器只能訪問Server都可以，因為Zabbix有兩種採集方式，主動和被動。需要以上這幾點去考慮監控。起碼網路通，你才能夠採集資料。vmware workstation有三種網路模式，自己瞭解一下，分析一下具體自己的故障點在哪裡吧。