Monitor and Log Tools

System Monitor

Currently, IoTDB provides users Java’s JConsole tool to monitor system status or use IoTDB’s open API to check data status.

System Status Monitoring

After starting JConsole tool and connecting to IoTDB server, a basic look at IoTDB system status(CPU Occupation, in-memory information, etc.) is provided. See official documentationMonitor and Log Tools - 图1 (opens new window) for more information.

JMX MBean Monitoring

By using JConsole tool and connecting with JMX you are provided with some system statistics and parameters.

This section describes how to use the JConsole Mbeantab of jconsole to monitor some system configurations of IoTDB, the statistics of writing, and so on. After connecting to JMX, you can find the “MBean” of “org.apache.iotdb.service”, as shown in the figure below.

Monitor and Log Tools - 图2

System Metric Framework

Metric Tool

Performance Monitor

Introduction

To grasp the performance of iotdb, this module is added to count the time-consumption of each operation. This module can compute the statistics of the avg time-consuming of each operation and the proportion of each operation whose time consumption falls into a time range. The output is in log_measure.log file. An output example is below.

Monitor and Log Tools - 图3

Configuration parameter

location:conf/iotdb-engine.properties

Table -parameter and description

ParameterDefault ValueDescription
enable_performance_statfalseIs stat performance of sub-module enable.

Cache Hit Ratio Statistics

Overview

To improve query performance, IOTDB caches ChunkMetaData and TsFileMetaData. Users can view the cache hit ratio through debug level log and MXBean, and adjust the memory occupied by the cache according to the cache hit ratio and system memory. The method of using MXBean to view cache hit ratio is as follows:

  1. Connect to jconsole with port 31999 and select ‘MBean’ in the menu item above.
  2. Expand the sidebar and select ‘org.apache.iotdb.db.service’. You will get the results shown in the following figure:

Monitor and Log Tools - 图4

System log

IoTDB allows users to configure IoTDB system logs (such as log output level) by modifying the log configuration file. The default location of the system log configuration file is in $IOTDB_HOME/conf folder.

The default log configuration file is named logback.xml. The user can modify the configuration of the system running log by adding or changing the xml tree node parameters. It should be noted that the configuration of the system log using the log configuration file does not take effect immediately after the modification, instead, it will take effect after restarting the system. The usage of logback.xml is just as usual.

At the same time, in order to facilitate the debugging of the system by the developers and DBAs, we provide several JMX interfaces to dynamically modify the log configuration, and configure the Log module of the system in real time without restarting the system.

Dynamic System Log Configuration

Connect JMX

Here we use JConsole to connect with JMX.

Start the JConsole, establish a new JMX connection with the IoTDB Server (you can select the local process or input the IP and PORT for remote connection, the default operation port of the IoTDB JMX service is 31999). Fig 4.1 shows the connection GUI of JConsole.

Monitor and Log Tools - 图5

After connected, click MBean and find ch.qos.logback.classic.default.ch.qos.logback.classic.jmx.JMXConfigurator(As shown in fig 4.2). Monitor and Log Tools - 图6

In the JMXConfigurator Window, there are 6 operations provided, as shown in fig 4.3. You can use these interfaces to perform operation.

Monitor and Log Tools - 图7

Interface Instruction

  • reloadDefaultConfiguration

This method is to reload the default logback configuration file. The user can modify the default configuration file first, and then call this method to reload the modified configuration file into the system to take effect.

  • reloadByFileName

This method loads a logback configuration file with the specified path and name, and then makes it take effect. This method accepts a parameter of type String named p1, which is the path to the configuration file that needs to be specified for loading.

  • getLoggerEffectiveLevel

This method is to obtain the current log level of the specified Logger. This method accepts a String type parameter named p1, which is the name of the specified Logger. This method returns the log level currently in effect for the specified Logger.

  • getLoggerLevel

This method is to obtain the log level of the specified Logger. This method accepts a String type parameter named p1, which is the name of the specified Logger. This method returns the log level of the specified Logger. It should be noted that the difference between this method and the getLoggerEffectiveLevel method is that the method returns the log level that the specified Logger is set in the configuration file. If the user does not set the log level for the Logger, then return empty. According to Logger’s log-level inheritance mechanism, a Logger’s level is not explicitly set, it will inherit the log level settings from its nearest ancestor. At this point, calling the getLoggerEffectiveLevel method will return the log level in which the Logger is in effect; calling getLoggerLevel will return null.