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

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza Documentazione di Apigee Edge.

Il criterio MessageLogging di Apigee consente agli sviluppatori di proxy API di registrare messaggi personalizzati Cloud Logging o endpoint syslog. 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 apre una connessione a un endpoint esterno per un criterio MessageLogging. Se il criterio utilizza TLS su TCP, come per gli endpoint syslog, si verifica l'overhead aggiuntivo di stabilire una connessione TLS.

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. Simile si verificano effetti negativi se si utilizza MessageLogging per accedere agli endpoint Cloud Logging.

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ù endpoint di 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.

  • Se il criterio MessageLogging è posizionato in flussi diversi da PostClient, è presente un è possibile che le informazioni non vengano registrate, poiché 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.

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

Best practice

  • All'interno del flusso del proxy, utilizza una o più istanze del criterio Takeout o del criterio JavaScript per impostare l'intero flusso variabili da inserire in una variabile di contesto; questo le renderà disponibili per il criterio MessageLogging che verrà eseguito in seguito.
  • Usa un singolo criterio MessageLogging per registrare tutti i dati richiesti in PostClientFlow, che viene eseguita incondizionatamente.
  • Se utilizzi syslog, utilizza il protocollo UDP se 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. Quindi, richiamandolo in PostClientFlow, all'esterno dell'elaborazione di richieste/risposte, i dati verranno sempre registrati indipendentemente dal fatto che se l'API è riuscita 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