How Standardized Application Monitoring Boosts Operational Efficiency

Introduction

Application monitoring is a critical component of the overall monitoring system. Because of the diversity and complexity of application systems, implementing comprehensive monitoring is a shared challenge for operations staff and monitoring administrators. G Bank’s years of practice have shown that standardizing application monitoring is a powerful solution for effective monitoring in complex IT environments and forms the basis for digital and intelligent monitoring.

1. Content and Significance of Monitoring Standardization

Definition of Application Systems – An application system consists of hardware, system software, and application software. While hardware, OS, databases, and middleware have relatively high standardization, application software varies widely and requires unified monitoring standards to ensure business continuity.

Scope of Monitoring Standardization – Standardization covers the creation, publication, and implementation of standards, focusing on metric sets, monitoring objects, tools, and the resulting closed‑loop quantitative management. Logging and tracing standards are excluded.

Benefits

Ensures the “Three‑Early” principle (monitoring tools before operators, technology before business, bank before customers) by deploying standardized metric sets.

Elevates monitoring management by consolidating operational experience into organization‑wide practices.

Integrates monitoring work into development and testing phases, forming a management closed loop.

2. Traditional Environment Monitoring Standardization

Initially, each application was integrated separately, leading to unclear metrics, thresholds, and interfaces, and manual verification of monitoring status. Standardization is needed to improve coverage, normalize processes, and increase implementation efficiency.

Monitoring Standardization Model

Monitoring Object : The application component whose state and performance need to be observed.

Monitoring Metric : Data that reflects the object's state.

Monitoring Policy : Standards for evaluating metric health.

Monitoring Tool : Technology used to collect metrics from the object.

Monitoring Rule : Guidelines derived from operational experience and best practices to deploy policies and audit their execution.

Application Monitoring Object Model

Key Monitoring Components and Metrics

Infrastructure Layer

Network – TCP long‑connection count and buffer queue depth to detect connection interruptions or processing bottlenecks.

File – Detection of abnormal or missing files (e.g., core dumps, .err files) and unprocessed timeout files.

Memory – GC cycles per minute and direct memory usage rate for Java applications.

Application Component Layer

API Calls – Monitoring errors and timeouts for external APIs such as encryption, Redis, or MQ.

Queue – Monitoring queue depth to identify performance bottlenecks.

Service Layer

Scheduled Tasks – Failure or timeout rates of batch jobs.

Application Health – Liveness checks via HTTP or transaction probes.

Business Services – Transaction success rate, response time, volume, and related metrics for online transaction systems.

3. Distributed Application Monitoring Standardization

With the rise of containers, micro‑services, and distributed deployments, traditional monitoring faces challenges such as numerous open‑source components, elastic scaling, and CI/CD pipelines. G Bank extends its standardization model to support distributed environments.

Distributed Monitoring Model

Distributed Metric Reference

Standardizing metrics is the core of distributed monitoring. G Bank adopts Google’s “golden metric” concept, illustrated in the following diagram.

Principles for Distributed Metric Definition

Layered classification – collaborative enrichment by monitoring and domain teams.

Uniform standards – consistent metrics across traditional and container platforms.

Cross‑type benchmarking – align new objects with existing similar ones.

Agile iteration – continuously supplement and refine standards based on incident analysis.

Distributed Monitoring Model

The model adds micro‑service components (service registry, config center, API gateway) and distributed components (distributed cache, batch, messaging, databases) to the traditional monitoring framework.

Distributed Metric Ingestion

Metrics follow the Prometheus exposition format:

<metric_name>{<label_name>=<label_value>, ...} <value>

Metric name describes the sample, labels provide dimensions for filtering and aggregation, and the value is the measured data.

Two exposure methods are supported:

Applications built on G Bank’s common development platform include a built‑in monitoring SDK that automatically exposes metrics for standard frameworks such as Spring Boot.

Other applications must implement a Prometheus client SDK or Spring Boot Actuator to expose metrics according to the standard.

Tag‑Based Automated Deployment

Each monitoring object is assigned a set of tags that map to standard metrics and policies, forming a “standardized monitoring rule.” Tags enable:

Targeted queries.

Rich aggregation and filtering.

Discovery of services with specific annotations.

Adding HTTP query parameters to scrape requests.

Storing only selected sample subsets.

Merging two label values into one.

Quantitative Monitoring Evaluation

Effectiveness is measured by discovery rate, alarm compression, root‑cause location rate, as well as coverage and standardization rates. The standardization rate is calculated as:

Monitoring Standardization Rate = (Monitoring Archive / Monitoring Standard) * 100%

where

Monitoring Archive = Σ (monitoring object × deployed standard policies)

Monitoring Standard = Σ (monitoring object × required standard policies)

Applying this formula yields a standardization rate for each application system, highlighting gaps and guiding corrective actions.

Conclusion and Outlook

Through years of practice, G Bank has built a comprehensive model for application monitoring standardization, covering traditional and distributed environments, metric sets, and closed‑loop quantitative management. Future work will expand metric collections, adopt non‑intrusive data acquisition, and support self‑service monitoring configuration to further enhance monitoring capabilities.