Data Storages

The Data Storages page displays a list of ClickHouse servers.

To add a new connection, click + Add in the top-right corner and enter the following:

• Name
• Cluster mode (On/Off)
• Host
• Port
• User name
• Password
• SSL (On/Off)

Both valid and invalid connections can be added to a data storage. To verify a connection, go to its profile and click Test connection. If the test fails, an error message will appear.

The first connected storage is used for synchronizing data collected by the monitoring agent. To select a different storage on Windows, specify the desired connection’s identifier in the storage_guid parameter within the configuration file com.operavix.subsystem.monitoring.json, then restart the container. On Linux, update or restart the container while passing the new value of the environment variable MN_STORAGE_GUID.

Access to the server list and the ability to add or edit connections are governed by the Storages privilege.

ClickHouse Server Profile

To open a ClickHouse server’s profile, click its name or use the context menu icon and select Edit.

Common Tab

In the Common tab, you can configure the following server parameters:

• Connection name
• Host
• Port
• User name
• Password
• SSL
• Authentication:
  • Standard (default)
  • Pass-through (login/password)
• Memory limit per query in scripts (MB)
• Memory limit per query in dashboards (MB)
• Number of concurrent connections
• Execution queue size
• Session timeout (in minutes)

This tab also includes the Test connection button.

The connection can be saved using the button in the bottom-left corner once all required fields are filled.

After saving, the connection is automatically tested.

Pass-through Authentication

Pass-through authentication is an authentication method that enables row-level data access for users in the Business Intelligence module. It links ClickHouse and Operavix, allowing user accounts and access rights in Operavix and ClickHouse to be created and synchronized. This ensures user identity verification and displays only the data the user is authorized to see.

In standard authentication mode, all users access ClickHouse through a technical account. With pass-through authentication, each request to ClickHouse is made under the corresponding security user account. This security user account is required to create users and configure access permissions.

Row-level Access

Row-level access configures user permissions based on user attributes. These attributes are retrieved from Operavix system tables and synchronized every 5 minutes. Available attributes include:

• Employee access rights
• Access roles
• Login
• Custom user fields

You can also add attributes from a reference table uploaded to the database.

Row-level access for users is managed via the Row-level Access Management Tool, available in the Marketplace.

Row-level Access Use Case

In a BI system, you can configure reports so each user sees only the data they’re authorized to view at the database level. This is especially important when handling sensitive information—such as employee performance reports, tasks, sales data, etc.

To set up row-level access:

1. Create an access rights table, where permissions are assigned by login, role, department, etc.
2. Link this table to your main data either through the BI system or at the data source level.
3. Restrict table access. Ensure users can only access the data sources relevant to their role.

The system automatically identifies the user opening the report and applies the appropriate filter. For example:

• Employee — sees only their own data
• Department manager — sees data for their team
• HR or executive leadership — sees company-wide employee data

Benefits of row-level access:

• Security — no one sees another user’s data
• Flexibility — multiple access levels within a single report
• Ease of maintenance — no need to create separate reports per department or role
• Scalability — straightforward onboarding of new employees and roles

Access Tab

In the Access tab, you assign user permissions to interact with workspaces associated with the selected server.

To grant users access to the server, click + Add, select employees from the list, and click Save. To revoke a user’s access, click the trash icon.

Cluster Mode

Cluster mode allows you to specify multiple ClickHouse servers within a single connection, helping distribute the load across several servers.

To create a connection in cluster mode, enable the corresponding toggle when adding the connection and specify:

• Connection name
• Cluster name

The Common tab displays:

• Server name
• Cluster name
• Quorum
• Connections
• Authentication
• Session timeout (in minutes)

The Connections section lists all connected servers. Each connection is configured individually using the + Add button.

Connections can be removed without restrictions.

When Pass-through (login/password) authentication is selected, the following settings become available:

• User management (automatic only)
• Security user
  • Security user name
  • Security user password

In the Access tab, you assign user access to the data storage (i.e., its servers). Once access is granted, the user can interact with workspaces linked to this storage. The access configuration process is identical to that for standard connections. When using pass-through authentication, you can also allow selected users to view the workspace’s database by checking the corresponding box at the bottom of the page.

Recommendations for Using ClickHouse in Cluster Mode

To replicate data across all ClickHouse nodes, use 1 shard and multiple replicas in cluster mode.

Additionally, use table engines from the Replicated family.

In cluster mode, a single connection includes multiple server connections, and dashboard queries are distributed among them. Therefore, when creating, dropping, renaming, or truncating a table via an SQL query, you must include ON CLUSTER cluster_name in the statement.

Example:

CREATE TABLE table_name ON CLUSTER cluster_name
DROP TABLE table_name ON CLUSTER cluster_name
RENAME TABLE old_name TO table_name ON CLUSTER cluster_name
TRUNCATE TABLE table_name ON CLUSTER cluster_name

If this clause is omitted, the query will execute only on a single node, and changes won’t propagate to other nodes.

When re-creating a previously deleted table using the ReplicatedReplacingMergeTree engine, an error may occur. This can be resolved by explicitly specifying ZooKeeper parameters: zoo_path—the path to the table in ClickHouse Keeper.

Example:

ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/{database}/table_name_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', '{replica}')

Connecting to ClickHouse in a Workspace

For information about connecting ClickHouse within a workspace, see the Connections page.