4.5. Validação de páginas WEB
4.5.1. Disponibilidade do site
O Zabbix denomina um teste de um site como um “scenario” (cenário), e dentro deste cenário há vários elementos chamados de “steps” (passos) que correspondem a uma requisição, ou seja, a uma URL.
O principal uso deste tipo de teste é verificar se a URL esta respondendo adequadamente, podemos, por exemplo, verificar se o HTML contém uma determinada “string” ou se o código de retorno corresponde a um sucesso, que normalmente é “200 OK”. Mas estas checagens tem outros itens embutidos nela. O servidor calcula automaticamente a latência de rede e a velocidade de download dos dados na URL e já gera gráficos destas estatísticas. Um
Muitas destas funcionalidades são encontradas em outras ferramentas como o “JMeter” (que possui “asserts” capazes de realizar este tipo de verificação), porém uma solução não substitui a outra, pois a intenção do Zabbix não é ser um validador de aplicativos web e sim um verificador de funcionalidades pontuais de URL. Ele também não deve ser usado como gerador de cargas para testes de performance. No entanto o Zabbix consegue armazenar o histórico de resultados online por um longo tempo.
Para criar um novo cenário acesse Configuration → Web. Na tela que surgir você verá
que o botão de criação estará desabilitado (Figura 4.48). Para habilitálo é preciso escolher um grupo e host conforme abaixo: 1) Group: escolha o grupo “Linux servers”. 2) Host: escolha “Application”, que é o host interno de nosso cenário que possui um JBoss e um Apache executando aplicações. Ao escolher os dois valores o botão será habilitado. Isso acontece porque não é possível colocar um cenário dentro de um template, apenas dentro de um host. Daí a necessidade de se escolher um host. Clique sobre “Create scenario”, uma nova janela de cadastro irá surgir.
Figura 4.48: Criando um cenário para disponibilidade Web (1/6)
Figura 4.49: Criando um cenário para disponibilidade Web (2/6)
1) Application: é o “application” de identificação para o cenário. Como ele não é cadastrado em nenhum template tome cuidado para não escolher um “application” que existe em outra parte do Zabbix. Coloque “Cenário HTTP” para o nosso exemplo. 2) Name: o identificador único do cenário dentro do host. Este nome vai aparecer no momento do monitoramento. O valor que colocaremos é “Teste de aplicação PHP no Apache”. 3) Authetication: no caso da URL requerer algum tipo de autenticação HTTP, você pode definila aqui. Não há necessidade de autenticação no nosso exemplo. 4) Update inverval (in sec): o tempo entre uma coleta e outra. Deixe 10 segundos para nosso cenário. 5) Agent: como o Zabbix vai se identificar para o servidor web. Essencialmente é a string do browser pelo qual ele vai se fazer passar. 6) Status: Se ele está ou não, ativo.
7) Variables: um conjunto de variáveis para serem enviadas ao servidor. Deixe em
branco neste caso.
Note que em lugar algum foi definido qual a URL que este cenário vai acessar. Isso porque é possível definir várias URLs dentro dele, cada uma é um “step”. Clique no botão “Add” do campo “Steps” para criar um novo passo.
1) Name: o nome deste “step” normalmente representa a URL a ser testada (por exemplo página principal, carrinho de compras, blog, etc.) 2) URL: o endereço web a ser acessado. Pode incluir parâmetros de método GET se desejado. No nosso caso colocaremos “phpapp.curso468.4linux.com.br”. 3) Post: se a página receber dados via “POST”, as variáveis e valores (um em cada linha) podem ser acrescentados aqui. Neste caso não há nenhuma. 4) Timeout: por quanto tempo o Zabbix vai esperar a resposta do servidor web onde a URL aponta. O valor é em segundos. Deixe 15. Valores menores podem ser usados se o teste for executado em infraestruturas locais, sites de baixo movimento ou em servidores de altíssimo índice de tempo de resposta.
5) Required: um texto que é esperado na página de resposta. Se o servidor falhar em
entregar uma página com esta “string” um “trigger” é acionado.
6) Status code: qual o código HTTP esperado para a resposta. Normalmente ele é “200”
que significa “OK, página encontrada”. Você pode ver a relação de códigos HTTP em
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. Note que este
campo não é obrigatório, você pode simplesmente pedir pro Zabbix ver se o servidor esta retornando algo, mas isso não é muito útil na maioria das vezes.
Para terminar a inserção do “step” clique em “Add”. Antes de continuar vale mencionar que a URL de testes usada neste “step” passa pela estrutura de cache e proxy reverso do cenário (Varnish → Apache+mod_proxy → Apache+PHP5) e por isso esta testando toda esta
infraestrutura. Poderíamos fazer um teste direto no servidor Apache se necessário.
Note que no final do quadro da janela de cenário o novo step fica listado em forma de tabela. Ainda não vamos acrescentar outros “steps” neste cenário. Salve clicando no botão “Save”.
Na lista de cenários, temos agora o nosso cadastrado. Para verificar este monitoramento temos uma tela especial só para ele. Acesse Monitoring →Web.
Clique sobre o nome do cenário e note que ele esta sendo organizado pela “application”
escolhida quando o cadastramos.
Na tela seguinte um resumo da última coleta com a velocidade (Speed), latência de rede (Response time), último código HTTP de resposta (Response code) e Status dos “triggers” gerados automaticamente. Logo abaixo deste quadro temos dois gráficos de velocidade e tempo de resposta prontos.
Figura 4.55: Detalhes do monitoramento Web
Figura 4.53: Criando um cenário para disponibilidade Web (6/6) Figura 4.52: Criando um cenário para disponibilidade Web (5/6)
Como você pode ver, a criação de um cenário é simples, mas permite uma flexibilidade muito grande. Vamos em seguida ver como realizar uma validação de um formulário web.
4.5.2. Exercícios
1) Crie um “action” para os “triggers” que o cenário gerou e faça os seguintes testes: 1.1) Parar o servidor Apache no host “Application”. 1.2) Parar o servidor Apache no host “Presentation”. 1.3) Parar o servidor Varnish no host “Presentation”. 1.4) Mudar o HTML da página principal para não retornar a string esperada.Figura 4.57: Gráfico de tempo de resposta para o cenário Web Figura 4.56: Gráfico de velocidade de download para o cenário Web