Antywzór: wielokrotne wywoływanie zasady MessageLogging w serwerze proxy interfejsu API

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Zasada MessageLogging w Apigee Edge umożliwia deweloperom proxy interfejsu API rejestrowanie niestandardowych wiadomości w syslogu lub na dysku (tylko Edge for Private Cloud). Wszystkie ważne informacje związane z żądaniem interfejsu API, takie jak parametry wejściowe, ładunek żądania, kod odpowiedzi, komunikaty o błędach (jeśli występują) itp., można rejestrować w celu późniejszego odniesienia lub debugowania. Zasada używa procesu działającego w tle do rejestrowania, ale jej stosowanie wiąże się z pewnymi ograniczeniami.

Antywzorzec

Zasada MessageLogging to skuteczny sposób na uzyskanie większej ilości informacji o żądaniu do interfejsu API i debugowanie problemów, które mogą wystąpić podczas jego realizacji. Jednak używanie tej samej zasady MessageLogging więcej niż raz lub stosowanie wielu zasad MessageLogging, które rejestrują dane w blokach w tym samym proxy interfejsu API w przepływach innych niż PostClientFlow, może mieć negatywne konsekwencje. Dzieje się tak, ponieważ Apigee Edge otwiera połączenie z zewnętrznym serwerem syslog na potrzeby zasady MessageLogging. Jeśli zasada używa protokołu TLS przez TCP, występuje dodatkowy narzut związany z nawiązywaniem połączenia TLS.

Wyjaśnijmy to na przykładzie proxy interfejsu API.

Proxy interfejsu API

W poniższym przykładzie zasada MessageLogging o nazwie "LogRequestInfo" jest umieszczona w przepływie żądania, a do przepływu odpowiedzi dodano inną zasadę MessageLogging o nazwie "LogResponseInfo". Obie znajdują się w PreFlow ProxyEndpoint. Zasada LogRequestInfo jest wykonywana w tle, gdy tylko proxy interfejsu API otrzyma żądanie, a zasada LogResponseInfo jest wykonywana po otrzymaniu przez proxy odpowiedzi z serwera docelowego , ale zanim proxy zwróci odpowiedź do klienta interfejsu API. Spowoduje to zużycie dodatkowych zasobów systemowych, ponieważ mogą zostać nawiązane 2 połączenia TLS.

Dodatkowo istnieje zasada MessageLogging o nazwie „LogErrorInfo”, która jest wykonywana tylko gdy podczas wykonywania proxy interfejsu API wystąpi błąd.

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

Zasada MessageLogging

W poniższych przykładach konfiguracji zasad dane są rejestrowane na serwerach logów innych firm za pomocą protokołu TLS przez TCP. Jeśli w tym samym proxy interfejsu API używana jest więcej niż 1 z tych zasad, narzut związany z nawiązywaniem połączeń TLS i zarządzaniem nimi będzie zajmować dodatkową pamięć systemową i cykle procesora, co spowoduje problemy z wydajnością na dużą skalę.

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

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

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

Wpływ

  • Zwiększony narzut sieciowy spowodowany wielokrotnym nawiązywaniem połączeń z serwerami logów multiple times podczas przepływu proxy interfejsu API.
  • Jeśli serwer syslog jest wolny lub nie może obsłużyć dużej liczby wywołań syslog spowoduje to wzrost obciążenia procesora wiadomości, co spowoduje wolne przetwarzanie żądań i potencjalnie duże opóźnienie lub błędy 504 Gateway Timeout.
  • Zwiększona liczba współbieżnych deskryptorów plików otwartych przez procesor wiadomości w konfiguracjach Private Cloud, w których używane jest rejestrowanie w plikach.

  • Jeśli zasada MessageLogging jest umieszczona w przepływach innych niż PostClientFlow, istnieje możliwość, że informacje nie zostaną zarejestrowane, ponieważ zasada MessageLogging nie zostanie wykonana, jeśli przed jej wykonaniem wystąpi jakikolwiek błąd.

    W poprzednim przykładzie ProxyEndpoint informacje nie zostaną zarejestrowane w tych okolicznościach:

    • Jeśli któraś z zasad umieszczonych przed zasadą LogRequestInfo w przepływie żądania zakończy się niepowodzeniem.
      lub
    • Jeśli serwer docelowy zakończy się niepowodzeniem z powodu błędu (HTTP 4XX, 5XX). W takiej sytuacji, gdy nie zostanie zwrócona prawidłowa odpowiedź, zasada LogResponseInfo nie zostanie wykonana.

    W obu przypadkach zasada LogErrorInfo zostanie wykonana i zarejestruje tylko informacje związane z błędem.

Sprawdzona metoda

  • Użyj zasady ExtractVariables lub zasady JavaScript, aby ustawić wszystkie zmienne przepływu , które mają być rejestrowane, i udostępnić je zasadzie MessageLogging.
  • Użyj jednej zasady MessageLogging, aby rejestrować wszystkie wymagane dane w PostClientFlow, który jest wykonywany bezwarunkowo.
  • Użyj protokołu UDP, w którym nie jest wymagane gwarantowane dostarczanie wiadomości do serwera syslog, a protokół TLS/SSL nie jest obowiązkowy.

Zasada MessageLogging została zaprojektowana tak, aby była niezależna od rzeczywistej funkcjonalności interfejsu API, w tym obsługi błędów. Dlatego wywoływanie jej w PostClientFlow, który znajduje się poza przetwarzaniem żądań i odpowiedzi, oznacza, że zawsze będzie rejestrować dane, niezależnie od tego, czy interfejs API zakończył się niepowodzeniem.

Oto przykład wywoływania zasady MessageLogging w PostClientFlow:

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

Oto przykład zasady MessageLogging, LogInfo, która rejestruje wszystkie dane:

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

Ponieważ zmienne odpowiedzi nie są dostępne w PostClientFlow po przepływie błędów, ważne jest aby jawnie ustawić woeid i weather.response* zmienne za pomocą zasad ExtractVariables lub JavaScript.

Więcej informacji