- Seata, as an integrated data consistency framework, will minimize the use of third-party dependencies to reduce the risk of conflicts in the Metrics module.
- The Metrics module will strive for higher measurement performance and lower resource overhead, minimizing side effects when enabled.
- When configuring, whether Metrics is activated and how data are published depend on the corresponding configuration; enabling configuration will automatically activate Metrics and publish measurement data to Prometheus.
- Using Service Provider Interface (SPI) for loading extensions instead of Spring.
- Initially, only core Transaction-related metrics will be published, and all other operational metrics will be gradually improved based on community needs.
It consists of two core API modules,
seata-metrics-core, as well as N implementation modules such as
- seata-metrics-api Module
This module is the core of Metrics and is part of the Seata infrastructure, referenced by TC, TM, and RM. It does not contain any specific implementation code, but it only includes interface definitions, including:
- Meter class interfaces:
- Registry container interface
- Measurement publishing interface
Note: There are many existing implementations of Metrics in the open-source community, such as
- seata-metrics-core Module
This core module of Metrics organizes (loads) one Registry and N Exporters based on configuration.
- seata-metrics-registry-compact Module
This is the default (built-in) Registry implementation we provide.Instead of using other open-source Metrics libraries, it provides lightweight implementations of four types of Meters:
- seata-metrics-exporter-prometheus Module
This is the default Metrics implementation we provide. Without using other open-source Metrics implementations, it provides lightweight implementations of three types of Meters:
|Single latest value meter
|Single accumulating meter, can increase or decrease
|Multi-measurement output counter, outputs
tps (total per second) with no units
|Multi-measurement output timer, outputs
average, supports accumulation in microseconds
- More complex meters such as Histogram may be added in the future. Histogram is a type of meter that locally aggregates 75th, 90th, 95th, 98th, 99th, 99.9th, etc., and is suitable for certain scenarios but requires more memory.
- All meters inherit from Meter, and after executing the measure() method, all meters will generate 1 or N normalized Measurement results.
It also implements an in-memory Registry and Prometheus Exporter to synchronize measurement data with Prometheus.
Note: Different monitoring systems have different ways of collecting measurement data. For example, Zabbix supports pushing with zabbix-agent, while Prometheus recommends using prometheus-server pulling. Similarly, data exchange protocols are also different, so adaptation is often needed one by one.
How to Use
If you need to enable TC Metrics, you need to add configuration items in its configuration file:
Take file.conf for example
## metrics settings
enabled = true
registryType = "compact"
# multi exporters use comma divided
exporterList = "prometheus"
exporterPrometheusPort = 9898
Or You can use application.yaml for versions above 1.5.0
Or You can also use a third-party configuration center such as nacos, apollo, etc.
Please refer to here to upload the seata metrics configuration items to the corresponding configuration center, or open the corresponding configuration center console for manually adding.
After starting TC, you can get the text format data of Metrics on
9898is used by default, and the list of ports registered by Prometheus can be visited here. If you want to change this port, you can use
metrics.exporter.prometheus.portto modify the configuration.