Acompanhe a solicitação de cotação até o destino

Introdução

PARCEL é uma loja fictícia de presentes. Os visitantes exploram Arc lamp ou Clay vase e comparam entrega e retirada. A retirada já retorna uma estimativa, mas a entrega falha. Sua tarefa é acompanhar uma nova solicitação com falha desde a entrada até o serviço que respondeu e restaurar preços corretos sem prejudicar a retirada.

Familiaridade básica com o terminal é suficiente. Você editará dois arquivos curtos do Nginx, lerá logs reais e testará respostas reais. Não precisa programar aplicações, usar SDK, conta externa, fazer compras ou fornecer dados pessoais. Todos os serviços compartilham uma instância de treinamento preparada: é correlação de solicitações, não uma plataforma completa de rastreamento distribuído.

Use Website para explorar e solicitar estimativas. Execute todos os comandos em Workstation, que começa em /home/labex/project/parcel. Cada unidade tem seu próprio ambiente. A entrada na porta 8081 encaminha cada estimativa a um backend. Entrega escuta em 8091, retirada em 8092. Uma porta identifica um serviço de rede; em Workstation, 127.0.0.1 significa esta instância do laboratório.

Dê uma referência comum a uma nova solicitação

Nesta etapa, você conhecerá o percurso normal do cliente, observará a falha e relacionará uma solicitação nova em dois logs reais. Comece em Website.

Conheça a loja

Abra Arc lamp em Two good things. Os detalhes mostram $48 e uma ilustração local. Selecione Estimate collection, mantenha Arc lamp e Near e clique em Get estimate. Devem aparecer $2.00 e HTTP 200. Essa é a função normal a preservar. Volte pelo PARCEL↗, abra Delivery e clique em Get estimate: aparecem Estimate unavailable e HTTP 404.

HTTP é o protocolo de solicitação/resposta do navegador. 200 indica resposta bem-sucedida; 404, que o serviço receptor não encontrou o caminho solicitado. Um erro de conexão é diferente: nenhuma resposta utilizável do servidor chegou. A referência ainda diz not available, dificultando relacionar a resposta do cliente aos logs.

Entenda as evidências

O log de entrada já registra o identificador que o Nginx gera para cada solicitação. O backend pode registrar um identificador encaminhado. Depois de conectados, uma solicitação com falha produz registros como estes; os pontos representam seu próprio identificador:

entry:    {"id":"...","path":"/api/delivery","status":404,"upstream":"127.0.0.1:8091","upstream_status":"404"}
delivery: {"service":"delivery","id":"...","path":"/v1/shipping","status":404}

O caminho de entrada é o solicitado pelo navegador. O caminho do backend é o efetivamente encaminhado. upstream nomeia o endereço contatado e upstream_status seu estado real de resposta. O identificador comum relaciona as observações; comparar somente horários seria menos confiável com muitas solicitações. Corpos de requisição e segredos não são registrados.

Conecte o identificador

Mude para Workstation. pwd imprime o diretório atual e cat exibe um arquivo:

pwd

Espere /home/labex/project/parcel. Se saiu desse diretório, execute cd /home/labex/project/parcel; cd muda o diretório atual. Caminhos sem / inicial, como correlation.conf, são relativos a esse diretório.

cat correlation.conf

O arquivo contém apenas um comentário. Nginx é o servidor de entrada preparado. Sua configuração usa diretivas terminadas por ponto e vírgula. O servidor principal inclui este arquivo pequeno; você não altera a estrutura principal.

Um cabeçalho é um valor nomeado que acompanha uma solicitação ou resposta HTTP. proxy_set_header define o enviado ao backend; add_header adiciona um à resposta do cliente. $request_id é o valor gerado pelo Nginx para esta solicitação. always inclui o cabeçalho nas falhas e nos sucessos. X-Request-ID é a convenção compartilhada aqui. A entrada cria seu identificador em vez de confiar em um valor do visitante.

cat > correlation.conf substitui o arquivo com um here-document. Cole o bloco inteiro, incluindo o último CONF sozinho na linha. As aspas em 'CONF' preservam $request_id literalmente para que seja interpretado pelo Nginx, não pelo shell:

cat > correlation.conf <<'CONF'
proxy_set_header X-Request-ID $request_id;
add_header X-Request-ID $request_id always;
CONF

Leia o arquivo salvo e aplique-o com o auxiliar fornecido. bash executa esse script de shell. Ele verifica a sintaxe primeiro e só recarrega o Nginx se ela for válida; não corrige rotas nem avalia preços.

cat correlation.conf

bash reload.sh

Espere um teste correto e Configuration accepted. Send a new request to test it. Se houver erro em uma linha, compare grafia, pontos e vírgulas e sinais de dólar literais com o bloco, reescreva e repita. Se a sintaxe falhar, a configuração anterior continua atendendo. Recarregar não altera uma resposta antiga: envie outra solicitação.

Acompanhe sua própria falha nova

Em Delivery de Website, clique novamente em Get estimate. Ainda falha, mas Request reference agora contém 32 caracteres hexadecimais. Copie esse valor novo exato, não os pontos acima nem um identificador de captura.

Volte a Workstation. Uma variável de shell guarda um valor para os próximos comandos. Substitua PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE pela referência nova exata copiada de Website. Preserve as aspas simples e não coloque espaços em torno de =. As aspas conservam o valor literal; não execute o marcador sem substituí-lo:

REQUEST_ID='PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE'

grep imprime linhas correspondentes. -F trata o valor como texto simples; aspas duplas mantêm o valor da variável unido. Estes caminhos absolutos funcionam de qualquer diretório:

grep -F "$REQUEST_ID" /var/log/parcel/entry.jsonl

grep -F "$REQUEST_ID" /var/log/parcel/delivery.jsonl

Os dois registros devem ter exatamente o mesmo identificador, o caminho backend /v1/shipping e estado 404. Você provou que a entrega chegou a um backend que responde; não é um serviço parado nem ausência de conexão. Uma saída vazia costuma indicar referência antiga ou incorreta: solicite de novo em Website, copie o valor novo e defina REQUEST_ID novamente. Se ativasse apenas o cabeçalho de resposta, o backend continuaria com -; as duas diretivas são necessárias.

A verificação da etapa envia novas solicitações somente de leitura para testar a correlação. Não exige uma variável específica, histórico de comandos nem arquivo de logs copiado.

Restaure a rota e mantenha as duas estimativas

Nesta etapa, você usará os dois registros e o contrato do serviço para corrigir a entrega. Comece em Workstation.

Separe endereço e caminho

Leia a configuração de rotas com cat:

cat routes.conf

Um bloco location = corresponde a um caminho público exato; as chaves agrupam suas diretivas. proxy_pass indica ao Nginx o destino. Em http://127.0.0.1:8091/v1/shipping, endereço e porta selecionam um serviço, enquanto /v1/shipping seleciona uma operação. Qualquer parte pode estar errada. Nessas locations exatas, o caminho backend configurado substitui o caminho público correspondente; as opções de consulta continuam sendo encaminhadas.

Este é o contrato dos serviços preparados:

Os dois também respondem a /health, mas um serviço saudável não prova roteamento correto. Os logs mostraram entrega em 8091 no caminho /v1/shipping. O serviço é responsável pela entrega, mas não fornece esse caminho. O contrato exige /v1/delivery. Endereço e caminho da retirada já estão corretos.

Aplique a pequena correção

Substitua somente o arquivo editável de rotas, preservando a retirada:

cat > routes.conf <<'CONF'
location = /api/delivery {
    proxy_pass http://127.0.0.1:8091/v1/delivery;
}
location = /api/collection {
    proxy_pass http://127.0.0.1:8092/v1/collection;
}
CONF

bash reload.sh

Se a sintaxe falhar, compare chaves e pontos e vírgulas, reescreva o arquivo e repita. Não edite backend, site, logs nem configuração principal. Retornar 200 sem uma estimativa real correta apenas esconderia o defeito.

Teste preços reais e correlação

Em Website, abra Delivery e solicite Arc lamp / Near novamente. Deve mostrar $6.00, HTTP 200 e uma referência nova. Solicite Clay vase / Far: espere $13.00. Em Collection, Arc lamp / Near deve continuar em $2.00, e Clay vase / Far, em $4.00. Cada clique envia outra solicitação, então as referências devem mudar. As páginas de produtos abertas por PARCEL↗ também devem manter figuras e preços.

Volte a Workstation. curl envia uma solicitação HTTP. -sS oculta o progresso, mas mostra erros de conexão; -i inclui cabeçalhos. As aspas simples mantêm & dentro da URL para o shell não o interpretar. As opções após ? escolhem objeto e distância:

curl -sS -i 'http://127.0.0.1:8081/api/delivery?item=vase&zone=far'

Espere HTTP/1.1 200 OK, um cabeçalho X-Request-ID e JSON com "service": "delivery", "amount": 13, "currency": "USD". JSON é um formato de texto de valores nomeados. O request_id do corpo deve ser igual ao cabeçalho. A capitalização dos nomes de cabeçalho pode variar sem alterar o significado.

Use a referência desta resposta para definir REQUEST_ID novamente e repita os dois grep -F da etapa 1. Os dois logs agora mostram 200 e o de delivery registra /v1/delivery. Os 404 antigos são histórico útil; não os apague nem reescreva.

Confira separadamente a função preservada:

curl -sS -i 'http://127.0.0.1:8081/api/collection?item=lamp&zone=near'

Espere 200, "service": "collection" e "amount": 2. Um 404 ainda é uma resposta HTTP normal; curl sem a opção de falhar por estado HTTP pode terminar normalmente. Um erro de conexão indica processo indisponível ou endereço errado: reveja a última configuração funcional em vez de confundir isso com a evidência de caminho anterior.

A verificação final solicita todas as combinações de objeto/distância das duas operações, relaciona identificadores novos com logs reais e testa o site completo. Só são acrescentados registros comuns de acesso; a avaliação não recarrega a configuração, reescreve arquivos nem cria pedidos.

Resumo

Você relacionou os logs de entrada e backend de uma solicitação nova por uma referência gerada, distinguiu um caminho ausente em um serviço que responde de uma falha de conexão e corrigiu a rota real. Testou resultados variados e preservou a retirada. O desafio independente muda o serviço receptor usando os mesmos métodos de endereço/caminho e correlação.