Антишаблон: несколько раз вызвать политику регистрации сообщений в прокси-сервере API. Антишаблон: несколько раз вызвать политику регистрации сообщений в прокси-сервере API.

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Политика MessageLogging в Apigee Edge позволяет разработчикам API-прокси записывать пользовательские сообщения в syslog или на диск (только в Edge для частного облака). Любая важная информация, связанная с запросом API, такая как входные параметры, полезная нагрузка запроса, код ответа, сообщения об ошибках (если таковые имеются) и т. д., может быть записана для последующего использования или отладки. Хотя политика использует фоновый процесс для выполнения логирования, существуют ограничения на ее использование.

Антипаттерн

Политика MessageLogging предоставляет эффективный способ получения дополнительной информации о запросе API и отладки любых проблем, возникающих при выполнении запроса API. Однако использование одной и той же политики MessageLogging несколько раз или использование нескольких политик MessageLogging для записи данных порциями в одном и том же API-прокси в потоках, отличных от PostClientFlow, может иметь негативные последствия. Это связано с тем, что Apigee Edge открывает соединение с внешним сервером syslog для политики MessageLogging. Если политика использует TLS поверх TCP, возникает дополнительная нагрузка на установление TLS-соединения.

Давайте объясним это на примере API-прокси.

API-прокси

В следующем примере политика логирования сообщений с именем "LogRequestInfo" помещена в поток запроса, а другая политика логирования сообщений с именем "LogResponseInfo" добавлена ​​в поток ответа. Обе находятся в предварительном потоке ProxyEndpoint. Политика LogRequestInfo выполняется в фоновом режиме, как только API-прокси получает запрос, а политика LogResponseInfo выполняется после того, как прокси получит ответ от целевого сервера, но до того, как прокси вернет ответ API-клиенту. Это приведет к потреблению дополнительных системных ресурсов, поскольку потенциально устанавливаются два TLS-соединения.

Кроме того, существует политика логирования сообщений под названием "LogErrorInfo", которая выполняется только в случае ошибки во время выполнения API-прокси.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
  ...
<FaultRules>
    <FaultRule name="fault-logging">
        <Step>
            <Name>LogErrorInfo</Name>
        </Step>
    </FaultRule>
</FaultRules>
<PreFlow name="PreFlow">
    <Request>
      <Step>
        <Name>LogRequestInfo</Name>
      </Step>
    </Request>
  </PreFlow>
  <PreFlow name="PreFlow">
    <Response>
      <Step>
        <Name>LogResponseInfo</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

Политика ведения журнала сообщений

В приведенных ниже примерах конфигураций политик данные записываются на сторонние серверы журналов с использованием TLS поверх TCP. Если в одном и том же API-прокси используется более одной такой политики, накладные расходы на установление и управление TLS-соединениями будут занимать дополнительную системную память и циклы ЦП, что приведет к проблемам с производительностью в масштабе.

Политика LogRequestInfo

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogRequestInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>INFO</logLevel>
</MessageLogging>

Политика LogResponseInfo

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogResponseInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Status: {response.status.code}, Response {response.content}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>INFO</logLevel>
</MessageLogging>

Политика LogErrorInfo

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogErrorInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Fault name: {fault.name}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>ERROR</logLevel>
</MessageLogging>

Влияние

  • Увеличение накладных расходов на сеть из-за многократного установления соединений с серверами журналов в процессе работы API-прокси.
  • Если сервер syslog работает медленно или не справляется с большим объемом запросов syslog, это создаст дополнительную нагрузку на обработчик сообщений, что приведет к замедлению обработки запросов и потенциально к высокой задержке или ошибкам 504 Gateway Timeout.
  • В конфигурациях частного облака, где используется логирование файлов, увеличилось количество одновременно открываемых обработчиком сообщений файловых дескрипторов.

  • Если политика MessageLogging размещена в потоках, отличных от потока PostClient, существует вероятность того, что информация может не быть записана в журнал, поскольку политика MessageLogging не будет выполнена, если до ее выполнения произойдет какой-либо сбой.

    В предыдущем примере с ProxyEndpoint информация не будет записываться в журнал при следующих обстоятельствах:

    • Если какая-либо из политик, расположенных перед политикой LogRequestInfo в потоке запросов, завершится неудачей.
      или
    • Если целевой сервер выдает ошибку (HTTP 4XX, 5XX), то в этом случае, если не получен успешный ответ, политика LogResponseInfo не будет выполнена.

    В обоих случаях будет выполнена политика LogErrorInfo, которая будет записывать в журнал только информацию, относящуюся к ошибке.

Передовая практика

  • Используйте политику ExtractVariables или политику JavaScript , чтобы задать все переменные потока, которые должны быть зарегистрированы, сделав их доступными для политики MessageLogging.
  • Используйте единую политику MessageLogging для записи всех необходимых данных в PostClientFlow, который выполняется безусловно.
  • Используйте протокол UDP, в рамках которого не требуется гарантированная доставка сообщений на сервер syslog, а использование TLS/SSL не является обязательным.

Политика MessageLogging разработана таким образом, чтобы быть независимой от фактической функциональности API, включая обработку ошибок. Поэтому её вызов в PostClientFlow, который находится вне обработки запросов/ответов, означает, что данные будут всегда записываться в лог независимо от того, завершился ли API с ошибкой или нет.

Вот пример вызова политики MessageLogging в PostClientFlow:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 ...
<PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>LogInfo</Name>
            </Step>
        </Response>
</PostClientFlow>
 ...

Вот пример политики MessageLogging под названием LogInfo, которая записывает все данные в журнал:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogInfo">
  <Syslog>
    <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {woeid} Status: {weather.response.code}, Response {weather.response}, Fault: {fault.name:None}.</Message>
    <Host>logs-01.loggly.com</Host>
    <Port>6514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <SSLInfo>
        <Enabled>true</Enabled>
    </SSLInfo>
  </Syslog>
  <logLevel>INFO</logLevel>
</MessageLogging>

Поскольку переменные ответа недоступны в PostClientFlow после обработки ошибки, важно явно установить переменные woeid и weather.response* с помощью ExtractVariables или политик JavaScript.

Дополнительная информация