ADQM Control overview

Features

Arenadata QuickMarts Control (ADQM Control) is an observability platform for Arenadata QuickMarts (ADQM) clusters that allows you to significantly simplify the administration and optimize the operation of ADQM databases.

Key objectives of ADQM Control are the following:

  • Monitor the health of an ADQM cluster. ADQM Control can work with multiple ADQM clusters simultaneously.

  • Collect and analyze system metrics and metrics of ADQM services.

  • Visualize the states of ADQM cluster hosts as a heat map.

  • Generate alerts. An alert is a notification message that describes a problem detected in an ADQM cluster and provides recommendations how to fix it. ADQM Control groups alerts by triggers that cause them:

    • threshold-based alerts that are generated when some metric in the system has reached the specified threshold;

    • event-based alerts that are generated when some event has happened in the system.

    In the ADQM Control user interface, you can specify criteria for generating alerts of different types (for example, configure thresholds, set timeouts) or disable tracking of some events.

NOTE
ADQM Control requires a fully deployed ADQM cluster with the monitoring service installed.

Architecture

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

ADQM Control architecture
ADQM Control architecture
ADQM Control architecture
ADQM Control architecture

Main points of the scheme:

  • ADQM Control is the main service that implements the full functionality of ADQM Control. It includes the following components:

    • Alert Generator. The alert-generator service reads metrics from a Prometheus instance of an ADQM cluster, generates alerts if necessary (taking into account criteria and timeouts for creating alerts specified in ADQM Control settings), sends alerts to Alertmanager.

    • Agents. The adqm-agent service receives data about hosts, components, queries, and table changes from the ADQM cluster’s ADQMDB service and stores this information in the database (Storage), and also generates internal alerts related to ADQM and sends them to Alertmanager.

    • Alertmanager. The alertmanager service handles alerts received from Alert Generator and Agents (filters alerts, mutes alerts of some type, adds additional labels, etc.) and resends processed alerts to Alert Receiver.

    • Alert Receiver. The alert-receiver service receives processed alerts from Alertmanager and stores them in the database.

    • Backend. The backend service communicates with the ADQM Control web interface (frontend in the scheme) via REST API — handles user requests from the frontend, saves specified ADQM Control settings, retrieves alerts and data about the ADQM cluster from the storage to transmit them to the web interface.

  • Storage is a PostgreSQL database for storing alerts, as well as data about users, tables, queries, and settings. You can set up it in one of the following ways:

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