Arenadata DB Control overview

Daria Barysheva

Features

Arenadata DB Control (ADB Control) is a real-time Arenadata DB query monitoring system.

ADB Control allows you to perform the following functions:

  • Work with multiple ADB clusters.

  • Monitor SQL commands and transactions, including inner queries.

  • Monitor active and idle sessions with ability to terminate them.

  • View information on system resource consumption at the query and transaction levels.

  • Build different charts for tracking the dynamic changes of system metrics over the selected time period.

  • Cancel running transactions.

  • Analyze statistics on resource group usage with ability to configure resource groups via the ADB Control web interface.

  • Move running transactions to another resource group.

  • View a query plan with ability to track the execution progress.

  • Offload ADB Control metrics and events to an external database (PostgreSQL/ADB).

  • Audit ADB relation accesses (in clusters used for monitoring), as well as user authorizations and other operations in ADB Control.

NOTE

  • ADB Control is available in the ADB Enterprise Edition.

  • Currently, ADB Control can be installed only offline.

  • To use ADB Control, you need to install Chrony. Time synchronization is required for proper work of Scheduler job triggers and accuracy of system metric calculations.

Architecture

The high-level architecture view of ADB Control is shown below.

ADB Control architecture
ADB Control architecture
ADB Control architecture
ADB Control architecture

ADB Control architecture is based on the following components:

  • Agent. Application for receiving and filtering metrics from ADB cluster segments. Agents are installed one per ADB cluster host, i.e. one agent collects metrics from all segments within a single host.

  • Service Registry. Registry of ADB Control services. Responsible for Service Discovery in ADB Control. Due to Service Registry, ADB Control discovers available agents (there is no pre-configured agent map in ADB Control). And agents, in turn, find necessary ADB Control services to send metrics. Since ADB Control can work with multiple ADB clusters at the same time — when you add a cluster, new agents are also registered via Service Registry.

  • Planchecker. PlanChecker service, within which you can view a plan of the selected SQL query and get the detailed information on possible performance problems that can occur during the query execution. Note that ADB Control comes with offline PlanChecker (without redirect to the public one).

  • UI Backend Server. Backend server of the ADB Control web interface. Handles requests from Backend Server.

  • Backend Server. Horizontally scalable service for processing and aggregating metrics from agents. It also writes query/metric information to the Query DB/Metrics DB databases and sends updates to the UI Backend Server.

  • Scheduler. Runs system jobs on a schedule:

    • Cleanups old metrics and other data in ADB Control.

    • Offloads ADB Control metrics and audit events to an external database (Offload DB).

    • Actualizes command and transaction statuses.

    • Aggregates information on system resource consumption.

    • Obtains metrics on resource groups.

  • Migration. Provides automatic migration of schemas and data in databases with which ADB Control interacts (Query DB, Metrics DB, Offload DB).

  • Query DB. PostgreSQL database that performs the following functions:

    • Query logging.

    • Transaction logging.

    • Storage of system metric aggregates by transactions and queries.

    • Audit.

    • Statistics on database relations.

    • Storage of ADB Control system tables with information on users, clusters, system settings, and so on.

  • Metrics DB. ClickHouse database that is used to store the following information:

    • System metrics obtained from agents.

    • History of resource consumption within resource groups (based on gp_resgroup_*).

  • Offload DB. External PostgreSQL/ADB database that is used to offload metrics and audit data from ADB Control.

External storage usage

 

  • By default, Query DB and Metrics DB are deployed via the Docker containers. You can connect both of them to ADB Control as external storage systems. To do this, fill in the External database parameters (for Query DB) and/or External ADQM parameters (for Metrics DB) section parameters when configuring the ADB Control service during ADB installation (for more details, see Configuration parameters → ADB Control).

  • Starting with ADB Control 4.7.5, you need to create users in external databases and grant them permissions manually. For more details, see Configure external databases for ADB Control.

Found a mistake? Seleсt text and press Ctrl+Enter to report it