Background

Currently, many large and medium-sized enterprises, such as major domestic banks (e.g., Bank of China, Agricultural Bank of China, Industrial and Commercial Bank of China, China Construction Bank, etc.), certain joint-stock banks (e.g., China Merchants Bank, Everbright Bank, etc.), and city commercial banks, utilize traditional monitoring software like IBM Tivoli Monitoring (ITM). However, with diminishing vendor support and the need to meet national-level localization requirements, many are considering replacing these solutions with open-source products like Zabbix. How does Lerwee Intelligent Monitoring, which elevates open-source capabilities from a score of 30 to 100, perfectly replace Tivoli? This analysis will compare and contrast the two from several perspectives: monitoring types, collection methods, deployment structures, alert management, front-end presentation, threshold configuration, data processing, permission control, local services, and indicator volumes.

Comparison Between Lerwee Monitoring and Tivoli

Lerwee Intelligent Monitoring Platform is a deeply customized product based on open-source enterprise-level monitoring software. Building on its original efficient collection capabilities and flexible notification mechanisms, and leveraging Lerwee’s years of industry experience and profound understanding of operations and maintenance, it centers on users and scenarios. With a brand-new UI design in a minimalist style, it offers more convenient operations and comprehensive functions. Its basic monitoring (ITIM) capabilities include intelligent monitoring of storage, network devices, servers, operating systems, middleware, databases, virtualization, cloud computing, containers, IoT devices, and applications, meeting the operational management needs of various industries.

IBM Tivoli Monitoring software’s basic architecture consists of the Tivoli Enterprise Portal Client and three servers (Tivoli Data Warehouse, Tivoli Enterprise Portal Server, and Tivoli Enterprise Monitoring Server).

Since the early 2010s, under the influence of open-source technological advancements, Lerwee has embraced open-source as its foundation and, with a new product mindset, elevated open-source solutions to a perfect enterprise-level delivery. Lerwee Intelligent Monitoring undergoes annual updates and iterations, better aligning with current and future enterprise needs. In contrast, Tivoli pales in comparison.

Monitoring Type Comparison

Lerwee Monitoring

• Offers strong comprehensiveness, openness, and scalability in monitoring.
• Supports monitoring of various device types, including operating systems, databases, middleware, network devices, servers, storage, cloud, web, links, and dynamic environmental monitoring, demonstrating powerful monitoring capabilities.

Tivoli

• Weak support for community-edition operating systems like CentOS.
• Limited database support (does not support non-relational databases like MongoDB, Elasticsearch).
• Weak middleware support (e.g., MQ, Weblogic, Websphere; open-source MQs like ActiveMQ and RabbitMQ have limited support), especially for localized types.

Collection Method Comparison

Lerwee Monitoring

• Open and flexible at the底层 (low-level), integrating multiple collection schemes.
• Supports various collection methods, with collection processes and calculations understandable via scripts or commands.
• Autonomous and controllable, allowing timely modifications if errors occur.
• Agent size is only 10M, with typical memory consumption around 7M.

Tivoli

• Built-in agent with closed-source limitations, preventing visibility into specific indicator collection methods and calculations.
• Requires submitting issues to the vendor for incorrect indicator collections, with patches provided afterward.
• Agent size reaches 700M, with resident memory consumption around 100M.

Deployment Structure Comparison

Lerwee Monitoring

• Supports high-availability architectures (including collection servers, web servers, database servers, and proxy servers).
• Utilizes distributed proxy servers to reduce collection pressure on servers and enable horizontal scalability, allowing the monitoring platform to manage more nodes.
• Supports multi-server architectures for unified and individual management.

Tivoli

• HUB central servers adopt a primary-backup mode, with horizontal scalability achieved through multiple Remote servers to support more nodes and devices while distributing HUB central server data processing pressure.

Alert Management Comparison

Lerwee Monitoring

• Strong controllability: Indicator items can be grouped, merged, calculated, and compared.
• Supports alert dependencies, convergence, and suppression.

Tivoli

• When configuring threshold alerts, Tivoli can only compare indicator items within the same attribute group and cannot cross attribute groups (e.g., CPU and memory indicators belong to different groups and cannot be configured under the same alert scenario).

Front-End Presentation Comparison

Lerwee Monitoring

• Simple and user-friendly interface developed with PHP.
• Supports customizable homepage content, different homepage style switching, and over ten types of Top N statistics (e.g., CPU, memory, port traffic).
• Provides business topology, network topology, projection views, panoramic business walls, and customizable reporting statistics.

Tivoli

• Java-developed front-end requiring Java support, with an unfriendly interface and inadequate data presentation, unsuitable for the current internet’s minimalist style.

Threshold Configuration Comparison

Lerwee Monitoring

• Supports up to 29 trigger functions, including numerical comparisons, no-data monitoring, inclusion, regular expression matching, attribute function operations, trend prediction, and date judgment.
• Allows calculation and comparison of any indicator items within the same trigger, with trigger expressions supporting arithmetic operations and alert dependencies and correlations.

Tivoli

• Limited operability, supporting numerical comparisons, missing item detection, inclusion, and attribute function operations (e.g., sum, count, avg).
• Supports trend prediction (requiring SPSS data analysis product, which is收费 (paid)), scenario correlations (cumbersome configuration), and logical operations on attributes.

Data Processing Comparison

Lerwee Monitoring

• Adopts time-series databases for higher data ingestion rates, faster queries, and stronger cascading storage.

Tivoli

• Limited to relational databases like Oracle or DB2, presenting performance bottlenecks.

Permission Control Comparison

Lerwee Monitoring

• Provides comprehensive permission management functions, supporting enterprise-level organizational structure settings and customizable role groups and roles.
• Allows assigning specific monitoring objects to different users with varying permissions (e.g., view, delete, add, modify, import/export).

Tivoli

• Supports role-based permission division, controlling servers managed by roles through logical views.
• Requires manual addition of servers to views when new servers are added, making management cumbersome.

Local Services Comparison

Lerwee Monitoring

• Continuous community iteration and rapid service response capabilities, enabling quick product iterations.

Tivoli

• Weakened technical support services and slow product upgrades, struggling to keep pace with evolving technological landscapes.

Case Study: Lerwee Monitoring Replacing Tivoli at a Bank

Customer Background

The bank’s IT infrastructure has been expanding rapidly, leading to an increase in corresponding failures. Before adopting effective management methods, relevant departments relied on traditional, dispersed, and inconsistent manual management approaches without a professional team for unified IT system hardware and software management. Responsibilities for construction, operation, and support were not clearly delineated, lacking effective management and operational monitoring means, as well as efficient asset management for devices/facilities. The creation of management tools lagged behind construction efforts, resulting in a conflict between management models and system construction.

The bank’s existing production monitoring system, developed in 2011 and primarily based on IBM’s commercial product Tivoli, has been in use for seven years. Derivative developments, including centralized alerting, automated operations and maintenance, and large-screen displays, were built upon it. To address these issues, an upgrade to the basic monitoring platform system was necessary to resolve current monitoring system problems, improve operational efficiency, and reduce operational risks.

Lerwee Monitoring Solution

Lerwee Monitoring, considering the bank’s development status and needs, managed all hardware and software devices, comprehensively presenting operational management data and related statistical information through an integrated platform. It enabled effective and timely fault information delivery via flexible alerting devices, precise alert detection, diverse alerting methods, and simple alert experience accumulation. It provided rapid fault localization and analysis, ultimately meeting IT operations and maintenance management requirements:

1. The basic monitoring platform needed to perform real-time monitoring of production system servers, operating systems, databases, middleware, storage, and network devices, ensuring timely alerts and operations during failures.
2. It required an aesthetically pleasing display interface and user-friendly UI, with large-screen display capabilities reflecting system operational status and alert information clearly.
3. While completing basic monitoring items, it needed to customize development for the bank’s specific requirements, configure relationships between monitoring items, and generate performance analysis and fault reports.
4. The basic monitoring platform needed to integrate alert information into a unified display interface (consistent with existing system integration methods).

Implementation

Addressing the bank’s challenges, Lerwee Intelligent Monitoring utilized open-source technologies and its product’s high availability, scalability, and ease of maintenance to monitor the bank’s IT assets, distribute alerts, and automate operations and maintenance processing.

Overall Architecture

System Performance Requirements

• After entering the website URL, the time to access the application system should not exceed 3 – 5 seconds.
• After entering (modifying) all the indicator information, the time from submission to response should not exceed 5 seconds.
• For simple queries, the average time from submitting the query conditions to receiving a response should not exceed 10 seconds; for complex queries, the average time should not exceed 60 seconds.
• Under the expected peak load conditions (with a maximum of 1000 concurrent system users), 10% of the processor capacity and 15% of the system’s available memory should be reserved as a buffer. Occasionally, the processor can run at full load (100%) for no more than 30 seconds.

Security Requirements

• During system operations, it is essential to ensure the accuracy, integrity, security, and consistency of data manipulation.
• Appropriate encryption/decryption techniques should be employed during data transmission to prevent data loss, distortion, theft, or tampering, especially when accessing data over the Internet. Additionally, the system should automatically disconnect when there is no user operation for a certain period.
• Data should be stored on relatively secure hardware devices. Regular backups of the stored data should be performed, and the backup data should be restorable as needed. Data backups and program backups should be carried out separately.
• The system should have flexible permission-setting functions, allowing system administrators to assign data query, modification, and other permissions to each user at the functional level as required.
• It should have a function to check permission settings. The roles of setting permission settings and checking them should be implemented by different roles. Users with the role of checking permission settings should not be able to set user permissions.

Unified Object Control and Centralized Management

1. Host Monitoring: RedHat, Windows, AIX, HMC
   • Monitoring AIX minicomputer LPAR information, JFS file systems, errpt log information, LVM information is different from that of Linux.
   • Management of AIX’s HMC data resources.
   • Monitoring of firewall status and application services.
2. Network Device Monitoring: Cisco, H3C, Huawei, F5, Maipu, Hillstone, Sangfor
   • F5’s hierarchical division, master-slave status, configuration synchronization, active connection numbers, and pools.
   • Monitoring of SDN-spine and SDN-leaf.
   • Integration of network device syslog logs.
   • Display of daily inspection reports for network devices.
   • Different methods of link detection (NQA, SQA) and login interaction detection.
3. Virtualization Monitoring: VMWARE
   • Monitoring of Clusters, Datacenters, Datastores, Hypervisors, and VMs.
   • Integration of Vcenter platform alarms.
   • The interrelated status of Clusters, Datacenters, Datastores, Hypervisors, and VM resources.
   • Integration of modules with the monitoring platform.
   • Message and queue processing and integration.
4. Database Monitoring: Oracle, DB2, Mysql, Redis
   • SQL ranking by time.
   • Redo log.
   • Database dataguard status and log synchronization status.
5. Middleware Monitoring: Weblogic, Tomcat, Nginx, Rabbitmq, ZooKeeper, Websphere
   • Interface integration.
   • Console data collection.
   • Maximum connection number and current connection number.
   • Health status.
   • Thread pool status.
   • Server status.
6. Storage Monitoring: EMC VNX, EMC VMAX, Netapp
   • Specialized storage tools should be used to connect and query data.

Virtualization Monitoring Solution

vPoller is a distributed VMware vSphere API proxy designed for discovering and polling vSphere objects. It utilizes the VMware vSphere API to perform the discovery and polling of vSphere objects.

vPoller employs the ZeroMQ messaging library to distribute tasks among workers and achieve load balancing for client requests.

vPoller can be integrated with other systems that require access to vSphere objects but lack native support for it.

The proposed solution using vPoller is to integrate it with the Lewei monitoring system during the discovery and polling processes to provide monitoring of the VMware vSphere environment.