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

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

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

Антипаттерн

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

Поясним это на примере API-прокси.

API-прокси

В следующем примере политика регистрации сообщений с именем «LogRequestInfo» помещается в поток запросов, а другая политика регистрации сообщений с именем «LogResponseInfo» добавляется в поток ответов. Оба находятся в ProxyEndpoint PreFlow. Политика 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 будут занимать дополнительную системную память и циклы ЦП, что приведет к проблемам с производительностью в масштабе.

Политика ЛогрекуестИнфо

<?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>

Политика Логреспонсенфо

<?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>

Политика Логерроинфо 

<?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.
  • Если сервер системного журнала работает медленно или не может справиться с большим объемом, вызванным несколькими вызовами системного журнала, это вызовет обратную нагрузку на процессор сообщений, что приведет к медленной обработке запросов и потенциально высокой задержке или ошибкам 504 Gateway Timeout.
  • Увеличено количество одновременных файловых дескрипторов, открываемых обработчиком сообщений в настройках частного облака, где используется ведение журнала файлов.

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

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

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

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

Лучшая практика

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

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

Вот пример вызова политики регистрации сообщений в PostClientFlow:

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

Вот пример политики регистрации сообщений 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.

Дальнейшее чтение