Descrever métricas de desempenho críticas
Você viu como coletar dados no Azure Monitor e no Monitor de Desempenho do Windows. Agora você aprenderá a criar métricas no Azure Monitor que permitem disparar alertas ou executar respostas de erro automatizadas.
Revisão das métricas do Azure
O serviço Azure Monitor inclui a capacidade de controlar várias métricas sobre a integridade geral de um determinado recurso. As métricas são coletadas em intervalos regulares e são o gateway para processos de alerta que ajudarão a resolver problemas de maneira rápida e eficiente. Métricas do Azure Monitor é um subsistema avançado que permite não apenas analisar e visualizar seus dados de desempenho, mas também disparar alertas que notificam os administradores ou geram ações automatizadas que podem disparar um runbook ou um webhook do Automação do Azure. Você também tem a opção de arquivar seus dados do Métricas do Azure no Armazenamento do Microsoft Azure, pois os dados ativos são armazenados apenas por 93 dias.
Criar alertas de métricas
Utilizando o portal do Azure, você pode criar regras de alerta com base em métricas definidas na seção Visão Geral da folha Azure Monitor. Os alertas do Azure Monitor podem ser delimitados de três maneiras. Usando Máquinas Virtuais do Microsoft Azure como exemplo, você pode especificar o escopo como:
Uma lista de máquinas virtuais em uma região do Azure dentro de uma assinatura
Todas as máquinas virtuais (em uma única região do Azure) em um ou mais grupos de recursos em uma assinatura
Todas as máquinas virtuais (em uma região do Azure) em uma assinatura
Dessa maneira, você pode criar uma regra de alerta com base em recursos contidos nos grupos de recursos, conforme mostrado.
O exemplo mostrado abaixo reflete uma máquina virtual chamada SQL2019, na qual estamos criando um alerta que está no escopo da máquina virtual individual.
Independentemente do escopo do alerta, o processo de criação é o mesmo.
Na tela Alertas, clique em Nova Regra de Alerta. Se um alerta for criado de dentro do escopo de um recurso, os valores do recurso serão preenchidos para você. Você pode ver que o recurso é a máquina virtual SQL2019, a assinatura é Dev-Test-Lab e o grupo de recursos no qual ele reside é SQLPlayground.
Na seção Condição, clique em Adicionar:
Escolha a métrica da qual você deseja criar um alerta. A imagem a seguir mostra a porcentagem de CPU, que você verá selecionada.
Os alertas podem ser configurados de maneira estática (por exemplo, gerar um alerta quando a CPU passar de 95%) ou de maneira dinâmica usando limites dinâmicos. Os limites dinâmicos aprendem o comportamento histórico da métrica e geram um alerta quando os recursos estão operando de maneira anormal. Esses limites dinâmicos podem detectar sazonalidade em suas cargas de trabalho e ajustar o alerta de acordo.
Se forem usados alertas estáticos, você deverá informar um limite para a métrica selecionada. Neste exemplo, 80% foi especificado. Esse limite significa que, se a utilização da CPU exceder 80% em um determinado período, um alerta será disparado, com a reação especificada.
Os dois tipos de alertas oferecem operadores boolianos, como os operadores "maior que" ou "menor que". Com os operadores boolianos, há medidas agregadas para seleção, como média, mínimo, máximo, contagem, média e total. Com essas opções disponíveis, é fácil criar um alerta flexível que se adequará praticamente a qualquer alerta de nível empresarial.
Depois de criar o alerta, para notificar os administradores ou iniciar um processo de automação, um grupo de ação precisa ser configurado.
Observação
Definir um grupo de ação é opcional e, se ele não estiver configurado, o alerta apenas registrará a notificação no armazenamento sem que nenhuma outra ação seja executada. Você pode criar um novo grupo de ações na tela Métricas clicando em Adicionar ao lado de Grupos de Ações. Você verá esta caixa de diálogo:
Depois de clicar em Criar grupo de ações, você verá a tela mostrada abaixo. Você dará um nome para o grupo de ações e definirá um alerta e a resposta. Neste exemplo, o administrador receberá um email caso a condição do alerta seja disparada.
Você pode configurar os detalhes do email ou do SMS, conforme visto abaixo. Você pode acessar essa tela clicando em Editar detalhes em Configurarou adicionando uma nova ação, que também abrirá a tela de configuração.
Com um grupo de ação, há várias maneiras para responder ao alerta. As seguintes opções estão disponíveis para definir a ação a ser tomada:
- Runbook de Automação
- Azure Function
- Enviar email para a Função do Azure Resource Manager
- Email/SMS/Push/Voz
- ITSM
- Aplicativo lógico do Azure
- Webhook Seguro
- webhook
Há duas categorias para essas ações: notificação, que significa notificar um administrador ou grupo de administradores de um evento, e automação, que adota uma ação definida para responder a uma condição de desempenho.
Examinar dados de desempenho mais antigos
Um dos benefícios de utilizar o Azure Monitor é a capacidade de revisar com facilidade e rapidez as métricas anteriores que foram coletadas. Se você examinar um recurso, observará um seletor de data e hora no canto superior direito. As Métricas do Azure Monitor serão retidas por 93 dias. Depois disso, serão eliminadas. No entanto, você terá a opção de arquivá-las no Armazenamento do Microsoft Azure.
Você também pode escolher uma janela de tempo menor, como últimos 30 minutos, última hora, últimas 4 horas ou últimas 12 horas, por exemplo. A flexibilidade do Azure Monitor permite que os administradores identifiquem rapidamente problemas e possam diagnosticar problemas anteriores.
Métricas importantes do SQL Server
O Microsoft SQL Server é um software bem instrumentado que coleta uma grande quantidade de metadados de desempenho. O mecanismo de banco de dados tem métricas que podem ser monitoradas para ajudar a identificar e melhorar os problemas relacionados ao desempenho. Algumas métricas de sistema operacional só são visíveis no monitor de desempenho, enquanto outras podem ser acessadas por meio de consultas T-SQL, em particular, escolhendo as DMVs (exibições de gerenciamento dinâmico). Há algumas métricas que são expostas em ambos os locais, de modo que é importante saber onde identificar métricas específicas. Um exemplo de dados que só podem ser capturados em DMVs é a latência de leitura/gravação do arquivo de log de transações, como exposto em sys.dm_os_volume_stats
. Por outro lado, um exemplo de uma métrica do sistema operacional que não está disponível diretamente por meio do SQL Server é a leitura e gravação de segundos por disco para o volume de disco. Combinar essas duas métricas pode ajudá-lo a entender melhor se um problema de desempenho está relacionado à estrutura do banco de dados ou a um gargalo do armazenamento físico.