Surveiller Azure Managed Instance pour Apache Cassandra à l’aide d’Azure Monitor

  • Article

Azure Managed Instance pour Apache Cassandra fournit des métriques et une journalisation des diagnostics via Azure Monitor.

Métriques Azure Managed Instance pour Apache Cassandra

Vous pouvez visualiser les métriques d’Azure Managed Instance pour Apache Cassandra dans le portail Azure en accédant à votre ressource de cluster et en sélectionnant Métriques. Vous pouvez ensuite choisir parmi les métriques et agrégations disponibles.

Screenshot that shows the Metrics pane in the Azure portal.

Paramètres de diagnostic dans Azure

Azure Monitor utilise des paramètres de diagnostic pour collecter les journaux de ressources, également appelés journaux de plan de données. Une ressource Azure émet des journaux de ressources pour fournir des données riches et fréquentes sur ses opérations. Azure Monitor capture ces journaux par requête. Des exemples d’opérations sur le plan de données incluent la suppression, l’insertion et readFeed. Le contenu de ces journaux d’activité varie en fonction du type de ressource.

Les métriques de plateforme et les journaux d’activité sont collectés automatiquement, tandis que vous devez créer un paramètre de diagnostic pour collecter les journaux de ressources ou les transférer en dehors d’Azure Monitor. Vous pouvez activer les paramètres de diagnostic pour Azure Managed Instance pour Apache Cassandra, et envoyer les journaux des ressources aux sources suivantes :

  • Espace de travail Log Analytics. Les données envoyées à Log Analytics peuvent être écrites dans des tables Diagnostics Azure (héritées) ou Spécifique à la ressource (préversion).
  • Event Hub.
  • Compte de stockage.

Remarque

Nous vous recommandons de créer le paramètre de diagnostic dans un mode spécifique de la ressource.

Créer des paramètres de diagnostic via le portail Azure

  1. Connectez-vous au portail Azure.

  2. Accédez à votre ressource de cluster Azure Managed Instance pour Apache Cassandra.

    Screenshot that shows selecting a cluster from a list of resources.

  3. Sélectionnez paramètres de diagnostic dans la section de surveillance, puis sélectionnez Ajouter un paramètre de diagnostic.

    Screenshot that shows the pane for diagnostic settings and the button for adding a diagnostic setting.

  4. Dans le volet Paramètre de diagnostic, choisissez un nom pour votre paramètre.

    Ensuite, sous détails de catégorie, sélectionnez vos catégories. La catégorie CassandraLogs enregistre les opérations du serveur Cassandra. Les opérations CassandraAudit catégorie enregistrent l’audit et les opérations CQL (Cassandra Query Language).

    Sous détails de destination, choisissez votre destination préférée pour vos journaux. Si vous envoyez des journaux à un espace de travail Log Analytics, veillez à sélectionner ressource spécifique comme table de destination.

    Screenshot that shows selections for a diagnostic setting.

    Remarque

    Si vous envoyez des journaux à un espace de travail Log Analytics, ils peuvent prendre jusqu’à 20 minutes. Jusqu’à présent, les tables spécifiques aux ressources (affichées sous Azure Managed Instance pour Apache Cassandra) ne sont pas visibles.

  5. Une fois que vous avez configuré la journalisation des diagnostics et que les données circulent, vous pouvez sélectionner Journaux et interroger les journaux de diagnostic disponibles à l'aide d'Azure Data Explorer. Pour plus d’informations sur Azure Monitor et Kusto Query Language, consultez Requêtes de journal dans Azure Monitor.

    Screenshot that shows query logs.

Créer un paramètre de diagnostic via Azure CLI

Pour créer un paramètre de diagnostic à l’aide d’Azure CLI, utilisez la commande az surveiller les paramètres de diagnostic créer :

    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

Créer un paramètre de diagnostic via l'API REST

Utilisez l’API REST Azure Monitor pour créer un paramètre de diagnostic via la console interactive.

Remarque

Nous vous recommandons de définir la propriété logAnalyticsDestinationType sur Dedicated pour activer les tables spécifiques aux ressources.

Requête

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

headers

Paramètres/en-têtes Valeur/description
name Le nom de votre paramètre de diagnostic
resourceUri subscriptions/{SUBSCRIPTION_ID}/resourceGroups/{RESOURCE_GROUP}/providers/Microsoft.DocumentDb/databaseAccounts/{ACCOUNT_NAME}/providers/microsoft.insights/diagnosticSettings/{DIAGNOSTIC_SETTING_NAME}
api-version 2017-05-01-preview
Content-Type application/json

Corps

{
    "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
}

Liste approuvée d’audit

Remarque

Cet article contient des références au terme liste blanche, que Microsoft n'utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.

Par défaut, la journalisation d’audit crée un enregistrement pour chaque tentative de connexion et chaque requête CQL. Le résultat peut être écrasant et augmenter les frais généraux. Pour gérer cette situation, vous pouvez utiliser une liste blanche pour inclure ou exclure de manière sélective des enregistrements d'audit spécifiques.

Cassandra 3.11

Dans Cassandra 3.11, vous pouvez utiliser la fonctionnalité de liste blanche d'audit pour définir les opérations qui ne créent pas d'enregistrement d'audit. La fonctionnalité de liste approuvée d’audit est activée par défaut dans Cassandra 3.11. Pour savoir comment configurer votre liste approuvée, consultez Role-based whitelist management (Gestion de la liste approuvée basée sur les rôles).

Exemples :

  • Pour filtrer toutes les opérations SELECT et MODIFY pour l’utilisateur bob à partir du journal d’audit, exécutez les instructions suivantes :

    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' };

  • Pour filtrer toutes les opérations SELECT sur la table decisions dans l’espace de clés design pour l’utilisateur jim à partir du journal d’audit, exécutez l’instruction suivante :

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

  • Pour révoquer la liste blanche de l'utilisateur bob sur toutes les opérations SELECT de l'utilisateur, exécutez l'instruction suivante :

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

  • Pour afficher les listes blanches actuelles, exécutez l’instruction suivante :

    cassandra@cqlsh> LIST ROLES;

Cassandra 4 et versions ultérieures

Dans Cassandra 4 et versions ultérieures, vous pouvez configurer votre liste blanche dans la configuration Cassandra. Pour obtenir des conseils détaillés, consultez Mettre à jour la configuration de Cassandra. Les options disponibles sont les suivantes (référence : documentation Cassandra pour la journalisation d'audit) :

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>

Les catégories disponibles sont : QUERY, DML, DDL, DCL, OTHER, AUTH, ERROR, PREPARE.

Voici un exemple de configuration :

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

Par défaut, la configuration est définie included_categories sur AUTH,ERROR,DCL,DDL.

Étapes suivantes