n recent years, Zabbix has surged ahead in the open-source monitoring field with its nearly omnipotent monitoring capabilities and superior performance, dominating the market. Meanwhile, Lerwee Monitoring, as an emerging IT monitoring platform, has continuously absorbed the strengths of excellent open-source platforms like Zabbix and Prometheus, embracing open-source compatibility and gradually forming its own unique characteristics, making a name for itself in the IT operations and maintenance sector. Below is a detailed comparison of the advantages and disadvantages of Lerwee Monitoring and Zabbix, focusing on their architecture and performance in this installment. Please stay tuned, forum_lwops.

I. Advantages of Zabbix

1. Architecture: Distributed centralized management with open interfaces. Supports distributed deployment, time-series databases, data compression transmission, and encrypted transmission.
2. Scalability: Flexibly integrates with third-party modules and products (such as Grafana, ELK, etc.) via databases or APIs.
3. Plasticity: Can be customized into monitoring products tailored to enterprise needs (e.g., database management platforms, hardware management platforms, unified monitoring platforms).

II. Advantages of Lerwee Monitoring

1. 1.1 Deployment Architecture1.1.1 BackgroundPrior to Zabbix Server 6.0, there was no high-availability architecture, and Zabbix Proxy still lacks one to this day. The traditional architecture is as follows:1.1.2 Optimization1.1.2.1 Distributed HA ArchitectureLerwee provides an HA architecture and distributed web interface for Zabbix deployment components and Zabbix high availability. The architecture is as follows:1.1.1.1 Multi-Server ArchitectureThe monitoring system adopts a multi-server architecture mode, supporting horizontal expansion of monitoring servers. The underlying data collection is separated to provide independent monitoring services. Specific requirements include:
   1. Compatibility with open-source solutions to fully leverage their powerful monitoring and data collection capabilities.
   2. For Zabbix_Server, establish server creation rules based on regional, object type, and business type dimensions. Support subsequent addition of Zabbix_Servers according to expansion rules. Implement a multi-server architecture based on Zabbix to resolve the performance bottlenecks of the existing architecture.
   3. Data Warehouse Construction: Establish a data warehouse based on OLAP characteristics and the characteristics of monitoring data types. Meet the needs of operations and maintenance reporting queries while storing raw data to provide a data foundation for subsequent big data and intelligence applications. The data warehouse adopts a distributed storage approach, supporting flexible horizontal expansion and retaining raw data for over three years.
   4. The upper-level platform functions adopt a modular deployment approach, allowing individual modules to be released and updated without affecting global functionality. Function modules are flexibly allocated based on usage and resource consumption, while the upper layer supports the flexible insertion of other functions in the future.
   Server Interface Configuration:
2. 1.2 Performance Bottlenecks1.2.1 BackgroundCommon defects in the underlying functions of Zabbix Server that have not been optimized include:
   1. Zabbix’s use of MySQL can lead to performance bottlenecks in data processing.
   2. Some built-in interfaces in Zabbix, such as SNMP and IPMI, are single-request interfaces, causing a surge in request numbers and unstable monitoring value retrieval for devices with poor performance.
   3. If certain devices monitored by Zabbix experience prolonged request actions (due to device load, poor interface performance, or script quality), it can affect the entire system, leading to busy processes, soaring queues, and widespread data collection failures.
   4. The active collection time of Zabbix Agent is not synchronized with the Zabbix Server, easily causing false alarms.
   5. It is unclear whether Zabbix objects have successfully collected data.
   6. Abnormal shutdowns of Zabbix can trigger alarm storms.
   1.2.2 OptimizationThe underlying functions of Lerwee have been optimized as follows:
   1. Table partitioning, database sharding, migration to time-series databases, and data offloading.
   2. Targeted elimination of the drawbacks of numerous requests, converting scripts into single requests to reduce connection requests.
   3. Setting timeout periods and request counts, executing data requests in the background as needed.
   4. Unified NTP and modification of some indicator modes.
   5. Custom interface collection of health status.
   6. Built-in alarm dependencies and alarm convergence.

The above is a comparative analysis of the architecture and performance of Lerwee Monitoring and Zabbix.