How Guming’s Front‑End Data Center Enables Real‑Time Monitoring for Web, Mini‑Programs, Flutter & Node.js

Introduction

Guming's front‑end data center provides monitoring, performance, logging, and event‑tracking capabilities, supporting mini‑programs, web, Flutter clients, and Node.js services.

Feature Design

The system is divided into eight major modules covering all front‑end data needs, hence the name “Big Front‑End Data Center”.

Architecture Design

The platform must satisfy several requirements due to heavy data reporting and analysis:

Real‑time : rapid anomaly detection and alerting.

High Availability : reliable clusters with fast recovery and disaster‑recovery.

Stability : elasticity to handle high concurrency and traffic spikes.

High Throughput : ability to ingest large volumes of logs and event data.

Client Fault Tolerance : SDK errors should not affect business operations.

The initial architecture is illustrated below:

Client SDK

We implement resource sampling to reduce server load for normal requests, loads, and performance data, while allowing full‑volume reporting when needed. Configuration options such as sampling rate, upload switches, queues, and channels are also supported.

Data Gateway

The gateway also supports server‑side sampling, offering more precise and real‑time control compared with client sampling.

Data Sharding

Data is split into three channels to meet different business needs:

Big Data Channel : for event‑based business analysis.

Real‑Time Computing Channel : for real‑time metrics such as product creation charts.

Persistence Channel : writes data to an Elasticsearch cluster for later querying and analysis.

Event Tracking Analysis

Beyond standard error and performance monitoring, we provide a custom chart creation feature that lets product teams define and view analysis charts directly after defining event points.

Previously, the workflow required product → developer → data platform → chart creation. Now product teams can self‑service event definitions and instantly generate charts.

Technical capabilities supporting this include:

Pre‑parsing : real‑time computed metrics enable chart rendering within tens of milliseconds (direct InfluxDB queries).

Historical Data Analysis : slower real‑time analysis of non‑pre‑computed data via Elasticsearch.

For the web side we also provide point management , event management , and attribute management .

Log Query

SDKs can report logs using the logger API, which automatically captures context and can associate user event data.

logger().debug(`xxxxx`)
logger().warn(`xxxxx`)
logger().error(`xxxxx`)
logger().info(`xxxxx`)

On the platform side logs can be searched by event, environment, user, content, or specific device (planned).

Data Correlation

All data is linked; logs can be correlated using identifiers such as userId or traceid to trace requests, events, errors, and more.

This enables end‑to‑end troubleshooting across logs, code errors, and request failures.

Node.js Module

The Node.js SDK is a standalone module integrated into the framework, offering CPU analysis, GC monitoring, and service data tracking.

CPU Analysis

We use the 0x flame‑graph profiler (GitHub ‑ davidmarkclements/0x). CPU data is collected via a C++ V8 extension and visualized with:

node node_modules/0x/cmd.js --visualize-cpu-profile

Collection flow:

// v8::CpuProfiler instance
static CpuProfiler *current_cpuprofiler = CpuProfiler::New(Isolate::GetCurrent());

// Start v8 CPU profiling
void StartCpuProfiling(const FunctionCallbackInfo<Value> &info) {
    HandleScope scope;
    Local<String> profilerTitle = New<String>("cpu_profiler").ToLocalChecked();
    current_cpuprofiler->StartProfiling(profilerTitle, true);
}

// Stop v8 CPU profiling
void StopCpuProfiling(const FunctionCallbackInfo<Value> &info) {
    HandleScope scope;
    const CpuProfile *profile = current_cpuprofiler->StopProfiling(profilerTitle);
    // - further processing of profile data
}

GC Analysis

GC data is also collected via a C++ V8 extension:

NAN_GC_CALLBACK(GCTracerPrologueCallback) {
    // - record GC start
}

NAN_GC_CALLBACK(GCTracerEpilogueCallback) {
    // - record GC end
}

void StartGC(const FunctionCallbackInfo<Value> &info) {
    // - initialization steps
    InitGcStatusHooks(); // - init
    AddGCPrologueCallback(GCPrologueCallback);
    AddGCEpilogueCallback(GCEpilogueCallback);
}

void StopGC(const FunctionCallbackInfo<Value> &info) {
    RemoveGCPrologueCallback(GCPrologueCallback);
    RemoveGCEpilogueCallback(GCEpilogueCallback);
    RemoveGcStatusHooks();
    // - cleanup steps
}

Collected data is uploaded to OSS, then parsed for charting and analysis.

Conclusion

The Guming Big Front‑End Data Platform is newly launched and already essential, yet it continues to evolve to support business governance. This article provides a brief overview; feedback and discussion are welcome.