Skip to main content
Data sources are where the alert engine queries data. You need to configure data sources first so the alert engine can read data from them for anomaly detection. Menu Entry: Data Sources

Supported data source types

Monitors supports the following 9 data source types:

Data source list

The data source list displays all configured data sources with the following information:
  • Name: The identifier for the data source
  • Type: Data source type with icon
  • Connection URL: The access address of the data source
  • Associated Alert Engine: The bound alert engine cluster name, with engine online status indicator
  • Notes: Supplementary description
You can filter data sources by name or type using the search box. The list auto-refreshes every 5 seconds to reflect real-time engine connection status.

Create a data source

1

Select data source type

Click the New button and select the data source type (e.g., Prometheus, MySQL) at the top of the form.
2

Fill in basic information

3

Configure connection parameters

Fill in the connection parameters specific to the data source type. See the sections below for details.
4

Save

Click OK to complete creation.

Two ways to bind data sources in alert rules

Alert rules support two methods for binding data sources. Both can be used together, and at least one must be specified. The rule applies to all data sources matched by either method (union).
Wildcard by name stores name strings — if a data source is renamed, existing wildcard rules may no longer match. Exact match by ID stores the data source ID and is unaffected by renames. If stability is a priority, prefer exact match.

Data source type configuration

Prometheus

MySQL / Oracle / PostgreSQL

Relational databases share a similar configuration structure: Oracle uses only the basic connection settings above. MySQL and PostgreSQL additionally support TLS/SSL encrypted connections, selected via the TLS/SSL mode dropdown.

TLS/SSL modes for MySQL

With any mode other than “Disable TLS”, you can also enable client certificate authentication (mTLS — the client certificate and client key must be provided as a pair), set the server name, and configure the minimum / maximum TLS version. With “Verify certificate and hostname”, use the database DNS name that matches the server certificate as the connection address instead of an IP address.
Setting any mode other than “Disable TLS” requires all registered Edge instances in the associated alert engine cluster to be v0.51.0 or later.

TLS/SSL modes for PostgreSQL

In “Verify certificate authority” and “Verify certificate and hostname” modes, a custom CA certificate is optional — leave it empty to use the system trust store of the alert engine host. Client certificate authentication (mTLS) can be enabled in any mode other than “Disable TLS”. With “Verify certificate and hostname”, use the database DNS name that matches the server certificate as the connection address instead of an IP address.
Setting any mode other than “Disable TLS” requires all registered Edge instances in the associated alert engine cluster to be v0.50.0 or later.

Elasticsearch / Loki / ClickHouse / SLS / VictoriaLogs

These data sources have connection configurations similar to Prometheus, including server address, authentication, and TLS settings. The default server address for VictoriaLogs is http://localhost:9428. Refer to the creation form for specific parameters.

Reference credentials locally in Edge

With Edge v0.46.0 or later, you can use environment variable references in supported data-source connection fields instead of placing credentials directly in the data-source configuration. Edge resolves each reference in its local process; the resolved credential is never written back to the synced data-source configuration, debug output, or API payloads.
1

Set environment variables for the Edge process

Set credentials in the environment of every Edge process that queries this data source. For example, set SLS_ACCESS_KEY_ID and SLS_ACCESS_KEY_SECRET for SLS. Restart the Edge process after changing its environment so the new values take effect.
2

Enter references in the data-source form

When editing a data source, enter ${env:VARIABLE_NAME} in a supported authentication or connection field. For example, enter ${env:SLS_ACCESS_KEY_ID} for the SLS AccessKey ID and ${env:SLS_ACCESS_KEY_SECRET} for the AccessKey Secret.
3

Save and test

Save the data source, then use Test to verify the connection. Each referenced variable must exist in the corresponding Edge process environment.
Variable names must start with an uppercase letter or underscore and may then contain only uppercase letters, digits, or underscores, such as SLS_ACCESS_KEY_SECRET.
Environment variable references are not supported in the data-source address. They are also not supported in Params for Prometheus, Loki, or VictoriaLogs. Use this syntax only in supported authentication and connection fields.

Test a data source

In the data source list, click the Test button for the corresponding data source to open a query preview window, verify the connection, and preview query results.

Edit and delete

  • Edit: Click the Edit button in the data source list to modify the configuration and save.
  • Delete: Click the Delete button in the data source list and confirm to delete the data source.
Before deleting a data source, ensure no alert rules reference it, otherwise the related alert rules will not execute properly.