Antipadrão: invoque a política MessageLogging várias vezes em um proxy de API

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

A política MessageLogging do Apigee Edge permite que os desenvolvedores do proxy de API registrem mensagens personalizadas para syslog ou para o disco (Edge para nuvem privada). Qualquer informação importante relacionada à solicitação de API, como parâmetros de entrada, payload da solicitação, código de resposta, mensagens de erro (se houver), pode ser registrada para referência posterior ou para depuração. A política usa um processo em segundo plano para executar a geração de registros, mas há ressalvas quanto ao uso dela.

Antipadrão

A política MessageLogging é uma maneira eficiente de receber mais informações sobre uma solicitação de API e depurar problemas encontrados com ela. No entanto, usar a mesma política MessageLogging mais de uma vez ou ter várias delas em blocos no mesmo proxy de API, em fluxos diferentes do PostClientFlow, pode ter implicações adversas. Isso ocorre porque o Apigee Edge abre uma conexão a um servidor syslog externo para uma política MessageLogging. Se a política usar TLS sobre TCP, haverá uma sobrecarga adicional do estabelecimento de uma conexão TLS.

Vamos explicar isso com a ajuda de um exemplo de proxy de API.

Proxy de API

No exemplo a seguir, uma política MessageLogging chamada "LogRequestInfo" é colocada no fluxo de solicitação, e outra política MessageLogging chamada "LogResponseInfo" é adicionada ao fluxo de resposta. Ambos estão no pré-processamento ProxyEndpoint. A política LogRequestInfo é executada em segundo plano assim que o proxy da API recebe a solicitação e a política LogResponseInfo é executada após o proxy receber uma resposta do servidor de destino, mas antes do proxy retornar a resposta ao cliente da API. Isso consumirá mais recursos do sistema, já que duas conexões TLS estão sendo estabelecidas.

Além disso, há uma política MessageLogging chamada "LogErrorInfo", que é executada somente se houver um erro durante a execução do proxy da API.

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes">?
Proxy<Endpoint n>ame=&<quot;default"
  ...
Fault>Rules
   < Fau>ltRule name=&<quot>;fault-loggi<ng&qu>ot;
     <   St>ep
  <          >N<ameLogError>I<nfo/Name
        /Step>
    </FaultR>ule
/Fa<ultR>ules
PreF<low >name="Pre<Flow&>quot;
 <   Re>quest<
      S>tep<
       > Na<meLogRequestInfo/Name
>     < /Step
 >   /Req<uest>
  /PreFl<ow
 > PreFlow name=&<quot;>PreFlow<">;
   < Response>
  <    Step>
      <  NameLogRespo>nseInfo/Name
      /Step
    /Response
  /PreFlow
  ...
/ProxyEndpoint

Política de geração de registros de mensagens

Nos exemplos de configurações de política a seguir, os dados estão sendo registrados em servidores de registros de terceiros usando TLS sobre TCP. Se mais de uma dessas políticas for usada no mesmo proxy da API, a sobrecarga de estabelecer e gerenciar conexões TLS ocupará mais memória do sistema e ciclos de CPU, levando a problemas de desempenho em escala.

Política do LogRequestInfo

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
Messag>eLo<gging >name=<"L>ogRequestInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"]< Weather> requ<est >for WOEID {request<.quer>ypara<m.w}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bled<true/Enab>l<ed
    /SSLInfo>
  /Syslog
  logLevelINFO/logLevel
/MessageLogging

Política do LogResponseInfo

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
Message>Log<ging n>ame=&<quot;Lo>gResponseInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Status: {r<esponse.>statu<s.co>de}, Response {res<ponse>.cont<ent}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bled<true/Enab>l<ed
    /SSLInfo>
  /Syslog
  logLevelINFO/logLevel
/MessageLogging

Política do LogErrorInfo

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?
Mess>age<Loggin>g nam<e=">;LogErrorInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{<environm>ent.n<ame}>"] Fault name<: {fa>ult.n<ame}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bledt<rue/Enabl>e<d
    /SSLInfo
>  /Syslog
  logLevelERROR/logLevel
/MessageLogging

Impacto

  • Aumento da sobrecarga de rede devido ao estabelecimento de conexões aos servidores de registros várias vezes durante o fluxo de proxy da API
  • Se o servidor syslog estiver lento ou não puder lidar com o volume alto causado por várias chamadas syslog, haverá uma pressão no processador da mensagem, o que resultará em um processamento de solicitação lento e erros de latência possivelmente elevada ou 504 Gateway Timeout.
  • Aumento do número de descritores de arquivo simultâneos abertos pelo processador de mensagens em Configurações de nuvem privada em que a geração de registros de arquivos é usada.

  • Se a política de MessageLogging for colocada em fluxos diferentes do PostPost, há uma possibilidade de que as informações não sejam registradas, já que a política do LoggingLogging não será executada se alguma falha ocorrer antes da execução dela.

    No exemplo de ProxyEndpoint anterior, as informações não serão registradas nas seguintes circunstâncias:

    • Se qualquer uma das políticas colocadas antes da política LogRequestInfo no fluxo de solicitação falhar.
      ou
    • Se o servidor de destino falhar com algum erro (HTTP 4XX, 5XX). Nessa situação, quando uma resposta bem-sucedida não é retornada, a política LogResponseInfo não será executada.

    Em ambos os casos, a política LogErrorInfo será executada e registrará apenas as informações relacionadas a erros.

Prática recomendada

  • Use uma política ExtractVariables ou uma política JavaScript para definir todas as variáveis de fluxo que serão registradas, disponibilizando-as para a política MessageLogging.
  • Use uma única política do MessageLogging para registrar todos os dados necessários no PostClientFlow, que são executados de maneira não condicional.
  • Use o protocolo UDP, em que a entrega garantida de mensagens para o servidor syslog não é obrigatória e o TLS/SSL não é obrigatório.

A política MessageLogging foi criada para ser separada da funcionalidade real da API, incluindo tratamento de erros. Portanto, sua invocação no PostClientFlow, que está fora do processamento de solicitação/resposta, significa que ela sempre registrará dados independentemente de a API ter falhado ou não.

Veja um exemplo que invoca a política MessageLogging no PostClientFlow:

<?xml version="1.0" encoding="UTF-8&quo>t; sta<ndalone=">yes"<?
 ...
P>ostClient<Flow
   >     Request/<
   >     Response
   <    >     St<ep
  >             < Name>LogInfo/N<ame
     > <      /Step
   >     /Response
/PostClientFlow
 ...

Veja um exemplo de uma política MessageLogging, LogInfo, que registra todos os dados:

<?xml version="1.0" encoding="UTF-8&quo>t<; standalone="yes"?>
Me<ssageL>oggin<g name=>"LogInfo"
  Syslog
    Message[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {woeid} Status: {weather.response.code}, Resp<onse {we>ather<.res>ponse}, Fault: {fa<ult.n>ame:N<one}>./Me<ssage>
    <Hostlogs>-01<.loggly.c>om/Ho<st
    Port65>14/P<ort
    Protoc>olTCP</Protoc>ol
    Fo<rmatMes>sage<true/For>matMe<ssage
  >  S<SLInfo
>   <     Ena>bled<true/Enab>l<ed
    /SSLInfo>
  /Syslog
  logLevelINFO/logLevel
/MessageLogging

Como as variáveis de resposta não estão disponíveis no PostClientFlow após um fluxo de erro, é importante definir explicitamente as variáveis woeid e weather.response* usando ExtractVariables ou políticas JavaScript.

Leitura adicional