You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
java-tron currently maintains two parallel monitoring systems: Prometheus and MetricsUtil + InfluxDB, leading to fragmented metrics and high maintenance cost. It is proposed to remove InfluxDB storage and standardize on Prometheus as the unified monitoring interface, reducing system complexity and improving observability.
Problem
Motivation
Real-time monitoring is critical for operating and maintaining java-tron nodes. A standard FullNode needs to monitor synchronization status (block height, lag) and API availability; SR nodes additionally need to track missed blocks, block production stability, and latency. The coexistence of two monitoring systems leads to resource waste and cognitive overhead for users.
Current State
java-tron currently provides two mechanisms for exposing monitoring metrics:
Prometheus Mode (mainstream)
Exposes metrics via /metrics (default: localhost:8545)
External systems (Prometheus + Grafana) handle collection, storage, visualization, and alerting
Implementation located at: org.tron.common.prometheus
MetricsUtil + InfluxDB Mode (legacy)
Uses io.dropwizard.metrics:metrics-core to collect metrics
Exposes metrics via HTTP endpoint /wallet/monitor/getstatsinfo (default: localhost:8090)
Supports periodic writes to InfluxDB
Implementation located at: org.tron.core.metrics.MetricsUtil
Limitations or Risks
Fragmented metrics system: Two parallel systems result in inconsistent metric definitions, increasing development, maintenance, and user understanding costs
Insufficient granularity in MetricsUtil: Incomplete coverage (missing dimensions such as chain sync, network, DB, JVM), coarse granularity, and lack of labels, making it unsuitable for fine-grained monitoring (per-peer, per-API), performance bottleneck analysis, and alerting
Limited applicability of InfluxDB: Isolated from the Prometheus ecosystem, requires additional deployment, increases operational complexity, lacks mature dashboards and alerting rules, and has low adoption in the community
Unclear responsibility boundaries: MetricsUtil + InfluxDB acts as a lightweight data sink, blurring the boundary between monitoring metrics (system behavior description) and business data storage
Proposed Solution
Proposed Design
Streamline and simplify the java-tron monitoring system in three steps:
Remove InfluxDB storage: Remove InfluxDB storage from MetricsUtil, stop maintaining related configuration, and enforce separation between monitoring and business data
# influxdb metrics
storageEnable = false # Whether write metrics data into InfluxDb. Default: false.
influxdb {
ip = ""
port = 8086
database = ""
metricsReportInterval = 10
}
API Changes: /wallet/monitor/getstatsinfo remains but is downgraded to an auxiliary interface and no longer recommended as the primary monitoring endpoint
Impact
Stability: Removing InfluxDB write logic reduces external dependencies and lowers the risk of node instability caused by InfluxDB connectivity issues
Developer Experience: Unifies the monitoring interface and reduces cognitive overhead; the community can directly reuse Grafana dashboards and alerting rules from tron-docker, avoiding duplicated effort
Backward Compatibility
Breaking Change: Yes — InfluxDB storage for metrics will be removed
Default Behavior Change: Nodes using InfluxDB will no longer have this functionality after upgrade
Migration Required: Yes — Migration documentation (InfluxDB → Prometheus) will be provided; users are encouraged to adopt the tron-docker solution. InfluxDB will be marked as deprecated for one or more release cycles before complete removal
Summary
java-tron currently maintains two parallel monitoring systems: Prometheus and MetricsUtil + InfluxDB, leading to fragmented metrics and high maintenance cost. It is proposed to remove InfluxDB storage and standardize on Prometheus as the unified monitoring interface, reducing system complexity and improving observability.
Problem
Motivation
Real-time monitoring is critical for operating and maintaining java-tron nodes. A standard FullNode needs to monitor synchronization status (block height, lag) and API availability; SR nodes additionally need to track missed blocks, block production stability, and latency. The coexistence of two monitoring systems leads to resource waste and cognitive overhead for users.
Current State
java-tron currently provides two mechanisms for exposing monitoring metrics:
Prometheus Mode (mainstream)
/metrics(default:localhost:8545)org.tron.common.prometheusMetricsUtil + InfluxDB Mode (legacy)
io.dropwizard.metrics:metrics-coreto collect metrics/wallet/monitor/getstatsinfo(default:localhost:8090)org.tron.core.metrics.MetricsUtilLimitations or Risks
Proposed Solution
Proposed Design
Streamline and simplify the java-tron monitoring system in three steps:
Remove InfluxDB storage: Remove InfluxDB storage from
MetricsUtil, stop maintaining related configuration, and enforce separation between monitoring and business dataStandardize on Prometheus as the monitoring interface: Continue improving metrics coverage across dimensions, such as [Feature] Add Prometheus metrics for empty blocks and SR set changes #6590; the community can refer to the existing implementation in tron-docker
Key Changes
org.tron.core.metrics.MetricsUtil(remove InfluxDB reporter logic)/wallet/monitor/getstatsinforemains but is downgraded to an auxiliary interface and no longer recommended as the primary monitoring endpointImpact
Backward Compatibility
References
Additional Notes
Yes
Yes