Fala pessoal!
Nesse post eu vou comentar sobre um sistema de alertas e monitoramento de SQL Server e Azure Managed Instance, desenvolvido pela empresa PowerTuning, que tem como objetivo fornecer várias métricas, análises e informações para rapidamente identificar o estado atual do banco (Health Check), enviar alertas por e-mail (incluindo gráficos) quando algum evento ocorre no banco de dados e monitorar mudanças de comportamento do banco, crescimento de tabelas, arquivos de dados e muito mais.
Já utilizei outros sistemas de monitoramento e alertas como Redgate SQL Monitor e SolarWinds SQL Database Monitoring, mas o PowerAlerts me surpreendeu pela quantidade de alertas disponíveis, nível de detalhe e o suporte diferenciado que a PowerTuning entrega.
O CEO da PowerTuning e um dos criadores do PowerAlerts, Fabrício Lima, falou que “Quem tem SQL Server e não usa o PowerAlerts é maluco”. Depois de testar bastante o produto, tenho que concordar com ele rs
Se você ficou interessado no Power Alerts, entre em contato com o time comercial da Power Tuning: [email protected]
1) O que é o Power Alerts?
É uma ferramenta de 62 mil linhas de código em T-SQL (e crescendo) criada de DBA SQL Server para DBA SQL Server com dezenas de Alertas para monitorar seu banco de dados e, agora, com a feature de gráficos para facilitar sua visualização e entendimento do ambiente.
O Power Alerts é um complemento de qualquer ferramenta de monitoramento porque ele já retorna informações detalhadas e com gráficos no próprio e-mail (sem que você tenha que olhar uma tela de monitoramento ou logar no ambiente). Quem tem um SQL Server, vai ficar feliz de ter esses alertas e logs que são gerados para o DBA.
Nessa live, vocês podem ver mais detalhes sobre o Power Alerts:
Não existe nada parecido com isso hoje aqui no Brasil (e nem lá fora até onde eu sei).
Dash com os clientes que já receberam o Power Alerts:
2) Alertas criados
Esses são os Alertas que são criados na Implementação do Power Alerts:
Plus 1: É criado também um e-mail mensal com informações da instância para ser utilizado em caso de desastre como uma documentação para saber como estava a instância antes do ambiente.
Isso ajuda a reinstalar o ambiente sem impactos de mudanças (ajuda demais em casos de desastre).
Plus 2: Criação de um Checklist diário do ambiente com gráficos para enviar informações da instância diariamente e ajudar na análise e comparação de informações em períodos diferentes.
Isso pode ser utilizado para ter uma análise rápida no ambiente ou para comparar como estão os valores entre duas datas distintas.
3) Exemplo de um Alerta de Log FULL
Esse é o cabeçalho do alerta que possui várias informações úteis:
Conforme podemos ver abaixo, no próprio e-mail já mostra o motivo do log estar preso (nesse caso é falta de backup do log – Coluna “Log Reuse Wait” com o valor “LOG_BACKUP”).
Também mostra o disco que esse log está e o espaço livre dele para te deixar mais tranquilo ou preocupado quando chegar esse alerta.
Ainda temos o quanto esse log vai crescer e se ele está limitado (para ver se ele está crescendo muito ou pouco isso ajuda bastante).
As primeiras informações que o DBA teria que logar e descobrir em um alerta como esse já estão mastigadas no alerta. Produtividade e economia de horas do DBA ($).
Seguindo no e-mail, temos um gráfico para facilitar sua visualização de quando o log começou a crescer e o tempo que ele levou para estourar.
Últimos 60 minutos para ver o comportamento recente do log:
Últimas 48 horas para ter uma visão mais longa do comportamento do log:
Seguindo ainda no e-mail, temos um gráfico para facilitar a visualização de como está o consumo do disco onde está esse arquivo de log. Se ele está acabando rápido ou devagar. Nenhum alerta de log por aí na internet trás essa informação.
Como um dos problemas comuns pode ser a falta de backup, o alerta também mostra quando foi o último backup do log da base com Log FULL:
Menos uma informação que o DBA teria que conferir (mais produtividade).
Além disso, são mostradas as queries que possuem uma transação aberta e estão consumindo o log para que o DBA possa analisar e ir atrás do responsável para saber se pode matar ou não:
O DBA teria que achar nos scripts dele qual query mostra quem está consumindo mais log para depois rodar e descobrir. No Power Alerts já apareceu o insert que coloquei para encher o Log usando 3.8 GB de log.
Ainda é mostrado o que está rodando naquele momento com uma foto da whoisactive:
Podemos ver novamente o insert enchendo o log.
Para finalizar, ainda conseguimos ver o gráfico de alertas por dia e por horas nos ajudando a identificar como está o histórico desse alerta.
Se tenho muitos alertas por dia chegando, temos que tentar fazer algo para reduzir:
Também conseguimos identificar se tem algum horário do dia que mais gera o alerta para ajudar a encontrar a rotina culpada:
No final do email tem a logo e nossa info de registro do alerta:
Este é um produto licenciado pela Power Tuning no INPI (Instituto Nacional da Propriedade Industrial), sob o número 512022002100-5, e não pode ser compartilhado ou utilizado sem um contrato de compra ou autorização prévia.
4) Rotinas de DBA criadas
Muito além dos gráficos bonitos, nosso sistema de alertas também cria mais de 25 rotinas que armazenam dados em tabelas e ajudam o DBA a monitorar e atuar com mais eficiência no ambiente. Essas rotinas são utilizadas pelo Power Alerts para envio dos e-mails e gráficos.
Rotinas de DBA que são criadas no ambiente (+25 rotinas):
- Rotina para monitorar Deadlocks.
- Rotina para monitorar erros de Scripts que acontecem nas bases de dados.
- Rotina para monitorar os maiores waits do ambiente em um determinado intervalo de tempo.
- Rotina para monitorar se as estatísticas estão atualizadas.
- Rotina para monitorar as queries que estão usando o tempdb.
- Rotina para monitorar o crescimento do arquivo de dados do tempdb.
- Rotina para acompanhar o crescimento das tabelas e databases. Com isso, podemos prever o crescimento do ambiente e realizar novos investimentos somente quando necessário.
- Rotina para monitorar contadores do SQL Server.
- Rotina para monitorar as queries mais demoradas do ambiente.
- Rotina para monitorar o uso de memória do ambiente.
- Rotina para monitorar as falhas de Logins.
- Rotina para monitorar o que está rodando no ambiente a cada um minuto (whoisactive).
- Rotina para monitorar o crescimento do Log das Databases.
- Rotina para monitorar o histórico de jobs.
- Rotina para monitorar a utilização dos índices do ambiente.
- Rotina para monitorar a fragmentação dos índices.
- Rotina para monitorar se tem colunas Identity estourando.
- Rotina para monitorar a fila de I/O pending no SQL Server.
- Rotina para monitorar o tempo de resposta e uso dos arquivos de dados e logs do SQL Server.
- Rotina para monitorar o Error Log do SQL Server.
- Rotina para monitorar o espaço em disco.
- Rotina para monitorar o uso de CPU.
- Rotina para monitorar as queries que estão usando mais CPU.
- Rotina para monitorar a execução do CheckDB nas bases.
- Rotina para monitorar o histórico dos backups.
- Se tiver cluster, rotina para monitorar o status dos nós do cluster.
- Se tiver Mirror, rotina para monitorar o status e performance do mirror.
- Se tiver AlwaysOn AG, rotina para monitorar o status e performance do AG.
- Rotina para deletar dados antigos de todos os logs criados.
5) Power Monitor
Com todas essas informações armazenadas para o Power Alerts, nosso time de BI criou um Dash no Power BI para ajudar no monitoramento do banco de nossos clientes:
O cliente precisa cumprir alguns pré-requisitos para utilizar o Power monitor, tais como:
-
- Conta do Power BI
- Gateway de dados que tenha acesso a base de traces
- Tem que ser habilitado a instalacao de apps nao listados no appsource
6) Power Reports
Além de melhorar muito o core dos alertas e incluir gráficos sensacionais, também foram criadas algumas procedures de relatórios (Power Report) para ajudar na análise do ambiente no dia a dia.
Basta passar seu e-mail e os parâmetros de data inicial e final para obter a informação desejada (quando for o caso).
Exemplo real de uso do Power Reports:
Queremos ver como foi a performance do ambiente entre 18h do dia 27/11 e 18h do dia 28/11.
Ao invés do DBA entrar no ambiente, procurar várias queries e validar manualmente as informações do que aconteceu naquele período, existe uma procedure que ele passa o e-mail, a data de início e a data de fim e vários gráficos como os abaixo serão enviados para o e-mail dele.
Com menos de 5 min, ele já tem muita informação disponível para análise e de forma visual.
EXEC stpPowerReport_SQL_Performance @Ds_Email=‘[email protected]’,@Dt_Start=‘20221127 18:32’,@Dt_End=‘20221127 18:32’,@Ds_Query = NULL
O resultado da execução dessa procedure gera todos os próximos gráficos.
Gráfico com informações de CPU:
Gráfico com informações do contador de memória PLE:
Gráfico com informações de conexões no SQL Server:
Gráfico com a quantidade de queries na tabela com o Log da Whoisactive:
Gráfico com informações de contador I/O pendentes:
Gráfico com informações de contador de memória física disponível:
Gráfico com a quantidade de queries demorando mais de 3 segundos (e a média delas):
Gráfico com informações do crescimento do tempdb (dados):
Gráfico com informações das queries mais demoradas:
*Após esse chart vem parte do código das queries no e-mail (Id Query). Não vou mostrar aqui para economizar espaço.
Gráfico com informações dos jobs mais demorados:
*Após esse chart vem o nome dos Jobs no e-mail (Id Job). Não vou mostrar aqui para economizar espaço.
Gráfico com informações dos maiores waits do SQL Server:
Aqui finaliza os gráficos que conseguimos enviar com apenas um F5 na procedure: stpPowerReport_SQL_Performance
Quanto tempo o DBA demoraria para levantar todas essas informações?
Mais uma vez, o Power Alerts aumenta a produtividade e economia de horas do DBA ($).
Outros Power Reports que podem utilizar no dia a dia:
Report com o crescimento de uma base de dados:
EXEC [dbo].[stpPowerReport_Database_Size] @Nm_Database=@Database_Name,@Ds_Email=@email
Report com o crescimento de uma tabela:
EXEC [dbo].[stpPowerReport_Table_Size] @Nm_Database=Nome_DB, @Nm_Table = Nome_Tabela, @Ds_Email = Seu_Email
Report para acompanhar a fragmentação dos índices atual do banco. Empresas de ERP pedem muito isso quando abrem chamado de lentidão.
EXEC [dbo].[stpPowerReport_Index_Fragmentation] @Ds_Email = Seu_Email
Report para validar como estão as estatísticas no ambiente. Na opinião da Power Tuning, estatísticas atualizadas são muito mais importantes do que índices desfragmentados. Esse job tem que ser prioridade.
EXEC [dbo].[stpPowerReport_Update_Statistics] @Ds_Email = Seu_Email
7) Feedbacks de clientes
Segue abaixo alguns prints de feedbacks de clientes que a PowerTuning coletou ao longo de nossas implantações:
8) Investimento Power Alerts
O Power Alerts é licenciado por instância com os valores abaixo:
- Licenças para as Instâncias de 1 a 4: R$ 240,00 por mês por instância.
- Licenças para as Instâncias de 5 a 9: R$ 180,00 por mês por instância.
- Licenças para as Instâncias de 10 a 19: R$ 120,00 por mês por instância.
- Acima de 20 instâncias, negociações direto pelo e-mail: [email protected]
Valor Mensal para 1 instância = R$ 240,00
Descontos:
Plano Anual com 20% de desconto
Valor plano Anual para 1 instância = R$ 2.304,00 (R$ 192,00 por mês)
- Plano de 3 Anos com 40% de desconto
Valor plano de 3 anos para 1 instância = R$ 5.184,00 (R$ 144,00 por mês)
Clientes que possuem suporte mensal com a Power Tuning:
- Clientes que possuem contrato de monitoramento com a Power Tuning não pagam nada a mais no mês pelo Power Alerts.
- Clientes que possuem contrato de sobreaviso de DBA 24×7 com a Power Tuning tem um desconto de 50%.
Também existe um custo único por instância (Valor total R$ 1.400,00) para o trabalho de instalação e configuração para a realidade do ambiente e monitoramento inicial. Esse valor único não tem desconto pois são horas do DBA que terão que ser trabalhadas sempre.
Esse é um produto que continuará evoluindo ao longo do tempo e o cliente terá direito a todas as melhorias.
O que não está incluso nessa proposta:
- Atuações de melhorias técnicas no ambiente após a implantação dos Alertas:
- Disco Cheio
- Log Full
- Base sem Backup
- Ambiente com Lentidão
- Outros problemas comuns do dia a dia de DBA
- Implantação de rotinas pesadas de Administração:
- Não serão implementadas rotinas de manutenção de índices, atualização de estatísticas e CheckDB no ambiente.
Portuguese 
English