Zasada MessageLogging

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

Co

Jednym z najlepszych sposobów na śledzenie problemów w środowisku wykonawczym interfejsu API jest rejestrowanie komunikatów. Możesz dołączyć i skonfigurować zasadę MessageLogging w interfejsie API, aby rejestrować komunikaty niestandardowe w dysku lokalnym (tylko brzegi chmury prywatnej) lub do syslog.

Przykłady

<MessageLogging name="LogToSyslog">
  <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>514</Port>
    <Protocol>TCP</Protocol>
    <FormatMessage>true</FormatMessage>
    <DateFormat>yyyy-MM-dd'T'HH:mm:ss.SSSZ</DateFormat>
  </Syslog>
  <logLevel>ALERT</logLevel>
</MessageLogging>

<MessageLogging name="LogToSyslog">
  <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>
    <DateFormat>yyMMdd-HH:mm:ss.SSS</DateFormat>
  </Syslog>
  <logLevel>WARN</logLevel>
</MessageLogging>

<MessageLogging name="LogPolicy">
  <File>
    <Message>This is a test message. Message id : {request.header.messageid}</Message>
      <FileName>test.log</FileName>
      <FileRotationOptions rotateFileOnStartup="true">
        <FileRotationType>SIZE</FileRotationType>
        <MaxFileSizeInMB>10</MaxFileSizeInMB>
        <MaxFilesToRetain>10</MaxFilesToRetain>
      </FileRotationOptions>
  </File>
  <logLevel>ERROR</logLevel>
</MessageLogging>

<MessageLogging name="LogPolicy">
  <File>
    <Message>This is a test message. Message id : {request.header.messageid}</Message>
    <FileName>test.log</FileName>
    <FileRotationOptions rotateFileOnStartup="true">
      <FileRotationType>TIME</FileRotationType>
      <RotationFrequency unit="minute">10</RotationFrequency>
      <MaxFilesToRetain>10</MaxFilesToRetain>
    </FileRotationOptions>
  </File>
  <logLevel>ERROR</logLevel>
</MessageLogging>

<MessageLogging name="LogPolicy">
  <File>
    <Message>This is a test message. Message id : {request.header.messageid}</Message>
    <FileName>test.log</FileName>
    <FileRotationOptions rotateFileOnStartup="true">
      <FileRotationType>TIME_SIZE</FileRotationType>
      <MaxFileSizeInMB>10</MaxFileSizeInMB>
      <MaxFilesToRetain>10</MaxFilesToRetain>
      <RotationFrequency unit="minute">10</RotationFrequency>
    </FileRotationOptions>
  </File>
  <logLevel>ERROR</logLevel>
</MessageLogging>

<MessageLogging name="LogPolicy">
  <File>
  ....
  ....
  </File>
  <BufferMessage>true</BufferMessage>
</MessageLogging>

Odwołanie do elementu

Użyj poniższych elementów, aby skonfigurować typ zasady MessageLogging.

<SSLInfo>
    <Enabled>true</Enabled>
</SSLInfo>

Schematy

Uwagi o wykorzystaniu

Gdy dołączasz zasadę MessageLogging do procesu proxy interfejsu API, rozważ umieszczenie jej w Odpowiedź ProxyEndpoint w specjalnym procesie o nazwie PostClientFlow. Działanie PostClientFlow jest wykonywane po wysłaniu odpowiedzi do klienta, który wysłał żądanie, dzięki czemu wszystkie wskaźniki są dostępne do logowania. Szczegółowe informacje o korzystaniu z PostClientFlow znajdziesz w dokumentacji konfiguracji serwera proxy interfejsu API.

Metoda PostClientFlow jest wyjątkowa pod dwoma względami:

1. Wykonano je tylko w ramach przepływu odpowiedzi.
2. Jest to jedyny proces wykonywany po przejściu serwera proxy w stan błędu.

Ponieważ jest wykonywany niezależnie od tego, czy serwer proxy się udał, czy nie, możesz umieścić Zasady MessageLogging w PostClientFlow i gwarantują, że będą one zawsze wykonywane.

Poniższy obraz logu czasu pokazuje zasadę MessageLogging wykonywaną w ramach PostClientFlow, po wykonaniu reguły DefaultFaultRule:

W tym przykładzie błąd związany z zasadą weryfikacji klucza interfejsu API wynikał z nieprawidłowego .

Poniżej znajduje się definicja punktu końcowego serwera proxy, która zawiera interfejs PostClientFlow:

<ProxyEndpoint name="default">
  ...
  <PostClientFlow>
    <Response>
      <Step>
        <Name>Message-Logging-1</Name>
      </Step>
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

komunikaty dzienników brzegowych w formie prostego tekstu. Możesz skonfigurować logowanie tak, aby uwzględniało zmienne, takie jak: data i godzina otrzymania żądania lub odpowiedzi, tożsamość użytkownika w żądaniu; źródłowy adres IP, z którego zostało wysłane żądanie itd. Komunikat logów brzegowych asynchronicznie, co oznacza, że nie są wprowadzane żadne opóźnienia, które mogą być spowodowane przez blokujące objaśnienia, do interfejsu API.

Zasada MessageLogging zapisuje zarejestrowane wiadomości w pamięci w buforze. Rejestrator wiadomości odczytuje wiadomości z bufora, a następnie zapisuje je w skonfigurowanym przez Ciebie miejscu docelowym. Każdy miejsce docelowe ma własny bufor.

Jeśli szybkość zapisu w buforze przekroczy wartość odczytu, bufor przepełni się i nie uda się zalogować. W takim przypadku w dzienniku może pojawić się komunikat zawierający te informacje: plik:

Log message size exceeded. Increase the max message size setting

Jeśli napotkasz ten problem w Edge for Private Cloud w wersji 4.15.07 lub starszej, znajdź message-logging.properties i użyj tego rozwiązania:

Zwiększ właściwość max.log.message.size.in.kb (wartość domyślna = 128 KB) w pliku message-logging.properties.

W przypadku Edge for Private Cloud w wersji 4.16.01 lub nowszej ustaw właściwość conf/message-logging.properties+max. log.message.size.in.kb w pliku /opt/apigee/customer/application/message-processor.properties i ponownie uruchom procesor wiadomości. Pamiętaj, że ta właściwość jest początkowo domyślnie komentowana.

Uwaga: wiadomość odpowiedzi zmienne w Edge nie są dostępne w przepływie błędów. Te zmienne również nie są uwzględniane dostępna w PostClientFlow, jeśli poprzedni przepływ był przepływem błędów. Jeśli chcesz zapisać odpowiedź z PostClientFlow, użyj obiektu message. Dostępne opcje użyj tego obiektu, aby uzyskać nagłówki i inne informacje z odpowiedzi niezależnie od tego, czy istnieje był błąd. Zobacz wiadomość zmiennych).

Kontrolowanie komunikatu logu sygnatura czasowa w Edge dla Private Cloud

Domyślnie sygnatura czasowa we wszystkich komunikatach dziennika ma format:

yyyy-MM-dd'T'HH:mm:ss.SSSZ

To ustawienie domyślne w całym systemie można zastąpić dla miejsc docelowych protokołu Syslog za pomocą DateFormat element. Działanie tego szablonu zostało opisane w dokumentacji klasy SimpleDateFormat w języku Java. Zgodnie z tą definicją nazwa yyyy zostanie zastąpiona w przypadku roku składającego się z 4 cyfr, wartość MM zostanie zastąpiona 2-cyfrowym numerem miesiąca itd. Powyższy format może spowodować utworzenie ciągu znaków w postaci takiej:

2022-09-28T22:38:11.721+0000

Możesz użyć metody conf_system_apigee.syslogger.dateFormat na urządzeniu brzegowym procesora wiadomości, aby kontrolować ten format. Na przykład zmiana wiadomości format na:

yy/MM/dd'T'HH:mm:ss.SSSZ

..zastępowanie myślników ukośnikami i skrócenie do 2-cyfrowego roku powoduje zarejestrowanie sygnatury czasowej w formacie:

22/09/28T22:38:11.721+0000

Aby zmienić format:

1. Otwórz plik message-processor.properties w redaktorem. Jeśli plik nie istnieje, utwórz go:
   > vi /opt/apigee/customer/application/message-processor.properties
2. Ustaw odpowiednie właściwości:
   conf_system_apigee.syslogger.dateFormat=yy/MM/dd'T'HH:mm:ss.SSSZ
3. Zapisz zmiany.
4. Sprawdź, czy plik właściwości należy do „apigee” użytkownik:
   > chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
5. Uruchom ponownie procesor komunikatów na serwerach brzegowych:
   > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Lokalizacja pliku logu w Edge dla Private Cloud

Edge dla Private Cloud w wersji 4.16.01 i nowszych

Domyślnie logi wiadomości Private Cloud znajdują się w Wiadomościach w poniższym katalogu Węzły procesora:

/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/

Domyślną lokalizację dziennika możesz zmienić, modyfikując właściwości w message-logging.properties w systemach przetwarzania wiadomości:

• bin_setenv_data_dir - Ustawia ścieżkę główną do przechowywania plików logów. Przykład: bin_setenv_data_dir=/opt/apigee/var/log
• conf_message-logging_log.root.dir – jeśli ustawisz w tym miejscu ścieżkę względną, np. conf/message-logging.properties+log.root.dir=custom/folder/, the path is appended to the bin_setenv_data_dir location.
  
  Jeśli ustawisz tę wartość na ścieżkę bezwzględną, np. conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages, wiadomość Dzienniki zostaną zapisane w /opt/apigee/var/log/messages/messagelog/. Ścieżka bezwzględna ma pierwszeństwo przed bin_setenv_data_dir.
  
  Pamiętaj, że musisz odwoływać się do tej właściwości jako conf/message-logging.properties+log.root.dir, ponieważ domyślnie jest wyświetlany jako komentowany. Zobacz Ustawianie aktualnie komentowany.

Jeśli pliki dziennika chcesz przechowywać w płaskiej strukturze, tak aby wszystkie pliki dziennika były umieszczane w w tym samym katalogu ustaw conf/message-logging.properties+enable.flat.directory.structure na true (prawda) w pliku message-logging.properties. Wiadomości są przechowywane w katalogu określonym przez tych właściwości, a nazwy plików mają postać {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}

Aby ustawić te właściwości:

1. Otwórz plik message-processor.properties w redaktorem. Jeśli plik nie istnieje, utwórz go:
   > vi /opt/apigee/customer/application/message-processor.properties
2. Ustaw odpowiednie właściwości:
   conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages
3. Zapisz zmiany.
4. Sprawdź, czy plik właściwości należy do „apigee” użytkownik:
   > chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
5. Ponownie uruchom komponent Edge:
   > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Edge dla Private Cloud w wersji 4.15.07 i starszych

Domyślnie dzienniki wiadomości znajdują się w następującej lokalizacji wiadomości procesory:

/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/

Domyślną lokalizację dziennika możesz zmienić, modyfikując te właściwości w message-logging.properties w systemach przetwarzania wiadomości:

• data.dir – ustawia poziom główny. ścieżkę do przechowywania plików logów. Przykład: data.dir=/opt/apigee4/var/log
• log.root.dir – jeśli ustawisz do ścieżki względnej, takiej jak log.root.dir=custom/folder/, ścieżka jest dołączana do sekcji lokalizację pliku data.dir.

Na przykład połączenie tych 2 usług ustawiłoby katalog logowania na wartość /opt/apigee4/var/log/custom/folder/messagelog/ (zwróć uwagę, że dodano ścieżkę /messagelog) ).

Jeśli ustawisz tutaj ścieżkę bezwzględną, np. log.root.dir=/opt/apigee4/var/log/messages, logi wiadomości będą przechowywane w folderze /opt/apigee4/var/log/messages/messagelog/. Ścieżka bezwzględna w Parametr log.root.dir ma pierwszeństwo przed plikiem data.dir.

Jeśli pliki dziennika chcesz przechowywać w płaskiej strukturze, tak aby wszystkie pliki dziennika były umieszczane w w tym samym katalogu, ustaw właściwośćenable.flat.directory.structure na true (prawda) w pliku message-logging.properties w aplikacji Wiadomości Procesory. Wiadomości są przechowywane w katalogu określonym przez powyższe właściwości, a plik nazwy mają postać {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}.

Domyślne wartości dla zmiennych w argumencie szablon wiadomości

Wartości domyślne można określić oddzielnie dla każdej zmiennej w szablonie wiadomości. Przykład: jeśli zmiennej request.header.id nie można znaleźć, jej wartość zostaje zastąpiona o wartości unknown.

<Message>This is a test message. id = {request.header.id:unknown}</Message>

Wspólną wartość domyślną można określić dla wszystkich nierozstrzygniętych zmiennych, ustawiając atrybut Atrybut defaultVariableValue w elemencie Message:

<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>

Konfigurowanie usług zarządzania dziennikami innych firm

Zasada MessageLogging umożliwia wysyłanie komunikatów syslog do systemu zarządzania logami innej firmy takich jak Splunk, Sumo Logic czy Loggly. Jeśli chcesz wysłać syslog do jednego z tych zapoznaj się z dokumentacją tej usługi, aby skonfigurować hosta, port i protokół usługi a następnie odpowiednio ustaw element Syslog dla tej zasady.

Aby dowiedzieć się więcej o konfiguracji zarządzania dziennikami w systemie innej firmy, zapoznaj się z tą dokumentacją:

• Splunk (wybierz wersję usługi)
  Zobacz też tego posta na karcie Społeczność Apigee: https://community.apigee.com/content/kbentry/13298/log-messages-into-splunk.html
• Sumo Operatory logiczne
  • Przeczytaj też tego posta na karcie Społeczność Apigee: https://community.apigee.com/questions/5226/setting-up-logging-with-sumo-logic-which-host-shou.html
  • Pełny przykład użycia Sumo Logic jako usługi logowania znajdziesz poniżej. Post na karcie Społeczność Apigee. Rozwiązanie używa jednej zasady JavaScriptu do wykonywania żądania HTTP POST żądania wysyłane do kolektora źródła HTTP Sumo Logic: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
• Loggly
  Jeśli używasz Loggly, <FormatMessage>true</FormatMessage> jest wymagana w zasady jako elementu podrzędnego elementu <Syslog>.
  Zapoznaj się też z tym postem ze społeczności Apigee, w którym znajdziesz więcej informacji o logowaniu komunikatów do Loggly: https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html

Informacje o błędzie

W tej sekcji opisano kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wyzwala błąd. Warto o tym wiedzieć, jeśli rozwijasz reguły błędów, aby obsługi błędów. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z zasadami i postępowaniu z błędami

Błędy w czasie wykonywania

Te błędy mogą wystąpić podczas wykonywania zasady.

Błędy wdrażania

Te błędy mogą wystąpić podczas wdrażania serwera proxy zawierającego tę zasadę.

Zmienne błędów

Te zmienne są ustawiane po wystąpieniu błędu działania. Więcej informacji znajdziesz w artykule Podstawowe informacje o błędach związanych z naruszeniem zasad.

Przykładowa odpowiedź na błąd

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.messagelogging.StepDefinitionExecutionFailed"
      },
      "faultstring":"Execution failed"
   }
}

Przykładowa reguła błędu

<FaultRule name="MessageLogging">
    <Step>
        <Name>ML-LogMessages</Name>
        <Condition>(fault.name Matches "StepDefinitionExecutionFailed") </Condition>
    </Step>
    <Condition>(messagelogging.ML-LogMessages.failed = true) </Condition>
</FaultRule>

Zmienne przepływu

W przypadku błędu zgodności z zasadami te zmienne są wypełniane.

• messagelogging.failed
• messagelogging.{stepdefinition-name}.failed

Powiązane artykuły

• Zmienne wyświetlane przez krawędź: informacje o zmiennych