Há um número crescente de ótimos sistemas de monitoramento de desempenho de banco de dados por aí. Recentemente, as soluções on-premises mais tradicionais foram unidas por soluções de software como serviço (SaaS).
Este blog contrasta a arquitetura típica de uma solução local com a de uma solução SaaS. É claro que os componentes variam em nome e estrutura de um fornecedor para outro, mas os principais conceitos discutidos aqui serão representados de uma forma ou de outra.
Diferenças entre soluções locais e SaaS
No geral, aqui estão alguns dos principais componentes de cada solução:
Solução tradicional no local
- Processo de coleta de dados.
- Repositório [diagnóstico] de desempenho de curto prazo.
- Repositório de relatórios/análise de longo prazo.
- Windows ou cliente de navegador.
- Qualquer infraestrutura de failover necessária para a infraestrutura de monitoramento.
Solução SaaS
- Processo de coleta de dados (para destinos locais).
- Cliente de navegador.
- Aplicativo para dispositivos móveis.
- O fornecedor de SaaS gerencia o aplicativo e o armazenamento de dados de back-end.
Observe que os nomes dos vários componentes variam de uma solução para outra. Em alguns casos, a funcionalidade pode ser dividida em vários serviços ou fontes de dados.
Soluções no local
Processo de coleta de dados
O coletor de dados geralmente é um serviço local sem agente que coleta dados de qualquer terminal monitorado local. Esse processo orquestra como e quando os dados são coletados. Deve ser capaz de coletar dados em diferentes frequências para equilibrar a necessidade de mais detalhes com o impacto na carga de trabalho monitorada. As frequências de coleta e os limites de alerta devem ser pré-configurados em cada métrica.
Todos terão uma instância “ruidosa” que não está em conformidade com os limites padrão. Isso pode resultar em muitos falsos positivos. Para lidar com isso, o sistema deve ter a capacidade de criar regras em nível de instância para lidar com circunstâncias excepcionais. Isso evita a “fadiga de alarme” de falsos positivos.
Em alguns casos, esse serviço também orquestra alertas e notificações. Em grandes organizações com centenas de instâncias monitoradas, pode ser necessário equilibrar a carga “federando” vários coletores de dados. A federação sincroniza coleções e configurações em um sistema disperso.
Repositório de diagnóstico de curto prazo
É aqui que os dados detalhados são armazenados. Isso inclui dados de DMVs, arquivos de log, XEvents e outras fontes de dados do SQL Server. Fontes que possam exercer pressão sobre as instâncias monitoradas devem ser evitadas, por exemplo, a maioria dos rastreamentos não é adequada para monitoramento em tempo real.
Como as frequências de coleta podem ser a cada segundo e grandes blocos de dados, como TSQL e planos, são coletados, esse repositório pode ficar grande rapidamente. Como resultado, a maioria dos sistemas normalmente limita o histórico entre uma semana e um mês (essas limitações não se aplicam a uma solução SaaS). Este repositório é altamente transacional por natureza.
Repositório de relatórios/análises de longo prazo
Ao final de um tempo predefinido, esses dados detalhados são agregados e armazenados em um repositório de relatórios para análises e tendências de alto nível. A quantidade de detalhes retidos terá um impacto significativo no tamanho eventual desse repositório e na capacidade de computação que se pode razoavelmente esperar que um usuário disponibilize para analisá-lo. Isso tende a variar consideravelmente de uma solução para outra. As soluções que suportam análises mais profundas terão arquiteturas de suporte e podem usar arquiteturas OLAP para facilitar a análise multidimensional.
Escalando uma solução de monitoramento no local
Soluções mais sofisticadas serão projetadas para facilitar uma arquitetura distribuída dos principais componentes para suportar a escala. O serviço de coleta de dados terá um número superior de conexões monitoradas que pode suportar. Quando esse limite for atingido, um coletor de dados adicional deve ser “federado” para coordenar a coleta de dados e orquestrar o armazenamento dos dados.
Os próprios repositórios de dados de desempenho podem compartilhar uma instância ou podem ser distribuídos por várias instâncias para dar suporte à escala. O armazenamento necessário será diretamente proporcional ao número de conexões monitoradas e ao volume de dados retidos. A estrutura e a arquitetura do repositório de análise também afetarão a capacidade total.
Experiência do usuário
A maioria das ferramentas locais terá um front-end do Windows. Alguns têm front-ends de navegador com base em uma implantação hospedada localmente. O acesso remoto a eles pode ser complicado e normalmente requer VPN. Eles raramente suportam aplicativos móveis.
Alta disponibilidade
O software de monitoramento que monitora cargas de trabalho de missão crítica precisa ser resiliente por si só. Devem ser tomadas provisões para lidar com situações de desastre que possam colocar a estrutura de monitoramento offline. Isso também deve ser considerado de uma perspectiva de arquitetura e custo.
Soluções SaaS
Processo de coleta de dados
Embora uma oferta de SaaS seja hospedada principalmente, ela geralmente mantém um coletor de dados local para cargas de trabalho locais. Isso ajuda a lidar com as restrições de desempenho e segurança. Dessa maneira, todas as conexões em nível de instância são feitas por meio do coletor local, que retransmite os dados de desempenho do banco de dados monitorado para o serviço de entrada na nuvem. Todos os dados devem ser criptografados em trânsito.
Repositórios de diagnóstico e relatórios/análises
A boa notícia aqui é que o fornecedor de SaaS lida com todo o seu armazenamento de dados. Você não precisa se preocupar em criar instâncias para os repositórios de diagnósticos, repositórios de relatórios, liberar o repositório de diagnósticos ou muitas outras dores de cabeça associadas a uma implantação local.
As soluções hospedadas usarão diferentes estratégias de armazenamento no back-end para facilitar uma combinação de atividades transacionais e analíticas conforme apropriado. Eles podem usar recursos de nuvem para lidar com volumes de dados mais altos e o processamento necessário para análises; por exemplo, Spotlight Cloud mantém um ano de dados detalhados. Assim, você pode não apenas relatar um ano no tempo, mas também reproduzir sua carga de trabalho até um ano no passado. Esta é uma capacidade realmente poderosa.
Uma solução SaaS para monitoramento de desempenho de banco de dados pode usar uma variedade de estratégias de armazenamento de back-end não apenas para se adequar à natureza mais transacional do diagnóstico e monitoramento, mas também para facilitar o processamento de números de alta intensidade associado à análise de longo prazo. O fornecedor de SaaS pode aproveitar consideráveis economias de escala para usar uma infraestrutura muito mais poderosa que estaria à disposição de organizações individuais.
Como dimensionar uma solução SaaS
O dimensionamento de uma solução SaaS é responsabilidade do fornecedor e não do usuário. Qualquer solução SaaS para monitoramento de desempenho de banco de dados deve ser construída para escalar desde o primeiro dia e, como resultado, tende a lidar com a escala em seu ritmo.
Experiência do usuário
Os aplicativos SaaS serão padronizados para um navegador Ux e muitos também terão aplicativos móveis abrangentes. Isso facilita equipes dispersas e remotas.
Segurança e Conformidade
A maioria das soluções SaaS será construída em uma das principais infraestruturas de nuvem, como Azure ou Amazon. Muitos dos principais fornecedores possuem infraestruturas de segurança sofisticadas. Eles estão fortemente investidos no suporte às necessidades de conformidade de seus clientes.
Alta disponibilidade
A boa notícia aqui novamente é que isso é responsabilidade do fornecedor. Vale a pena verificar com seu fornecedor para descobrir qual provisão eles fizeram em termos de failover e alta disponibilidade. Os aplicativos SaaS devem ser arquitetados para serem muito resilientes. Os vários serviços que compõem um aplicativo SaaS geralmente são projetados para serem resilientes individualmente. A provisão também pode ser feita para indisponibilidades do data center em que o aplicativo faria failover de um data center para outro no caso de uma indisponibilidade do data center.
