Monitor Azure Managed Instance for Apache Cassandra by using Azure Monitor

Azure Managed Instance for Apache Cassandra provides metrics and diagnostic logging through Azure Monitor.

Azure Managed Instance for Apache Cassandra metrics

You can visualize metrics for Azure Managed Instance for Apache Cassandra in the Azure portal by going to your cluster resource and selecting Metrics. You can then choose from the available metrics and aggregations.

Diagnostic settings in Azure

Azure Monitor uses diagnostic settings to collect resource logs, which are also called data plane logs. An Azure resource emits resource logs to provide rich, frequent data about its operations. Azure Monitor captures these logs per request. Examples of data plane operations include delete, insert, and readFeed. The content of these logs varies by resource type.

Platform metrics and activity logs are collected automatically, whereas you must create a diagnostic setting to collect resource logs or to forward them outside Azure Monitor. You can turn on diagnostic settings for Azure Managed Instance for Apache Cassandra cluster resources and send resource logs to the following sources:

• Log Analytics workspace. Data sent to Log Analytics workspaces is written into Azure Diagnostics (legacy) or Resource-specific (preview) tables.
• Event hub.
• Storage account.

Create diagnostic settings via the Azure portal

1. Sign in to the Azure portal.

2. Go to your Azure Managed Instance for Apache Cassandra cluster resource.

   

3. Select Diagnostic settings in the Monitoring section, and then select Add diagnostic setting.

   

4. On the Diagnostic setting pane, choose a name for your setting.

   Then, under Category details, select your categories. The CassandraLogs category records Cassandra server operations. The CassandraAudit category records audit and Cassandra Query Language (CQL) operations.

   Under Destination details, choose your preferred destination for your logs. If you're sending logs to a Log Analytics workspace, be sure to select Resource specific as the destination table.

   

   Note

   If you're sending logs to a Log Analytics workspace, they can take up to 20 minutes to appear. Until then, the resource-specific tables (shown under Azure Managed Instance for Apache Cassandra) aren't visible.

5. After you set up diagnostic logging and data is flowing, you can select Logs and query the available diagnostic logs by using Azure Data Explorer. For more information on Azure Monitor and Kusto Query Language, see Log queries in Azure Monitor.

   

Create a diagnostic setting via the Azure CLI

To create a diagnostic setting by using the Azure CLI, use the az monitor diagnostic-settings create command:

    logs='[{"category":"CassandraAudit","enabled":true,"retentionPolicy":{"enabled":true,"days":3}},{"category":"CassandraLogs","enabled":true,"retentionPolicy":{"enabled":true,"days":3}}]'
    resourceId='/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/{RESOURCE_GROUP}/providers/Microsoft.DocumentDB/cassandraClusters/{CLUSTER_NAME}'
    workspace='/subscriptions/{SUBSCRIPTION_ID}/resourcegroups/{RESOURCE_GROUP}/providers/microsoft.operationalinsights/workspaces/{WORKSPACE_NAME}'

    az monitor diagnostic-settings create  --name tvk-diagnostic-logs-cassandra --resource $resourceId --logs  $logs --workspace $workspace --export-to-resource-specific true

Create a diagnostic setting via the REST API

Use the Azure Monitor REST API for creating a diagnostic setting via the interactive console.

Request

PUT
https://management.azure.com/{resource-id}/providers/microsoft.insights/diagnosticSettings/service?api-version={api-version}

Headers

Body

{
    "id": "/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/{RESOURCE_GROUP}/providers/Microsoft.DocumentDb/databaseAccounts/{ACCOUNT_NAME}/providers/microsoft.insights/diagnosticSettings/{DIAGNOSTIC_SETTING_NAME}",
    "type": "Microsoft.Insights/diagnosticSettings",
    "name": "name",
    "location": null,
    "kind": null,
    "tags": null,
    "properties": {
        "storageAccountId": null,
        "serviceBusRuleId": null,
        "workspaceId": "/subscriptions/{SUBSCRIPTION_ID}/resourcegroups/{RESOURCE_GROUP}/providers/microsoft.operationalinsights/workspaces/{WORKSPACE_NAME}",
        "eventHubAuthorizationRuleId": null,
        "eventHubName": null,
        "logs": [
            {
                "category": "CassandraAudit",
                "categoryGroup": null,
                "enabled": true,
                "retentionPolicy": {
                    "enabled": false,
                    "days": 0
                }
            },
            {
                "category": "CassandraLogs",
                "categoryGroup": null,
                "enabled": true,
                "retentionPolicy": {
                    "enabled": false,
                    "days": 0
                }
            }
        ],
        "logAnalyticsDestinationType": "Dedicated"
    },
    "identity": null
}

Audit whitelist

By default, audit logging creates a record for every login attempt and CQL query. The result can be overwhelming and increase overhead. To manage this situation, you can use a whitelist to selectively include or exclude specific audit records.

Cassandra 3.11

In Cassandra 3.11, you can use the audit whitelist feature to set what operations don't create an audit record. The audit whitelist feature is enabled by default in Cassandra 3.11. To learn how to configure your whitelist, see Role-based whitelist management.

Examples:

• To filter out all SELECT and MODIFY operations for the user bob from the audit log, execute the following statements:

  cassandra@cqlsh> ALTER ROLE bob WITH OPTIONS = { 'GRANT AUDIT WHITELIST FOR SELECT' : 'data' };
  cassandra@cqlsh> ALTER ROLE bob WITH OPTIONS = { 'GRANT AUDIT WHITELIST FOR MODIFY' : 'data' };
  

• To filter out all SELECT operations on the decisions table in the design keyspace for user jim from the audit log, execute the following statement:

  cassandra@cqlsh> ALTER ROLE jim WITH OPTIONS = { 'GRANT AUDIT WHITELIST FOR SELECT' : 'data/design/decisions' };
  

• To revoke the whitelist for user bob on all the user's SELECT operations, execute the following statement:

  cassandra@cqlsh> ALTER ROLE bob WITH OPTIONS = { 'REVOKE AUDIT WHITELIST FOR SELECT' : 'data' };
  

• To view current whitelists, execute the following statement:

  cassandra@cqlsh> LIST ROLES;
  

Cassandra 4 and later

In Cassandra 4 and later, you can configure your whitelist in the Cassandra configuration. For detailed guidance, see Update Cassandra configuration. The available options are as follows (reference: Cassandra documentation for audit logging):

audit_logging_options:
    included_keyspaces: <Comma separated list of keyspaces to be included in audit log, default - includes all keyspaces>
    excluded_keyspaces: <Comma separated list of keyspaces to be excluded from audit log, default - excludes no keyspace except system, system_schema and system_virtual_schema>
    included_categories: <Comma separated list of Audit Log Categories to be included in audit log, default - includes all categories>
    excluded_categories: <Comma separated list of Audit Log Categories to be excluded from audit log, default - excludes no category>
    included_users: <Comma separated list of users to be included in audit log, default - includes all users>
    excluded_users: <Comma separated list of users to be excluded from audit log, default - excludes no user>

The available categories are: QUERY, DML, DDL, DCL, OTHER, AUTH, ERROR, PREPARE.

Here's an example configuration:

audit_logging_options:
    included_keyspaces: keyspace1,keyspace2
    included_categories: AUTH,ERROR,DCL,DDL

By default, the configuration sets included_categories to AUTH,ERROR,DCL,DDL.

Next steps

• For detailed information about how to create a diagnostic setting by using the Azure portal, the Azure CLI, or PowerShell, see Diagnostic settings in Azure Monitor.