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

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Zasada MessageLogging Apigee Edge zezwala programistom interfejsów API interfejsu API na rejestrowanie niestandardowych komunikatów w pliku Syslog lub na dysku (tylko Edge dla Private Cloud). Wszystkie ważne informacje związane z żądaniem do interfejsu API, takie jak parametry wejściowe, ładunek żądania, kod odpowiedzi, komunikaty o błędach (jeśli występują) itd., można rejestrować w celu późniejszego wglądu lub debugowania. Chociaż zasada do logowania korzysta z procesu w tle, korzystanie z niej podlega pewnym ograniczeniom.

Antywzór

Zasada MessageLogging pozwala efektywnie uzyskiwać więcej informacji o żądaniach do interfejsu API i debugować wszelkie problemy związane z tymi żądaniami. Jednak używanie tej samej zasady MessageLogging więcej niż raz lub używanie wielu danych logu MessageLogging we fragmentach w tym samym serwerze 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 korzysta z protokołu TLS przez TCP, nawiązanie połączenia TLS wiąże się z dodatkowym nakładem pracy.

Wyjaśnimy to za pomocą przykładowego serwera proxy interfejsu API.

proxy interfejsu API

W poniższym przykładzie zasada MessageLogging o nazwie „LogRequestInfo” została umieszczona w przepływie żądania, a druga zasada MessageLogging o nazwie „LogResponseInfo” została dodana do przepływu odpowiedzi. Oba są w trybie PreFlow ProxyEndpoint. Zasada LogRequestInfo jest wykonywana w tle natychmiast po otrzymaniu żądania przez serwer proxy interfejsu API, a zasada LogResponseInfo jest realizowana po otrzymaniu odpowiedzi z serwera docelowego, ale przed zwróceniem odpowiedzi na klienta API przez serwer proxy. Spowoduje to wykorzystanie dodatkowych zasobów systemowych, ponieważ może być nawiązywane 2 połączenia TLS.

Oprócz tego istnieje zasada MessageLogging o nazwie „LogErrorInfo”, która jest wykonywana tylko w przypadku wystąpienia błędu podczas wykonywania serwera proxy interfejsu 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>

Zasady logowania wiadomości

W poniższych przykładowych konfiguracjach zasad dane są logowane na serwerach logów innych firm przy użyciu protokołu TLS przez TCP. Jeśli w tym samym serwerze proxy interfejsu API jest używana więcej niż 1 z tych zasad, nakład pracy związany z nawiązywaniem połączeń TLS i zarządzaniem nimi zajmowałby dodatkową pamięć systemową i cykle procesora, co prowadziłoby do problemów 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ększenie obciążenia sieci spowodowane wielokrotnym nawiązywaniem połączeń z serwerami logów podczas przepływu serwera proxy interfejsu API.
  • Jeśli serwer syslog działa wolno lub nie jest w stanie obsłużyć dużej ilości danych z powodu wielu wywołań syslog, spowoduje to ciśnienie wsteczne na procesor wiadomości, co spowoduje powolne przetwarzanie żądań i potencjalnie wysokie opóźnienie lub błędy 504 limitu czasu bramy.
  • Zwiększona liczba równoczesnych deskryptorów plików otwieranych przez procesor wiadomości w konfiguracjach chmury prywatnej, w której używane jest logowanie plików.

  • Jeśli zasada MessageLogging znajduje się w przepływach innych niż przepływ klienta PostClient, istnieje możliwość, że informacje nie zostaną zarejestrowane, ponieważ zasada MessageLogging nie zostanie wykonana, jeśli przed wykonaniem tej zasady wystąpi jakiś błąd.

    W poprzednim przykładzie ProxyEndpoint informacje nie będą rejestrowane w tych sytuacjach:

    • Jeśli któraś z zasad umieszczona przed zasadą LogRequestInfo w przepływie żądania nie powiedzie się.
      lub
    • Jeśli na serwerze docelowym wystąpi błąd (HTTP 4XX, 5XX). W takiej sytuacji, jeśli odpowiedź z odpowiedzią nie zostanie zwrócona, zasada LogResponseInfo nie zostanie wykonana.

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

Sprawdzona metoda

  • Użyj zasady wyodrębniania danych lub zasady JavaScript, aby ustawić wszystkie zmienne przepływu, które mają być logowane, i udostępnij je na potrzeby zasady MessageLogging.
  • Użyj pojedynczej zasady MessageLogging, aby rejestrować wszystkie wymagane dane w ramach PostClientFlow, która jest wykonywana bezwarunkowo.
  • Użyj protokołu UDP, gdzie gwarantowane dostarczanie wiadomości do serwera Syslog nie jest wymagane, a protokół TLS/SSL nie jest wymagany.

Zasada MessageLogging została zaprojektowana tak, aby oddzielać ją od rzeczywistych funkcji interfejsu API, w tym obsługi błędów. Dlatego wywołanie go w PostClientFlow, który jest poza przetwarzaniem żądań/odpowiedzi, oznacza, że będzie zawsze logował dane niezależnie od tego, czy interfejs API zawiedził czy nie.

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ż po przeprowadzeniu procesu błędów zmienne odpowiedzi są niedostępne w PostClientFlow, ważne jest wyraźne ustawienie zmiennych woeid i weather.response* za pomocą zasad ExtractVariables lub zasad JavaScript.

Więcej informacji