Partager via

Restaurer les journaux dans Azure Monitor

  • Article

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. Cet article explique comment restaurer des données, interroger ces données, puis faire disparaître les données une fois que vous avez terminé.

Remarque

Les tables avec le plan de table auxiliaire ne prennent pas en charge la restauration des données. Utilisez un travail de recherche pour récupérer des données qui sont en conservation à long terme à partir d’une table auxiliaire.

autorisations

Pour restaurer des données à partir d’une conservation à long terme, vous avez besoin d’autorisations Microsoft.OperationalInsights/workspaces/tables/write et Microsoft.OperationalInsights/workspaces/restoreLogs/write sur l’espace de travail Log Analytics, par exemple, comme fourni par le rôle intégré Contributeur Log Analytics.

Quand restaurer les journaux

Utilisez l’opération de restauration pour interroger les données en conservation à long terme. Vous pouvez également utiliser l’opération de restauration pour exécuter des requêtes puissantes dans un intervalle de temps spécifique sur une table d’analyse lorsque les requêtes de journal que vous exécutez sur la table source ne peuvent pas se terminer dans le délai d’expiration de la requête de journal de 10 minutes.

Remarque

La restauration est une méthode permettant d’accéder aux données en conservation à long terme. Utilisez restore pour exécuter des requêtes sur un ensemble de données dans un intervalle de temps particulier. Utilisez des tâches de recherche pour accéder aux données en fonction de critères spécifiques.

Que fait la restauration ?

Lorsque vous restaurez des données, vous spécifiez la table source qui contient les données que vous souhaitez interroger et le nom de la nouvelle table de destination à créer.

L’opération de restauration crée la table de restauration et alloue des ressources de calcul supplémentaires pour interroger les données restaurées à l’aide de requêtes hautes performances prenant en charge les KQL complètes.

La table de destination fournit une vue des données sources sous-jacentes, mais ne les affecte en aucune façon. La table n’a pas de paramètre de rétention et vous devez explicitement Ignorer les données restaurées lorsque vous n’en avez plus besoin.

Restaurer des données

Pour restaurer des données à partir d’une table, appelez l’API de création ou de mise à jour de tables . Le nom de la table de destination doit se terminer par _RST.

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{user defined name}_RST?api-version=2021-12-01-preview

Corps de la demande

Le corps de la requête doit inclure les valeurs suivantes :

Nom Type Description
properties.restoredLogs.sourceTable string Table avec les données à restaurer.
properties.restoredLogs.startRestoreTime string Début de l’intervalle de temps à restaurer.
properties.restoredLogs.endRestoreTime string Fin de l’intervalle de temps à restaurer.

Restaurer l’état de la table

La propriété provisioningState indique l’état actuel de l’opération de restauration de la table. L’API retourne cette propriété lorsque vous démarrez la restauration, et vous pouvez récupérer cette propriété ultérieurement à l’aide d’une opération d’extraction sur la table. La propriété provisioningState a l’une des valeurs suivantes :

Valeur Description
Mise à jour Opération de restauration en cours.
Opération réussie Opération de restauration effectuée.
Suppression Suppression de la table restaurée.

Exemple de requête

Cet exemple restaure les données du mois de janvier 2020 à partir de la table usage dans une table appelée Usage_RST.

Requête

PUT https://management.azure.com/subscriptions/00000000-0000-0000-0000-00000000000/resourcegroups/testRG/providers/Microsoft.OperationalInsights/workspaces/testWS/tables/Usage_RST?api-version=2021-12-01-preview

Corps de la demande :

{
    "properties":  {
    "restoredLogs":  {
                      "startRestoreTime":  "2020-01-01T00:00:00Z",
                      "endRestoreTime":  "2020-01-31T00:00:00Z",
                      "sourceTable":  "Usage"
    }
  }
}

Interroger les données restaurées

Les journaux restaurés conservent leurs horodatages d’origine. Lorsque vous exécutez une requête sur les journaux restaurés, définissez l’intervalle de temps de requête en fonction de l’origine des données générées.

Définissez l’intervalle de temps de requête :

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

    ou

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

    let startTime =datetime(01/01/2022 8:00:00 PM);
let endTime =datetime(01/05/2022 8:00:00 PM);
TableName_RST
| where TimeGenerated between(startTime .. endTime)

Ignorer les données restaurées

Pour réduire les coûts, nous vous recommandons de supprimer la table restaurée pour faire disparaître les données restaurées lorsque vous n’en avez plus besoin.

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

Notes

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 ignorées de la table restaurée. Toutefois, la table vide est conservée si vous ne la supprimez pas explicitement.

Limites

La restauration est soumise aux restrictions suivantes :

Vous pouvez :

  • Restaurez les données à partir d’une période d’au moins deux jours.

  • Restaurez jusqu’à 60 To.

  • Exécutez simultanément jusqu’à deux processus de restauration dans un espace de travail.

  • Exécutez une seule restauration active sur une table spécifique à un moment donné. L’exécution d’une deuxième restauration sur une table qui a déjà une restauration active qui échoue.

  • Effectuez jusqu’à quatre restaurations par table et par semaine.

Modèle de tarification

Les frais des journaux restaurés sont basés sur le volume de données restaurées et sur la durée d’activité de la restauration. Ainsi, les unités de prix sont par Go par jour. Les restaurations de données sont facturées pour chaque jour UTC d’activité de restauration.

  • Les frais sont soumis à un volume de données restauré minimum de 2 To par restauration, car la restauration alloue des ressources de calcul supplémentaires pour interroger les données restaurées. Si vous restaurez moins de données, vous êtes facturé l’équivalent de 2 To minimum par jour jusqu’à ce que la restauration soit ignorée.

  • Au cours des premiers et derniers jours pendant lesquels la restauration est active, vous n’êtes facturé que pour la partie du jour où la restauration a été active.

  • Les frais minimaux représentent une durée de restauration de 12 heures, même si la restauration est active moins de 12 heures.

  • Pour plus d’informations sur le prix de la restauration des données, consultez Tarification Azure Monitor sous l’onglet Journaux.

Voici quelques exemples pour illustrer les calculs de coût de restauration des données :

  1. Si votre table contient 500 Go par jour et que vous restaurez 10 jours de données à partir de cette table, votre taille de restauration totale est de 5 To. Vous êtes facturé pour ces 5 To de données restaurées chaque jour jusqu’à ce que vous ignorez les données restaurées. Votre coût quotidien est de 5 000 Go multiplié par votre prix de restauration de données (voir Tarification Azure Monitor.)

  2. Si au lieu de cela, seules 700 Go de données sont restaurées, chaque jour où la restauration est active est facturée pour le niveau de restauration minimal de 2 To. Votre coût quotidien est de 2 000 Go multiplié par votre prix de restauration de données.

  3. Si une restauration de données de 5 To est conservée active uniquement pendant 1 heure, elle est facturée pour une durée minimale de 12 heures. Le coût de cette restauration de données est de 5 000 Go multiplié par le prix de restauration des données multiplié par 0,5 jours (le minimum de 12 heures).

  4. Si une restauration de données de 700 Go est conservée active uniquement pendant 1 heure, elle est facturée pour une durée minimale de 12 heures. Le coût de cette restauration de données est de 2 000 Go (la taille minimale de restauration facturée) multiplié par le prix de restauration des données multiplié par 0,5 jours (le minimum de 12 heures).

Remarque

L’interrogation des journaux restaurés est gratuite puisqu’il s’agit de journaux Analytics.

Étapes suivantes