How G Bank Scaled Monitoring with Zabbix: Architecture & Automation

1. Zabbix Monitoring Background

As G Bank’s business grew rapidly, the cost of monitoring and management rose sharply, and existing commercial monitoring tools could no longer meet the requirements. To reduce monitoring costs and improve automation and autonomy, the bank launched an open‑source monitoring project based on Zabbix.

Commercial monitoring software often brings management pain points. After evaluating several open‑source solutions for flexibility, compatibility, and ease of use, Zabbix was selected for its multi‑platform support, complex conditional alerts, rich API for secondary development, auto‑discovery, and strong community resources.

2. Project Overview

The project started with monitoring of development and testing environments, then expanded to head‑office and branch production systems, ultimately replacing traditional commercial tools with a unified, automated platform. The implementation is described across five aspects: deployment architecture, support for open‑source/Xinchuang ecosystems, data collection methods, alert strategy, and automation.

2.1 Deployment Architecture

A distributed Server‑Proxy‑Agent architecture is used, with multiple Zabbix instances for head‑office, branches, production, and testing to reduce server load.

Development & testing: automatic discovery + registration for short‑lived hosts.

Head‑office production: hosts grouped by type, each proxy handling specific responsibilities to balance load.

Branch production: central Zabbix Server at head‑office; each branch deploys an independent proxy (containerized for flexibility), with compressed and encrypted data transfer between proxy and server.

2.2 Support for Open‑Source & Xinchuang

Zabbix’s open‑source nature allows full monitoring of domestic (Xinchuang) products, including:

Operating systems: Kylin Linux, Kylin ARM.

Databases: Dameng, MySQL, Kingbase.

Middleware: Baolande, Nginx, RocketMQ.

Big‑data components: Kafka, Spark, Elasticsearch.

2.3 Data Collection Methods

Zabbix supports a variety of collection techniques that can be customized per item:

Agent, SSH, or WMI to monitor server software.

DBforBix plugin, JDBC, or Agent for databases.

JMX or T3 protocol for Java services.

Ping and web checks for web applications.

Log monitoring for proactive anomaly detection. system.run to invoke existing scripts and tools.

Pre‑processing and parsing to reuse collected data for multiple purposes, improving efficiency and reducing target load.

2.4 Alert Strategy

Zabbix can send alerts via email, SMS, WeChat, or API. The bank calls the Zabbix API to retrieve alert data, performs rule‑based parsing and enrichment, and forwards the processed alerts to a unified monitoring management platform for centralized display and handling.

2.5 Automation

Standardized data‑center management underpins monitoring automation. Key automated capabilities include:

One‑click deployment of Zabbix Agent via SMDB or scripts.

Agent auto‑start, health checks, remote restart, and disable.

Low‑level discovery (LLD) of partitions, NICs, and customizable discovery of databases or middleware instances.

Automatic registration of new devices, host creation, template association, and monitoring activation.

Bulk host addition and template linking through the API.

Unified templates combined with composite trigger rules to cover diverse scenarios.

Simple self‑healing: classify and grade alerts, then execute remediation scripts (e.g., file cleanup, service restart) automatically when conditions are met.

3. Phase Results

After four development phases, the bank achieved full coverage of commercial software monitoring, enhanced open‑source monitoring capabilities, and self‑service monitoring. Zabbix now monitors the development/testing environment, the head‑office, and all 39 branches, providing fine‑grained monitoring of HPUX production systems and replacing commercial tools.

4. Summary & Outlook

Digital banking relies on robust technology support. The bank will continue to follow emerging technologies, strengthen infrastructure and architecture, and provide comprehensive monitoring for new tech stacks. Future directions include shifting monitoring mindset toward data‑driven services, leveraging big‑data and machine‑learning for intelligent alert root‑cause analysis, dynamic baselines, and predictive monitoring, while maintaining continuous technical innovation and standardized, self‑service monitoring operations.