Temos um servidor da Web que está em nossa DMZ que atende um aplicativo da Web ASP.NET. O aplicativo está ativo há cerca de dois meses e funciona muito bem, mas recebemos e-mails periódicos dos usuários dizendo que eles não podem acessar o site porque recebem um tempo limite ou um link quebrado ou a página não foi encontrada, etc.
Meu primeiro pensamento é que isso é algo para eles, já que as pessoas testaram o site literalmente ao redor do mundo sem problemas e não houve interrupções conhecidas. Meu problema é que eu não quero apenas dizer ao usuário: "O problema está no seu fim, descubra." Eu gostaria de ter uma maneira de provar isso para eles ou talvez alguns passos para eles provarem isso para si mesmos.
Alguma sugestão para mim ou para o usuário com problemas?
Editar: Para esclarecer um pouco mais, o problema é com os mesmos usuários várias vezes (como um total de 5 até o momento) e eles não podem acessar o site. Portanto, não é um problema específico da página. Algumas ótimas respostas até agora eu gostaria de poder marcar mais de uma como a resposta, já que todas são boas.
Obrigado pela rápida volta também. Foi mais rápido perguntar e obter uma resposta aqui do que entrar em contato com meu servidor / grupo de rede em casa:)
Você pode usar este site para verificar se seu site está fora de "fora"
Se o usuário for mais experiente e estiver disposto a fazer um pouco mais de trabalho para você, faça com que ele carregue o plug-in 'YSlow' no Firefox e visite seu site. Isso ajudará a identificar gargalos de desempenho, links quebrados etc.
Existem muitos serviços que testarão seu site em vários locais e fornecerão um relatório dos tempos de resposta de cada um deles. Um desses sites é mon.itor.us
Você também pode querer verificar suas configurações e registros do servidor . Talvez você esteja maximizando o seu número permitido de conexões , ou largura de banda , memória ou capacidade da CPU ?
Use um serviço de monitoramento remoto de vários locais. O Website Pulse é um bom e barato e fácil de configurar. Pode dar uma ideia do desempenho do seu site em diferentes partes do mundo e em redes diferentes.
Eles podem enviar e-mails e traps SNMP para que você saiba quando seu site está lento ou não está respondendo.
Eu encontrei esse problema na minha última empresa. Eu iria remoto em minha máquina em casa e verifique o site. Corri para um problema fazendo assim, eu estava no mesmo ISP que os nossos servidores, por isso não era uma verificação verdadeira do lado de fora, apenas fora do nosso firewall.
Agora eu uso downforeveryoneorjustme.com além do meu controle remoto para ir para casa para verificar.
Além disso, se sua empresa tiver vários sites, você poderá usar o Nagios ou mesmo o PowerShell para verificar sites da Web e alertá-lo se eles forem desativados. Apenas certifique-se de usar seu endereço público no cheque.
Eu usei o Pingdom com grande sucesso. Você pode criar verificações que testam a conectividade DNS, ICMP, HTTP, bem como os métodos HTTP Get e Post para garantir que seu site esteja retornando uma resposta válida e que os scripts / formulários estejam funcionando corretamente.
Preços razoáveis e os cheques são originados de 5 ou 30 locais (conta básica ou empresarial, respectivamente). Eles também rastreiam os tempos de resposta dos locais para que você tenha uma noção de como o seu site funciona em todo o mundo.
Se for um problema intermitente, isso pode ser causado por problemas de rede transitórios em qualquer parte do caminho ou por problemas de desempenho do servidor. O número de razões possíveis é ENORME! Você precisa eliminar o servidor como a causa do problema. Verifique os logs do sistema operacional de eventos, os logs de erros do IIS, etc. tente pedir a alguém para contatá-lo imediatamente, pois o problema ocorre. Peça-lhes para fazer um rastreio ou um caminho para o servidor para diagnosticar problemas de rede. E verifique se há alta carga no servidor enquanto o problema está acontecendo.
Para uma resposta mais conclusiva, precisaríamos de mais informações.
É claro que há uma quantidade "normal" de tempo de inatividade para sites ... você pode tentar monitorar o site por conta própria e verificar seu tempo de atividade. Contanto que esteja acima dos 4 ou 5 noves de acordo com o seu SLA, às vezes isso é tudo que importa.
Se você já tem pessoas de todo o mundo usando o site, você deve apontar os usuários com o problema para algo como link . Isso é para provar a eles que, seja qual for o problema, não é você. Você também deve ter configurado algum tipo de monitoramento interno que realmente carregue as páginas da Web. Monitorar um site não é simplesmente receber uma mensagem de 200 OK. Você precisa de uma solução de monitoramento que realmente procure por algo na página correta. Se houver alguma conexão de back-end de algum tipo (SQL DB, autorização do ADAM), a solução de monitoramento deve ser capaz de carregar uma página usando isso também.
Provar isso de uma forma ou de outra é difícil, pois o roteamento da Internet pode ser interessante, assim como o DNS pode doer.
Lembre-se que pode não ser você ou quem tem um problema, pode ser um pouco da internet entre você. Como o DNS do ISP do seu ISP. Ou o encaminhamento do ISP do ISP do ISP. Ou o prefixo do seu servidor da web pode ser bloqueado pela propaganda de alguém muito ampla como uma máscara de rede (aconteceu no google!)
Para saber definitivamente, você precisa realizar um teste de nslookup do seu site a partir de sua localização, idealmente a partir dos servidores de nomes raiz, por exemplo. a.root-servers.net. e trabalhando para baixo. Você quer experimentar todos os servidores DNS no caminho entre a raiz e o servidor DNS autenticador do nome do host do seu servidor web, pois ocorre ocasionalmente que um dos servidores autorizados será fubar, mas outro OK, então funciona para dizer você, mas não para eles .
Supondo que o DNS esteja OK, eles precisam ver se os pacotes podem chegar até você. Ou seja um ping no primeiro exemplo. E você precisa ter certeza de que seus pacotes podem voltar. Ping-los de volta. Supondo que tudo esteja bem, você provavelmente vai querer fazer com que eles façam um wget, curl ou telnet no seu servidor web e façam um GET manualmente (para eliminar caches do navegador). Então é provavelmente razoável dizer que seu sit é alcançável - supondo que seja. E se não, então você terá uma ideia razoável de onde está o problema.
Como você pode ver, este é um assunto não trivial.
Como outros sugeriram, alguns servidores comerciais podem ajudar a localizar seus próprios servidores em vários locais em várias redes e fazer verificações uns dos outros.
Você precisa de um serviço externo para verificar se hospeda o servidor da Web ou pode hospedar o serviço de monitoramento se o servidor da Web for externo.
Em qualquer caso, bem, exceto, talvez, para o seu caso exatamente, mas de qualquer forma - normalmente você precisa fazer mais do que apenas verificar uma resposta ...
Configure verificações de conteúdo específico nas respostas, para que você, por exemplo, não permita uma resposta bem-sucedida que seja apenas uma página de erro ou outra falha no site, como uma luz verde - andando por aí pensando que tudo está bem quando é realmente não ^^
O monitoramento de qualquer serviço não é tão fácil quanto parece, e é por isso que ternos realmente úteis costumam ser extremamente complexos e / ou caros. Naturalmente, os métodos simples podem cobrir o básico, especialmente talvez neste caso específico.
Eu tive boa sorte com o Keynote (não posso adicionar o link, já que sou um novo usuário). Você pode configurar monitores de vários pontos, especificar intervalos de teste, etc.
Eu usei as redes keynote e gomez no passado, mas primeiro devo perguntar, como você sabe que não é realmente um problema com seu site?
Em um trabalho anterior, uma vez tivemos reclamações de que nosso serviço não estava disponível e descobrimos que apenas através do rastreamento de pacotes que o usuário estava se conectando e obtendo zero bytes retornados.
Nada aparece nos registros de acesso e nenhum outro vestígio do que deu errado foi deixado em nossos sistemas.
Aconteceu de ser algum tipo de bug no módulo do apache que causou pânico em vez de emitir um erro de qualquer tipo.