Monitorar e diagnosticar o processamento de solicitações no proxy reverso

Artigo
08/25/2024

A partir da versão 5.7 do Service Fabric, os eventos de proxy reverso estão disponíveis para coleta. Os eventos estão disponíveis em dois canais, um com apenas eventos de erro relacionados à falha de processamento de solicitações no proxy reverso e o segundo canal contendo eventos detalhados com entradas para solicitações bem-sucedidas e falhadas.

Consulte Coletar eventos de proxy reverso para habilitar a coleta de eventos desses canais em clusters locais e do Azure Service Fabric.

Solucionar problemas usando logs de diagnóstico

Aqui estão alguns exemplos sobre como interpretar os logs de falha comuns que se pode encontrar:

O proxy reverso retorna o código de status de resposta 504 (tempo limite).

Uma das razões pode dever-se ao facto de o serviço não ter respondido dentro do prazo limite do pedido. O primeiro evento abaixo registra os detalhes da solicitação recebida no proxy reverso. O segundo evento indica que a solicitação falhou durante o encaminhamento para o serviço, devido a "erro interno = ERROR_WINHTTP_TIMEOUT"

A carga útil inclui:

traceId: Este GUID pode ser usado para correlacionar todos os eventos correspondentes a uma única solicitação. Nos dois eventos abaixo, o traceId = 2f87b722-e254-4ac2-a802-fd315c1a0271, implicando que pertencem à mesma solicitação.
requestUrl: O URL (URL de proxy reverso) para o qual a solicitação foi enviada.
verbo: verbo HTTP.
remoteAddress: Endereço do cliente que envia a solicitação.
resolvedServiceUrl: URL do ponto de extremidade do serviço para o qual a solicitação de entrada foi resolvida.

errorDetails: Informações adicionais sobre a falha.

{
"Timestamp": "2017-07-20T15:57:59.9871163-07:00",
"ProviderName": "Microsoft-ServiceFabric",
"Id": 51477,
"Message": "2f87b722-e254-4ac2-a802-fd315c1a0271 Request url = https://localhost:19081/LocationApp/LocationFEService?zipcode=98052, verb = GET, remote (client) address = ::1, resolved service url = Https://localhost:8491/LocationApp/?zipcode=98052, request processing start time =     15:58:00.074114 (745,608.196 MSec) ",
"ProcessId": 57696,
"Level": "Informational",
"Keywords": "0x1000000000000021",
"EventName": "ReverseProxy",
"ActivityID": null,
"RelatedActivityID": null,
"Payload": {
"traceId": "2f87b722-e254-4ac2-a802-fd315c1a0271",
"requestUrl": "https://localhost:19081/LocationApp/LocationFEService?zipcode=98052",
"verb": "GET",
"remoteAddress": "::1",
"resolvedServiceUrl": "Https://localhost:8491/LocationApp/?zipcode=98052",
"requestStartTime": "2017-07-20T15:58:00.0741142-07:00"
}
}

{
"Timestamp": "2017-07-20T16:00:01.3173605-07:00",
...
"Message": "2f87b722-e254-4ac2-a802-fd315c1a0271 Error while forwarding request to service: response status code = 504, description = Reverse proxy Timeout, phase = FinishSendRequest, internal error = ERROR_WINHTTP_TIMEOUT ",
...
"Payload": {
"traceId": "2f87b722-e254-4ac2-a802-fd315c1a0271",
"statusCode": 504,
"description": "Reverse Proxy Timeout",
"sendRequestPhase": "FinishSendRequest",
"errorDetails": "internal error = ERROR_WINHTTP_TIMEOUT"
}
}

O proxy reverso retorna o código de status de resposta 404 (Não encontrado).

Aqui está um exemplo de evento em que o proxy reverso retorna 404 uma vez que não conseguiu localizar o ponto de extremidade de serviço correspondente. As entradas de carga útil de interesse aqui são:

processRequestPhase: Indica a fase durante o processamento da solicitação quando ocorreu a falha, TryGetEndpoint, ou seja, ao tentar buscar o ponto de extremidade do serviço para o qual encaminhar.

errorDetails: Lista os critérios de pesquisa de pontos de extremidade. Aqui você pode ver que o listenerName especificado = FrontEndListener enquanto a lista de pontos finais de réplica contém apenas um ouvinte com o nome OldListener.

{
...
"Message": "c1cca3b7-f85d-4fef-a162-88af23604343 Error while processing request, cannot forward to service: request url = https://localhost:19081/LocationApp/LocationFEService?ListenerName=FrontEndListener&zipcode=98052, verb = GET, remote (client) address = ::1, request processing start time = 16:43:02.686271 (3,448,220.353 MSec), error = FABRIC_E_ENDPOINT_NOT_FOUND, message = , phase = TryGetEndoint, SecureOnlyMode = false, gateway protocol = https, listenerName = FrontEndListener, replica endpoint = {\"Endpoints\":{\"\":\"Https:\/\/localhost:8491\/LocationApp\/\"}} ",
"ProcessId": 57696,
"Level": "Warning",
"EventName": "ReverseProxy",
"Payload": {
"traceId": "c1cca3b7-f85d-4fef-a162-88af23604343",
"requestUrl": "https://localhost:19081/LocationApp/LocationFEService?ListenerName=NewListener&zipcode=98052",
...
"processRequestPhase": "TryGetEndoint",
"errorDetails": "SecureOnlyMode = false, gateway protocol = https, listenerName = FrontEndListener, replica endpoint = {\"Endpoints\":{\"OldListener\":\"Https:\/\/localhost:8491\/LocationApp\/\"}}"
}
}

Outro exemplo em que o proxy reverso pode retornar 404 Not Found é: O parâmetro de configuração ApplicationGateway\Http SecureOnlyMode é definido como true com a escuta de proxy reverso em HTTPS, no entanto, todos os pontos de extremidade de réplica não são seguros (escutando em HTTP). O proxy reverso retorna 404, pois não consegue encontrar um ponto de extremidade escutando em HTTPS para encaminhar a solicitação. Analisar os parâmetros na carga útil do evento ajuda a reduzir o problema:

"errorDetails": "SecureOnlyMode = true, gateway protocol = https, listenerName = NewListener, replica endpoint = {\"Endpoints\":{\"OldListener\":\"Http:\/\/localhost:8491\/LocationApp\/\", \"NewListener\":\"Http:\/\/localhost:8492\/LocationApp\/\"}}"

A solicitação para o proxy reverso falha com um erro de tempo limite. Os logs de eventos contêm um evento com os detalhes da solicitação recebida (não mostrados aqui). O próximo evento mostra que o serviço respondeu com um código de status 404 e o proxy reverso inicia uma reresolução.
```
{
  ...
  "Message": "7ac6212c-c8c4-4c98-9cf7-c187a94f141e Request to service returned: status code = 404, status description = , Reresolving ",
  "Payload": {
    "traceId": "7ac6212c-c8c4-4c98-9cf7-c187a94f141e",
    "statusCode": 404,
    "statusDescription": ""
  }
}
{
  ...
  "Message": "7ac6212c-c8c4-4c98-9cf7-c187a94f141e Re-resolved service url = Https://localhost:8491/LocationApp/?zipcode=98052 ",
  "Payload": {
    "traceId": "7ac6212c-c8c4-4c98-9cf7-c187a94f141e",
    "requestUrl": "Https://localhost:8491/LocationApp/?zipcode=98052"
  }
}
```
Ao coletar todos os eventos, você verá um conjunto de eventos mostrando cada tentativa de resolução e encaminhamento. O último evento da série mostra que o processamento da solicitação falhou com um tempo limite, juntamente com o número de tentativas de resolução bem-sucedidas.

Nota

Recomenda-se manter a coleção de eventos do canal detalhado desabilitada por padrão e habilitá-la para solução de problemas com base na necessidade.
```
{
  ...
  "Message": "7ac6212c-c8c4-4c98-9cf7-c187a94f141e Error while processing request: number of successful resolve attempts = 12, error = FABRIC_E_TIMEOUT, message = , phase = ResolveServicePartition,  ",
  "EventName": "ReverseProxy",
  ...
  "Payload": {
    "traceId": "7ac6212c-c8c4-4c98-9cf7-c187a94f141e",
    "resolveCount": 12,
    "errorval": -2147017729,
    "errorMessage": "",
    "processRequestPhase": "ResolveServicePartition",
    "errorDetails": ""
  }
}
```
Se a coleta estiver habilitada apenas para eventos críticos/de erro, você verá um evento com detalhes sobre o tempo limite e o número de tentativas de resolução.

Os serviços que pretendem enviar um código de status 404 de volta ao usuário, devem adicionar um cabeçalho "X-ServiceFabric" na resposta. Depois que o cabeçalho é adicionado à resposta, o proxy reverso encaminha o código de status de volta para o cliente.

Casos em que o cliente desconectou a solicitação.

O seguinte evento é registrado quando o proxy reverso está encaminhando a resposta para o cliente, mas o cliente se desconecta:

{
  ...
  "Message": "6e2571a3-14a8-4fc7-93bb-c202c23b50b8 Unable to send response to client: phase = SendResponseHeaders, error = -805306367, internal error = ERROR_SUCCESS ",
  "ProcessId": 57696,
  "Level": "Warning",
  ...
  "EventName": "ReverseProxy",
  "Payload": {
    "traceId": "6e2571a3-14a8-4fc7-93bb-c202c23b50b8",
    "sendResponsePhase": "SendResponseHeaders",
    "errorval": -805306367,
    "winHttpError": "ERROR_SUCCESS"
  }
}

O proxy reverso retorna 404 FABRIC_E_SERVICE_DOES_NOT_EXIST

FABRIC_E_SERVICE_DOES_NOT_EXIST erro será retornado se o esquema de URI não for especificado para o ponto de extremidade do serviço no manifesto do serviço.
```
<Endpoint Name="ServiceEndpointHttp" Port="80" Protocol="http" Type="Input"/>
```
Para resolver o problema, especifique o esquema de URI no manifesto.
```
<Endpoint Name="ServiceEndpointHttp" UriScheme="http" Port="80" Protocol="http" Type="Input"/>
```

Nota

Os eventos relacionados ao processamento de solicitações de websocket não são registrados no momento. Isso será adicionado na próxima versão.

Próximos passos

Agregação e coleta de eventos usando o Diagnóstico do Windows Azure para habilitar a coleta de logs em clusters do Azure.
Para exibir eventos do Service Fabric no Visual Studio, consulte Monitorar e diagnosticar localmente.
Consulte Configurar proxy reverso para se conectar a serviços seguros para exemplos de modelo do Azure Resource Manager para configurar proxy reverso seguro com as diferentes opções de validação de certificado de serviço.
Leia o proxy reverso do Service Fabric para saber mais.

Partilhar via

Monitorar e diagnosticar o processamento de solicitações no proxy reverso

Solucionar problemas usando logs de diagnóstico

Próximos passos

Comentários

Recursos adicionais