Monitorizar e diagnosticar o processamento de pedidos no proxy inverso

Artigo
06/01/2023

A partir da versão 5.7 do Service Fabric, os eventos de proxy inverso estão disponíveis para recolha. Os eventos estão disponíveis em dois canais, um com apenas eventos de erro relacionados com a falha de processamento de pedidos no proxy inverso e no segundo canal que contém eventos verbosos com entradas para pedidos com êxito e falhados.

Veja Recolher eventos de proxy inverso para permitir a recolha de eventos destes canais em clusters locais e do Azure Service Fabric.

Resolver problemas com registos de diagnósticos

Eis alguns exemplos sobre como interpretar os registos de falhas comuns que se podem encontrar:

O proxy inverso devolve o código de estado de resposta 504 (Tempo limite).

Um dos motivos pode dever-se ao facto de o serviço não ter respondido dentro do período de tempo limite do pedido. O primeiro evento abaixo regista os detalhes do pedido recebido no proxy inverso. O segundo evento indica que o pedido falhou durante o reencaminhamento para o serviço, devido a "erro interno = ERROR_WINHTTP_TIMEOUT"

O payload inclui:

traceId: este GUID pode ser utilizado para correlacionar todos os eventos correspondentes a um único pedido. Nos dois eventos abaixo, o traceId = 2f87b722-e254-4ac2-a802-fd315c1a0271, implica que pertencem ao mesmo pedido.
requestUrl: o URL (URL de proxy inverso) para o qual o pedido foi enviado.
verbo: verbo HTTP.
remoteAddress: endereço do cliente que envia o pedido.
resolvedServiceUrl: URL do ponto final de serviço para o qual o pedido recebido foi resolvido.

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 inverso devolve o código de estado de resposta 404 (Não Encontrado).

Eis um evento de exemplo em que o proxy inverso devolve 404, uma vez que não conseguiu localizar o ponto final de serviço correspondente. As entradas de juros do payload aqui são:

processRequestPhase: indica a fase durante o processamento do pedido quando ocorreu a falha, Ou seja, ao tentar obter o ponto final de serviço para onde reencaminhar.

errorDetails: lista os critérios de pesquisa de pontos finais. Aqui, pode ver que o listenerName especificado = FrontEndListener , ao passo que a lista de pontos finais de réplica contém apenas um serviço de escuta 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 inverso pode devolver 404 Não Encontrado é: O parâmetro de configuração ApplicationGateway\Http SecureOnlyMode está definido como verdadeiro com o proxy inverso a escutar em HTTPS. No entanto, todos os pontos finais da réplica não são seguros (escutar em HTTP). O proxy inverso devolve 404, uma vez que não consegue encontrar um ponto final a escutar em HTTPS para reencaminhar o pedido. Analisar os parâmetros no payload de eventos ajuda a restringir o problema:

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

O pedido para o proxy inverso falha com um erro de tempo limite. Os registos de eventos contêm um evento com os detalhes do pedido recebido (não mostrados aqui). O evento seguinte mostra que o serviço respondeu com um código de estado 404 e o proxy inverso inicia uma nova resoluçã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 recolher todos os eventos, verá uma formação de eventos que mostra todas as tentativas de resolução e reencaminhamento. O último evento da série mostra que o processamento do pedido 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 de canal verboso desativada por predefinição e ativá-la para resolução de problemas numa base necessária.
```
{
  ...
  "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 coleção estiver ativada apenas para eventos críticos/de erro, 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 estado 404 de volta para o utilizador devem adicionar um cabeçalho "X-ServiceFabric" na resposta. Depois de o cabeçalho ser adicionado à resposta, o proxy inverso reencaminha o código de estado para o cliente.

Casos em que o cliente desligou o pedido.

O evento seguinte é registado quando o proxy inverso está a reencaminhar a resposta para o cliente, mas o cliente desliga-se:

{
  ...
  "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"
  }
}

Proxy Inverso devolve 404 FABRIC_E_SERVICE_DOES_NOT_EXIST

FABRIC_E_SERVICE_DOES_NOT_EXIST erro é devolvido se o esquema de URI não for especificado para o ponto final de 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 com o processamento de pedidos websocket não são atualmente registados. Esta ação será adicionada na próxima versão.

Passos seguintes

Agregação e coleção de eventos com o Windows Diagnóstico do Azure para ativar a recolha de registos em clusters do Azure.
Para ver eventos do Service Fabric no Visual Studio, veja Monitorizar e diagnosticar localmente.
Veja Configurar o proxy inverso para ligar a serviços seguros para exemplos de modelos do Azure Resource Manager para configurar o proxy inverso seguro com as diferentes opções de validação de certificados de serviço.
Leia o proxy inverso do Service Fabric para saber mais.

Monitorizar e diagnosticar o processamento de pedidos no proxy inverso

Resolver problemas com registos de diagnósticos

Passos seguintes

Recursos adicionais