Antipattern: richiamare il criterio MessageLogging più volte in un proxy API

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Il criterio MessageLogging di Apigee Edge consente agli sviluppatori di proxy API di registrare messaggi personalizzati syslog o su disco (solo Edge per cloud privato). Qualsiasi informazione importante relativa all'API richieste come parametri di input, payload della richiesta, codice di risposta, messaggi di errore (se presenti), e così via, possono essere registrati per riferimento futuro o per il debug. Anche se il criterio utilizza un parametro in background per eseguire il logging, occorre prestare attenzione all'utilizzo del criterio.

Antipattern

Il criterio MessageLogging consente di recuperare in modo efficiente ulteriori informazioni su un Richiesta API e debug di eventuali problemi riscontrati con la richiesta API. Tuttavia, utilizzare lo stesso criterio MessageLogging più di una volta o avere più I criteri MessageLogging registrano i dati in blocchi nello stesso proxy API in flussi diversi dal PostClientFlow potrebbe avere implicazioni negative. Il motivo è che Apigee Edge apre una connessione a un server syslog esterno per un criterio MessageLogging. Se il criterio utilizza TLS su TCP, il processo di stabilire una connessione TLS comporta un ulteriore overhead.

Spieghiamo tutto questo con l'aiuto di un proxy API di esempio.

proxy API

Nell'esempio seguente, un criterio MessageLogging denominato "LogRequestInfo" viene inserito nel Flusso di richiesta e un altro criterio MessageLogging denominato "LogResponseInfo" viene aggiunto al Flusso di risposta. Entrambi si trovano nel ProxyEndpoint PreFlow. Il criterio LogRequestInfo esegue in background, non appena il proxy API riceve la richiesta, viene eseguito dopo che il proxy ha ricevuto una risposta dal server di destinazione ma prima che il proxy restituisca la risposta al client API. Questo consumerà risorse di sistema aggiuntive quando sono potenzialmente in corso due connessioni TLS.

Inoltre, esiste un criterio MessageLogging denominato "LogErrorInfo" che viene eseguito se si verifica un errore durante l'esecuzione del proxy 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>

Criterio di logging dei messaggi

Nelle configurazioni di criteri di esempio che seguono, i dati vengono registrati su un server di terze parti. dei log mediante TLS su TCP. Se nello stesso proxy API vengono utilizzati più criteri, per stabilire e gestire connessioni TLS occuperebbe della memoria di sistema e dei cicli di CPU, con conseguenti problemi di prestazioni su larga scala.

Norme di 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>

Norme di 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>

Criterio di 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>

Impatto

  • Aumento dell'overhead di rete dovuto alla connessione di più connessioni ai server dei log volte durante il flusso del proxy API.
  • Se il server syslog è lento o non riesce a gestire il volume elevato causato da più syslog causerà una retropressione sul processore dei messaggi, determinando una richiesta lenta e potenzialmente elevata latenza o errori 504 di timeout del gateway.
  • Aumento del numero di descrittori di file in contemporanea aperti dal processore di messaggi su Configurazioni del cloud privato in cui viene utilizzato il logging dei file.

  • Se il criterio MessageLogging è posizionato in flussi diversi da PostClient, è presente un è possibile che le informazioni non vengano registrate, in quanto il criterio MessageLogging non in caso di errori prima dell'esecuzione di questo criterio.

    Nell'esempio di ProxyEndpoint precedente, le informazioni non vengano registrate nei seguenti casi:

    • Se uno qualsiasi dei criteri posizionati prima del criterio LogRequestInfo nella flusso di richiesta non va a buon fine.
      o
    • In caso di errore del server di destinazione (HTTP 4XX, 5XX). In questa situazione, quando non viene restituita una risposta positiva, il criterio LogResponseInfo non vengono eseguiti tutti i test.

    In entrambi i casi, il criterio LogErrorInfo viene eseguito e registrerà solo gli errori informazioni.

Best practice

  • Utilizza un criterio Takeout o un criterio JavaScript per impostare l'intero flusso da registrare, rendendole disponibili per il criterio MessageLogging.
  • Usa un singolo criterio MessageLogging per registrare tutti i dati richiesti in PostClientFlow, che viene eseguita incondizionatamente.
  • Utilizza il protocollo UDP, dove la consegna garantita dei messaggi al server syslog non è e TLS/SSL non è obbligatorio.

Il criterio MessageLogging è stato progettato per essere disaccoppiato dalle effettive funzionalità dell'API. inclusa la gestione degli errori. Pertanto, richiamandolo in PostClientFlow, all'esterno dell'elaborazione di richieste/risposte, i dati verranno sempre registrati indipendentemente dal fatto che se l'API è fallita o meno.

Ecco un esempio di richiamo del criterio MessageLogging in PostClientFlow:

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

Ecco un esempio di criterio MessageLogging, LogInfo, che registra tutti i dati:

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

Poiché la risposta non sono disponibili in PostClientFlow dopo un flusso di errori, è importante per impostare in modo esplicito le variabili woeid e weather.response* utilizzando Criteri ExtractVariables o JavaScript.

Per approfondire