Along with IoTDB running, we hope to observe the status of IoTDB, so as to troubleshoot system problems or discover potential system risks in time. A series of metrics that can reflect the operating status of the system are system monitoring metrics.

1. When to use metric framework?

Belows are some typical application scenarios

  1. System is running slowly

    When system is running slowly, we always hope to have information about system’s running status as detail as possible, such as:

    • JVM:Is there FGC? How long does it cost? How much does the memory usage decreased after GC? Are there lots of threads?
    • System:Is the CPU usage too hi?Are there many disk IOs?
    • Connections:How many connections are there in the current time?
    • Interface:What is the TPS and latency of every interface?
    • Thread Pool:Are there many pending tasks?
    • Cache Hit Ratio
  2. No space left on device

    When meet a “no space left on device” error, we really want to know which kind of data file had a rapid rise in the past hours.

  3. Is the system running in abnormal status

    We could use the count of error logs、the alive status of nodes in cluster, etc, to determine whether the system is running abnormally.

2. Who will use metric framework?

Any person cares about the system’s status, including but not limited to RD, QA, SRE, DBA, can use the metrics to work more efficiently.

3. What is metrics?

3.1. Key Concept

In IoTDB’s metric module, each metrics is uniquely identified by Metric Name and Tags.

  • Metric Name: Metric type name, such as logback_events means log events.
  • Tags: indicator classification, in the form of Key-Value pairs, each indicator can have 0 or more categories, common Key-Value pairs:
    • name = xxx: The name of the monitored object, which is the description of business logic. For example, for a monitoring item of type Metric Name = entry_seconds_count, the meaning of name refers to the monitored business interface.
    • type = xxx: Monitoring indicator type subdivision, which is a description of monitoring indicator itself. For example, for monitoring items of type Metric Name = point, the meaning of type refers to the specific type of monitoring points.
    • status = xxx: The status of the monitored object is a description of business logic. For example, for monitoring items of type Metric Name = Task, this parameter can be used to distinguish the status of the monitored object.
    • user = xxx: The relevant user of the monitored object is a description of business logic. For example, count the total points written by the root user.
    • Customize according to the specific situation: For example, there is a level classification under logback_events_total, which is used to indicate the number of logs under a specific level.
  • Metric Level: The level of metric managing level, The default startup level is Core level, the recommended startup level is Important level, and the audit strictness is Core > Important > Normal > All
    • Core: Core metrics of the system, used by the operation and maintenance personnel, which is related to the * performance, stability, and security* of the system, such as the status of the instance, the load of the system, etc.
    • Important: Important metrics of the module, which is used by operation and maintenance and testers, and is directly related to the running status of each module, such as the number of merged files, execution status, etc.
    • Normal: Normal metrics of the module, used by developers to facilitate locating the module when problems occur, such as specific key operation situations in the merger.
    • All: All metrics of the module, used by module developers, often used when the problem is reproduced, so as to solve the problem quickly.

3.2. External data format for metrics

  • IoTDB provides metrics in JMX, Prometheus and IoTDB formats:
    • For JMX, metrics can be obtained through org.apache.iotdb.metrics.
    • For Prometheus, the value of the metrics can be obtained through the externally exposed port
    • External exposure in IoTDB mode: metrics can be obtained by executing IoTDB queries

4. The detail of metrics

Currently, IoTDB provides metrics for some main modules externally, and with the development of new functions and system optimization or refactoring, metrics will be added and updated synchronously.

If you want to add your own metrics data in IoTDB, please see the [IoTDB Metric Framework] (https://github.com/apache/iotdb/tree/master/metricsMetric Tool - 图1open in new window) document.

4.1. Core level metrics

Core-level metrics are enabled by default during system operation. The addition of each Core-level metrics needs to be carefully evaluated. The current Core-level metrics are as follows:

4.1.1. Cluster

MetricTagsTypeDescription
config_nodename=”total”,status=”Registered/Online/Unknown”AutoGaugeThe number of registered/online/unknown confignodes
data_nodename=”total”,status=”Registered/Online/Unknown”AutoGaugeThe number of registered/online/unknown datanodes
pointsdatabase=””, type=”flush”GaugeThe point number of last flushed memtable

4.1.2. IoTDB process

MetricTagsTypeDescription
process_cpu_loadname=”process”AutoGaugeThe current CPU usage of IoTDB process, Unit: %
process_cpu_timename=”process”AutoGaugeThe total CPU time occupied of IoTDB process, Unit: ns
process_max_memname=”memory”AutoGaugeThe maximum available memory of IoTDB process
process_total_memname=”memory”AutoGaugeThe current requested memory for IoTDB process
process_free_memname=”memory”AutoGaugeThe free available memory of IoTDB process

4.1.3. System

MetricTagsTypeDescription
sys_cpu_loadname=”system”AutoGaugeThe current CPU usage of system, Unit: %
sys_cpu_coresname=”system”GaugeThe available number of CPU cores
sys_total_physical_memory_sizename=”memory”GaugeThe maximum physical memory of system
sys_free_physical_memory_sizename=”memory”AutoGaugeThe current available memory of system
sys_total_swap_space_sizename=”memory”AutoGaugeThe maximum swap space of system
sys_free_swap_space_sizename=”memory”AutoGaugeThe available swap space of system
sys_committed_vm_sizename=”memory”AutoGaugeThe space of virtual memory available to running processes
sys_disk_total_spacename=”disk”AutoGaugeThe total disk space
sys_disk_free_spacename=”disk”AutoGaugeThe available disk space

4.2. Important level metrics

4.2.1. Cluster

MetricTagsTypeDescription
cluster_node_leader_countname=”:”GaugeThe count of consensus group leader on each node
cluster_node_statusname=”:”,type=”ConfigNode/DataNode”GaugeThe current node status, 0=Unkonwn 1=online

4.2.2. Node

MetricTagsTypeDescription
quantityname=”database”AutoGaugeThe number of database
quantityname=”timeSeries”AutoGaugeThe number of timeseries
quantityname=”pointsIn”CounterThe number of write points
regionname=”total”,type=”SchemaRegion”AutoGaugeThe total number of SchemaRegion in PartitionTable
regionname=”total”,type=”DataRegion”AutoGaugeThe total number of DataRegion in PartitionTable
regionname=”:”,type=”SchemaRegion”GaugeThe number of SchemaRegion in PartitionTable of specific node
regionname=”:”,type=”DataRegion”GaugeThe number of DataRegion in PartitionTable of specific node

4.2.3. IoTConsensus

MetricTagsTypeDescription
mutli_leadername=”logDispatcher-:”, region=””, type=”currentSyncIndex”AutoGaugeThe sync index of synchronization thread in replica group
mutli_leadername=”logDispatcher-:”, region=””, type=”cachedRequestInMemoryQueue”AutoGaugeThe size of cache requests of synchronization thread in replica group
mutli_leadername=”IoTConsensusServerImpl”, region=””, type=”searchIndex”AutoGaugeThe write process of main process in replica group
mutli_leadername=”IoTConsensusServerImpl”, region=””, type=”safeIndex”AutoGaugeThe sync index of replica group
stagename=”iot_consensus”, region=””, type=”getStateMachineLock”HistogramThe time consumed to get statemachine lock in main process
stagename=”iot_consensus”, region=””, type=”checkingBeforeWrite”HistogramThe time consumed to precheck before write in main process
stagename=”iot_consensus”, region=””, type=”writeStateMachine”HistogramThe time consumed to write statemachine in main process
stagename=”iot_consensus”, region=””, type=”offerRequestToQueue”HistogramThe time consumed to try to offer request to queue in main process
stagename=”iot_consensus”, region=””, type=”consensusWrite”HistogramThe time consumed to the whole write in main process
stagename=”iot_consensus”, region=””, type=”constructBatch”HistogramThe time consumed to construct batch in synchronization thread
stagename=”iot_consensus”, region=””, type=”syncLogTimePerRequest”HistogramThe time consumed to sync log in asynchronous callback process

4.2.4. Cache

MetricTagsTypeDescription
cache_hitname=”chunk”AutoGaugeThe cache hit ratio of ChunkCache, Unit: %
cache_hitname=”schema”AutoGaugeThe cache hit ratio of SchemaCache, Unit: %
cache_hitname=”timeSeriesMeta”AutoGaugeThe cache hit ratio of TimeseriesMetadataCache, Unit: %
cache_hitname=”bloomFilter”AutoGaugeThe interception rate of bloomFilter in TimeseriesMetadataCache, Unit: %
cachename=”Database”, type=”hit”CounterThe hit number of Database Cache
cachename=”Database”, type=”all”CounterThe access number of Database Cache
cachename=”SchemaPartition”, type=”hit”CounterThe hit number of SchemaPartition Cache
cachename=”SchemaPartition”, type=”all”CounterThe access number of SSchemaPartition Cache
cachename=”DataPartition”, type=”hit”CounterThe hit number of DataPartition Cache
cachename=”DataPartition”, type=”all”CounterThe access number of SDataPartition Cache

4.2.5. Interface

MetricTagsTypeDescription
operationname = “”HistogramThe time consumed of operations in client
entryname=””TimerThe time consumed of thrift operations
thrift_connectionsname=”ConfigNodeRPC”AutoGaugeThe number of thrift internal connections in ConfigNode
thrift_connectionsname=”Internal”AutoGaugeThe number of thrift internal connections in DataNode
thrift_connectionsname=”MPPDataExchange”AutoGaugeThe number of thrift internal connections in MPP
thrift_connectionsname=”RPC”AutoGaugeThe number of thrift connections of Client
thrift_active_threadsname=”ConfigNodeRPC-Service”AutoGaugeThe number of thrift active internal connections in ConfigNode
thrift_active_threadsname=”DataNodeInternalRPC-Service”AutoGaugeThe number of thrift active internal connections in DataNode
thrift_active_threadsname=”MPPDataExchangeRPC-Service”AutoGaugeThe number of thrift active internal connections in MPP
thrift_active_threadsname=”ClientRPC-Service”AutoGaugeThe number of thrift active connections of client

4.2.6. Memory

MetricTagsTypeDescription
memname=”databaseAutoGaugeThe memory usage of DataRegion in DataNode, Unit: byte
memname=”chunkMetaData“AutoGaugeThe memory usage of chunkMetaData when writting TsFile, Unit: byte
memname=”IoTConsensus”AutoGaugeThe memory usage of IoTConsensus, Unit: byte
memname=”schema_region_total_usage”AutoGaugeThe memory usage of all SchemaRegion, Unit: byte
memname=”schema_region_total_remaining”AutoGaugeThe memory remaining for all SchemaRegion, Unit: byte

4.2.7. Task

MetricTagsTypeDescription
queuename=”compaction_inner”, status=”running/waiting”GaugeThe number of inner compaction tasks
queuename=”compaction_cross”, status=”running/waiting”GaugeThe number of cross compatcion tasks
cost_taskname=”inner_compaction/cross_compaction/flush”GaugeThe time consumed of compaction tasks
queuename=”flush”,status=”running/waiting”AutoGaugeThe number of flush tasks
queuename=”Sub_RawQuery”,status=”running/waiting”AutoGaugeThe number of Sub_RawQuery

4.2.8. Compaction

MetricTagsTypeDescription
data_writtenname=”compaction”, type=”aligned/not-aligned/total”CounterThe written size of compaction
data_readname=”compaction”CounterThe read size of compaction
compaction_task_countname = “inner_compaction”, type=”sequence”CounterThe number of inner sequence compction
compaction_task_countname = “inner_compaction”, type=”unsequence”CounterThe number of inner sequence compction
compaction_task_countname = “cross_compaction”, type=”cross”CounterThe number of corss compction

4.2.9. File

MetricTagsTypeDescription
file_sizename=”wal”AutoGaugeThe size of WAL file, Unit: byte
file_sizename=”seq”AutoGaugeThe size of sequence TsFile, Unit: byte
file_sizename=”unseq”AutoGaugeThe size of unsequence TsFile, Unit: byte
file_sizename=”inner-seq-temp”AutoGaugeThe size of inner sequence space compaction temporal file
file_sizename=”inner-unseq-temp”AutoGaugeThe size of inner unsequence space compaction temporal file
file_sizename=”cross-temp”AutoGaugeThe size of cross space compaction temoporal file
file_sizename=”modsAutoGaugeThe size of modification files
file_countname=”wal”AutoGaugeThe count of WAL file
file_countname=”seq”AutoGaugeThe count of sequence TsFile
file_countname=”unseq”AutoGaugeThe count of unsequence TsFile
file_countname=”inner-seq-temp”AutoGaugeThe count of inner sequence space compaction temporal file
file_countname=”inner-unseq-temp”AutoGaugeThe count of inner unsequence space compaction temporal file
file_countname=”cross-temp”AutoGaugeThe count of cross space compaction temporal file
file_countname=”open_file_handlers”AutoGaugeThe count of open files of the IoTDB process, only supports Linux and MacOS
file_countname=”modsAutoGaugeThe count of modification file

4.2.10. IoTDB Process

MetricTagsTypeDescription
process_used_memname=”memory”AutoGaugeThe used memory of IoTDB process
process_mem_rationame=”memory”AutoGaugeThe used memory ratio of IoTDB process
process_threads_countname=”process”AutoGaugeThe number of thread of IoTDB process
process_statusname=”process”AutoGaugeThe status of IoTDB process, 1=live, 0=dead

4.2.11. Log

MetricTagsTypeDescription
logback_eventslevel=”trace/debug/info/warn/error”CounterThe number of log events

4.2.12. JVM Thread

MetricTagsTypeDescription
jvm_threads_live_threadsAutoGaugeThe number of live thread
jvm_threads_daemon_threadsAutoGaugeThe number of daemon thread
jvm_threads_peak_threadsAutoGaugeThe number of peak thread
jvm_threads_states_threadsstate=”runnable/blocked/waiting/timed-waiting/new/terminated”AutoGaugeThe number of thread in different states

4.2.13. JVM GC

MetricTagsTypeDescription
jvm_gc_pauseaction=”end of major GC/end of minor GC”,cause=”xxxx”TimerThe number and time consumed of Young GC/Full Gc caused by different reason
jvm_gc_concurrent_phase_timeaction=””,cause=””TimerThe number and time consumed of Young GC/Full Gc caused by different
jvm_gc_max_data_size_bytesAutoGaugeThe historical maximum value of old memory
jvm_gc_live_data_size_bytesAutoGaugeThe usage of old memory
jvm_gc_memory_promoted_bytesCounterThe accumulative value of positive memory growth of old memory
jvm_gc_memory_allocated_bytesCounterThe accumulative value of positive memory growth of allocated memory

4.2.14. JVM Memory

MetricTagsTypeDescription
jvm_buffer_memory_used_bytesid=”direct/mapped”AutoGaugeThe used size of buffer
jvm_buffer_total_capacity_bytesid=”direct/mapped”AutoGaugeThe max size of buffer
jvm_buffer_count_buffersid=”direct/mapped”AutoGaugeThe number of buffer
jvm_memory_committed_bytesAutoGaugeThe committed memory of JVM
jvm_memory_max_bytesAutoGaugeThe max memory of JVM
jvm_memory_used_bytesAutoGaugeThe used memory of JVM

4.2.15. JVM Class

MetricTagsTypeDescription
jvm_classes_unloaded_classesAutoGaugeThe number of unloaded class
jvm_classes_loaded_classesAutoGaugeThe number of loaded class

4.2.16. JVM Compilation

MetricTagsTypeDescription
jvm_compilation_time_msAutoGaugeThe time consumed in compilation

4.3. Normal level Metrics

4.3.1. Cluster

MetricTagsTypeDescription
regionname=””,type=”SchemaRegion/DataRegion”AutoGaugeThe number of DataRegion/SchemaRegion of database in specific node
slotname=””,type=”schemaSlotNumber/dataSlotNumber”AutoGaugeThe number of DataSlot/SchemaSlot of database in specific node

4.4. All Metric

Currently there is no All level metrics, and it will continue to be added in the future.

5. How to get these metrics?

The relevant configuration of the metric module is in conf/iotdb-{datanode/confignode}.properties, and all configuration items support hot loading through the load configuration command.

5.1. JMX

For metrics exposed externally using JMX, you can view them through Jconsole. After entering the Jconsole monitoring page, you will first see an overview of various running conditions of IoTDB. Here you can see heap memory information, thread information, class information, and the server’s CPU usage.

5.1.1. Obtain metric data

After connecting to JMX, you can find the “MBean” named “org.apache.iotdb.metrics” through the “MBeans” tab, and you can view the specific values of all monitoring metrics in the sidebar.

metric-jmx

5.1.2. Get other relevant data

After connecting to JMX, you can find the “MBean” named “org.apache.iotdb.service” through the “MBeans” tab, as shown in the image below, to understand the basic status of the service

Metric Tool - 图3

In order to improve query performance, IOTDB caches ChunkMetaData and TsFileMetaData. Users can use MXBean and expand the sidebar org.apache.iotdb.db.service to view the cache hit ratio:

Metric Tool - 图4

5.2. Prometheus

5.2.1. The mapping from metric type to prometheus forma

For metrics whose Metric Name is name and Tags are K1=V1, …, Kn=Vn, the mapping is as follows, where value is a specific value

For metrics whose Metric Name is name and Tags are K1=V1, …, Kn=Vn, the mapping is as follows, where value is a specific value

Metric TypeMapping
Countername_total{k1=”V1”, …, Kn=”Vn”} value
AutoGauge、Gaugename{k1=”V1”, …, Kn=”Vn”} value
Histogramname_max{k1=”V1”, …, Kn=”Vn”} value
name_sum{k1=”V1”, …, Kn=”Vn”} value
name_count{k1=”V1”, …, Kn=”Vn”} value
name{k1=”V1”, …, Kn=”Vn”, quantile=”0.0”} value
name{k1=”V1”, …, Kn=”Vn”, quantile=”0.25”} value
name{k1=”V1”, …, Kn=”Vn”, quantile=”0.5”} value
name{k1=”V1”, …, Kn=”Vn”, quantile=”0.75”} value
name{k1=”V1”, …, Kn=”Vn”, quantile=”1.0”} value
Ratename_total{k1=”V1”, …, Kn=”Vn”} value
name_total{k1=”V1”, …, Kn=”Vn”, rate=”m1”} value
name_total{k1=”V1”, …, Kn=”Vn”, rate=”m5”} value
name_total{k1=”V1”, …, Kn=”Vn”, rate=”m15”} value
name_total{k1=”V1”, …, Kn=”Vn”, rate=”mean”} value
Timername_seconds_max{k1=”V1”, …, Kn=”Vn”} value
name_seconds_sum{k1=”V1”, …, Kn=”Vn”} value
name_seconds_count{k1=”V1”, …, Kn=”Vn”} value
name_seconds{k1=”V1”, …, Kn=”Vn”, quantile=”0.0”} value
name_seconds{k1=”V1”, …, Kn=”Vn”, quantile=”0.25”} value
name_seconds{k1=”V1”, …, Kn=”Vn”, quantile=”0.5”} value
name_seconds{k1=”V1”, …, Kn=”Vn”, quantile=”0.75”} value
name_seconds{k1=”V1”, …, Kn=”Vn”, quantile=”1.0”} value

5.2.2. Config File

  1. Taking DataNode as an example, modify the iotdb-datanode.properties configuration file as follows:
  1. dn_metric_reporter_list=PROMETHEUS
  2. dn_metric_level=CORE
  3. dn_metric_prometheus_reporter_port=9091

Then you can get metrics data as follows

  1. Start IoTDB DataNodes
  2. Open a browser or use curl to visit http://servier_ip:9091/metrics, you can get the following metric data:
  1. ...
  2. # HELP file_count
  3. # TYPE file_count gauge
  4. file_count{name="wal",} 0.0
  5. file_count{name="unseq",} 0.0
  6. file_count{name="seq",} 2.0
  7. ...

5.2.3. Prometheus + Grafana

As shown above, IoTDB exposes monitoring metrics data in the standard Prometheus format to the outside world. Prometheus can be used to collect and store monitoring indicators, and Grafana can be used to visualize monitoring indicators.

The following picture describes the relationships among IoTDB, Prometheus and Grafana

iotdb_prometheus_grafana

iotdb_prometheus_grafana

  1. Along with running, IoTDB will collect its metrics continuously.
  2. Prometheus scrapes metrics from IoTDB at a constant interval (can be configured).
  3. Prometheus saves these metrics to its inner TSDB.
  4. Grafana queries metrics from Prometheus at a constant interval (can be configured) and then presents them on the graph.

So, we need to do some additional works to configure and deploy Prometheus and Grafana.

For instance, you can config your Prometheus as follows to get metrics data from IoTDB:

  1. job_name: pull-metrics
  2. honor_labels: true
  3. honor_timestamps: true
  4. scrape_interval: 15s
  5. scrape_timeout: 10s
  6. metrics_path: /metrics
  7. scheme: http
  8. follow_redirects: true
  9. static_configs:
  10. - targets:
  11. - localhost:9091

The following documents may help you have a good journey with Prometheus and Grafana.

Prometheus getting_startedMetric Tool - 图6open in new window

Prometheus scrape metricsMetric Tool - 图7open in new window

Grafana getting_startedMetric Tool - 图8open in new window

Grafana query metrics from PrometheusMetric Tool - 图9open in new window

5.2.4. Apache IoTDB Dashboard

We provide the Apache IoTDB Dashboard, and the rendering shown in Grafana is as follows:

Apache IoTDB Dashboard

Apache IoTDB Dashboard

5.2.4.1. How to get Apache IoTDB Dashboard
  1. You can obtain the json files of Dashboards by GitHub:
    1. Apache IoTDB ConfigNode Dashboard
    2. Apache IoTDB DataNode Dashboard
  2. You can visit Grafana Dashboard official websiteMetric Tool - 图11open in new window, search for Apache IoTDB Dashboard and use

When creating Grafana, you can select the json file you just downloaded to Import and select the corresponding target data source for Apache IoTDB Dashboard.

5.2.4.2. Apache IoTDB ConfigNode Dashboard Instructions

Except for the metrics specified specially, the following metrics are guaranteed to be available in the monitoring framework at the Important levels.

  • Overview: system overview
    • Registered Node: The number of registered ConfigNode/DataNode
    • DataNode: The status of the cluster DataNode, including Online and Unknown.
    • ConfigNode: The status of the cluster ConfigNode, including Online and Unknown.
    • The Status Of Node: The status of specific nodes in the cluster, including Online and Unknown.
  • Region: Region overview
    • Region Number: the number of Regions, including the total number, the number of DataRegions and the number of SchemaRegions.
    • Leadership distribution: Cluster leader distribution, which refers to the number of Leaders corresponding to the Region on each node.
    • Total Region in Node: The total number of Regions of different Nodes.
    • Region in Node: the number of SchemaRegions/DataRegions of different Nodes.
    • Region in Database (Normal level): the number of Regions in different Databases, including SchemaRegion and DataRegion.
    • Slot in Database (Normal level): The number of Slots in different Databases, including the number of DataSlots and SchemaSlots.
  • System: system
    • CPU Core: the number of CPU cores in the system.
    • CPU Load: system CPU load, progress CPU load.
    • CPU Time Per Minute: The process takes up the system CPU time per minute on average. Note: multi-core will cause this value to exceed 1 minute.
    • System Memory: the physical memory size of the system, the physical memory size used by the system, and the memory size submitted by the virtual machine.
    • System Swap Size: the total size of the system swap area, the size used by the system swap area.
    • Process Memory: the maximum total memory size of the IoTDB process, the total memory size of the IoTDB process, and the memory size used by the IoTDB process.
    • The Number of GC Per Minute: The average number of GC per minute.
    • The Time Consumed Of GC Per Minute: Average GC time spent per minute.
    • The Number Of Java Thread: The number of threads in different states of the IoTDB process.
    • Heap Memory: the heap memory of the IoTDB process
    • Off Heap Memory: the off-heap memory of the IoTDB process
    • Log Number Per Minute: the average number of logs per minute of the IoTDB process
    • The Time Consumed of Compliation Per Minute: average compilation time per minute
    • The Number Of Class: The number of classes loaded and unloaded by the JVM
5.2.4.3. Apache IoTDB DataNode Dashboard Instructions

Except for the metrics specified specially, the following metrics are guaranteed to be available in the monitoring framework at the Important levels.

  • Overview: system overview
    • The Number Of Entity: the number of entities, including time series, etc.
    • Write Point Per Minute: the average number of system write points per minute
    • Database Used Memory: the memory size used by each Database
  • Interface: interface
    • The Time Consumed Of Operation(50%): Median time spent by different client operations
    • The Time Consumed Of Operation(75%): The upper quartile of the time consumed by different client operations
    • The Time Consumed Of Operation(100%): The maximum time spent by different client operations
    • The QPS of Interface: system interface visits per second
    • The Time Consumed Of Interface: the average time consumed by the system interface
    • Cache Hit Rate: cache hit rate
    • Thrift Connection: the number of Thrift connections established
    • Thrift Active Thread: The number of active Thrift connections established
  • Engine:
    • Task Number: the number of tasks in different states in the system
    • The Time Consumed Of Tasking: Time consumption of tasks in different states in the system
    • Compaction Read And Write Per Minute: the average amount of combined read and write data per minute
    • Compaction R/W Ratio Per Minute: The average ratio of combined read and write data per minute
    • Compaction Number Per Minute: the average number of different types of consolidation tasks per minute
  • IoTConsensus
    • IoTConsensus Used Memory:The size of the memory used by IoTConsensus consensus
    • IoTConsensus Sync Index:the searchIndex and safeIndex of region
    • IoTConsensus Overview:The total sync lag and total size of buffered requests of node
    • The time consumed of different stages(50%):The median of the time consumed of different stages
    • The time consumed of different stages(75%):The upper quartile of the time consumed of different stages
    • The time consumed of different stages(100%):The max of the time consumed of different stages
    • IoTConsensus Search Index Rate:The increasing rate of searchIndex of region
    • IoTConsensus Safe Index Rate:The increasing rate of safeIndex of region
    • IoTConsensus LogDispatcher Request Size:The number of requests buffered in logDispatcher
    • Sync Lag:The sync lag of region
    • Min Peer Sync Lag:The sync lag between the searchIndex of IoTConsensusServerImpl and the max currentSyncIndex of LogDispatcher
    • Sync speed diff of Peers:The sync lag between the max currentSyncIndex of LogDispatcher and the min currentSyncIndex of LogDispatcher
  • System: system
    • CPU Core: the number of CPU cores in the system.
    • CPU Load: system CPU load, progress CPU load.
    • CPU Time Per Minute: The process takes up the system CPU time per minute on average. Note: multi-core will cause this value to exceed 1 minute.
    • System Memory: the physical memory size of the system, the physical memory size used by the system, and the memory size submitted by the virtual machine.
    • System Swap Size: the total size of the system swap area, the size used by the system swap area.
    • Process Memory: the maximum total memory size of the IoTDB process, the total memory size of the IoTDB process, and the memory size used by the IoTDB process.
    • The Size Of File: IoTDB system-related file size, including the total file size under wal, the total size of tsfile files under seq, and the total size of tsfile files under unseq
    • The Number Of File: the number of files related to the IoTDB system, including the number of files under wal, the number of tsfile files under seq, and the number of tsfile files under unseq
    • The Space Of Disk: the total size and remaining size of the disk mounted in the current data directory
    • The Number of GC Per Minute: The average number of GC per minute.
    • The Time Consumed Of GC Per Minute: Average GC time spent per minute.
    • The Number Of Java Thread: The number of threads in different states of the IoTDB process.
    • Heap Memory: the heap memory of the IoTDB process
    • Off Heap Memory: the off-heap memory of the IoTDB process
    • Log Number Per Minute: the average number of logs per minute of the IoTDB process
    • The Time Consumed of Compliation Per Minute: average compilation time per minute
    • The Number Of Class: The number of classes loaded and unloaded by the JVM

5.3. IoTDB

5.3.1. IoTDB mapping relationship of metrics

Metric TypeMapping
Counterroot.system.metric.ip:port.name.K1=V1Kn=Vn.value
AutoGauge、Gaugeroot.system.metric.ip:port.name.K1=V1Kn=Vn.value
Histogramroot.system.metric.ip:port.name.K1=V1Kn=Vn.count
root.
system.metric.ip:port.name.K1=V1Kn=Vn.max
root.system.metric.ip:port.name.K1=V1Kn=Vn.sum
root.
system.metric.ip:port.name.K1=V1Kn=Vn.p0
root.system.metric.ip:port.name.K1=V1Kn=Vn.p25
root.
system.metric.ip:port.name.K1=V1Kn=Vn.p50
root.system.metric.ip:port.name.K1=V1Kn=Vn.p75
root.
system.metric.ip:port.name.K1=V1Kn=Vn.p100
Rateroot.system.metric.ip:port.name.K1=V1Kn=Vn.count
root.
system.metric.ip:port.name.K1=V1Kn=Vn.mean
root.system.metric.ip:port.name.K1=V1Kn=Vn.m1
root.
system.metric.ip:port.name.K1=V1Kn=Vn.m5
root.system.metric.ip:port.name.K1=V1Kn=Vn.m15
Timerroot.system.metric.ip:port.name.K1=V1Kn=Vn.count
root.system.metric.ip:port.name.K1=V1Kn=Vn.max
root.
system.metric.ip:port.name.K1=V1Kn=Vn.mean
root.system.metric.ip:port.name.K1=V1Kn=Vn.sum
root.
system.metric.ip:port.name.K1=V1Kn=Vn.p0
root.system.metric.ip:port.name.K1=V1Kn=Vn.p25
root.
system.metric.ip:port.name.K1=V1Kn=Vn.p50
root.system.metric.ip:port.name.K1=V1Kn=Vn.p75
root.
system.metric.ip:port.name.K1=V1Kn=Vn.p100
root.system.metric.ip:port.name.K1=V1Kn=Vn.m1
root.
system.metric.ip:port.name.K1=V1Kn=Vn.m5
root.__system.metric.ip:port.name.K1=V1Kn=Vn.m15

5.3.2. Obtain metrics

According to the above mapping relationship, related IoTDB query statements can be formed to obtain metrics