Restaurer les journaux dans Azure Monitor

L’opération de restauration rend une plage horaire spécifique de données dans une table disponible dans le cache à niveau d’accès chaud pour les requêtes hautes performances. Vous spécifiez une table source et un intervalle de temps, Azure Monitor crée une table de destination (se terminant par_RST) et vous exécutez des requêtes KQL complètes sur les données restaurées. Une fois terminé, fermez la restauration pour arrêter la facturation.

La restauration est un moyen d’accéder aux données en rétention à long terme. Utilisez la restauration pour exécuter des requêtes KQL (Kusto Query Language) complètes sur des données dans un intervalle de temps particulier. Utilisez tâches de recherche pour accéder aux données à partir de critères spécifiques. Utilisez également l’opération de restauration pour exécuter des requêtes sur n’importe quelle table Analytics lorsque les requêtes de journal ne peuvent pas se terminer dans le délai d’expiration de 10 minutes.

Prerequisites

Pour restaurer des données à partir de la conservation à long terme, vous avez besoin des autorisations Microsoft.OperationalInsights/workspaces/tables/write et Microsoft.OperationalInsights/workspaces/restoreLogs/write sur l’espace de travail Log Analytics. Le rôle intégré Log Analytics Contributeur fournit ces autorisations.

Les tables avec le plan de table auxiliaire ne prennent pas en charge la restauration des données. Utilisez une tâche de recherche pour récupérer des données stockées en rétention à long terme dans une table auxiliaire.

Remarque

Azure Lighthouse ne prend pas en charge l'accès délégué dans le cadre des travaux de restauration ou de recherche, même lorsqu'un rôle délégué inclut l'autorisation restoreLogs/write.

Restaurer des données

Lorsque vous restaurez des données, vous spécifiez la table source et un nom pour la nouvelle table de destination. Le nom de la table de destination doit se terminer par _RST. L’opération de restauration crée cette table et alloue des ressources de calcul supplémentaires pour interroger les données restaurées à l’aide de requêtes hautes performances qui prennent en charge le KQL complet. La table de destination fournit une vue des données sources sous-jacentes, mais ne l’affecte pas.

Spécifiez les heures de début et de fin sous forme de chaînes au format UTC au format ISO 8601, par exemple, 2026-01-01T00:00:00Z. Choisissez une plage dans les données conservées de la table source qui répondent aux contraintes de restauration.

Important

La facturation commence lorsque la restauration débute et continue jusqu’à ce que vous supprimiez les données restaurées. Fermez la restauration dès que vous avez terminé vos requêtes. Pour plus d’informations sur les coûts, consultez la tarification de la restauration.

L’exemple de Azure CLI suivant utilise la az monitor log-analytics workspace table restore create commande. Il restaure un intervalle de temps de données d’une table source dans une nouvelle table de destination. Le nom de la table de destination, que vous définissez à l’aide du --name paramètre, doit se terminer par _RST.

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_RST"
sourceTable="<SourceTableName>"
startRestoreTime="<StartRestoreTime>"
endRestoreTime="<EndRestoreTime>"

# Create the Log Analytics workspace restore logs table
az monitor log-analytics workspace table restore create \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --name "$tableName" \
  --restore-source-table "$sourceTable" \
  --start-restore-time "$startRestoreTime" \
  --end-restore-time "$endRestoreTime" \
  --no-wait

Remarque

Azure CLI commandes utilisent le point de terminaison Azure Resource Manager à partir du contexte CLI actuel. Par conséquent, management.azure.com n'a pas besoin d'être spécifié dans la syntaxe de commande.

Pour une restauration asynchrone, récupérez la table de destination avec az monitor log-analytics workspace table show, Get-AzOperationalInsightsTableou Tables - Get. Attendez que provisioningState soit Succeeded avant d’effectuer la requête.

Interroger les données restaurées

Lorsque vous interrogez une table restaurée dans Azure Monitor, utilisez le nom de la table de destination (se terminant par _RST). Les journaux restaurés conservent leurs horodatages d’origine, et non l’heure de l’opération de restauration. Définissez l’intervalle de temps de requête en fonction du moment où les données ont été générées à l’origine.

Définissez l’intervalle de temps de requête de l'une des manières suivantes :

  • Sélectionnez Personnaliser dans la liste déroulante Intervalle de temps en haut de l’éditeur de requête et définissez les valeurs From et To.

  • Spécifiez l’intervalle de temps dans la requête. Par exemple :

    let startTime = datetime(<StartRestoreTime>);
let endTime = datetime(<EndRestoreTime>);
<TableName>_RST
| where TimeGenerated between (startTime .. endTime)

Ignorer les données restaurées

Supprimer les données restaurées consiste à supprimer la table de destination _RST afin d’arrêter la facturation liée à la restauration. Supprimez la table restaurée lorsque vous n’en avez plus besoin.

La suppression de la table restaurée ne supprime pas les données de la table source.

Remarque

Les données restaurées sont disponibles tant que les données sources sous-jacentes le sont également. Lorsque vous supprimez la table source de l’espace de travail ou lorsque la période de rétention de la table source se termine, les données sont supprimées de la table restaurée. Toutefois, la table vide reste jusqu’à ce que vous la supprimiez explicitement.

Considérations relatives à la restauration

L’opération de restauration dans Azure Monitor a les contraintes suivantes :

  • Plans de table prises en charge : Analytique et Essentiel. Le plan auxiliaire n’est pas pris en charge.
  • Intervalle de temps minimal : au moins deux jours de données par restauration.
  • Volume de données maximal : jusqu’à 60 To par restauration.
  • Restaurations simultanées : jusqu’à deux processus de restauration par espace de travail en même temps.
  • Une restauration active par table : l’exécution d’une deuxième restauration sur une table qui a déjà une restauration active échoue.
  • Limite hebdomadaire : jusqu’à quatre restaurations par table par semaine.

Tarification de la restauration

Le coût des journaux restaurés dépend du volume de données que vous restaurez et de la durée pendant laquelle la restauration est active. Le prix est facturé par Go par jour chaque jour UTC pendant lequel la restauration est active.

Règles de tarification clés :

  • Volume de données minimal : 2 To par restauration. Si vous restaurez moins, vous êtes facturé pour 2 To.
  • Durée minimale : 12 heures. Si la restauration est active moins de 12 heures, 12 heures (0,5 jour) vous sont facturées.
  • Facturation d’un jour partiel : au cours des premiers et derniers jours, vous n’êtes facturé que pour la partie du jour où la restauration est active.
  • Aucun frais de requête : l’interrogation des données restaurées n’a aucun coût supplémentaire, car les tables restaurées utilisent le plan Analytics.

Pour plus d’informations sur la tarification, consultez l’onglet Journaux de Azure Monitor tarification.

Exemples de coûts

Scénario Données restaurées Durée Volume facturé par jour Calcul
Restauration volumineuse, sur plusieurs jours 5 To (500 Go/jour × 10 jours) Jusqu’à ce qu’elle soit ignorée 5 000 Go 5 000 Go × prix par Go/jour × nombre de jours actifs
Restauration légère, sur plusieurs jours 700 Go Jusqu’à ce qu’elle soit ignorée 2 000 Go (minimum) 2 000 Go × prix par Go/jour × nombre de jours actifs
Restauration importante, 1 heure 5 To 1 heure 5 000 Go 5 000 Go × prix par Go/jour × 0,5 jours (minimum de 12 heures)
Petite restauration, 1 heure 700 Go 1 heure 2 000 Go (minimum) 2 000 Go × prix par Go/jour × 0,5 jours (minimum de 12 heures)

Contenu connexe

  • Dernière mise à jour :