Otimizar os custos ao gerir automaticamente o ciclo de vida dos dados

Os conjuntos de dados têm ciclos de vida exclusivos. No início do ciclo de vida, as pessoas acedem frequentemente a alguns dados. Mas a necessidade de acesso geralmente diminui drasticamente à medida que os dados envelhecem. Alguns dados permanecem inativos na cloud e raramente são acedidos uma vez armazenados. Alguns conjuntos de dados expiram dias ou meses após a criação, enquanto outros conjuntos de dados são lidos e modificados ativamente ao longo das respetivas durações. A gestão do ciclo de vida do Armazenamento do Azure oferece uma política baseada em regras que pode utilizar para fazer a transição de dados do blob para as camadas de acesso apropriados ou expirar dados no final do ciclo de vida.

Nota

Cada última atualização da hora de acesso é cobrada como uma "outra transação" no máximo uma vez a cada 24 horas por objeto, mesmo que seja acedida 1000 vezes num dia. Isto é separado dos custos de transações de leitura.

Com a política de gestão do ciclo de vida, pode:

  • Faça a transição de blobs de esporádico para frequente imediatamente quando são acedidos, para otimizar o desempenho.
  • Transfira as versões atuais de um blob, versões anteriores de um blob ou instantâneos de blobs para uma camada de armazenamento mais fria se estes objetos não tiverem sido acedidos ou modificados durante um período de tempo, para otimizar o custo. Neste cenário, a política de gestão do ciclo de vida pode mover objetos de frequente para esporádico, de frequente para arquivo ou de esporádico para arquivo.
  • Elimine as versões atuais de um blob, versões anteriores de um blob ou instantâneos de blobs no final dos respetivos ciclos de vida.
  • Defina regras a serem executadas uma vez por dia ao nível da conta de armazenamento.
  • Aplique regras a contentores ou a um subconjunto de blobs, utilizando prefixos de nome ou etiquetas de índice de blobs como filtros.

Considere um cenário em que os dados são acedidos frequentemente durante as fases iniciais do ciclo de vida, mas apenas ocasionalmente após duas semanas. Além do primeiro mês, o conjunto de dados raramente é acedido. Neste cenário, o armazenamento frequente é o melhor durante as fases iniciais. O armazenamento esporádico é mais adequado para acesso ocasional. O armazenamento de arquivo é a melhor opção de camada após os dados terem mais de um mês. Ao mover dados para a camada de armazenamento adequada com base na sua idade com regras de política de gestão do ciclo de vida, pode conceber a solução menos dispendiosa para as suas necessidades.

As políticas de gestão do ciclo de vida são suportadas para blobs de blocos e blobs de acréscimo nas contas fins gerais v2, blob de blocos premium e de Armazenamento de Blobs. A gestão do ciclo de vida não afeta os contentores do sistema, como os $logs contentores ou $web .

Importante

Se um conjunto de dados precisar de ser legível, não defina uma política para mover blobs para a camada de arquivo. Os blobs na camada de arquivo não podem ser lidos a menos que sejam reidratados pela primeira vez, um processo que pode ser moroso e dispendioso. Para obter mais informações, veja Descrição geral da reidratação de blobs da camada de arquivo.

Definição da política de gestão do ciclo de vida

Uma política de gestão do ciclo de vida é uma coleção de regras num documento JSON. O seguinte JSON de exemplo mostra uma definição de regra completa:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

Uma política é uma coleção de regras, conforme descrito na tabela seguinte:

Nome do parâmetro Tipo de parâmetro Notas
rules Uma matriz de objetos de regra É necessária, pelo menos, uma regra numa política. Pode definir até 100 regras numa política.

Cada regra na política tem vários parâmetros, descritos na tabela seguinte:

Nome do parâmetro Tipo de parâmetro Notas Necessário
name String Um nome de regra pode incluir até 256 carateres alfanuméricos. O nome da regra é sensível às maiúsculas e minúsculas. Tem de ser exclusivo dentro de uma política. Verdadeiro
enabled Booleano Um booleano opcional para permitir que uma regra seja temporariamente desativada. O valor predefinido é verdadeiro se não estiver definido. Falso
type Um valor de numeração O tipo válido atual é Lifecycle. Verdadeiro
definition Um objeto que define a regra de ciclo de vida Cada definição é composta por um conjunto de filtros e um conjunto de ações. Verdadeiro

Definição da regra de gestão do ciclo de vida

Cada definição de regra numa política inclui um conjunto de filtros e um conjunto de ações. O conjunto de filtros limita as ações de regras a um determinado conjunto de objetos dentro de um contentor ou nomes de objetos. O conjunto de ações aplica a camada ou elimina as ações ao conjunto filtrado de objetos.

Regra de exemplo

A seguinte regra de exemplo filtra a conta para executar as ações em objetos que existem no interior sample-container e começar com blob1.

  • Blob de camada para a camada esporádica 30 dias após a última modificação
  • Blob de camadas para arquivar camada 90 dias após última modificação
  • Eliminar blob 2.555 dias (sete anos) após a última modificação
  • Eliminar versões anteriores 90 dias após a criação
{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastTierChangeGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

Nota

O elemento baseBlob numa política de gestão do ciclo de vida refere-se à versão atual de um blob. O elemento de versão refere-se a uma versão anterior.

Filtros de regras

Filtra as ações de regra de limite para um subconjunto de blobs na conta de armazenamento. Se for definido mais do que um filtro, é executada uma lógica AND em todos os filtros.

Os filtros incluem:

Nome do filtro Tipo de filtro Notas É Necessário
blobTypes Uma matriz de valores de numeração predefinidos. A versão atual suporta blockBlob e appendBlob. Apenas a eliminação é suportada para appendBlob, o escalão definido não é suportado. Yes
prefixMatch Uma matriz de cadeias para que os prefixos sejam correspondidos. Cada regra pode definir até 10 prefixos sensíveis a maiúsculas e minúsculas. Uma cadeia de prefixo tem de começar com um nome de contentor. Por exemplo, se quiser corresponder todos os blobs em https://myaccount.blob.core.windows.net/sample-container/blob1/... para uma regra, o prefixoMatch é sample-container/blob1.

Para corresponder exatamente ao nome do blob, inclua a barra à direita ('/'), por exemplo, sample-container/blob1/. Para corresponder ao padrão de nome, omita a barra à direita para a frente, por exemplo, sample-container/blob1.
Se não definir prefixMatch, a regra aplica-se a todos os blobs na conta de armazenamento. No
blobIndexMatch Uma matriz de valores de dicionário que consiste em condições de chave de etiqueta de índice de blobs e de valor a corresponder. Cada regra pode definir até 10 condições de etiquetas de índice de blobs. Por exemplo, se quiser corresponder todos os blobs a Project = Contoso uma https://myaccount.blob.core.windows.net/ regra, o blobIndexMatch é {"name": "Project","op": "==","value": "Contoso"}. Se não definir blobIndexMatch, a regra aplica-se a todos os blobs na conta de armazenamento. No

Para saber mais sobre a funcionalidade de índice de blobs juntamente com problemas e limitações conhecidos, veja Gerir e localizar dados em Armazenamento de Blobs do Azure com o índice de blobs.

Ações de regras

As ações são aplicadas aos blobs filtrados quando a condição de execução é cumprida.

A gestão do ciclo de vida suporta a camada e a eliminação de versões atuais, versões anteriores e instantâneos de blobs. Defina pelo menos uma ação para cada regra.

Nota

A camada ainda não é suportada numa conta de armazenamento de blobs de blocos premium. Para todas as outras contas, o arrumo só é permitido em blobs de blocos e não para blobs de acréscimo e páginas.

Ação Versão Atual Instantâneo Versões anteriores
tierToCool Suportado para blockBlob Suportado Suportado
enableAutoTierToHotFromCool Suportado para blockBlob Não suportado Não suportado
tierToArchive Suportado para blockBlob Suportado Suportado
eliminar1 Suportado para blockBlob e appendBlob Suportado Suportado

1 Quando aplicada a uma conta com um espaço de nomes hierárquico ativado, uma ação de eliminação remove diretórios vazios. Se o diretório não estiver vazio, a ação de eliminação remove os objetos que cumprem as condições da política no primeiro ciclo de 24 horas. Se essa ação resultar num diretório vazio que também cumpra as condições da política, esse diretório será removido no próximo ciclo de 24 horas e assim sucessivamente.

Nota

Se definir mais do que uma ação no mesmo blob, a gestão do ciclo de vida aplica a ação menos dispendiosa ao blob. Por exemplo, a ação delete é mais barata do que a ação tierToArchive. A ação tierToArchive é mais barata do que a ação tierToCool.

As condições de execução baseiam-se na idade. As versões atuais utilizam a última hora de modificação ou hora do último acesso, as versões anteriores utilizam a hora de criação da versão e os instantâneos de blobs utilizam o tempo de criação de instantâneos para controlar a idade.

Condição de execução de ação Valor da condição Descrição
daysAfterModificationGreaterThan Valor inteiro que indica a idade em dias A condição para ações numa versão atual de um blob
daysAfterCreationGreaterThan Valor inteiro que indica a idade em dias A condição para ações na versão atual ou versão anterior de um blob ou instantâneo de blob
daysAfterLastAccessTimeGreaterThan1 Valor inteiro que indica a idade em dias A condição para uma versão atual de um blob quando o controlo de acesso está ativado
daysAfterLastTierChangeGreaterThan Valor inteiro que indica a idade em dias após a última alteração da camada de blobs Esta condição aplica-se apenas a ações tierToArchive e só pode ser utilizada com a daysAfterModificationGreaterThan condição.

1 Se o último controlo de tempo de acesso não estiver ativado para um blob, daysAfterLastAccessTimeGreaterThan utiliza a data em que a política de ciclo de vida foi ativada em vez da LastAccessTime propriedade do blob.

Evento concluído da política de ciclo de vida

O LifecyclePolicyCompleted evento é gerado quando as ações definidas por uma política de gestão do ciclo de vida são executadas. O seguinte json mostra um evento de exemplo LifecyclePolicyCompleted .

{
    "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",
        "deleteSummary": {
            "totalObjectsCount": 16,
            "successCount": 14,
            "errorList": ""
        },
        "tierToCoolSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToArchiveSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        }
    },
    "dataVersion": "1",
    "metadataVersion": "1"
}

A tabela seguinte descreve o esquema do LifecyclePolicyCompleted evento.

Campo Tipo Descrição
scheduleTime cadeia (de carateres) A hora em que a política de ciclo de vida foi agendada
deleteSummary byte de vetor<> O resumo dos resultados dos blobs agendados para a operação de eliminação
tierToCoolSummary byte de vetor<> O resumo dos resultados dos blobs agendados para a operação camada a esporádica
tierToArchiveSummary byte de vetor<> O resumo dos resultados dos blobs agendados para a operação camada a arquivo

Exemplos de políticas de ciclo de vida

Os exemplos seguintes demonstram como abordar cenários comuns com regras de política de ciclo de vida.

Mover dados de envelhecimento para uma camada mais fria

Este exemplo mostra como fazer a transição de blobs de blocos prefixados com sample-container/blob1 ou container2/blob2. A política faz a transição de blobs que não foram modificados há mais de 30 dias para o armazenamento esporádico e os blobs não modificados há 90 dias para a camada de arquivo:

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Mover dados com base no último acesso

Pode ativar o último controlo de tempo de acesso para manter um registo de quando o blob é lido ou escrito pela última vez e como um filtro para gerir a camada e a retenção dos seus dados de blobs. Para saber como ativar o controlo da hora do último acesso, veja Opcionalmente ativar o controlo de tempo de acesso.

Quando o controlo da hora do último acesso está ativado, a propriedade blob chamada LastAccessTime é atualizada quando um blob é lido ou escrito. Uma operação Obter Blob é considerada uma operação de acesso. Obter Propriedades do Blob, Obter Metadados de Blobs e Obter Etiquetas de Blobs não são operações de acesso e, portanto, não atualize a última hora de acesso.

Para minimizar o efeito na latência de acesso de leitura, apenas a primeira leitura das últimas 24 horas atualiza a última hora de acesso. As leituras subsequentes no mesmo período de 24 horas não atualizam a última hora de acesso. Se um blob for modificado entre leituras, a última hora de acesso será a mais recente dos dois valores.

Se o controlo da hora do último acesso estiver ativado para um blob, a gestão do ciclo de vida utiliza LastAccessTime para determinar se a condição de execução daysAfterLastAccessTimeGreaterThan é cumprida. Se o controlo da hora do último acesso não estiver ativado, utiliza a data em que a política de ciclo de vida foi ativada em vez de LastAccessTime.

No exemplo seguinte, os blobs são movidos para o armazenamento esporádico se não tiverem sido acedidos durante 30 dias. A enableAutoTierToHotFromCool propriedade é um valor booleano que indica se um blob deve ser colocado automaticamente em camadas de volta esporádico para quente se for acedido novamente depois de ser colocado em camadas para esporádico.

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

Arquivar dados após a ingestão

Alguns dados permanecem inativos na cloud e raramente são acedidos, se alguma vez forem acedidos. A seguinte política de ciclo de vida está configurada para arquivar dados pouco depois de ingeridos. Este exemplo transi os blobs de blocos num contentor com o nome archivecontainer para uma camada de arquivo. A transição é efetuada ao agir em blobs 0 dias após a última modificação da hora.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { 
                "daysAfterModificationGreaterThan": 0
              }
          }
        }
      }
    }
  ]
}

Nota

A Microsoft recomenda que carregue os blobs diretamente na camada de arquivo para uma maior eficiência. Pode especificar a camada de arquivo no cabeçalho x-ms-access-tier na operação Colocar Blob ou Colocar Lista de Blocos . O cabeçalho x-ms-access-tier é suportado com a versão REST 2018-11-09 e mais recente ou com as bibliotecas de cliente de armazenamento de blobs mais recentes.

Expirar dados com base na idade

Espera-se que alguns dados expirem dias ou meses após a criação. Pode configurar uma política de gestão do ciclo de vida para expirar dados através da eliminação com base na idade dos dados. O exemplo seguinte mostra uma política que elimina todos os blobs de blocos que não foram modificados nos últimos 365 dias.

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Eliminar dados com etiquetas de índice de blobs

Alguns dados só devem expirar se forem explicitamente marcados para eliminação. Pode configurar uma política de gestão do ciclo de vida para expirar dados marcados com atributos de chave/valor de índice de blobs. O exemplo seguinte mostra uma política que elimina todos os blobs de blocos etiquetados com Project = Contoso. Para saber mais sobre o índice de blobs, veja Gerir e localizar dados em Armazenamento de Blobs do Azure com o índice de blobs.

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Gerir versões anteriores

Para dados modificados e acedidos regularmente ao longo da sua duração, pode ativar o controlo de versões do armazenamento de blobs para manter automaticamente versões anteriores de um objeto. Pode criar uma política para colocar em camadas ou eliminar versões anteriores. A idade da versão é determinada ao avaliar o tempo de criação da versão. Esta regra de política move versões anteriores no contentor activedata com 90 dias ou mais após a criação da versão para o escalão esporádico e elimina versões anteriores com 365 dias ou mais.

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata"
          ]
        }
      }
    }
  ]
}

Suporte de funcionalidades

O suporte para esta funcionalidade pode ser afetado ao ativar Data Lake Storage Gen2, o protocolo NFS (Network File System) 3.0 ou o SSH File Transfer Protocol (SFTP).

Se tiver ativado qualquer uma destas capacidades, veja Suporte de funcionalidades de Armazenamento de Blobs nas contas de Armazenamento do Azure para avaliar o suporte para esta funcionalidade.

Disponibilidade e preços regionais

A funcionalidade de gestão do ciclo de vida está disponível em todas as regiões do Azure.

As políticas de gestão do ciclo de vida são gratuitas. Os clientes são cobrados pelos custos de operação padrão para as chamadas da API Definir Camada de Blobs . As operações de eliminação são gratuitas. No entanto, outros serviços e utilitários do Azure, como Microsoft Defender para Armazenamento, podem cobrar pelas operações geridas através de uma política de ciclo de vida.

Cada atualização para a última hora de acesso de um blob é faturada na outra categoria de operações .

Para obter mais informações sobre preços, veja Preços do Blob de Blocos.

FAQ

Criei uma nova política. Por que motivo as ações não são executadas imediatamente?

A plataforma executa a política do ciclo de vida uma vez por dia. Depois de configurar uma política, pode demorar até 24 horas a entrar em vigor. Assim que a política estiver em vigor, poderá demorar até 24 horas para algumas ações serem executadas pela primeira vez.

Se atualizar uma política existente, quanto tempo demora a execução das ações?

A política atualizada demora até 24 horas para entrar em vigor. Quando a política estiver em vigor, pode demorar até 24 horas para que as ações sejam executadas. Por conseguinte, as ações da política podem demorar até 48 horas a serem concluídas. Se a atualização for para desativar ou eliminar uma regra e enableAutoTierToHotFromCool tiver sido utilizada, a colocação em camadas automáticas para o escalão Frequente continuará a ocorrer. Por exemplo, defina uma regra que inclui enableAutoTierToHotFromCool com base no último acesso. Se a regra for desativada/eliminada e um blob estiver atualmente esporádico e, em seguida, acedido, será movido novamente para Frequente, uma vez que é aplicado no acesso fora da gestão do ciclo de vida. Em seguida, o blob não passa de Frequente para Esporádico, dado que a regra de gestão do ciclo de vida está desativada/eliminada. A única forma de impedir autoTierToHotFromCool é desativar o controlo da hora do último acesso.

Reidrati um blob arquivado. Como devo proceder para impedir que seja movido temporariamente para a camada Arquivo?

Se existir uma política de gestão do ciclo de vida em vigor para a conta de armazenamento, reidratar um blob alterando o escalão pode resultar num cenário em que a política de ciclo de vida move o blob novamente para a camada de arquivo. Isto pode acontecer se a hora da última modificação, hora de criação ou hora de último acesso estiver fora do limiar definido para a política. Existem três formas de impedir que isto aconteça:

  • Adicione a daysAfterLastTierChangeGreaterThan condição à ação tierToArchive da política. Esta condição aplica-se apenas à hora da última modificação. Veja Utilizar políticas de gestão do ciclo de vida para arquivar blobs.

  • Desative a regra que afeta temporariamente este blob para impedir que seja arquivado novamente. Reativar a regra quando o blob pode ser movido em segurança para a camada de arquivo.

  • Se o blob precisar de permanecer permanentemente na camada frequente ou esporádica, copie o blob para outra localização onde a política de gestão do ciclo de vida não esteja em vigor.

A cadeia de correspondência do prefixo de blobs não aplicou a política aos blobs esperados

O campo de correspondência do prefixo de blobs de uma política é um caminho de blobs completo ou parcial utilizado para corresponder aos blobs aos quais quer aplicar as ações da política. O caminho tem de começar com o nome do contentor. Se não for especificada nenhuma correspondência de prefixo, a política será aplicada a todos os blobs na conta de armazenamento. O formato da cadeia de correspondência do prefixo é [container name]/[blob name].

Tenha em atenção os seguintes pontos sobre a cadeia de correspondência do prefixo:

  • Uma cadeia de correspondência de prefixo como container1/ aplica-se a todos os blobs no contentor com o nome container1. Uma cadeia de correspondência de prefixo do contentor1, sem o caráter de barra (/) à direita, aplica-se a todos os blobs em todos os contentores onde o nome do contentor começa com o contentor de cadeia1. O prefixo corresponderá a contentores com o nome container11, container1234, container1ab, etc.
  • Uma cadeia de correspondência de prefixo de contentor1/sub1/ aplica-se a todos os blobs no contentor com o nome container1 que começam com a cadeia sub1/. Por exemplo, o prefixo corresponderá a blobs com o nome container1/sub1/test.txt ou container1/sub1/sub2/test.txt.
  • O caráter asterisco * é um caráter válido num nome de blob. Se o caráter asterisco for utilizado num prefixo, o prefixo corresponderá aos blobs com um asterisco nos respetivos nomes. O asterisco não funciona como um caráter universal.
  • O caráter de ponto de interrogação ? é um caráter válido num nome de blob. Se o caráter de ponto de interrogação for utilizado num prefixo, o prefixo corresponderá aos blobs com um ponto de interrogação nos respetivos nomes. O ponto de interrogação não funciona como caráter universal.
  • A correspondência de prefixos considera apenas comparações lógicas positivas (=). As comparações lógicas negativas (!=) são ignoradas.

Existe alguma forma de identificar o momento em que a política será executada?

Infelizmente, não há forma de controlar o momento em que a política será executada, uma vez que se trata de um processo de agendamento em segundo plano. No entanto, a plataforma executará a política uma vez por dia.

Passos seguintes