Partager via

Surveiller les exécutions de stratégie de gestion du cycle de vie

Vous pouvez surveiller l’exécution de la stratégie de gestion du cycle de vie du stockage Blob Azure à l’aide d’événements, d’indicateurs et de journaux. Vous pouvez déterminer quand une exécution de gestion du cycle de vie se termine en vous abonnant à un événement. Vous pouvez utiliser des propriétés d’événement pour identifier les problèmes, puis diagnostiquer ces problèmes à l’aide de métriques et de journaux.

Réception de notifications lorsqu’une exécution est terminée

Pour être averti lorsqu’une exécution de gestion du cycle de vie est terminée, abonnez-vous à l’événement LifecyclePolicyCompleted . Cet événement est généré lorsque les actions définies par une stratégie de gestion du cycle de vie sont effectuées. Une section récapitulative s’affiche pour chaque action incluse dans la définition de stratégie. Le JSON suivant montre un exemple d’événement LifecyclePolicyCompleted pour une stratégie. Une section récapitulative apparaît pour les actions delete, tierToCool, tierToCold et tierToArchive. Le code JSON suivant montre un exemple de notification d’événement.

{
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
    "subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
    "eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
    "eventTime": "2022-05-26T00:00:40.1880331",    
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "data": {
          "scheduleTime": "2022/05/24 22:57:29.3260160",
        "policyRunSummary": { 
            "completionStatus": "Completed/CompletedWithError/Incomplete" 
        },
        "deleteSummary": {
            "totalObjectsCount": 5,
            "successCount": 3,
            "errorList": ["testFile4.txt", "testFile5.txt"]
        },
        "tierToCoolSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToColdSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToArchiveSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        }
    },
    "dataVersion": "1",
    "metadataVersion": "1"
}

Pour en savoir plus sur les différentes façons de s’abonner à un événement, consultez Les gestionnaires d’événements dans Azure Event Grid.

Examen des erreurs à l’aide des métriques et des logs

L’exemple de réponse aux événements de la section précédente montre que la stratégie de gestion du cycle de vie a tenté de supprimer cinq objets, mais a réussi avec seulement trois d’entre eux. Les fichiers testFile4.txt et testFile5.txt n’ont pas été supprimés avec succès durant cette exécution. Pour diagnostiquer pourquoi certains objets n’ont pas été traités avec succès, vous pouvez utiliser metrics Explorer et interroger les journaux de ressources dans Azure Monitor.

Métriques

Pour déterminer exactement quand les opérations ont échoué, utilisez metrics Explorer. Vous pouvez voir toutes les transactions qui ont été appliquées au compte pendant la période comprise entre les valeurs scheduleTime et eventTime qui apparaissent dans les propriétés LifecyclePolicyCompleted.

Utilisez les filtres de métriques suivants pour limiter les transactions à celles exécutées par la stratégie :

Filtre Opérateur Valeur
Type de transaction égal system
Nom de l’API égal DeleteBlob
Type de réponse différent de Success

L’image suivante montre un exemple de requête et le résultat de la requête. Le graphique en courbes qui apparaît dans le résultat de la requête indique l’heure à laquelle ces opérations ont échoué.

Capture d’écran montrant les métriques appliquées pour déterminer les opérations de suppression qui ont échoué.

Journaux

Pour savoir pourquoi les objets n’ont pas été traités correctement par la stratégie, vous pouvez examiner les journaux des ressources. Limitez les journaux à l’intervalle de temps des défaillances. Examinez ensuite les entrées où le champ UserAgentHeader est défini sur ObjectLifeCycleScanner ou OLCMScanner. Si vous avez configuré un paramétrage de diagnostic pour envoyer des journaux vers l'espace de travail Azure Monitor Log Analytics, vous pouvez utiliser une requête Kusto pour localiser ces entrées de journal. Pour en savoir plus sur la configuration d’un paramètre de diagnostic, consultez Surveiller le stockage Blob.

L’exemple de requête suivant recherche les entrées de journal pour les opérations de suppression ayant échoué qui ont été lancées par une stratégie de gestion du cycle de vie.

StorageBlobLogs
| where OperationName contains "DeleteBlob" and UserAgentHeader contains "ObjectLifeCycleScanner"
| project TimeGenerated, StatusCode, StatusText

StatusCode et StatusText indiquent ce qui a provoqué l’échec. L’image suivante montre la sortie de cette requête. Les deux entrées de journal affichent une valeur StatusText de LeaseIdMissing. Cela signifie que les deux objets ont un bail actif qui doit être rompu ou libéré avant que l’opération puisse réussir.

Capture d’écran montrant une requête kusto et les résultats de la requête qui affiche les tentatives d’échec de suppression d’objets.

Voir aussi