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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Zasady MessageLogging Apigee Edge umożliwiają programistom korzystającym z serwera proxy interfejsu API logowanie niestandardowych wiadomości w syslog lub na dysk (tylko Edge dla Private Cloud). Wszystkie ważne informacje związane z interfejsem API takie jak parametry wejściowe, ładunek żądania, kod odpowiedzi, komunikaty o błędach (jeśli występują), i tak dalej, mogą być rejestrowane do późniejszego wglądu lub debugowania. Chociaż zasada używa w tle do celów rejestrowania, mają pewne ograniczenia związane z korzystaniem z tych zasad.

Antywzór

Zasady MessageLogging to efektywny sposób uzyskiwania dodatkowych informacji na temat żądań do interfejsu API i debugowania wszelkich problemów, które mogą wystąpić w związku z tym żądaniem; Jednak użycie tej samej zasady MessageLogging więcej niż raz lub korzystanie z wielu Zasady MessageLogging logują dane we fragmentach na tym samym serwerze proxy interfejsu API w przepływach innych niż PostClientFlow może mieć niepożądane skutki. Dzieje się tak, ponieważ Apigee Edge otwiera połączenie do zewnętrznego serwera Syslog na potrzeby zasady MessageLogging. Jeśli zasada używa protokołu TLS przez TCP, wiążą się z tym dodatkowe wymagania związane z nawiązywaniem połączenia TLS.

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

proxy interfejsu API

W poniższym przykładzie zasada MessageLogging o nazwie „LogRequestInfo” jest umieszczane w kolumnie Przepływ żądań i inna zasada MessageLogging o nazwie „LogResponseInfo” jest dodawane do Przepływ odpowiedzi. Oba typy znajdują się w ProxyEndpoint PreFlow. Zasada LogRequestInfo jest wykonywana w tle, gdy tylko serwer proxy interfejsu API otrzyma żądanie, a tag LogResponseInfo zasada jest wykonywana po otrzymaniu odpowiedzi od serwera docelowego przez serwer proxy ale zanim serwer proxy zwróci odpowiedź klientowi interfejsu API. Zużyje to dodatkowych zasobów systemowych jako dwóch połączeń TLS.

Dodatkowo istnieje zasada MessageLogging o nazwie „LogErrorInfo”. który jest wykonywany tylko jeśli podczas wykonywania serwera 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 logowania wiadomości

W poniższych przykładowych konfiguracjach zasad dane są logowane w usłudze innej firmy serwerów logów korzystających z protokołu TLS przez TCP. Jeśli na tym samym serwerze proxy interfejsu API jest używanych więcej niż 1 z tych zasad, związane z nawiązywaniem połączeń TLS i zarządzaniem nimi stanowiłyby dodatkowe koszty. pracy pamięci systemu i cykli procesora, co prowadzi do dużych problemów z wydajnością.

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ększone obciążenie sieci z powodu nawiązania wielu połączeń z serwerami logów; podczas procesu API Proxy.
  • Jeśli serwer Syslog działa wolno lub nie może obsłużyć dużego woluminu spowodowanego przez wiele komunikatów Syslog spowoduje to wywieranie presji na procesor wiadomości, co spowalnia żądania i potencjalnie duże błędy czasu oczekiwania lub 504 przekroczenie limitu czasu bramy.
  • Większa liczba równoczesnych deskryptorów plików otwartych przez procesor wiadomości w dniu Konfiguracje chmury prywatnej, w których używane jest logowanie plików.

  • Jeśli zasada MessageLogging zostanie umieszczona w przepływach innych niż przepływ PostClient, powstanie błąd informacje mogą nie zostać zarejestrowane, ponieważ zasady MessageLogging zostanie wykonana, jeśli przed wykonaniem tej zasady wystąpi jakiś błąd.

    W poprzednim przykładzie (ProxyEndpoint) informacje zostaną nie mogą być rejestrowane w następujących okolicznościach:

    • Jeśli którakolwiek z zasad umieszczonych przed zasadą LogRequestInfo w nie udało się zrealizować żądania.
      lub
    • Jeśli wystąpi błąd serwera docelowego (HTTP 4XX, 5XX). W tej sytuacji, nie zostanie zwrócona pomyślna odpowiedź, zasada LogResponseInfo nie zostanie zostanie wykonany.

    W obu przypadkach zasada LogErrorInfo zostanie wykonana i zarejestruje tylko błąd i informacjami o nich.

Sprawdzona metoda

  • Użyj zasady ExtractZmiennes lub JavaScriptu, aby określić cały przepływ które mają być rejestrowane, udostępniając je zasadom MessageLogging.
  • za pomocą jednej zasady MessageLogging do rejestrowania wszystkich wymaganych danych w PostClientFlow; który jest wykonywany bezwarunkowo.
  • Używaj protokołu UDP, gdzie gwarantowane dostarczenie wiadomości do serwera syslog nie jest możliwe i protokołu TLS/SSL nie są wymagane.

Zasady MessageLogging zostały zaprojektowane w taki sposób, aby umożliwić odłączenie od rzeczywistych funkcji interfejsu API, łącznie z obsługą błędów. Dlatego też jego wywołanie w obiekcie PostClientFlow, który jest poza zakresem przetwarzania żądań/odpowiedzi, co oznacza, że zawsze będą rejestrowane dane, niezależnie od tego, lub błąd API.

Oto przykład wywołania 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 zasad 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ż reakcja zmiennych są niedostępne w PostClientFlow po wystąpieniu błędu, jawnie ustawić zmienne woeid i weather.response* za pomocą funkcji ExtractZmienne i zasady JavaScriptu.

Więcej informacji