Noções básicas sobre as opções de migração para alertas mais novos

  • Artigo

Os alertas clássicos foram retirados para os usuários de nuvem pública. Os alertas clássicos da nuvem do Azure Governamental e do Microsoft Azure operado pela 21Vianet serão desativados no dia 29 de fevereiro de 2024.

Este artigo explica como funciona a migração manual e a ferramenta de migração voluntária, que será usada para migrar as demais regras de alerta. Ele também descreve soluções para alguns problemas comuns.

Importante

Os alertas do log de atividades (incluindo alertas de Integridade do serviço) e os alertas de pesquisa de log não são afetados pela migração. A migração se aplica somente às regras de alerta clássicas descritas aqui.

Observação

Se suas regras de alerta clássicas forem inválidas, ou seja, se estiverem em métricas preteridas ou recursos que foram excluídos, elas não serão migradas e não estarão disponíveis depois que o serviço for desativado.

Como migrar manualmente alertas clássicos para alertas mais recentes

Os clientes que estão interessados em migrar manualmente seus alertas restantes já podem fazer isso usando as seções a seguir. Isso também inclui métricas desativadas e que, portanto, não podem ser migradas diretamente.

Métricas de convidado em máquinas virtuais

Antes de criar novos alertas de métrica em métricas de convidado, as métricas de convidado devem ser enviadas para o repositório de logs do Azure Monitor. Siga estas instruções para criar alertas:

Há mais opções para coletar métricas de convidado e alertar sobre elas, saiba mais.

Métricas de Armazenamento e de Conta de Armazenamento Clássica

Todos os alertas clássicos em contas de armazenamento podem ser migrados, exceto alertas nessas métricas:

  • PercentAuthorizationError
  • PercentClientOtherError
  • PercentNetworkError
  • PercentClientOtherError
  • PercentSuccess
  • PercentThrottlingError
  • PercentTimeoutError
  • AnonymousThrottlingError
  • SASThrottlingError
  • ThrottlingError

As regras de alerta clássicas em métricas de Porcentagem devem ser migradas com base no mapeamento entre métricas de armazenamento antigas e novas. Os limites precisarão ser modificados adequadamente porque a nova métrica disponível é absoluta.

As regras de alerta clássicas em AnonymousThrottlingError, SASThrottlingError e ThrottlingError devem ser divididas em dois novos alertas porque não há nenhuma métrica combinada que forneça a mesma funcionalidade. Os limites precisarão ser adaptados adequadamente.

Métricas do Azure Cosmos DB

Todos os alertas clássicos nas métricas do Azure Cosmos DB podem ser migrados, exceto os alertas nestas métricas:

  • Média de Solicitações por Segundo
  • Nível de coerência
  • Http 2xx
  • Http 3xx
  • Máximo de RUPM Consumido por Minuto
  • Máximo de RUs por Segundo
  • Outros Encargos de Solicitação do Mongo
  • Outras Tarifas de Solicitação do Mongo
  • Latência de Leitura Observada
  • Latência de Gravação Observada
  • Disponibilidade do serviço
  • Capacidade de Armazenamento

A Média de Solicitações por Segundo, o Nível de Consistência, o Máximo de RUPM Consumido por Minuto, o Máximo de RUs por Segundo, a Latência de Leitura Observada, a Latência de Gravação Observada e a Capacidade de Armazenamento não estão disponíveis no novo sistema no momento.

Alertas sobre métricas de solicitação como Http 2xx, Http 3xx e Disponibilidade de Serviço não são migrados porque a maneira como as solicitações são contadas é diferente entre métricas clássicas e novas métricas. Os alertas sobre essas métricas precisarão ser recriados manualmente com limites ajustados.

Regras de alerta clássicas em métricas preteridas

A seguir estão as regras de alerta clássicas em métricas com suporte anterior, mas que eventualmente foram preteridas. Um pequeno percentual de clientes pode ter regras de alerta clássicas inválidas em tais métricas. Como essas regras de alerta são inválidas, elas não serão migradas.

Tipo de recurso Métrica(s) preterida(s)
Microsoft.DBforMySQL/servers compute_consumption_percent, compute_limit
Microsoft.DBforPostgreSQL/servers compute_consumption_percent, compute_limit
Microsoft.Network/publicIPAddresses defaultddostriggerrate
Microsoft.SQL/servers/databases service_level_objective, storage_limit, storage_used, throttling, dtu_consumption_percent, storage_used
Microsoft.Web/hostingEnvironments/multirolepools averagememoryworkingset
Microsoft.Web/hostingEnvironments/workerpools bytesreceived, httpqueuelength

Como novas regras de alerta e grupos de ações equivalentes são criados

A ferramenta de migração converte suas regra de alerta clássicas em regras de alerta novas e grupos de ação equivalentes. Para as regras de alerta mais clássicas, as novas regras de alerta equivalentes estão na mesma métrica com as mesmas propriedades, como windowSize e aggregationType. No entanto, há algumas regras de alerta clássicas em métricas que têm uma métrica diferente e equivalente no novo sistema. Os seguintes princípios se aplicam à migração de alertas clássicos, a menos que especificado na seção abaixo:

  • Frequência: define com que frequência uma regra de alerta clássica ou nova verifica a condição. O frequency nas regras de alerta clássicas não era configurável pelo usuário e era sempre de 5 minutos para todos os tipos de recursos. A frequência de regras equivalentes também é definida como 5 min.
  • Tipo de Agregação: define como a métrica é agregada na janela de interesse. O aggregationType também é o mesmo entre alertas clássicos e novos alertas para a maioria das métricas. Em alguns casos, como a métrica é diferente entre alertas clássicos e novos alertas, o aggregationType equivalente ou o primary Aggregation Type definido para a métrica é usado.
  • Unidades: a propriedade da métrica na qual o alerta é criado. Algumas métricas equivalentes têm unidades diferentes. O limite é ajustado adequadamente, conforme necessário. Por exemplo, se a métrica original tiver segundos como unidades, mas a nova métrica equivalente tiver milissegundos como unidades, o limite original será multiplicado por 1000 para garantir o mesmo comportamento.
  • Tamanho da Janela: define a janela sobre a qual os dados de métrica são agregados para servir de comparação com o limite. Para valores windowSize padrão como 5 min, 15 min, 30 min, 1 hora, 3 horas, 6 horas, 12 horas, 1 dia, não há nenhuma alteração feita para a nova regra de alerta equivalente. Para outros valores, o windowSize mais próximo é usado. Para a maioria dos clientes, não há nenhum efeito com essa alteração. Para um pequeno percentual de clientes, pode haver a necessidade de ajustar o limite para obter exatamente o mesmo comportamento.

Nas seções a seguir, detalhamos as métricas que têm uma métrica diferente e equivalente no novo sistema. Qualquer métrica que permaneça a mesma para regras de alerta clássicas e novas não está listada. Você pode encontrar uma lista de métricas com suporte no novo sistema aqui.

Microsoft.Storage/storageAccounts e Microsoft.ClassicStorage/storageAccounts

Para serviços de conta de armazenamento como blob, tabela, arquivo e fila, as seguintes métricas são mapeadas para métricas equivalentes, conforme mostrado abaixo:

Métrica em alertas clássicos Métrica equivalente em novos alertas Comentários
AnonymousAuthorizationError Métrica Transações com dimensões "ResponseType"="AuthorizationError" e "Authentication" = "Anonymous"
AnonymousClientOtherError Métrica Transações com dimensões "ResponseType"="ClientOtherError" e "Authentication" = "Anonymous"
AnonymousClientTimeOutError Métrica Transações com dimensões "ResponseType"="ClientTimeOutError" e "Authentication" = "Anonymous"
AnonymousNetworkError Métrica Transações com dimensões "ResponseType"="NetworkError" e "Authentication" = "Anonymous"
AnonymousServerOtherError Métrica Transações com dimensões "ResponseType"="ServerOtherError" e "Authentication" = "Anonymous"
AnonymousServerTimeOutError Métrica Transações com dimensões "ResponseType"="ServerTimeOutError" e "Authentication" = "Anonymous"
AnonymousSuccess Métrica Transações com dimensões "ResponseType"="Success" e "Authentication" = "Anonymous"
AuthorizationError Métrica Transações com dimensões "ResponseType"="AuthorizationError"
AverageE2ELatency SuccessE2ELatency
AverageServerLatency SuccessServerLatency
Capacity BlobCapacity Use aggregationType “average” em vez de “last”. A métrica se aplica somente aos serviços Blob
ClientOtherError Métrica Transações com dimensões "ResponseType"="ClientOtherError"
ClientTimeoutError Métrica Transações com dimensões "ResponseType"="ClientTimeOutError"
ContainerCount ContainerCount Use aggregationType “average” em vez de “last”. A métrica se aplica somente aos serviços Blob
NetworkError Métrica Transações com dimensões "ResponseType"="NetworkError"
ObjectCount BlobCount Use aggregationType “average” em vez de “last”. A métrica se aplica somente aos serviços Blob
SASAuthorizationError Métrica Transações com dimensões "ResponseType"="AuthorizationError" e "Authentication" = "SAS"
SASClientOtherError Métrica Transações com dimensões "ResponseType"="ClientOtherError" e "Authentication" = "SAS"
SASClientTimeOutError Métrica Transações com dimensões "ResponseType"="ClientTimeOutError" e "Authentication" = "SAS"
SASNetworkError Métrica Transações com dimensões "ResponseType"="NetworkError" e "Authentication" = "SAS"
SASServerOtherError Métrica Transações com dimensões "ResponseType"="ServerOtherError" e "Authentication" = "SAS"
SASServerTimeOutError Métrica Transações com dimensões "ResponseType"="ServerTimeOutError" e "Authentication" = "SAS"
SASSuccess Métrica Transações com dimensões "ResponseType"="Success" e "Authentication" = "SAS"
ServerOtherError Métrica Transações com dimensões "ResponseType"="ServerOtherError"
ServerTimeOutError Métrica Transações com dimensões "ResponseType"="ServerTimeOutError"
Êxito Métrica Transações com dimensões "ResponseType"="Success"
TotalBillableRequests Transactions
TotalEgress Saída
TotalIngress Entrada
TotalRequests Transactions

Microsoft.DocumentDB/databaseAccounts

No Azure Cosmos DB, as métricas equivalentes são conforme mostrado abaixo:

Métrica em alertas clássicos Métrica equivalente em novos alertas Comentários
AvailableStorage AvailableStorage
Tamanho dos dados DataUsage
Contagem de documentos DocumentCount
Tamanho do Índice IndexUsage
Serviço indisponível ServiceAvailability
TotalRequestUnits TotalRequestUnits
Solicitações Limitadas TotalRequests com dimensão "StatusCode" = "429" O tipo de agregação “Average” é corrigido para “Count”
Erros internos do servidor TotalRequests com dimensão "StatusCode" = "500"} O tipo de agregação “Average” é corrigido para “Count”
Http 401 TotalRequests com dimensão "StatusCode" = "401" O tipo de agregação “Average” é corrigido para “Count”
Http 400 TotalRequests com dimensão "StatusCode" = "400" O tipo de agregação “Average” é corrigido para “Count”
Total de Solicitações TotalRequests O tipo de agregação “Max” é corrigido para “Count”
Encargo de Solicitação de Contagem do Mongo MongoRequestCharge com dimensão "CommandName" = "count"
Taxa de Solicitação de Contagem do Mongo MongoRequestsCount com dimensão "CommandName" = "count"
Encargo de Solicitação de Exclusão do Mongo MongoRequestCharge com dimensão "CommandName" = "delete"
Taxa de Solicitação de Exclusão do Mongo MongoRequestsCount com dimensão "CommandName" = "delete"
Encargo de Solicitação de Inserção do Mongo MongoRequestCharge com dimensão "CommandName" = "insert"
Taxa de Solicitação de Inserção do Mongo MongoRequestsCount com dimensão "CommandName" = "insert"
Encargo de Solicitação de Consulta do Mongo MongoRequestCharge com dimensão "CommandName" = "find"
Taxa de Solicitação de Consulta do Mongo MongoRequestsCount com dimensão "CommandName" = "find"
Encargo de Solicitação de Atualização do Mongo MongoRequestCharge com dimensão "CommandName" = "update"
Solicitações com Falha de Inserção do Mongo MongoRequestCount com dimensões "CommandName" = "insert" e "Status" = "failed" O tipo de agregação “Average” é corrigido para “Count”
Solicitações com Falha de Consulta do Mongo MongoRequestCount com dimensões "CommandName" = "query" e "Status" = "failed" O tipo de agregação “Average” é corrigido para “Count”
Solicitações com Falha de Contagem do Mongo MongoRequestCount com dimensões "CommandName" = "count" e "Status" = "failed" O tipo de agregação “Average” é corrigido para “Count”
Solicitações com Falha de Atualização do Mongo MongoRequestCount com dimensões "CommandName" = "update" e "Status" = "failed" O tipo de agregação “Average” é corrigido para “Count”
Outras Solicitações com Falha do Mongo MongoRequestCount com dimensões "CommandName" = "other" e "Status" = "failed" O tipo de agregação “Average” é corrigido para “Count”
Solicitações com Falha de Exclusão do Mongo MongoRequestCount com dimensões "CommandName" = "delete" e "Status" = "failed" O tipo de agregação “Average” é corrigido para “Count”

Como os grupos de ação equivalentes são criados

As regras de alerta clássicas tinham email, webhook, aplicativo lógico e ações de runbook vinculadas à própria regra de alerta. As novas regras de alerta usam grupos de ação que podem ser reutilizados em várias regras de alerta. A ferramenta de migração cria um grupo de ação único para as mesmas ações, independentemente de quantas regras de alerta estão usando a ação. Os grupos de ação criados pela ferramenta de migração usam o formato de nomenclatura “Migrated_AG*”.

Observação

Os alertas clássicos enviaram emails localizados com base na localidade do administrador clássico quando usados para notificar funções de administrador clássicas. Os novos emails de alerta são enviados por meio de Grupos de Ação e são somente em inglês.

Fases de distribuição

A ferramenta de migração está sendo distribuída em fases para os clientes que usam as regras de alerta clássicas. Os proprietários da assinatura receberão um email quando a assinatura estiver pronta para ser migrada usando a ferramenta.

Observação

Como a ferramenta está sendo distribuída em fases, você pode ver que algumas de suas assinaturas ainda não estão prontas para serem migradas durante as fases iniciais.

A maioria das assinaturas está marcada atualmente como pronta para migração. Somente as assinaturas que têm alertas clássicos nos tipos de recursos a seguir ainda não estão prontas para migração.

  • Microsoft.classicCompute/domainNames/slots/roles
  • Microsoft.insights/components

Quem pode disparar a migração?

Qualquer usuário com a função interna de Colaborador de Monitoramento no nível da assinatura pode disparar a migração. Os usuários que têm uma função personalizada com as seguintes permissões também podem disparar a migração:

  • */leitura
  • Microsoft.Insights/actiongroups/*
  • Microsoft.Insights/AlertRules/*
  • Microsoft.Insights/metricAlerts/*
  • Microsoft.AlertsManagement/smartDetectorAlertRules/*

Observação

Além de ter as permissões acima, sua assinatura também deve ser registrada com o provedor de recursos Microsoft.AlertsManagement. Isso é necessário para migrar com êxito os alertas de Anomalia de Falha no Application Insights.

Problemas comuns e suas soluções

Depois de disparar a migração, você receberá um email nos endereços fornecidos para notificá-lo de que a migração foi concluída ou se alguma ação adicional é necessária. Esta seção descreve alguns problemas comuns e como lidar com eles.

Falha na validação

Devido a algumas alterações recentes nas regras de alerta clássicas em sua assinatura, a assinatura não pode ser migrada. Esse problema é temporário. Você pode reiniciar a migração depois que o status de migração voltar para Pronto para migração em alguns dias.

Bloqueio de escopo nos impedindo de migrar suas regras

Como parte da migração, novos alertas de métrica e novos grupos de ação serão criados e as regras de alerta clássicas serão excluídas. No entanto, um bloqueio de escopo pode impedi-lo de criar ou excluir recursos. Dependendo do bloqueio de escopo, algumas ou todas as regras não puderam ser migradas. Você pode resolver esse problema removendo o bloqueio de escopo para a assinatura, o grupo de recursos ou o recurso, que está listado na ferramenta de migração, e disparando a migração novamente. O bloqueio de escopo não pode ser desabilitado e deve ser removido durante o processo de migração. Saiba mais sobre como gerenciar bloqueios de escopo.

Política com o efeito “Deny” nos impedindo de migrar suas regras

Como parte da migração, novos alertas de métrica e novos grupos de ação serão criados e as regras de alerta clássicas serão excluídas. No entanto, uma atribuição do Azure Policy pode nos impedir de criar recursos. Dependendo da atribuição de política, algumas ou todas as regras não puderam ser migradas. As atribuições de política que estão bloqueando o processo são listadas na ferramenta de migração. Resolva esse problema:

Próximas etapas