Para os administradores de banco de dados encarregados de responder aos alertas do SQL Server em todas as horas do dia e da noite, a sensação de estar sobrecarregado provavelmente é exacerbada pela enxurrada constante de notificações de que algo precisa de sua atenção. DIREITA. AGORA.
O monitoramento do SQL Server é crucial para manter a alta disponibilidade e rastrear problemas de desempenho em seu sistema, e os alertas são a maneira mais eficiente de descobrir que há um problema. Mas é possível ter muito de uma coisa boa.
Como diz o ditado:“Quando tudo é prioridade, nada é prioridade”. A fadiga do alerta é real e pode levar você a ignorar ou descartar eventos que estão afetando negativamente seus usuários.
Ao configurar o monitoramento de desempenho do SQL Server, é importante configurar os alarmes com atenção e de forma a controlar quando, por que e com que frequência você recebe notificações. Aqui estão quatro maneiras de gerenciar alertas que ajudarão a aliviar a sobrecarga de alertas e salvar o que resta de sua sanidade.
1. Desligue os alarmes que você não precisa
Para muitos DBAs, é mais fácil falar do que fazer. Há um pequeno elemento de terror no pensamento de escolher quais alertas não receber. Felizmente, existem algumas práticas recomendadas que você pode implementar que podem tornar seu FOMO um pouco menos doloroso.
Uma das coisas mais fáceis que você pode fazer é revisar os logs de alerta e desligar os alertas que são cronicamente falsos alarmes ou falsos positivos. As chances são boas de que você não perderá um problema real, e seu cérebro apreciará a pausa de reagir a notificações desnecessárias.
Outra estratégia vem dos engenheiros de confiabilidade do site (SREs) do Google. Os SREs são responsáveis pela disponibilidade, latência, desempenho, eficiência, gerenciamento de mudanças, monitoramento, resposta a emergências e planejamento de capacidade.
As equipes do SRE têm um sistema de Alerta/Ticket/Log para minimizar a sobrecarga de alertas, atribuindo uma resposta a um evento com base na rapidez com que a intervenção humana é necessária. As três respostas possíveis incluem:
- Alerta:um alerta só é enviado se uma pessoa precisar agir imediatamente.
- Ingresso:se o evento exigir ação de uma pessoa, mas puder aguardar até o horário comercial normal, um ingresso será enviado e passará pelos canais normais.
- Log:se nenhuma ação for necessária, o evento será registrado para diagnóstico.
2. Use alarmes inteligentes para chegar rapidamente à causa raiz de um alerta
Quando seu telefone explode com notificações às 3 da manhã, você não quer passar uma hora bisbilhotando para resolver o problema.
Os alarmes inteligentes não apenas informam que você tem um problema, mas também sugerem maneiras de corrigi-lo e ajudam a identificar a causa raiz. Os alarmes inteligentes também fornecem dados históricos sobre o evento para que você saiba o que aconteceu imediatamente antes e depois que o alerta foi acionado.
3. Priorize seus alertas para identificar os problemas mais urgentes
Todos os alertas não são criados iguais, por isso é importante configurar sua ferramenta de monitoramento de desempenho do SQL Server para que ela envie alertas apenas para os problemas mais importantes. Ao priorizar alertas com base no nível de gravidade, impacto nos negócios ou nos clientes e se uma ação imediata é necessária, você elimina parte do ruído gerado por alertas que não são críticos.
Concentre-se na configuração de alertas para problemas que podem fazer com que seus servidores fiquem offline, corromper gravemente dados ou resultar em perda significativa de dados (ou seja, gravidade 17 ou superior e mensagens de erro 823, 824 e 825).
4. Gerencie alarmes aplicando limites e regras específicos
Definir limites e regras é uma grande economia de sanidade, pois ajudará você a evitar ser bombardeado por vários alertas em um curto espaço de tempo.
Quando você define limites de desempenho, o SQL Server adia a notificação até que um valor para uma métrica especificada atinja um nível preocupante — por exemplo, espaço livre em disco ou níveis de memória física livre estão perigosamente baixos. Isso libera os DBAs para trabalhar em outras tarefas sem monitorar constantemente as métricas.
Definir regras para alertas permite personalizar ações, como a frequência com que você deseja ser notificado. Por exemplo, você pode definir o SQL Server para enviar uma notificação apenas quando um alerta especificado for acionado quatro vezes ou se o alerta contiver um determinado objeto de banco de dados ou nome de usuário.
À medida que os DBAs começam a navegar em um ambiente de negócios novo e muito diferente pós-COVID-19, os níveis de estresse certamente aumentarão. Manter a alta disponibilidade e garantir que seus sistemas SQL Server estejam seguros e com desempenho ideal continuará sendo uma grande prioridade. Mas agora é um bom momento para contratar recursos de monitoramento do SQL Server para assumir o controle de suas configurações de alerta e se livrar do ruído desnecessário.
