Diffuser des journaux vers Microsoft Sentinel à l’aide de Logstash et de l’API basée sur les DCR

Le plug-in de sortie Logstash de Microsoft Sentinel prend en charge les transformations de pipeline et la configuration avancée via des règles de collecte de données (DCR). Le plug-in transfère tout type de journaux d’activité provenant de sources de données externes dans des tables personnalisées ou standard dans Log Analytics ou Microsoft Sentinel.

Dans cet article, découvrez comment configurer le plug-in Logstash pour diffuser des données dans Log Analytics ou Microsoft Sentinel à l’aide de DCR, avec un contrôle total sur le schéma de sortie.

Avec le plug-in, vous pouvez :

• Contrôlez la configuration des noms et des types de colonnes.
• Effectuez des transformations au moment de l’ingestion, telles que le filtrage ou l’enrichissement.
• Ingérer des journaux personnalisés dans une table personnalisée ou ingérer un flux d’entrée Syslog dans la table Syslog Log Analytics.

L’ingestion dans des tables standard est limitée aux tables standard prises en charge pour l’ingestion des journaux personnalisés.

Pour en savoir plus sur l’utilisation du moteur de collecte de données Logstash, consultez Prise en main de Logstash.

Vue d’ensemble de l’architecture

Le moteur Logstash est composé de trois composants :

• Plug-ins d’entrée : collecte personnalisée de données provenant de différentes sources.
• Plug-ins de filtre : manipulation et normalisation des données en fonction de critères spécifiés.
• Plug-ins de sortie : envoi personnalisé de données collectées et traitées vers différentes destinations.

Le module externe envoie des données au format JSON à votre espace de travail Log Analytics à l’aide de l’API d’ingestion des journaux. Les données sont importées dans des journaux personnalisés ou une table standard.

• En savoir plus sur l’API d’ingestion des journaux.

Déployer le plug-in de sortie Microsoft Sentinel dans Logstash

Pour configurer le plug-in, procédez comme suit :

• Examinez les prérequis du plugin Logstash
• Installer le plug-in
• Créer un exemple de fichier
• Créer les ressources liées au DCR requises
• Configurer le fichier de configuration Logstash
• Redémarrer Logstash
• Afficher les journaux entrants dans Microsoft Sentinel
• Surveiller les journaux d’audit du plug-in de sortie

Prérequis du plug-in Logstash

• Installez une version prise en charge de Logstash. Le plug-in prend en charge les versions de Logstash suivantes :

  • 7.0 - 7.17.13

  • 8.0 - 8.9 (ces versions nécessitent une mise à jour de sécurité, selon Logstash)

  • 8.11 - 8.15 (ces versions nécessitent une mise à jour de sécurité, selon Logstash)

  • 8.19.2 (cette version nécessite une mise à jour de sécurité, selon Logstash)

  • 9.0.8 (cette version nécessite une mise à jour de sécurité, selon Logstash)

  • 9.1.10 (cette version nécessite une mise à jour de sécurité, selon Logstash)

  • 9.2.4 - 9.2.5 (ces versions nécessitent une mise à jour de sécurité, selon Logstash)

  • 9.3.3

  • 9.4.0

    Remarque

    Si vous utilisez Logstash 8, nous vous recommandons de désactiver ECS dans le pipeline.

• Vérifiez que vous disposez d’un espace de travail Log Analytics avec au moins les autorisations Contributeur.

• Vérifiez que vous disposez des autorisations nécessaires pour créer des objets DCR dans l’espace de travail.

Installer le plug-in

Le plug-in de sortie Microsoft Sentinel est disponible dans la collection Logstash sur RubyGems.

• Suivez les instructions du document Logstash Utilisation des plug-ins pour installer le plug-in microsoft-sentinel-log-analytics-logstash-output-plugin . Pour installer sur une installation Logstash existante, exécutez la commande suivante :

  logstash-plugin install microsoft-sentinel-log-analytics-logstash-output-plugin
  

• Si votre système Logstash n’a pas accès à Internet, suivez les instructions du document Gestion des plug-ins hors connexion Logstash pour préparer et utiliser un pack de plug-ins hors connexion. (Cela nécessite la création d’un autre système Logstash avec accès à Internet.)

Créer un exemple de fichier

Dans cette section, vous allez créer un exemple de fichier dans l’un des scénarios suivants :

• Créer un exemple de fichier pour les journaux personnalisés
• Créer un exemple de fichier pour ingérer des journaux dans la table Syslog

Créer un exemple de fichier pour les journaux personnalisés

Dans ce scénario, vous configurez le plug-in d’entrée Logstash pour envoyer des événements à Microsoft Sentinel. Cet exemple utilise le plug-in d’entrée du générateur pour simuler des événements. Vous pouvez utiliser n’importe quel autre plug-in d’entrée.

Dans cet exemple, le fichier de configuration Logstash ressemble à ceci :

input {
      generator {
            lines => [
                 "This is a test log message"
            ]
           count => 10
      }
}

Pour créer l’exemple de fichier, procédez comme suit :

1. Copiez la configuration du plug-in de sortie ci-dessous dans votre fichier de configuration Logstash.

   output {
       microsoft-sentinel-log-analytics-logstash-output-plugin {
         create_sample_file => true
         sample_file_path => "<enter the path to the file in which the sample data will be written>" #for example: "c:\\temp" (for windows) or "/tmp" for Linux. 
       }
   }
   

2. Vérifiez que le chemin du fichier référencé existe déjà, puis démarrez Logstash.

   Le plug-in écrit dix enregistrements dans un exemple de fichier nommé sampleFile<epoch seconds>.json dans le chemin configuré une fois qu’il y a 10 événements à échantillonner ou lorsque le processus Logstash se termine correctement. Par exemple : c :\temp\sampleFile1648453501.json. Voici une partie d’un exemple de fichier créé par le plug-in :

   [
           {
               "host": "logstashMachine",
               "sequence": 0,
               "message": "This is a test log message",
               "ls_timestamp": "2022-03-28T17:45:01.690Z",
               "ls_version": "1"
           },
           {
               "host": "logstashMachine",
               "sequence": 1
       ...
   
       ]    
   

   Le plug-in ajoute automatiquement ces propriétés à chaque enregistrement :

   • ls_timestamp: heure à laquelle l’enregistrement est reçu du plug-in d’entrée
   • ls_version : version du pipeline Logstash.

   Vous pouvez supprimer ces champs lorsque vous créez la DCR.

Créer un exemple de fichier pour ingérer des journaux dans la table Syslog

Dans ce scénario, vous configurez le plug-in d’entrée Logstash pour envoyer des événements syslog à Microsoft Sentinel.

1. Si vous n’avez pas encore de messages syslog transférés sur votre ordinateur Logstash, vous pouvez utiliser la commande enregistreur d’événements pour générer des messages. Par exemple (pour Linux) :

   logger -p local4.warn --rfc3164 --tcp -t CEF "0|Microsoft|Device|cef-test|example|data|1|here is some more data for the example" -P 514 -d -n 127.0.0.1
   

   Voici un exemple pour le plug-in d’entrée Logstash :

   input {
        syslog {
            port => 514
       }
   }
   

2. Copiez la configuration du plug-in de sortie ci-dessous dans votre fichier de configuration Logstash.

   output {
       microsoft-sentinel-log-analytics-logstash-output-plugin {
         create_sample_file => true
         sample_file_path => "<enter the path to the file in which the sample data will be written>" #for example: "c:\\temp" (for windows) or "/tmp" for Linux. 
       }
   }
   

3. Vérifiez que le chemin du fichier existe déjà, puis démarrez Logstash.

   Le plug-in écrit dix enregistrements dans un exemple de fichier nommé sampleFile<epoch seconds>.json dans le chemin configuré une fois qu’il y a 10 événements à échantillonner ou lorsque le processus Logstash se termine correctement. Par exemple : c :\temp\sampleFile1648453501.json. Voici une partie d’un exemple de fichier créé par le plug-in :

   [
           {
               "logsource": "logstashMachine",
               "facility": 20,
               "severity_label": "Warning",
               "severity": 4,
               "timestamp": "Apr  7 08:26:04",
               "program": "CEF:",
               "host": "127.0.0.1",
               "facility_label": "local4",
               "priority": 164,
               "message": "0|Microsoft|Device|cef-test|example|data|1|here is some more data for the example",
               "ls_timestamp": "2022-04-07T08:26:04.000Z",
               "ls_version": "1"
           }
   ]    
   
   

   Le plug-in ajoute automatiquement ces propriétés à chaque enregistrement :

   • ls_timestamp: heure à laquelle l’enregistrement est reçu du plug-in d’entrée
   • ls_version : version du pipeline Logstash.

   Vous pouvez supprimer ces champs lorsque vous créez la DCR.

Créer les ressources DCR requises

Pour configurer l’Microsoft Sentinel plug-in Logstash basé sur DCR, commencez par créer les ressources associées à la DCR.

Dans cette section, vous allez créer des ressources à utiliser pour votre DCR, dans l’un des scénarios suivants :

• Créer des ressources DCR pour l’ingestion dans une table personnalisée
• Créer des ressources DCR pour l’ingestion dans une table standard

Créer des ressources DCR pour l’ingestion dans une table personnalisée

Pour ingérer des données dans une table personnalisée, procédez comme suit (en vous basant sur le tutoriel Envoyer des données aux journaux Azure Monitor à l’aide de l’API REST (portail Azure)) :

1. Examinez les conditions préalables.

2. Configurez l’application.

3. Ajoutez une table de journaux personnalisée.

4. Analysez et filtrez les exemples de données à l’aide de l’exemple de fichier que vous avez créé dans la section précédente.

5. Collecter des informations à partir de la DCR.

6. Attribuez des autorisations à la DCR.

   Ignorez l’étape Envoyer un exemple de données.

Si vous rencontrez des problèmes, consultez la procédure de dépannage de l’API d’ingestion des journaux.

Créer des ressources DCR pour l’ingestion dans une table standard

Pour ingérer les données dans une table standard comme Syslog ou CommonSecurityLog, vous utilisez un processus basé sur le tutoriel Envoyer des données aux journaux Azure Monitor à l’aide de l’API REST (modèles Resource Manager). Bien que le tutoriel explique comment ingérer des données dans une table personnalisée, vous pouvez facilement ajuster le processus pour ingérer des données dans une table standard. Les étapes ci-dessous indiquent les modifications pertinentes dans les étapes.

1. Examinez les conditions préalables.

2. Collecter les détails de l’espace de travail.

3. Configurer une application.

   Ignorez l’étape Créer une table dans l’espace de travail Log Analytics. Cette étape n’est pas pertinente lors de l’ingestion de données dans une table standard, car la table est déjà définie dans Log Analytics.

4. Créez la DCR. Dans cette étape :

   • Fournissez le fichier d’exemple que vous avez créé dans Créer un fichier d’exemple.
   • Utilisez l’exemple de fichier que vous avez créé pour définir la streamDeclarations propriété . Chacun des champs de l’exemple de fichier doit avoir une colonne correspondante portant le même nom et le type approprié (voir l’exemple ci-dessous).
   • Configurez la valeur de la outputStream propriété avec le nom de la table standard au lieu de la table personnalisée. Contrairement aux tables personnalisées, les noms de table standard n’ont pas le _CL suffixe .
   • Le préfixe du nom de la table doit être Microsoft- au lieu de Custom-. Dans cet exemple, la valeur de la outputStream propriété est Microsoft-Syslog.

5. Attribuer des autorisations à une DCR.

   Ignorez l’étape Envoyer un exemple de données.

Si vous rencontrez des problèmes, consultez la procédure de dépannage de l’API d’ingestion des journaux.

Exemple : DCR qui ingère des données dans la table Syslog

Gardez ces points à l’esprit :

• Les streamDeclarations noms et types de colonnes doivent être identiques aux champs de l’exemple de fichier, mais vous n’avez pas à les spécifier tous. Par exemple, dans la DCR ci-dessous, les champs PRI, type et ls_version sont omis de la colonne streamDeclarations.
• La dataflows propriété transforme l’entrée au format de table Syslog et affecte la outputStream valeur à Microsoft-Syslog.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "dataCollectionRuleName": {
      "type": "String",
      "metadata": {
        "description": "Specifies the name of the Data Collection Rule to create."
      }
    },
    "location": {
      "defaultValue": "[resourceGroup().location]",
      "type": "String",
      "metadata": {
        "description": "Specifies the location in which to create the Data Collection Rule."
      }
    },
    "workspaceResourceId": {
      "type": "String",
      "metadata": {
        "description": "Specifies the Azure resource ID of the Log Analytics workspace to use."
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.Insights/dataCollectionRules",
      "apiVersion": "2021-09-01-preview",
      "name": "[parameters('dataCollectionRuleName')]",
      "location": "[parameters('location')]",
      "properties": {
        "streamDeclarations": {
          "Custom-SyslogStream": {
            "columns": [
              { "name": "ls_timestamp", "type": "datetime" },
              { "name": "timestamp", "type": "datetime" },
              { "name": "message", "type": "string" },
              { "name": "facility_label", "type": "string" },
              { "name": "severity_label", "type": "string" },
              { "name": "host", "type": "string" },
              { "name": "logsource", "type": "string" }
            ]
          }
        },
        "destinations": {
          "logAnalytics": [
            {
              "workspaceResourceId": "[parameters('workspaceResourceId')]",
              "name": "clv2ws1"
            }
          ]
        },
        "dataFlows": [
          {
            "streams": ["Custom-SyslogStream"],
            "destinations": ["clv2ws1"],
            "transformKql": "source | project TimeGenerated = ls_timestamp, EventTime = todatetime(timestamp), Computer = logsource, HostName = logsource, HostIP = host, SyslogMessage = message, Facility = facility_label, SeverityLevel = severity_label",
            "outputStream": "Microsoft-Syslog"
          }
        ]
      }
    }
  ],
  "outputs": {
    "dataCollectionRuleId": {
      "type": "String",
      "value": "[resourceId('Microsoft.Insights/dataCollectionRules', parameters('dataCollectionRuleName'))]"
    }
  }
}

Configurer le fichier de configuration Logstash

Le plug-in prend en charge deux méthodes d’authentification : le principal de service (informations d’identification du client) et l’identité managée (sans mot de passe). Choisissez la méthode qui convient à votre environnement.

Authentification du principal de service

Pour configurer le fichier de configuration Logstash afin d’importer les journaux dans une table personnalisée à l’aide de l’authentification par principal de service, récupérez les valeurs suivantes : client_id, client_secret, tenant_id, data_collection_endpoint, dcr_id et stream_name.

Après avoir récupéré les valeurs requises :

1. Remplacez la section de sortie du fichier de configuration Logstash que vous avez créé à l’étape précédente par l’exemple ci-dessous.
2. Remplacez les chaînes d’espace réservé de l’exemple ci-dessous par les valeurs que vous avez récupérées.
3. Veillez à remplacer l’attribut par create_sample_filefalse.

Exemple : configuration du module externe de sortie du service principal

output {
    microsoft-sentinel-log-analytics-logstash-output-plugin {
      client_id => "<enter your client_id value here>"
      client_secret => "<enter your client_secret value here>"
      tenant_id => "<enter your tenant id here>"
      data_collection_endpoint => "<enter your logsIngestion URI here>"
      dcr_id => "<enter your DCR immutableId here>"
      stream_name => "<enter your stream name here>"
      create_sample_file=> false
      sample_file_path => "c:\\temp"
    }
}

Authentification d’identité managée (sans mot de passe)

Lorsque vous ne fournissez pas les identifiants du principal de service (client_id, , et tenant_id), le plugin s'authentifie en utilisant DefaultAzureCredential depuis le client_secretKit de développement logiciel (SDK) Azure. DefaultAzureCredential il essaie une séquence de méthodes d’authentification et utilise la première qui réussit. Dans un environnement serveur, les méthodes pertinentes sont tentées dans cet ordre :

1. Variables d’environnement : Lit les identifiants des variables d’environnement telles que AZURE_CLIENT_ID, AZURE_TENANT_ID, et AZURE_CLIENT_SECRET pour authentifier en tant que principal de service.
2. Identité de charge de travail : Si le plugin s’exécute sur un hôte Azure avec l’identité de charge activée (par exemple, AKS avec la variable d’environnement AZURE_FEDERATED_TOKEN_FILE définie), le plugin effectue un échange de jetons OIDC.
3. Identité gérée : Si l’hôte a une identité gérée activée, le plugin s’authentifie en utilisant cette identité. Cette méthode couvre les machines virtuelles Azure, les Virtual Machine Scale Sets et les serveurs compatibles Azure Arc.

Pour connaître la séquence complète des informations d’identification que DefaultAzureCredential essaie, consultez Chaînes d’informations d’identification dans la bibliothèque Azure Identity pour Java.

Configuration requise pour l’identité managée :

Exemple : Identité gérée

output {
    microsoft-sentinel-log-analytics-logstash-output-plugin {
      data_collection_endpoint => "<enter your DCE logsIngestion URI here>"
      dcr_id => "<enter your DCR immutableId here>"
      stream_name => "<enter your stream name here>"
    }
}

Configuration facultative

Redémarrer Logstash

Redémarrez Logstash avec la configuration du plug-in de sortie mise à jour. Vérifiez que les données sont ingérées dans la table appropriée en fonction de votre configuration DCR.

Afficher les journaux entrants dans Microsoft Sentinel

Pour vérifier que les données de journal atteignent votre espace de travail, procédez comme suit :

1. Vérifiez que les messages sont envoyés au plug-in de sortie.

2. Dans le menu de navigation Microsoft Sentinel, sélectionnez Journaux. Sous l’en-tête Tables , développez la catégorie Journaux personnalisés . Recherchez et sélectionnez le nom de la table que vous avez spécifiée (avec un _CL suffixe) dans la configuration.

   

3. Pour afficher les enregistrements dans la table, interrogez la table en utilisant le nom de la table comme schéma.

   

Surveiller les journaux d’audit du plug-in de sortie

Pour surveiller la connectivité et l’activité du plug-in de sortie Microsoft Sentinel, activez le fichier journal Logstash approprié. Consultez le document Disposition du répertoire Logstash pour connaître l’emplacement du fichier journal.

Si vous ne voyez aucune donnée dans ce fichier journal, générez et envoyez des événements localement via les plug-ins d’entrée et de filtre pour vous assurer que le plug-in de sortie reçoit des données. Microsoft Sentinel prend uniquement en charge les problèmes liés au plug-in de sortie.

Sécurité réseau

Définissez les paramètres réseau et activez l’isolation réseau pour le plug-in de sortie Microsoft Sentinel Logstash.

Étiquettes de service de réseau virtuel

Le plug-in de sortie de Microsoft Sentinel prend en charge les balises de service de réseau virtuel Azure. Les balises AzureMonitor et AzureActiveDirectory sont requises.

Les étiquettes de service Réseau virtuel Azure peuvent être utilisées pour définir des contrôles d’accès réseau sur les groupes de sécurité réseau, Pare-feu Azure et les itinéraires définis par l’utilisateur. Utilisez des étiquettes de service au lieu d’adresses IP spécifiques lorsque vous créez des règles de sécurité et des itinéraires. Pour les scénarios dans lesquels les étiquettes de service du réseau virtuel Azure ne peuvent pas être utilisées, la configuration requise du pare-feu est décrite ci-dessous.

Configuration requise du pare-feu

Le tableau suivant répertorie les exigences de pare-feu pour les scénarios où Azure étiquettes de service de réseau virtuel ne peuvent pas être utilisées.

Historique des versions du plug-in

2.5.0

• Ajout d’une configuration optionnelle par proxy par plugin pour le trafic d’authentification et d’ingestion utilisant proxy, proxy_aad, et proxy_endpoint.
• Mise à jour des composants Netty handler, HTTP, HTTP/2 et DNS de 4.1.133.Final à 4.1.136.Final.
• Mise à jour de Jackson Databind et Jackson Core de la version 2.18.6 à la 2.18.8.

2.4.0

• Les threads d'agent s’exécutent désormais sous forme de cycles d’exécution limités, programmés par l’exécuteur : les exceptions récupérables sont consignées et le thread de travail reprend au cycle suivant ; les erreurs fatales de la JVM sont consignées, puis relancées.
• Arrêt fixe et gracieux pour que les lots en cours soient vidés (agents de mise en lots, puis unificateurs, puis émetteurs) avant que les agents ne s’arrêtent, limités par max_graceful_shutdown_time_seconds.
• Ajout de délais d’expiration d’envoi configurables connect_timeout_seconds (par défaut 15) et write_timeout_seconds (par défaut 60) ; les opérations de connexion et d’écriture sont retentées en cas de dépassement de délai.
• Ajout d’ID de thread, de type d’exception, de taille de lot et de flux DCR aux journaux de défaillance de lot.

2.3.3

• Correction de la perte de fidélité des types numériques et booléens : les champs reposant sur les types JRuby internes de Logstash (par exemple, les ports et les nombres d’octets) sont désormais préservés en tant que nombres et booléens JSON natifs au lieu d’être convertis en chaînes de caractères, garantissant une ingestion fiable dans des DCR comportant des colonnes typées.

2.3.2

• Correction d’un arrêt silencieux du thread de l'agent causé par des exceptions non interceptées dans la boucle de traitement du thread.
• Correction de NullPointerException dans SenderWorker lorsque Azure retourne une LogsUploadException avec une réponse HTTP nulle.
• Ajout d’une gestion résiliente des erreurs avec suivi d’erreurs consécutif afin de réduire les défaillances permanentes des travailleurs.
• Valeur de configuration optionnelle id ajoutée pour la télémétrie.
• Ajout du flux DCR à la journalisation des lots envoyés.

2.3.0

• Fonctionnalité activée avec Logstash 9.4.
• Passage des versions des dépendances des bibliothèques externes (azure-sdk-bom, logback, slf4j, Netty).

2.2.1

• Ajoute une ligne de journalisation de niveau info lorsque les lots ont été envoyés avec succès.

2.2.0

• Ajoute la possibilité d’utiliser des valeurs de configuration neuves ou anciennes.

2.1.2

• Mises à jour de la documentation.

2.1.0

• Correction de la normalisation des événements.

2.0.0

• Refactorisé le plug-in de Ruby vers Java.
• Ajout de l’authentification ManagedIdentity.
• Déplacement du codebase de GitHub vers Azure DevOps.
• Base de code fermée.

1.2.0

• Ajoute la prise en charge de l’authentification par identité managée pour les machines virtuelles Azure/VMSS Azure (identités attribuées par le système et par l’utilisateur via IMDS).
• Ajoute la prise en charge des identités de charge de travail AKS via l’échange de jetons OIDC.
• Ajoute la prise en charge de l’identité managée Azure Arc pour les serveurs hybrides et locaux.
• Détecte automatiquement la méthode d’authentification au moment de l’exécution en fonction de l’environnement (identité de charge de travail env vars, agent Arc ou secours IMDS).
• Migre le client HTTP de excon vers rest-client afin d’améliorer la compatibilité avec l’écosystème des plug-ins JRuby et Logstash.
• Renomme les références à Azure Active Directory en Microsoft Entra ID.

1.1.4

• Limite la excon version de la bibliothèque à une version inférieure à 1.0.0 pour garantir que le port est toujours utilisé lors de l’utilisation d’un proxy.

1.1.3

• Remplace la rest-client bibliothèque utilisée pour la connexion à Azure par la excon bibliothèque.

1.1.1

• Ajoute la prise en charge du cloud Azure gouvernement des États-Unis et de Microsoft Azure gérés par 21Vianet en Chine.

1.1.0

• Permet de définir différentes valeurs de proxy pour les connexions d’API.
• Met à jour la version de l’API d’ingestion des logs vers 2023-01-01.
• Renomme le plug-in microsoft-sentinel-log-analytics-logstash-output-plugin.

1.0.0

• Version initiale du plug-in de sortie Logstash pour Microsoft Sentinel. Ce plug-in utilise des règles de collecte de données (DCR) avec l’API d’ingestion des journaux d’Azure Monitor.

Problèmes connus

Lors de l’utilisation de Logstash installé sur une image Docker de Lite Ubuntu, l’avertissement suivant peut s’afficher :

java.lang.RuntimeException: getprotobyname_r failed

Pour résoudre cette erreur, installez le package netbase dans votre fichier Dockerfile :

USER root
RUN apt install netbase -y

Pour plus d’informations, consultez Régression JNR dans Logstash 7.17.0 (Docker).

Si le taux d’événements de votre environnement est faible, augmentez la valeur de max_waiting_time_for_batch_seconds et max_waiting_for_unifier_time_seconds à 60 ou plus. Vous pouvez surveiller la charge utile d’ingestion à l’aide des métriques DCR. Pour plus d’informations sur les variables de temps d’attente, voir le tableau de configuration optionnel .

Limitations

• L’ingestion dans des tables standard est limitée aux tables standard prises en charge pour l’ingestion des journaux personnalisés.

• Les colonnes du flux d’entrée dans la streamDeclarations propriété doivent commencer par une lettre. Si vous démarrez une colonne avec d’autres caractères (par exemple @ ou _), l’opération échoue.

• Le TimeGenerated champ datetime est obligatoire. Vous devez inclure ce champ dans la transformation KQL.

• Pour d’autres problèmes potentiels, consultez la procédure de dépannage de l’API d’ingestion des journaux.