Partager via

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

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.

Capture d’écran montrant le volet Métriques dans le portail Azure.

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. Parmi les exemples d’opérations de plan de données, citons la suppression, l’insertion et le flux de lecture. 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. 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 en mode spécifique aux ressources.

Créer des paramètres de diagnostic à l’aide du portail Azure

  1. Connectez-vous au portail Azure.

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

    Capture d’écran montrant la sélection d’un cluster dans une liste de ressources.

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

    Capture d’écran montrant le volet des paramètres de diagnostic et le bouton permettant d’ajouter un paramètre de diagnostic.

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

  5. 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).

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

    Capture d’écran montrant les sélections d’un paramètre de diagnostic.

    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.

  7. 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.

    Capture d’écran qui montre les journaux de requête.

Créer un paramètre de diagnostic à l’aide d’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 à l’aide de l’API REST

Utilisez l’API REST Azure Monitor pour créer un paramètre de diagnostic à l’aide de la console interactive. Pour plus d’informations, consultez Paramètres de diagnostic.

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 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 dans le 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 verte pour l’utilisateur bob sur toutes les opérations de SELECT 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 plus d’informations, 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.

Étape suivante