既然進程之間是流水線式的協作，我們看一下監控數據在三類進程之間如何進行輸入和輸出。首先，Trapper和poller進程接收到的數據按照來源分為兩種，一種是來自proxy端，一種是來自agent端。由于來自proxy端的數據已經由proxy完成了預處理，所以，這部分數據會直接輸出到共享內存，供historysyncer進程使用。對于來自agent端的數據，無論其監控項是否設置了預處理步驟，都會通過unix域套接字傳遞給預處理進程。預處理進程接收到數據以后，如果發現該數據并沒有設置預處理步驟，則直接寫入共享內存，供historysyncer進程使用；如果發現需要預處理，則在預處理完畢以后再寫入共享內存，供historysyncer進程使用。對于historysyncer進程來說，其輸入數據來自共享內存，它會批量地從共享內存讀取數據進行處理，具體處理過程是先寫入數據庫，然后計算觸發器表達式生成event。Zabbix6.2驚喜發布!特別優化中大型環境部署的性能!zabbix 6.2詳細部署過程

除了監控數據本身，Zabbix中的元數據（或者叫主數據）也體現出性，元數據主要包含host、item、trigger等信息，其性主要體現在host層面，因為item屬性與host屬性是關聯的，而trigger又是與item關聯的。所以每個host元數據相互關聯，構成整體。然而，某個host屬性的修改不會影響到其他host。在Zabbix系統中所反映出的監控數據以及元數據之間的性，為并行和可擴展性提供了基礎，可以說Zabbix監控系統非常適合基于數據分組的并行化和微服務化。時代zabbix有哪些集群節點發送到數據庫后端的心跳是非常小的消息，記錄在一個較小的Zabbix數據庫表中，故性能影響忽略不計。

監控數據的邏輯視角：監控數據首先特點是具有相互獨立性。在不同的數據處理階段，這種**性會體現在不同的層面，在數據采集階段會體現在value層面，如果不考慮日志監控的話，同一監控項的多次數據采集之間不會互相影響，相當于是無狀態的。在數據傳輸階段，也就是從agent發送數據到server接收數據的階段，**性體現在host層面，不同的host使用不同的地址和接口進行數據傳輸，互不影響，而在同一個host內部，每次傳輸的數據往往包含多個監控項的值。

下面看一下元數據對數據處理效率的影響。元數據位于共享內存中，包含監控項、主機、觸發器、接口等所有必要的信息，這些信息分別存儲在很多個哈希表結構中。這些信息供幾乎所有Zabbix進程使用，在Zabbixserver端，無論是數據接收階段、預處理階段、數據計算階段都離不開對元數據的訪問。此外，元數據還需要通過configurationsyncer進程進行定期數據同步，目的是將數據庫中所作的修改同步到緩存中。當在同步過程中需要修改元數據，configurationsyncer進程會對面臨一個較大的挑戰，就是與其他進程的協調。考慮到大部分進程只是讀取元數據，而不會進行寫操作，Zabbix選擇使用讀寫鎖來協調所有進程對元數據的訪問，從而允許多個進程同時讀取元數據。zabbix主動模式和被動模式的優缺點。

在實際的工作環境中，根據網絡環境和監控的規模不同，zabbix一共有三種框架，分別是server_client架構、master_node_client架構和server_proxy_client架構。1、server_client架構zabbix**簡單的架構，監控設備和被監控設備之間直接相連，zabbix_server和zabbix_client之間直接進行數據交互。2、zabbix_proxy_client架構proxy是連接server和client之間的橋梁，其本身不存放數據，只是將zabbix_agent端發來的數據暫存，然后再提交給server。這種架構一般用于跨機房、跨網絡的中型網絡架構。在server_proxy_client架構中，server設備的宕機會導致整個系統癱瘓而無法正常工作。3、master_node_client架構master_node_client架構是zabbix**復雜的架構。一般用于跨機房、跨網絡、監控設備較多的大型網絡架構。與server_proxy_client架構相比，master_node_client架構的主要區別在于node與proxy上.在master_node_client架構中，每個node可以理解為一個小的server端，在自己的配置文件和數據庫，node下游可以直接連接client，也可以再次經過proxy代理后連接client。在master_node_client架構中，master設備宕機不會影響node節點的正常工作。zabbix通過一系列的UI/UX優化、新監控項和配置選項以及中大型環境部署的性能優化。哪里有zabbix認真負責

Zabbix如何實現對大流量監控數據的高效處理？zabbix 6.2詳細部署過程

ValueCache以哈希表形式存儲每個監控項的熱數據，這些數據主要用于觸發器表達式的計算，從而，監控項數量的增長基本不會影響觸發器表達式計算所消耗的時間。趨勢緩存中存儲的是每個監控項**近自然小時內的累計趨勢數據，這些數據的更新和寫庫均需要經歷查找的過程，因為數據的更新和寫庫都是由***到來的監控數據驅動的，需要根據到來的監控數據查找對應的監控項數據。除了需要解決快速查找問題，Zabbix還需要解決快速排序問題，這一問題源于historysyncer進程處理監控數據時應該按照什么樣的順序進行處理，Zabbix是以監控項為單位對所有監控數據按照時間戳從小到大進行全局性的排序，所使用的排序方法就是堆排序，當需要選擇目標時，只需要訪問根節點即可。在使用堆排序的情形下，每次排序所消耗的時間與堆的規模直接相關。所以我們應該盡可能降低歷史緩存中的監控項的數量，以加快數據處理速度。在壓力較小的Zabbix系統中，歷史緩存中的數據總是接近于0。上述哈希表結構的設計體現了監控數據的**性，正是由于**性，每次查找數據只需要訪問單個目標。而堆排序的設計則體現了監控數據在時間維度的先后次序。zabbix 6.2詳細部署過程

上海觀縱科技有限公司是一家集研發、生產、咨詢、規劃、銷售、服務于一體的服務型企業。公司成立于2022-11-14，多年來在webfunny前端監控，webfunny前端埋點，全鏈路應用性能監控，Argus-IT運維監控行業形成了成熟、可靠的研發、生產體系。公司主要經營webfunny前端監控，webfunny前端埋點，全鏈路應用性能監控，Argus-IT運維監控等產品，產品質量可靠，均通過傳媒、廣電行業檢測，嚴格按照行業標準執行。目前產品已經應用與全國30多個省、市、自治區。上海觀縱科技有限公司每年將部分收入投入到webfunny前端監控，webfunny前端埋點，全鏈路應用性能監控，Argus-IT運維監控產品開發工作中，也為公司的技術創新和人材培養起到了很好的推動作用。公司在長期的生產運營中形成了一套完善的科技激勵政策，以激勵在技術研發、產品改進等。webfunny前端監控，webfunny前端埋點，全鏈路應用性能監控，Argus-IT運維監控產品滿足客戶多方面的使用要求，讓客戶買的放心，用的稱心，產品定位以經濟實用為重心，公司真誠期待與您合作，相信有了您的支持我們會以昂揚的姿態不斷前進、進步。