Arquitetura para aplicativo da Web para monitorar servidores remotos

5

Então eu sou um programador relativamente novo, tentando criar um aplicativo da Web (ASP.net) para exibir as informações do sistema (EG Status dos serviços do Windows, uso de disco e recursos e erros em logs de eventos) de um número de servidores remotos para fins de monitoramento (inicialmente - eu também gostaria de manter o design aberto para a adição, no futuro, de algum controle remoto básico sobre esses servidores também) .

Comecei criando um pequeno protótipo, mas fiquei um pouco confuso em relação ao design da solução.

Minha solução atual envolve a criação de um serviço windows que é executado em cada cliente servidores (aqueles que estão sendo monitorados), que periodicamente coleta os dados necessários do local e envia-o como JSON por meio de uma solicitação POST para uma API da Web hospedada no IIS no Servidor Monitoring , que recebe os dados e os armazena em um Banco de Dados SQL. Eu agora pretendo criar um separado ASP.net MVC projeto para hospedar como um aplicativo separado no IIS no Monitoring server e usar isso como meu front-end - para ler a partir do DB e exibir as estatísticas das máquinas.

Existe algo de errado com o design especificado acima?

Eu também não tenho certeza se esse design limita o quanto eu posso usar esse aplicativo, por exemplo, como adicionar recursos para permitir que os usuários executem ações nos servidores cliente por meio da interface da web ( EG solicitando manualmente para informações do sistema em tempo real, controlando remotamente os serviços do Windows, limpando logs de eventos, etc). Seria um projeto defeituoso também hospedar uma API da Web dentro dos serviços do Windows client para que o servidor pudesse conversar / fazer solicitações a todos os clientes também?

Desculpe antecipadamente se este post é muito longo / ambíguo - Qualquer conselho e / ou sugestões de design seriam muito apreciados!

    
por BananaSandwich 17.01.2016 / 16:15
fonte

1 resposta

4

Não há nada "errado" com uma abordagem para projetar / implantar um agente em um PC que copie logs e alimente em uma fonte central. Mas quando me pediram recentemente para desenvolver uma solução que envolvesse pesquisar PCs para determinados bits de configuração / saúde, optei por um servidor que realizasse sondagens via WMI para obter as estatísticas desejadas. Se os bits que você precisa reunir estiverem disponíveis por meio do WMI (e provavelmente são), eu recomendaria isso versus os logs de raspagem.

Atualmente, estou pesquisando cerca de 60.000 desktops e servidores Windows globalmente para uma empresa. Eu tenho uma conta de serviço provisionada com os direitos necessários e quatro processos em execução em uma caixa do Windows 2008 (um para cada região) e despejo dos resultados em MSSQL e, em seguida, usando o SSRS como a camada de apresentação.

Depois que consegui reunir os dados e fornecer visualizações do problema em regiões / divisões e contagens de servidores e desktops vulneráveis, o problema rapidamente se transformou em como alterar as configurações em um grande número de hosts para fechar o problema. vulnerabilidade, e para fazer isso eu só precisava mudar minha chamada WMI de um "get" para um "set".

Aproveitando o WMI e colocando o "agente" em um servidor, evitei o tempo necessário para desenvolver e testar um pacote de cliente e tê-lo empurrado para fora etc. E quando o requisito foi alterado, o que geralmente é o caso, Não é necessário passar por essa iteração de desenvolvimento / implementação novamente. E o WMI veio para ficar, portanto, meu código funcionará conforme os desktops se transformam no Windows 10 e nos servidores para 2012. Se os locais de log forem alterados, etc. Não estou sendo afetado. E como não implantei nada nos hosts, não posso ser culpado por problemas de desempenho, etc. Chamar o WMI para obter informações é minimamente impactante.

Registros de raspagem devem ser o último recurso. Se a plataforma que você está coletando dados fornecer uma API, aproveitar essa API sempre facilitará seu trabalho e sua escala de solução, sobreviverá a atualizações de versão, etc.

    
por 25.02.2016 / 00:51
fonte