Мониторинг и диагностика обработки запросов на обратном прокси-сервере

2025-04-08

Начиная с выпуска Service Fabric версии 5.7, для сбора доступны события обратного прокси. События доступны в двух каналах, один из которых содержит только события ошибок, связанные с сбоем обработки запросов на обратном прокси-сервере и втором канале с подробными событиями с записями для успешных и неудачных запросов.

См. раздел Сбор событий обратного прокси-сервера, чтобы включить сбор событий из этих каналов в кластерах локальных и Azure Service Fabric.

Устранение неполадок с помощью журналов диагностики

Ниже приведены некоторые примеры интерпретации распространенных журналов сбоев, с которыми можно столкнуться:

Обратный прокси-сервер возвращает код состояния ответа 504 (время ожидания).

Одна из причин может заключаться в том, что служба не смогла ответить в течение установленного времени ожидания запроса. Первое событие ниже регистрирует сведения о запросе, полученном на обратном прокси-сервере. Второе событие указывает, что запрос завершился сбоем при переадресации в службу из-за внутренней ошибки = ERROR_WINHTTP_TIMEOUT.

Полезная нагрузка включает:
- traceId: этот GUID можно использовать для сопоставления всех событий, соответствующих одному запросу. В нижеупомянутых двух событиях traceId = 2f87b722-e254-4ac2-a802-fd315c1a0271, что подразумевает, что они принадлежат одному и тому же запросу.
- requestUrl: URL-адрес (обратный прокси-адрес), на который был отправлен запрос.
- verb: HTTP verb.
- remoteAddress: адрес клиента, отправляющего запрос.
- resolvedServiceUrl: URL-адрес конечной точки службы, на который был разрешен входящий запрос.
- errorDetails: дополнительные сведения о сбое.
```
{
"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"
}
}
```
Обратный прокси-сервер возвращает код состояния ответа 404 (не найден).

Ниже приведен пример события, в котором обратный прокси-сервер возвращает 404, так как не удалось найти соответствующую конечную точку службы. Ниже приведены полезные данные:
- processRequestPhase: указывает этап во время обработки запросов при сбое, TryGetEndpoint т. е. при попытке получить конечную точку службы для перенаправления.
- errorDetails: перечисляет критерии поиска конечной точки. Здесь можно увидеть, что имя прослушивателя указано = FrontEndListener , а список конечных точек реплики содержит только прослушиватель с именем 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\/\"}}"
}
}
```
  Другой пример, в котором обратный прокси-сервер может вернуть значение 404 Not Found: Параметр конфигурации ApplicationGateway\Http SecureOnlyMode имеет значение true с обратным прокси-сервером, прослушивающим HTTPS, однако все конечные точки реплики небезопасны (прослушивание по ПРОТОКОЛу HTTP). Обратный прокси-сервер возвращает 404, так как он не может найти конечную точку, прослушивающую HTTPS, чтобы перенаправить запрос. Анализ параметров в полезной нагрузке события помогает определить проблему.
```
"errorDetails": "SecureOnlyMode = true, gateway protocol = https, listenerName = NewListener, replica endpoint = {\"Endpoints\":{\"OldListener\":\"Http:\/\/localhost:8491\/LocationApp\/\", \"NewListener\":\"Http:\/\/localhost:8492\/LocationApp\/\"}}"
```
Запрос на обратный прокси-сервер завершается ошибкой времени ожидания. Журналы событий содержат событие со сведениями о полученном запросе (не показано здесь). Следующее событие показывает, что служба ответила с кодом состояния 404, и обратный прокси-сервер инициирует повторное разрешение.
```
{
  ...
  "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"
  }
}
```
При сборе всех событий вы увидите поезд событий, показывающий каждую попытку разрешения и пересылки. Последнее событие в серии указывает, что обработка запроса завершилась ошибкой из-за истечения времени ожидания, а также показывает число успешных попыток обработки запроса.

Примечание.

Рекомендуется сохранить коллекцию событий подробного канала, отключенную по умолчанию, и включить ее для устранения неполадок на основе необходимости.
```
{
  ...
  "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": ""
  }
}
```
Если сбор данных включён только для критических событий или ошибок, вы увидите одно событие с деталями о тайм-ауте и количестве попыток разрешения результатов.

Службы, которые намерены отправить код состояния 404 обратно пользователю, должны добавить в ответ заголовок X-ServiceFabric. После добавления заголовка в ответ обратный прокси-сервер перенаправит код состояния обратно клиенту.

Случаи, когда клиент отключил запрос.

Следующее событие записывается, когда обратный прокси-сервер перенаправит ответ клиенту, но клиент отключается:

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

Обратный прокси-сервер возвращает 404 FABRIC_E_SERVICE_DOES_NOT_EXIST

Ошибка FABRIC_E_SERVICE_DOES_NOT_EXIST возвращается, если схема URI не указана для точки доступа в манифесте службы.
```
<Endpoint Name="ServiceEndpointHttp" Port="80" Protocol="http" Type="Input"/>
```
Чтобы устранить проблему, укажите схему URI в манифесте.
```
<Endpoint Name="ServiceEndpointHttp" UriScheme="http" Port="80" Protocol="http" Type="Input"/>
```

Примечание.

События, связанные с обработкой запросов websocket, в настоящее время не регистрируются. Это будет добавлено в следующем выпуске.

Дальнейшие действия

Агрегирование и сбор событий с помощью средств диагностики Windows Azure для активации сбора журналов в кластерах Azure.
Сведения о просмотре событий Service Fabric в Visual Studio см. в статье "Мониторинг и диагностика локально".
Обратитесь к настройке обратного прокси-сервера для подключения к защищенным службам для примеров шаблонов Azure Resource Manager, которые демонстрируют настройку безопасного обратного прокси-сервера с различными вариантами проверки сертификатов служб.
Дополнительные сведения см. в обратном прокси-сервере Service Fabric .

Поделиться через

Мониторинг и диагностика обработки запросов на обратном прокси-сервере

Устранение неполадок с помощью журналов диагностики

Дальнейшие действия

Обратная связь

Дополнительные ресурсы