Captura o tipo de erro que está retornando (500.503.402, etc) e adiciona isso na mensagem? [fechadas]

Question

Como eu faço este script para capturar o tipo de erro que está retornando (500,503,402, etc) e adicionar isso na mensagem?

#!/bin/bash
hostlist=(s-colin.coverhound.us s-joe.coverhound.us)
  for host in "${hostlist[@]}"; do
if nc -w 2 -z $host 80; then
    echo "INFO: ssh on $host responding [Looks Good]"
else
    echo "ERROR: ssh on $host not responding[Ooops something went 
  wrong]"
fi
done

    

Answer 1

Seu script atual não realiza uma solicitação HTTP, portanto, não há resposta HTTP e, portanto, nenhum código de resultado HTTP a ser relatado. nc -z simplesmente tenta estabelecer uma conexão TCP e, em seguida, sai imediatamente e informa se isso foi bem-sucedido ou não. Um cliente HTTP adequado não faria isso; ele enviaria uma solicitação HTTP GET ou POST válida assim que a conexão TCP fosse estabelecida e aguardasse a resposta do servidor para ela e, em seguida, reportaria isso ao usuário de alguma forma.

Você provavelmente deve adicionar outra ação ao seu script para se conectar usando, por exemplo, curl se o teste nc for bem-sucedido. O que exatamente testar é pouco claro, mas uma coisa comum para verificar é que buscar a página inicial funciona.

if curl -s http://$host/ >/dev/null; then
    echo "INFO: fetching http://$host/ worked" >&2
else
    rc=$?
    echo "ERROR: fetching http://$host/ failed (curl exit code $rc)" >&2
    exit $rc
fi

Ainda há cenários de falha em que nenhum código de resultado HTTP específico será retornado, portanto, não quis incluir isso. Se você precisar, não será difícil obter curl para reportá-lo quando estiver disponível.

Resumindo, você precisa entender o que está testando e como é uma transação HTTP completa no nível da rede, se é isso que você está tentando testar.

Observe também que a saída de diagnóstico vai para o erro padrão (o >&2 redirect).

Um script de teste de rede adequado é uma tarefa difícil de escrever no script de shell porque há tantas coisas que podem dar errado. Existe pelo menos um dispositivo de rede física? O cabo está conectado? Existe uma rota para a rede? Podemos resolver o nome do host remoto? Podemos nos conectar a ele em uma determinada porta? (Seu script atual testa isso.) O que recebe essa conexão fala o protocolo esperado? Ele lida com um pedido trivial? Ele lida com um pedido específico não trivial? É tratado corretamente - os resultados são o que esperávamos, tanto no servidor quanto na resposta recebida pelo cliente? (Por exemplo, se há um banco de dados no estado de back-end, seu estado agora é diferente, em somente o único aspecto que estamos testando?)

Um aborrecimento comum é testar GET /static-page e não perceber que a coisa que você realmente quer trabalhar está retornando um erro de 500 servidores, mas POST /dynamic-content com uma carga de teste era muito difícil ou tedioso automatize assim você nunca fez.