Managing your Astra DB database

As a database administrator, you can manage your database. This includes the following tasks:

Create your database

Complete the following steps to create and launch your DataStax Astra DB database.

Procedure

In your Astra DB dashboard, select Create Database.

If you need more options, contact DataStax Support.
Enter your basic details:
- Database Name: Name your database something meaningful. The database name cannot be altered after the database is created. Use only alphanumeric characters; there is no character limit.
- Keyspace Name: Name your keyspace to reflect your data model. You cannot name your keyspace “dse” or “system”. Use only alphanumeric characters and no more than 48 total characters.

Select your cloud provider and then the region where you want to launch your database from the region menu, which reflects the available regions based on your selected cloud provider.

Regions with the lock symbol require payment. When selecting a region with a lock, you have to option to upgrade to a Pay-as-you-go-plan. If you select a region without a lock, you are still on the Free plan.

You can preview the costs for the database based on read and write requests, storage, and data transfer.

Select Create Database. The Database Created! page appears.
1. Click Download Token Details to download tokens generated for you. You can also click the clipboard in the Your Token box to copy these tokens.
2. Click Get Instructions for quick explanations on how to complete certain tasks and links for more information.
3. Click X at the top right of the screen to return to your Astra DB dashboard.
You will see a screen highlighting your selected plan. Select Continue.

Results

You are redirected to your Organization Dashboard. The new database and status is shown under Databases. You will receive an email when your database creation is complete. Select the database name to manage or connect with your new database.

View your databases

View all databases in your organization, and select a database to view detailed information about the database.

The Dashboard shows all of your databases within your organization, including databases you created and databases created by other team members. From here, you can select an individual database name to manage and connect those databases.

Selecting a database in DataStax Astra DB provides access to detailed information about the database. You can view the keyspaces, size and location of the database, and the estimate cost per hour.

Open a browser, navigate to Astra DB, and log in.
On the Dashboard page, select the database name to access the Overview page for your selected database.

You can only view connection details and database management operations for databases that you created.
On the Overview tab, you can see several database details:
- Database Name
- Status
- Usage for current billing period
  - Read Requests
  - Write Requests
  - Storage Consumed
  - Data Transfer
- Compute Size [Only for Classic tier databases]
- Replication Factor [Only for Classic tier databases]
- Current Capacity [Only for Classic tier databases]
- Regions
  - Provider
  - Area
  - Region
  - Datacenter ID
  - Region Availability
- Keyspaces

Database statuses

Your database can exist in a range of statuses. These statuses vary based on the actions you take within your database.

To see the system status of Astra, see https://status.astra.datastax.com/.

To see the status of a specific database, view your database Dashboard.

All databases

Active

Your database is available and ready to use.

Initializing

You’ve made your database selections. It should be ready for you to use soon.

Terminating/Terminated

You have terminated your database, which means your database and all data on your database will be removed. Your database is no longer available.

Error

Something is wrong with your database. Contact DataStax Support.

Maintenance

When a database is moving into hibernated or restarting from hibernated, your database will display that it is in the Maintenance status.

Hibernated

When an Astra DB database on the Free plan has been unused for more than 48 hours, it will automatically enter the Hibernated status.

It may take a few minutes for your hibernated Astra DB database to resume (return to Active status).

Database hibernation only occurs on the Free plan. Hibernated does not occur on the Astra DB paid plans. To avoid Hibernated, and to take full advantage of additional Astra DB functionality, upgrade from the Free plan to a Pay As You Go plan, or to an Enterprise plan. For details, see Pricing and billing and the Astra DB pricing calculators.

To view the status of any database within your organization,

Open your Astra DB dashboard.
1. If you have more than one database in a hibernated status, a banner appears at the top of the screen prompting you to click Resume Databases.
To activate a specific database, navigate to the Databases table on your dashboard. Select the database(s) to activate.
1. Click Resume to activate a hibernated database.
2. Hover Hibernated for a quick definition of this term.
3. Click the database name to open it, but remain in the hibernated status.

Monitor your databases

View connection details, performance metrics, and health details for databases in your organization.

The Databases page provides an overview of all databases in your organization, including the databases you created and databases created by other team members. However, only a database creator can make changes to a database and view its connection details, which can be shared manually with other team members.

View your databases

View all databases in your organization, and select a database to view detailed information about the database.

Selecting a database in DataStax Astra DB provides access to detailed information about the database. You can view the keyspaces, size and location of the database, and the estimate cost per hour.

Open a browser, navigate to Astra DB, and log in.
On the Dashboard page, select the database name to access the Overview page for your selected database.

You can only view connection details and database management operations for databases that you created.
On the Overview tab, you can see several database details:
- Database Name
- Status
- Usage for current billing period
  - Read Requests
  - Write Requests
  - Storage Consumed
  - Data Transfer
- Compute Size [Only for Classic tier databases]
- Replication Factor [Only for Classic tier databases]
- Current Capacity [Only for Classic tier databases]
- Regions
  - Provider
  - Area
  - Region
  - Datacenter ID
  - Region Availability
- Keyspaces

View health and metrics

Select a database to view health metrics and performance information. When selecting a database, you can view health metrics that include information regarding latency and throughput to the database. These metrics provide insights into the performance of the database and how workloads are distributed.

When viewing information about a database on the Health page, choose the region from the dropdown available at the right to view the health metrics of the database particular to that region. This is only applicable for multi-region databases.

Procedure

Open a browser, navigate to DataStax Astra DB, and log in.
On the Databases page, select the database name to view details for. Details for the database display on the Overview tab.
To view health metrics for the database, select the Health tab.
Select the time period to display in the health metrics for.

Results

Metrics for the database display in the Grafana dashboard embedded in Astra Portal. To view more granular metrics, hover over a specific time in the graph. Read and write latencies display in nanoseconds.

View health dashboard in a full browser window

Select Cycle View Mode in the upper right corner. This selection displays the cycle view.
Press Esc.
Select the share icon in the upper left corner.
Copy the URL.
Paste the URL in a new browser tab or window to see the dashboard.

Export Astra DB metrics to an external system

Enterprises depend on the ability to view database health metrics in centralized systems along with their other software metrics. The Astra DB Metrics feature lets you forward Astra DB database health metrics to an external third-party metrics system. We refer to the recipient of the exported metrics as the destination system.

Introduction

The functionality provided by the Astra DB Metrics feature is often referred to as:

Observability
External monitoring
Third-party metrics
Prometheus monitoring integration

At this time, Astra DB Metrics supports exporting health metrics from Astra DB serverless databases to:

You can also use Grafana or Grafana Cloud as a visualization tool.

You’ll configure the export of Astra DB health metrics in the payload of the following DevOps v2 API call:

POST /v2/databases/{databaseId}/telemetry/metrics

The Astra DB Metrics feature:

Is available only for Astra DB serverless databases.
Is available only on a paid pricing plan, such as Pay As You Go (PAYG) or Enterprise.
Is not available on the Astra DB Free plan.
Free plan users: click the Chat icon and ask the DataStax representative about options to upgrade your organization.

Benefits

The Astra DB Metrics feature allows you to take full control of forwarding Astra DB database health metrics to your preferred observability system. The functionality is intended for developers, site reliability engineers (SREs), IT managers, and product owners.

Ingesting database health metrics into your system gives you the ability to craft your own alerting actions and dashboards based on your service level objectives and retention requirements. While you can continue to view metrics displayed in Astra Portal via each database’s Health tab, forwarding metrics to a third-party app gives you a more complete view of all metrics being tracked, across all your products.

This enhanced capability can provide your team with broader insights into historical performance, issues, and areas for improvement.

The exported Astra DB health metrics are nearly real-time when consumed externally. You can find the source-of-truth view of your metric values in Astra Portal’s Health dashboard.

Prerequisites

If you haven’t already, create a serverless database using Astra Portal.

Keep track of your databaseId. You’ll specify it in the DevOps POST API call for /v2/databases/{databaseId}/telemetry/metrics. You can find the databaseId on Astra Portal’s dashboard.

Example:
Generate an application token so you can authenticate your account in the DevOps API.

If you don’t have a current token, see Manage application tokens.

Example:

When using the DevOps API, pass in the auth token’s value in the call’s Header.
Ensure you have permission to use the DevOps v2 API for enabling third-party metrics. See Roles and permissions in this topic.

You’ll need an existing destination system to receive the forwarded Astra DB metrics. Currently, Prometheus, Apache Kafka, Confluent Kafka, and Grafana / Grafana Cloud are supported.

Pricing

With an Astra DB PAYG or Enterprise plan, there is no additional cost to using Astra DB Metrics, outside of standard data transfer charges. Exporting third-party metrics is not available on the Astra DB Free Tier.

Metrics monitoring may incur costs at the destination system. Consult the destination system’s documentation for its pricing information.

Roles and permissions

The following Astra DB roles can export third-party metrics:

Organization Administrator (recommended)
Database Administrator
Service Account Administrator
User Administrator

The required db-manage-thirdpartymetrics permission is automatically assigned to those roles.

If you create a custom role in Astra DB, be sure to assign db-manage-thirdpartymetrics permission to the custom role.

Database metrics forwarded by Astra DB

Here’s a list of database metrics forwarded by the Astra DB Metrics feature.

rate_limited_requests_total - A counter, it’s the number of operations that failed due to an Astra DB rate limit. You can request that rate limits are increased for your Astra DB databases. Take a rate, such as 5 minutes (5m), and alert if the value is > 0.
read_requests_failures_total - A counter, it’s the number of reads that failed. Cassandra drivers will retry failed operations, but significant failures can be problematic. Take a rate, such as 5m, and alert if the value is > 0. Warn alert on low amount. High alert on larger amounts; determine potentially as a percentage of read throughput.
read_requests_timeouts_total - Timeouts happen when operations against the database take longer than the server side timeout. Take a rate, such as 5m, and alert if the value is > 0.
read_requests_unavailables_total - Occurs when the service is not available to complete a specific request. Take a rate, such as 5m, and alert if the value is > 0.
write_requests_failures_total - A counter, it’s the number of writes that failed. Cassandra drivers will retry failed operations, but significant failures can be problematic. Take a rate, such as 5m, and alert if the value is > 0. Warn alert on low amount. High alert on larger amounts; determine potentially as a percentage of read throughput.
write_requests_timeouts_total - Timeouts occur when operations take longer than the server side timeout. Take a rate, such as 5m, and compare with write_requests_failures_total.
write_requests_unavailables_total - Unavailable errors occur when the service is not available to service a particular request. Take a rate, such as 5m, and compare with write_requests_failures_total.
range_requests_failures_total - A counter, it’s the number of range reads that failed. Cassandra drivers retry failed operations, but significant failures can be problematic. Take a rate, such as 5m, and alert if the value is > 0. Warn alter on low amount. High alert on larger amounts; determine potentially as a percentage of read throughput.
range_requests_timeouts_total - Timeouts are a subset of total failures. Use this metric to understand if failures are due to timeouts. Take a rate, such as 5m, and compare with range_requests_failures_total.
range_requests_unavailables_total - Unavailable errors are a subset of total failures. Use this metric to understand if failures are due to timeouts. Take a rate, such as 5m, and compare with range_requests_failures_total.
write_latency_seconds_count - Take rate for write throughput. Alert based on your application Service Level Objective (business requirement).
write_latency_seconds_bucket - Take percentiles write for latency. Alert based on your application Service Level Objective (business requirement).
write_requests_mutation_size_bytes_bucket - Take percentiles to see how big your writes are over time.
read_latency_seconds_count - Take the rate for read throughput. Alert based on your application Service Level Objective (business requirement).
read_latency_seconds_bucket - Take percentiles read for latency. Alert based on your application Service Level Objective (business requirement).
range_latency_seconds_count - Take the rate for range read throughput. Alert based on your application Service Level Objective (business requirement).
range_latency_seconds_bucket - Take percentiles range read for latency. Alert based on your application Service Level Objective (business requirement).

Prometheus setup at the destination

For information about setting up Prometheus itself as the destination of the forwarded Astra DB database metrics, see the Prometheus Getting Started documentation.

Minimum version: Prometheus v2.25
Recommended versions: Prometheus v2.33+

For Prometheus, remote-write-receiver must be enabled in the destination app. For the steps, see:

After completing those steps in your Prometheus environment, verify it by sending a POST request to the remote write endpoint. For an example test client, which also verifies that ingress is setup properly, see:

https://github.com/m3dbx/prometheus_remote_client_golang

promremote is a Prometheus remote write client written in Go.

For more information about Prometheus metric types, see this topic.

Kafka setup at the destination

For information about setting up Kafka as a destination of the forwarded Astra DB database metrics, see:

Kafka metrics overview and Kafka Monitoring in the open-source Apache Kafka documentation.
Confluent Cloud Kafka documentation.

Configure the POST payload

Use the following POST to export metrics to an external system:

POST /v2/databases/{databaseId}/telemetry/metrics

The configuration payload (JSON) depends on which destination you’ll use. Currently we support Prometheus remote_write, and Kafka destinations.

To ensure that metrics are enabled for your destination app, provide the relevant properties.

Each POST replaces any existing configuration.

See the following sections for curl examples. If you prefer, use Postman with raw JSON in the body.

In the --header, use Bearer and specify your token ID to authenticate with the DevOps v2 API.

If you don’t have a current token, see Manage application tokens.

Specify your database ID.

See the Astra DB console Dashboard for its value. You can define a variable such as $DB_ID, set it to your databaseId value, and then use the variable in a curl command.

In the request payload, specify the destination’s --data properties.

Astra DB Metrics configuration for Prometheus

With a required top-level key of prometheus_remote, the POST payload:

prometheus_remote
- endpoint
- auth_strategy
- token
- user
- password

For auth_strategy, specify basic or bearer, depending on your Prometheus remote_write auth type.

If you specified "auth_strategy": "bearer", provide your Prometheus token. Do not include user or password in the POST request payload.
If you specified "auth_strategy": "basic", provide your Prometheus user and password. Do not include token.

Example payloads:

{
    "prometheus_remote":  {
        "endpoint": "https://prometheus.example.com/api/prom/push",
        "auth_strategy" : "bearer",
        "token" : "lSAYp9oLtdAa9ajasoNNS999"
    }
}

Or:

{
    "prometheus_remote":  {
        "endpoint": "https://prometheus.example.com/api/prom/push",
        "auth_strategy" : "basic",
        "password" : "myPromPassword",
        "user" : "myPromUsername"
    }
}

For Prometheus, remote-write-receiver must be enabled in the destination system. See:

POST metrics configuration examples (Prometheus)

cURL command
Result

curl --request POST \
  --url 'https://api.astra.datastax.com/v2/databases/$DB_ID/telemetry/metrics' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <application_token>' \
  --include \
  --data '{
           "prometheus_remote": {
             "endpoint": "Enter a full HTTP or HTTPS adddress and path for prometheus endpoint",
             "auth_strategy": "bearer or basic",
             "token": "If auth_strategy bearer, enter Prom Remote Write auth token",
             "user": "If auth_strategy basic, enter Prom username",
             "password": "If auth_strategy basic, enter Prom password"
            }
          }'

Examples with POST request payload:

curl --request POST \
  --url 'https://api.astra.datastax.com/v2/databases/$DB_ID/telemetry/metrics' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <application_token>' \
  --include \
  --data '{
           "prometheus_remote": {
             "endpoint": "https://prometheus.example.com/api/prom/push",
             "auth_strategy": "bearer",
             "token": "lSAYp9oLtdAa9ajasoNNS999"
            }
          }'

Or:

curl --request POST \
  --url 'https://api.astra.datastax.com/v2/databases/$DB_ID/telemetry/metrics' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <application_token>' \
  --include \
  --data '{
           "prometheus_remote": {
             "endpoint": "https://prometheus.example.com/api/prom/push",
             "auth_strategy": "basic",
             "user": "myPromUsername",
             "password": "myPromPassword"
            }
          }'

202 OK

Or one of the following:

400 Bad request.
401 Unauthorized.
403 The user is forbidden to perform the operation.
404 The specified resource was not found.
409 The request could not be processed because of conflict.
5XX A server error occurred.

Example:

{
  "errors": [
    {
      "description": "The name of the environment must be provided",
      "internalCode": "a1012",
      "internalTxId": "103B-A018-3898-0ABF"
    }
  ]
}

Get metrics configuration examples (Prometheus)

Retrieve third-party metrics configuration for an Astra DB database:

cURL command
Result

curl --request GET \
  --url 'https://api.astra.datastax.com/v2/databases/$DB_ID/telemetry/metrics' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <application_token>' \
  --include

200 OK

Example:

{
    "prometheus_remote": {
        "endpoint": "https://prometheus.example.com/api/prom/push",
        "auth_strategy": "basic",
        "user": "myPromUsername",
        "password": "myPromPassword"
  }
}

Or one of the following:

400 Bad request.
403 The user is forbidden to perform the operation.
404 The specified resource was not found.
500 A server error occurred.

{
  "errors": [
    {
      "description": "The name of the environment must be provided",
      "internalCode": "a1012",
      "internalTxId": "103B-A018-3898-0ABF"
    }
  ]
}

Astra DB Metrics configuration for Kafka

With a required top-level key of kafka, the POST payload’s required properties are:

bootstrap_servers
topic
sasl_mechanism
sasl_username
sasl_password

Example payload for Kafka:

{
  "kafka": {
    "bootstrap_servers": [
      "pkc-9999e.us-east-1.aws.confluent.cloud:9092"
    ],
    "topic": "astra_metrics_events",
    "sasl_mechanism": "PLAIN",
    "sasl_username": "9AAAAALPRC9AAAAA",
    "sasl_password": "viAAr/geQxxacrAAmydHb7wz6DRu6mL9W9999juQcS1s++pECM99mnW+3Gs06xDd",
    "security_protocol": "SASL_PLAINTEXT"
  }
}

The security_protocol property is an advanced option, and is not required. Most Kafka installations will not require this setting for Astra DB Metrics to connect. Users of hosted Kafka on Confluent Cloud, though, may need to set 'SASL_SSL' in the security_protocol property. Valid options are:

SASL_PLAINTEXT - SASL authenticated, non-encrypted channel.
SASL_SSL - SASL authenticated, encrypted channel. Non-Authenticated options (SSL and PLAINTEXT) are not supported.

Be sure to specify the appropriate, related sasl_mechanism property. For Confluent Cloud, you may only be able to use PLAIN. See the Confluent Cloud security tutorial. From the Confluent docs: "Confluent Cloud uses SASL/PLAIN (or PLAIN) over TLS v1.2 encryption for authentication because it offers broad client support while providing a good level of security. The usernames and passwords used in the SASL exchange are API keys and secrets that should be securely managed using a secrets store and rotated periodically."

POST metrics configuration example (Kafka)

cURL command
Result

curl --request POST \
  --url 'https://api.astra.datastax.com/v2/databases/$DB_ID/telemetry/metrics' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <application_token>' \
  --include \
  --data '{
      "kafka": {
          "bootstrap_servers": [
              "kafka-0.yourdomain.com:9092"
          ],
          "topic": "astra_metrics_events",
          "sasl_mechanism": "PLAIN",
          "sasl_username": "kafkauser",
          "sasl_password": "kafkapassword",
          "security_protocol": "SASL_PLAINTEXT"
      }
    }'

Example with POST request payload:

curl --request POST \
  --url 'https://api.astra.datastax.com/v2/databases/$DB_ID/telemetry/metrics' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <application_token>' \
  --include \
  --data '{
          "kafka": {
            "bootstrap_servers": [
              "pkc-9999e.us-east-1.aws.confluent.cloud:9092"
          ],
          "topic": "astra_metrics_events",
          "sasl_mechanism": "PLAIN",
          "sasl_username": "9AAAAALPRC9AAAAA",
          "sasl_password": "viAAr/geQxxacrAAmydHb7wz6DRu6mL9W9999juQcS1s++pECM99mnW+3Gs06xDd",
          "security_protocol": "SASL_PLAINTEXT"
  }
}'

202 OK

Or one of the following:

400 Bad request.
401 Unauthorized.
403 The user is forbidden to perform the operation.
404 The specified resource was not found.
409 The request could not be processed because of conflict.
5XX A server error occurred.

Example:

{
  "errors": [
    {
      "description": "The name of the environment must be provided",
      "internalCode": "a1012",
      "internalTxId": "103B-A018-3898-0ABF"
    }
  ]
}

Get metrics configuration examples (Kafka)

Retrieve third-party metrics configuration for an Astra DB database:

cURL command
Result

curl --request GET \
  --url 'https://api.astra.datastax.com/v2/databases/$DB_ID/telemetry/metrics' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <application_token>' \
  --include

200 OK

Example:

{
    "kafka": {
      "bootstrap_servers": [
         "kafka-0.yourdomain.com:9092"
      ],
      "topic": "astra_metrics_events",
      "sasl_mechanism": "PLAIN",
      "sasl_username": "kafkauser",
      "sasl_password": "kafkapassword",
      "security_protocol": "SASL_PLAINTEXT"
    }
}

Or one of the following:

400 Bad request.
403 The user is forbidden to perform the operation.
404 The specified resource was not found.
500 A server error occurred.

{
  "errors": [
    {
      "description": "The name of the environment must be provided",
      "internalCode": "a1012",
      "internalTxId": "103B-A018-3898-0ABF"
    }
  ]
}

Visualize exported Astra DB metrics with Grafana Cloud

This section explains how to configure Grafana Cloud to consume Astra DB (serverless) health metrics.

We’ll use Prometheus as the destination system in the examples.

You’ll need a Grafana Cloud account. They offer a Free plan with 14-day retention. For details, see Grafana pricing.

Initial steps in Grafana Cloud

The following initial steps occur before submitting the POST /v2/telemetry/metrics payload described previously in this topic.

On login to Grafana Cloud, select + Connect data from the home page.
Select the Custom Prometheus metrics section that includes the Prometheus icon.
You can accept the default selections, or make edits as needed. Provide a name to the API Key (such as AstraDB_PS) and click Create API Key.

The config file is generated. Here’s an example - your values will be different:

cat << EOF > ./agent-config.yaml
global:
  scrape_interval: 60s

scrape_configs:
  - job_name: node
    static_configs:
    - targets: ['localhost:9100']

remote_write:
  - url: https://prometheus-prod-10-prod-us-central-0.grafana.net/api/prom/push
    basic_auth:
      username: 412XXX
      password: eyJrIjoiMmE1ZTY4YWRhY2ZmNmZlMjllZmY3ZjczYWQ0NzRiZjNlNTE1NTVkMCIsIm4iOiJBc3RyYURCX1BTIiwiaWQiOjYzOTQXXX=
EOF

DevOps config via Postman & Grafana Cloud followup

To configure and publish metrics from Astra DB using the DevOps API, follow these steps. We’ll use Postman and have a bearer token configured.

To publish metrics, create a POST request in Postman:

https://api.astra.datastax.com/v2/databases/{databaseId}/telemetry/metrics

In the Body, set the parameters to the values that you retrieved from Grafana Cloud. Example:

{
  "prometheus_remote": {
    "endpoint": "https://prometheus-prod-10-prod-us-central-0.grafana.net/api/prom/push",
    "auth_strategy": "basic",
    "user": "412XXX",
    "password": "eyJrIjoiMmE1ZTY4YWRhY2ZmNmZlMjllZmY3ZjczYWQ0NzRiZjNlNTE1NTVkMCIsIm4iOiJBc3RyYURCX1BTIiwiaWQiOjYzOTQXXX=
  }
}

The POST response should return a 202 on success.

Now, switch back to Grafana Cloud:

Select the option to Create a New Dashboard.
Select Add a new panel and select the Data Source as grafanacloud-<YourUserId>-prom. Example:
If configured correctly, you should see the Astra DB Metrics under the Metrics Browser in Grafana Cloud. Example:
Now you can select the metrics that you want to visualize in Grafana Cloud. The Dashboard panel displays the charts.

Alternative approach: import from Astra DB Health to Grafana Cloud

This alternative approach will explore an import option from Astra DB health to your Grafana Cloud instance. You will still need to complete the steps listed above:

Initial steps in Grafana Cloud
DevOps config via Postman & Grafana Cloud followup

Then continue with the steps below.

Login to Astra Portal.
Select the database you want to ultimately monitor in Grafana Cloud by first navigating to your database’s Health tab.
Click on DSE Cluster Condensed. Example:
Click the Share icon:
Then select the Export tab:
Click View JSON and then Copy to Clipboard:

Make the following edits to the copied JSON.

Replace all references to coordinator_…{tenant= … } with astra_coordinator and remove the tenant references. For example, in the following expression:

"expr": "histogram_quantile(.99, sum(rate(coordinator_write_requests_mutation_size_bytes_bucket{tenant='${__user.login}'}[$__rate_interval])) by (le))",

You would replace that expression with:

"expr": "histogram_quantile(.99, sum(rate(astra_coordinator_write_requests_mutation_size_bytes_bucket{}[$__rate_interval])) by (le))",

Now switch over to your Grafana Cloud instance. Click the Create option, and then click Import from the menu.
Upload or paste in your edited JSON.
You can change the name. Example:
Once imported, all your Astra DB health charts will auto-populate in Grafana Cloud. Example:

Now you can use your own Grafana Cloud instance to monitor the Astra DB database’s health via its metrics.

What’s next?

See the following related topics.

DevOps v2 API reference

You can also use Grafana or Grafana Cloud to visualize the exported metrics.

Metrics API and UI options

You can configure the export of Astra DB metrics via the Astra Portal, or via the DevOps API and its /v2/databases/{databaseId}/telemetry/metrics call. For details, see:

Manage access list for public endpoints

Use access lists to limit what public endpoints are able to access your database. You can choose to restrict access in one of two ways:

Restrict access to specific IP addresses
Restrict access to a range of IP addresses using Classless Inter-Domain Routing (CIDR)

When Access List is configured and active, access to these endpoints is restricted:

CQL, GraphQL, and REST
GraphQL Playground
Swagger
CQLsh

This information applies to only serverless databases.

You can also manage your access list using the DevOps API.

If you are using the access list and restricting public access, these restrictions exclude the Astra internal site reliability controls.

Only Organization and Database Administrators for the database have permissions to manage the access list.

Restrict public access

By default, public access to your database is not restricted. Access to your database is possible via public internet.

In your database Settings, select the toggle to restrict public access.
Confirm your selection to Restrict Public Access.

Until you add an address to your access list, public access is still available.

Add IP address or CIDR to access list

Ensure public access is restricted.
Select Add Access.
Select Add new endpoint.

Select IP Address or CIDR from the Type menu.

A CIDR indicates a range of IP addresses. For example, the CIDR range '192.168.0.0/16' represents the first IP address of '192.168.0.0' through the last IP address of '192.168.255.255'. The '/16' mask indicates that the first 16 bits of the IP address are static. The addresses in the CIDR range are represented by all the permutations of the last 16 bits.

Enter the IP address or CIDR into the Address field.

If you want to add you current IP address, copy it from the display and paste it into the Address field.

All IP address must be entered in the IPv4 format, which is four decimal numbers, each ranging from 0 to 255. For example, 179.46.234.11.
Optional: Add a description for the address you are adding. For example, office or home.
Select Add to add the address to the access list.

It takes approximately five minutes for each address to sync and have access.

Upload list of endpoints

Ensure public access is restricted.
Select Add Access.

Select Upload from file.

[
  {
    "address": "10.0.0.1",
    "description": "Reader"
  },
  {
    "address": "10.0.0.1/32",
    "description": "Librarians"
  }
]

Use the Select File button to find the JSON file with your access list to upload.

You will see the list of addresses to be added to the access list.
Select Import to add the addresses to your access list.

Import endpoints from database

You can import an access list from another Astra database. If you do not have another active Astra database, this option will not be available.

Ensure public access is restricted.
Select Add Access.
Select Import from database.
Select the active Astra database from which you want to import the addresses.

You will see the list of addresses to be added to the access list.
Select Import to add the addresses to your access list.

Enable or disable an endpoint

Select the overflow menu for the address you want to enable or disable.
Select Enable or Disable.

The overflow menu will show the Disable option only when the address is enabled and the Enable option only when the address is disabled.
Confirm your selection to Enable or Disable the endpoint.

Your access list remains active, even if all endpoints are disabled. If you want to allow public access, you must select the toggle to stop restricting public access.

Delete an endpoint

If you remove all of the addresses on your access list, your database will be accessible from the public internet, even if Restrict public access is selected.

Select the overflow menu for the address you want to remove.
Select Delete.
Confirm your selection to Delete the endpoint.

It takes approximately five minutes for each address to sync and be removed from the access list.

Allow public access

If you stop restricting public access, access to your database is possible via public internet.

Select the toggle to stop restricting public access.
Confirm your selection to Enable public access.

Manage multiple keyspaces

In Astra, keyspaces hold the datacenter names associated with your Astra regions and defines the replication factor (3 for writes in LOCAL_QUORUM) for each datacenter. A replication factor of 3 ensures against losing your data. You can create keyspaces either with the Astra Dashboard or the DevOps API. Use the instructions below to delete a keyspace with your Astra account, if necessary.

Creating a database with multiple keyspaces allows you to create different data models for each keyspace or store unique data in unique keyspaces. Multiple keyspaces within a single region allows for an application built on a per-keyspace data model.

Adding a new keyspace

Open a browser, navigate to Astra DB, and log in.

On the Dashboard page, select the database name to access the Overview page for your selected database.

Select Add Keyspace.

Enter the name of the new keyspace.

Select Save.

Your list of keyspaces displays on the Overview page for your database.

Deleting a keyspace

If you delete a keyspace, all data in that keyspace is removed and cannot be recovered.

Open a browser, navigate to DataStax Astra DB, and log in.

On the Dashboard page, select the database name to access the Overview page for your selected database.

Select the overview menu (…) for the keyspace you want to delete.

Select Delete.

In the Delete keyspace menu, type in the name of the keyspace to delete.

Select Delete Keyspace.

Your list of keyspaces will be updated on the Overview page to show only the remaining keyspaces for your database.

Using multiple regions

You can replicate data to multiple regions for high availability scenarios to ensure active-active applications failover models. Multiple regions also ensure application data availability for locality purposes with the added value of cost savings.

Because having multiple regions increase your billing, see Pricing and billing for more details.

Video introduction

See this short video introduction to the Astra DB multi-region implementation:

Eventual consistency model and multi-region updates

Apache Cassandra® and DataStax Astra DB follow the eventual consistency model. As a result, data written to one datacenter/region may not be immediately accessible in other datacenters/regions in the same database cluster. The time span is normally within a few minutes to fully replicate the data. However, it could take longer, and possibly span one or more days. There are several contributing factors to the latter scenario, such as the workload volume, the number of regions, the process that runs data repair operations, and network resources.

For more, see the [_astra_db_serverless_multi_region_faq] in this topic.

Serverless databases

Multiple regions is available on only pay as you go and annual plans.

If you are adding multiple regions to your database, you can use each region only once. You cannot add the same region to the same database more than one time.

Lightweight Transactions (LWTs) are not supported in multi-region Astra DB Serverless databases. Serverless only supports serial consistency on the local datacenter, in a single region.

Add a new region to your database

From your database’s Dashboard, select Add Region.
Select your desired region from the dropdown menu of available choices.

You can review your selected region and its cost below the dropdown menu.

You can add only a single region at one time.
Select Add Region to add the region to your database.

After you add the new region, your new region will show up in the list of regions on your database Dashboard. Your existing region status will change to Maintenance, but will still be available for operations.

The information displayed on the Connect page for your database is region specific.

Delete a region from your database

The information displayed on the Connect page for your database is region specific.

Removing a region is not reversible. Proceed with caution.

From you database Dashboard, select the overflow menu for the database you want to delete.
Select Delete.
Type "delete" in the text bar.
Select Delete to delete your region.

Limitations

Lightweight transactions work for only a single-region datacenter.

If you original region is disconnected, schema changes are suspended and repairs do not run. If any regions are disconnected, the writes to those regions will not be forwarded.

While adding a new region, you cannot drop a table or keyspace and you cannot truncate a table.

If any region is not online, you cannot truncate a table.

Data sovereignty

Astra DB serverless replicates all data in the database to all of a database’s regions. By contrast, multiple keyspaces in Apache Cassandra® and DataStax Enterprise (DSE) allow a database to replicate some tables to a subset of regions. To achieve the same behavior as Cassandra or DSE, create a separate Astra DB instance that adheres to the necessary region restrictions. The database client will need to add a separate connection for the additional database and send queries to the appropriate connection depending on the table being queried.

Astra DB Serverless multi-region FAQ

While creating an Astra DB database, can I select multiple regions?

No. The workflow is to create a database with a selected region; then once the launched database reaches an Active status, you may add a region.

How many regions can I add?

The only limitation is the number of regions that are available in Astra DB. See Database Regions for the list of supported regions.

How many datacenters/regions can I add or remove at a time?

The current implementation allows one addition or removal at a time.

How quickly are updates applied to all datacenters/regions in the same database cluster?

It depends on several factors. As noted above, Apache Cassandra® and DataStax Astra DB follow the eventual consistency model. As a result, data written to one datacenter/region may not be immediately accessible in other datacenters/regions in the same database cluster. The time span is normally within a few minutes to fully replicate the data. However, it could take longer, and possibly span one or more days. There are several contributing factors to the latter scenario, such as the workload volume, the number of regions, the process that runs data repair operations, and network resources.

Can I remove a datacenter/region that I no longer need?

Yes, this action is supported with Astra DB Serverless. Exception: you cannot remove the original region selected when you created the Astra DB database. The original region can be deleted after all other regions are deleted by using the Terminate database operation.

Will I lose data when I remove a datacenter/region?

No. All data in the datacenter is replicated prior to being decommissioned.

Can I park a datacenter/region?

No. The best option, in this case, is to remove the datacenter/region.

Can I specify replication rules by keyspace?

By default, replication is applied at the database level. With Astra DB Serverless, there is no upfront database setup costs. The replication goal may be addressed by separating workloads by database without an impact on costs.

Is the Access List configuration by datacenter/region?

The Access List configuration applies at the database level.

How are backups managed?

Backups are taken on the region in which the database was first created.
The restore process follows this workflow: restore to the original datacenter, and then add the other regions.
For help with restore, please contact DataStax Support.

What’s next?

See additional database management topics.

Terminating your database

When you no longer need a database, terminate it to reduce costs and streamline operations. When you terminate a database, all data is permanently deleted and cannot be recovered.

If you have administrator privileges in the DataStax Astra Portal for your team, you can contact DataStax to terminate databases that are owned by other team members. For example, if a team member leaves your organization and you want to delete their databases, contact DataStax with the names of the databases owned by that team member.

Procedure

See instructions on how to terminate a multi-region database here.

Open a browser, navigate to Astra DB, and log in.
From the Dashboard page, select the overflow menu for the database you want to terminate and select Terminate.

All data in the database will be permanently deleted. You cannot restart the database. Proceed with caution.
To terminate the database, type in the database name you want to terminate and select Terminate.

Results

Your database is removed from the list of available databases. You will receive an email when your database is successfully terminated.