Antes de começar a analisar uma ferramenta de monitoramento do SQL Server, pense em seu ambiente específico:
- Quantas instâncias você deseja monitorar?
- Eles estão em um local ou dispersos?
- Você precisa monitorar o sistema operacional e/ou hipervisor?
- De quanto histórico você precisa para ter uma visão precisa dos limites de operação da sua instância?
- Todos eles estão no local ou alguns estão na nuvem?
- Suas equipes estão distribuídas?
- Você compra software sob um orçamento de despesas de capital ou despesas operacionais?
- Você pode investir um montante fixo em infraestrutura e licença ou prefere distribuir seus custos ao longo do tempo?
- Você tem instâncias de infraestrutura e banco de dados disponíveis para dedicar a uma ferramenta de monitoramento?
- Você tem tempo para construir uma infraestrutura de monitoramento?
- Você tem conhecimento consistentemente alto em sua equipe?
- Você utiliza recursos juniores para triagem inicial ou depende de seus especialistas para tudo?
- Você tem tempo ou recursos internos para manter a infraestrutura de monitoramento?
Devo rolar o meu?
Posso declarar nosso preconceito aqui. A Quest Software vem construindo ferramentas de monitoramento de desempenho nos últimos 20 anos. Há uma excelente razão pela qual nós e muitos outros como nós permanecemos neste segmento por tanto tempo e por que temos uma base de clientes crescente. O monitoramento de desempenho bem feito não é fácil!
De fato, existem algumas ótimas maneiras de coletar métricas do SQL Server usando PerfMon, rastreamentos, DMVs e XEvents, para citar alguns. Fazer isso em uma base única para um único problema é muito bom – se você tiver tempo para investir em pesquisar onde e como coletar os dados para esse problema. Quando os problemas começam a se acumular e o número de instâncias aumenta, isso rapidamente se torna inescalável.
Existem várias centenas de métricas disponíveis que valem a pena acompanhar para obter uma visão completa da integridade do desempenho do SQL Server. Além disso, existe o código SQL que é executado e os planos de consulta associados a cada execução do mesmo. Algumas métricas devem ser coletadas a cada segundo, algumas a cada hora e algumas com base em quando o código é executado. Alguns métodos de coleta podem impactar a instância monitorada e devem ser evitados.
Cada métrica terá diferentes limites que definiriam seu status. Instâncias particulares podem ter níveis fora do padrão. Então você tem que armazenar tudo isso. O volume de dados aumenta MUITO rápido. Você precisará implementar uma estratégia para eliminar dados detalhados regularmente e, se necessário, agregar esses dados para geração de relatórios.
É MUITO trabalho… e claro, toda vez que uma nova versão do SQL Server sai, você tem uma dor de cabeça de regressão para lidar. A menos que você realmente queira vender uma ferramenta de monitoramento, eu desaconselho vivamente a lançar a sua própria, a menos que o volume de problemas seja baixo e os problemas que você precisa resolver sejam muito específicos.
E quanto às ferramentas gratuitas?
Muitas vezes vale a pena considerar as ferramentas gratuitas, especialmente para equipes menores com instâncias menos críticas. Pense nisso como o próximo passo na escada da escalabilidade depois de “roll your own”. Muitas das ferramentas de monitoramento de servidor SQL comerciais de nível básico devem ter considerações semelhantes. Considere o seguinte:
- A ferramenta cobre uma amplitude suficiente de métricas para fornecer cobertura adequada para todos os casos de uso em suas instâncias monitoradas? Muitas ferramentas gratuitas darão algum tipo de “personalização” para adicionar suas próprias métricas. Quando a “personalização” está sendo usada para preencher lacunas na funcionalidade, você rapidamente descobrirá que sua equipe acaba “fazendo o seu próprio” com a distração necessária e a dor de cabeça de manutenção.
- A ferramenta é compatível com alertas? Ele é pré-configurado? A configuração de alertas pode ser muito demorada. O alerta pronto para uso é essencial para evitar muitas horas de trabalho perdidas configurando a ferramenta de outra pessoa. Também deve facilitar a personalização de alertas para os casos extremos que não estão em conformidade com os padrões.
- Como e onde os dados são armazenados? A maioria das ferramentas gratuitas deixa para você gerenciar o armazenamento de dados de desempenho. Desconfie do monitoramento “gratuito” de fornecedores de nuvem. Eles cobram pelo armazenamento, e isso pode ficar grande e caro rapidamente!
Então, por todos os meios, explore as ferramentas gratuitas que estão por aí. Apenas esteja ciente de suas limitações e procure os antipadrões clássicos em sua equipe, como:
- Mais tempo gasto corrigindo ou mantendo a ferramenta do que usando-a para corrigir problemas
- Mais dinheiro gasto em infraestrutura e armazenamento
- Muitos dados, mas nenhum insight
- Não há profundidade suficiente no diagnóstico para resolver problemas
- Não é escalável o suficiente para atender às suas necessidades
Se você notar qualquer um dos itens acima, isso deve apontar para a necessidade de atualizar para uma solução mais robusta.
Arquitetura Típica de um Sistema de Monitoramento do SQL Server
Ao considerar se deve optar por uma solução local tradicional ou por uma solução de software como serviço (SaaS) hospedada, é útil considerar a arquitetura do aplicativo de monitoramento. Aqui está um resumo dos principais componentes de arquitetura.
O principal desvio entre SaaS e local está relacionado a onde os dados de desempenho são armazenados e quem gerencia esse repositório. Para uma solução local, isso é responsabilidade do usuário final. Esses repositórios podem ficar grandes rapidamente, por isso precisam ser gerenciados com cuidado. A infraestrutura precisa ser planejada e orçada (mais abaixo).
Em uma solução SaaS para monitoramento de servidor SQL, esses principais componentes de infraestrutura são hospedados e gerenciados para você.
| Solução no local tradicional | Solução SaaS |
|
|
Para mais detalhes, confira nosso blog, Arquitetura do Sistema de Monitoramento de Banco de Dados.
