Skip to content

Workspace Management

Workspaces are designed for multiple users and can isolate data across different units.

Create a Workspace

In the workspace list, click Create Workspace in the upper-right corner.

Workspace Information

  1. Enter the workspace name;

  2. Select the workspace language;

  3. Select the workspace owner: the owner has the highest operation permissions for the workspace;

  4. Optionally enter a description for the workspace.

Primary Storage Engine

The data storage engine is listed automatically.

If you do not select a data storage engine, data is saved in the system primary storage engine.

Data Retention Policy

This is the data retention duration of the current workspace.

In addition to the storage duration corresponding to each data type, you can also set a custom retention duration (<= 1800 days).

Configure Extra-Long Storage Duration
  • When configuring extra-long data retention for OpenSearch or Elasticsearch clusters, estimate not only storage space usage but also the number of index shards;
  • OpenSearch or Elasticsearch clusters allow up to 1000 shards per node by default. For example, for a 3-node cluster, the total number of shards should not exceed 3000;
  • Shard count calculation example: assume a workspace's log index is configured with 2 replicas, 3 shards, a maximum shard size of 30 GB, and approximately 180 GB of data per day (i.e., 2 indexes), with data retained for 200 days. The total shard count formula is: number of replicas × number of daily indexes × number of shards per index × data retention days = 2 × 2 × 3 × 200 = 2400 shards;
  • If multiple workspaces exist, add up the index shard counts of all workspaces, and also estimate the index shard counts for other data types.

Others

  1. Left-star query: determines whether the newly created workspace supports left-star queries;

  2. Custom mapping rules: after enabling this configuration, the corresponding workspace can define custom mapping rules. Custom mapping rules in the workspace take precedence over mapping rules in the management backend.

    Note

    If the mapping rules configured in the management backend overlap with those in the workspace, the member role will be the union of the roles assigned by the management backend and the workspace.

  3. Custom log indexes: after enabling, the workspace is allowed to create multiple index policies for saving logs;

  4. Extra-large log counting unit: used to set the counting unit for extra-large logs. Logs can be split into multiple entries for billing according to the configured counting unit;

  5. Query count limit: imposes custom limits on the number of queries for workspaces of different users, to avoid degraded cluster query performance caused by excessively large query data volumes and to preserve the product experience. Once the query limit is reached, additional results require another query.

  6. Backend access isolation: limits the scope of viewing and managing a specified workspace in the current management backend to backend super administrators. See Backend Access Isolation.

Manage Workspaces

Backend Access Isolation

Backend access isolation protects workspaces that need restricted backend access. After enabling it, only super administrators can view and manage the workspace in the current management backend; for regular backend accounts, the workspace is filtered out of the workspace list, search results, workspace selector, associated information, and count statistics.

Before enabling, confirm that all management backend services have been upgraded to a version that supports backend access isolation, and use a backend super administrator account. The super administrator here is a management backend account identity and is authorized separately from the Owner and Administrator of the console workspace.

  1. Go to Workspace > Workspace List in the management backend, click Create Workspace, or edit an existing workspace;
  2. In the Others area of the dialog, enable Backend Access Isolation;
  3. Click OK to save.

This switch is disabled by default for both new and existing workspaces. After saving, the new state takes effect. Enabled workspaces display an Isolated tag next to the name. Click Cancel to keep the original state. Backend super administrators can disable isolation through the same entry point to restore the workspace's original backend permission scope.

Isolation also applies to workspace details, configuration, deletion, members, and indexes in the backend, as well as access to resources associated with the workspace on other backend pages. When a regular backend account accesses an isolated workspace through an old link, the system prompts "Workspace does not exist or you do not have permission to access it." Subsequent requests from already-open pages also follow the new isolation rules.

When a regular backend account saves workspace authorization for users or groups, the system retains the original associations of isolated workspaces. Member group changes, group deletion, and shared role permission changes involving isolated workspaces are performed by backend super administrators. The backend records audit logs for isolation switch changes.

The console continues to access workspaces according to members, teams, management groups, and SSO authorization rules. Data collection and monitoring continue to follow existing rules.

Filtering

Use the Primary Storage Engine and Business filters to quickly filter and locate workspaces.

The workspace list page displays basic information for all workspaces. You can search by workspace name keyword.

Index Configuration

This configures primary shards, shard size, and replica shards for all index templates in the current workspace.

Click the Configure button next to a data type to customize the primary shards, shard size, hot data retention duration, whether to enable replicas, and advanced configuration for that data type.

Under Volcengine, the storage policies for traces, logs, and custom log indexes include:

  • Standard storage: configures hot data;
  • Infrequent access storage: can be configured when the standard storage duration is 7 days or more;
  • Archive storage: can be configured when the standard storage duration is 30 days or more.
Note

  • After enabling replicas, a redundant replica is created for each index shard by default;

  • After enabling advanced configuration, you can modify the index mapping template configuration, including parameter changes such as tokenization related settings.

Data Reporting Limits

To meet the needs of the same role in a workspace, data reporting limits can be configured to determine, on a daily basis, whether a certain type of data has triggered a threshold. Once the threshold is triggered, subsequently reported data cannot be written into the database and is discarded, thereby saving resource usage costs.

As shown in the figure, you can configure limits for metrics, network (host count), log entries, APM Trace count, APM Profile count, RUM PV count, and Synthetic Test count.

Note

  • 0 indicates that all corresponding data is discarded and not written, no upper limit;

  • Because metrics and network data are measured by time series and networks, there is no quantity limit. Only two modes are supported: enable data write limit or no limit.

View Members

Click to enter the member page of the corresponding workspace to view basic information about all members in the workspace.

You can search, change roles, delete, and perform other operations.

Note

A workspace can have only one owner. If you change another member to owner, the original owner is downgraded to administrator.

Add Users

  1. Click to enter the add page;
  2. Select members;
  3. Set role permissions;
  4. Click OK.

Note

The members added here must already exist in the system. For new system members, add them successfully on the Users > Add User page, and then return here to proceed.

Modify/Delete Members

Click to modify the workspace configuration or delete the workspace directly.

Tenant Configuration Management

Note

Only applies to workspaces using the ScopeDB engine.

  1. Workgroup: the work group actually executed. After configuration, all queries in this workspace are executed by the specified work group and do not enter the cluster's default work group.
  2. Query concurrency: default 50. The number of concurrent queries in the workspace. Excess queries must wait in the queue.
  3. Maximum partition time: the maximum time range set for a single query. Once sufficient data is obtained within this range, the search stops immediately.

  4. Sampling threshold: freely configurable. When the data volume scanned by a query reaches the preset threshold, sampling queries are automatically enabled and data is returned.

    • Defaults: Dashboard queries (200 million), Explorer queries (100 million), Facet (5 million), Reports (500 million), other queries (200 million)

  5. Asynchronous execution timeout: default 2 minutes. The query timeout.

  6. Disable streaming aggregation: disabled by default.

Delete a Workspace

After deleting a workspace, users cannot log in to the workspace and data will no longer be reported.

The system does not clean up data and configurations immediately. It retains them for a seven-day buffer to avoid the unnecessary trouble caused by accidental deletion.

Feedback

Is this page helpful?