Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. informacje

Co
Jednym z najlepszych sposobów na śledzenie problemów w środowisku uruchomienia interfejsu API jest rejestrowanie komunikatów. Możesz dołączyć i skonfigurować w interfejsie API zasadę MessageLogging, aby rejestrować wiadomości niestandardowe na dysku lokalnym (tylko Edge dla Private Cloud) lub w pliku syslog.
Przykłady
Syslog
<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>
Typ zasady MessageLogging jest często używany do rejestrowania na koncie syslog. Gdy serwer proxy interfejsu API jest skonfigurowany do przesyłania komunikatów syslog z Apigee Edge na serwer syslog zdalny, Musisz już mieć serwer syslog. Jeśli nie, możesz skorzystać z publicznych usług zarządzania logami, takich jak Splunk, Sumo Logic czy Loggly. Zapoznaj się z artykułem Konfigurowanie usług zarządzania logami innych firm.
Wyobraź sobie na przykład, że musisz rejestrować informacje o każdej wiadomości z żądaniem, którą interfejs API otrzymuje z aplikacji dla użytkowników. Wartość 3f509b58
to klucz odpowiadający usłudze loggly. Jeśli masz konto loggly, zastąp klucz loggly. Wygenerowana wiadomość dziennika będzie zawierać 4 wartości: organizację, serwer proxy interfejsu API i nazwę środowiska powiązanego z transakcją, a także wartość parametru zapytania w wiadomości żądania.
Jeśli masz wdrożenie usługi Edge for Private Cloud, możesz też zapisywać komunikaty logowania w pliku.
Syslog przez TLS/SSL
<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>
Możesz wysyłać wiadomości do zewnętrznych dostawców usług rejestrowania wiadomości przy użyciu protokołu TLS/SSL, dodając blok <SSLInfo>
.
Obrót pliku: rozmiar
<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>
Rotacja plików na podstawie ich rozmiaru.
Rotacja plików: czas
<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>
rotacja plików na podstawie czasu;
Obrót pliku: czas i rozmiar
<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>
Rotacja plików na podstawie czasu i rozmiaru.
Możliwość strumieniowania
<MessageLogging name="LogPolicy"> <File> .... .... </File> <BufferMessage>true</BufferMessage> </MessageLogging>
Logowanie wiadomości z włączonym strumieniowaniem
Element referencyjny
Aby skonfigurować typ zasady MessageLogging, użyj tych elementów.
Nazwa pola | Opis pola | |
---|---|---|
Miejsce docelowe pliku lokalnego. (logowanie plików jest obsługiwane tylko w przypadku wdrożeń Edge for Private Cloud). Informacje o lokalizacji plików znajdziesz w artykule Lokalizacja plików dziennika w Edge dla Private Cloud. |
Message |
Utwórz wiadomość, która zostanie wysłana do pliku dziennika, łącząc tekst ze zmiennymi, aby przechwycić odpowiednie informacje. Zobacz przykłady. |
FileName |
Podstawowa nazwa pliku dziennika.
Nie podawaj ścieżki do pliku. Na przykład element FileName określa ścieżkę pliku i jest nieprawidłowy:
<FileName>/opt/apigee/var/log/messages/mylog.log</FileName> Ten kod określa tylko nazwę pliku i jest prawidłowy: <FileName>mylog.log</FileName> Informacje o lokalizacji pliku znajdziesz w artykule Lokalizacja pliku dziennika w Edge dla Private Cloud. |
|
FileRotationOptions |
||
rotateFileOnStartup |
Atrybut. Prawidłowe wartości: Jeśli ma wartość Prawda, plik dziennika jest obracany za każdym razem, gdy silnik wiadomości jest ponownie uruchamiany. |
|
FileRotationType |
Określa zasadę rotacji (size lub time ) pliku dziennika. |
|
MaxFileSizeInMB |
(Po wybraniu opcji size jako typu rotacji)
Określa rozmiar pliku dziennika, który powoduje przeniesienie wiadomości z dziennika na osobny plik. Gdy plik dziennika osiągnie określony rozmiar, serwer zmieni nazwę bieżącego pliku dziennika. |
|
RotationFrequency |
(po wybraniu opcji time jako typu rotacji)
Określa czas w minutach, po którym serwer przenosi wiadomości z dziennika do osobnego pliku. Po upływie określonego interwału nazwa bieżącego pliku dziennika zostanie zmieniona. |
|
MaxFilesToRetain |
Określa maksymalną liczbę plików, które mają być zachowane w kontekście ustawień rotacji. Wartość domyślna to 8. Jeśli podasz zero (0), pliki dziennika będą przechowywane przez nieokreślony czas, ale zgodnie z ustawieniami rotacji plików. Żaden z plików nie zostanie usunięty ani przemianowany. Aby uniknąć przyszłych błędów związanych z brakiem miejsca na dysku, ustaw tę wartość na wartość większą od 0 lub wprowadź regularny automatyczny system czyszczenia lub archiwizowania starszych zachowanych plików dziennika. |
|
BufferMessage |
Jeśli transmisja strumieniowa HTTP jest włączona na serwerze proxy, wiadomości żądania i odpowiedzi nie są buforowane. Jeśli chcesz rejestrować treści, które wymagają przeanalizowania wiadomości przepływu, ustaw opcję BufferMessage na wartość true. Przykład znajdziesz na karcie „Stream-enabled” (Obsługa strumieniowania). Wartość domyślna: false |
|
Miejsce docelowe syslog. Aby wysyłać syslog do Splunk, Sumo Logic lub Loggly, zapoznaj się z artykułem Konfigurowanie zewnętrznych usług zarządzania logami. |
Message |
Utwórz wiadomość, która ma zostać wysłana do sysloga, łącząc tekst ze zmiennymi, aby przechwycić odpowiednie informacje. Zobacz przykłady. Uwaga: zmienna odpowiedzi będzie niedostępna w PostClientFlow po przetworzeniu ścieżki błędu. Użyj zmiennych wiadomości, aby rejestrować informacje o odpowiedziach zarówno w przypadku błędów, jak i sukcesów. Zobacz też Uwagi dotyczące korzystania. |
Host |
Nazwa hosta lub adres IP serwera, na który mają być wysyłane dane syslog. Jeśli nie podasz tego elementu, domyślnie zostanie użyta wartość localhost. | |
Port |
Port, na którym działa syslog. Jeśli nie podasz tego elementu, domyślnie zostanie użyta wartość 514. | |
Protocol |
TCP lub UDP (wartość domyślna). UDP jest bardziej wydajny, ale protokół TCP zapewnia dostarczenie logów wiadomości na serwer syslog. W przypadku wysyłania komunikatów syslog przez TLS/SSL obsługiwany jest tylko protokół TCP. | |
FormatMessage |
Opcjonalny, ale Ten element umożliwia kontrolowanie formatu treści generowanych przez Apigee i dodawanych na początku wiadomości. Jeśli ma wartość Prawda, wiadomość syslog jest poprzedzona stałą liczbą znaków, co umożliwia odfiltrowywanie tych informacji z wiadomości. Oto przykład formatu stałego:
Informacje generowane przez Apigee obejmują:
Jeśli ma wartość Fałsz (domyślnie), wiadomość nie jest poprzedzona tymi znakami. |
|
PayloadOnly |
Ten element ustawia format wiadomości generowanych przez Apigee tak, aby zawierały tylko treść wiadomości syslog bez dołączonych znaków określonych przez element FormatMessage. Jeśli nie podasz tego elementu lub pozostawisz go pusty, zostanie przyjęta domyślna wartość Patrz FormatMessage. |
|
DateFormat |
Opcjonalnie. Szablonowy ciąg znaków do formatowania sygnatury czasowej dla każdej wiadomości dziennika.
Domyślnie Apigee używa |
|
SSLInfo |
Umożliwia rejestrowanie wiadomości za pomocą protokołu SSL/TLS. Użyj go z podelementem Jeśli nie podasz tego elementu lub pozostawisz go pusty, domyślnie zostanie przyjęta wartość false (nie TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> Tag <SSLInfo> możesz skonfigurować tak samo jak tag TargetEndpoint, w tym włączyć dwukierunkowy TLS/SSL zgodnie z opisem w dokumentacji dotyczącej konfiguracji serwera proxy API. Obsługiwany jest tylko protokół TCP. |
|
logLevel |
Opcjonalnie. Prawidłowe wartości: Ustaw konkretny poziom informacji, które mają być uwzględnione w dzienniku wiadomości. Jeśli używasz elementu |
Schematy
Uwagi
Podczas dołączania zasady MessageLogging do przepływu proxy interfejsu API rozważ umieszczenie jej w odpowiedzi ProxyEndpoint w specjalnym przepływie o nazwie PostClientFlow. Funkcja PostClientFlow jest wykonywana po wysłaniu odpowiedzi do klienta, co zapewnia dostępność wszystkich danych do rejestrowania. Szczegółowe informacje o używaniu parametru PostClientFlow znajdziesz w artykule Referencje dotyczące konfiguracji serwera proxy interfejsu API.
PostClientFlow jest wyjątkowy z 2 powodów:
- Jest ona wykonywana tylko w ramach przepływu odpowiedzi.
- Jest to jedyny przepływ, który jest wykonywany po tym, jak serwer proxy przechodzi w stan błędu.
Jest ona wykonywana niezależnie od tego, czy wywołanie funkcji proxy zakończyło się powodzeniem czy nie. Możesz więc umieścić zasady MessageLogging w postClientFlow i mieć pewność, że będą one zawsze wykonywane.
Na tym obrazie z wynikiem działania funkcji śledzenia błędów widać, jak zasada MessageLogging jest wykonywana w ramach PostClientFlow po wykonaniu reguły DefaultFaultRule:
W tym przykładzie błąd spowodowała polityka weryfikacji klucza interfejsu API z powodu nieprawidłowego klucza.
Poniżej znajduje się definicja ProxyEndpoint, która obejmuje PostClientFlow:
<ProxyEndpoint name="default"> ... <PostClientFlow> <Response> <Step> <Name>Message-Logging-1</Name> </Step> </Response> </PostClientFlow> ... </ProxyEndpoint>
Edge rejestruje wiadomości jako zwykły tekst. Możesz skonfigurować rejestrowanie, aby obejmowało ono zmienne, takie jak: data i godzina otrzymania żądania lub odpowiedzi, tożsamość użytkownika, z którego wysłano żądanie, adres IP źródła, z którego wysłano żądanie, itp. Edge rejestruje wiadomości asynchronicznie, co oznacza, że nie wprowadza opóźnień w Twoim interfejsie API, które mogłyby być spowodowane blokowaniem wywołań.
Zasady MessageLogging zapisują zalogowane wiadomości w pamięci do bufora. Dziennik wiadomości odczytuje wiadomości z bufora, a następnie zapisze je w skonfigurowanym miejscu docelowym. Każde miejsce docelowe ma własny bufor.
Użytkownicy mogą odczuwać opóźnienia w otrzymywaniu komunikatów z dziennika wysyłanych do nowego punktu końcowego syslog. Wynika to z zamierzonego działania „zimnego startu” w ramach zasad. Gdy skonfigurowana zostanie nowa lokalizacja rejestrowania, oprócz istniejących lokalizacji rejestrowania procesor wiadomości (MP) może najpierw umieścić w kolejce 1000 wiadomości logowania w pamięci, zanim je wyśle. Może to spowodować początkowe opóźnienie w środowiskach o małej liczbie wizyt. Ta początkowa zwłoka jest niezauważalna w przypadku typowych zadań produkcyjnych, ponieważ wiadomości powinny gromadzić się szybko. Gdy zostanie osiągnięty limit, wiadomości z logu będą dostarczane zgodnie z oczekiwaniami. Ponowne uruchomienie usługi Message Processor może też spowodować dostarczenie wiadomości oczekujących w kolejce.
Jeśli szybkość zapisu do bufora wzrośnie ponad szybkość odczytu, bufor się przepełni i rejestrowanie nie powiedzie się. W takim przypadku w pliku dziennika może pojawić się komunikat:
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ź plik message-logging.properties
i zastosuj to rozwiązanie:
Zwiększ wartość właściwości 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 uruchom ponownie usługę Message Processor. Pamiętaj, że ta właściwość jest domyślnie skomentowana.
Uwaga: zmienne wiadomość odpowiedzi w Edge nie są dostępne w ramach procesu błędów. Te zmienne są też niedostępne w postClientFlow, jeśli poprzedni przepływ danych to ErrorFlow. Jeśli chcesz zarejestrować informacje o odpowiedzi z postClientFlow, użyj obiektu message. Za pomocą tego obiektu możesz uzyskać nagłówki i inne informacje z odpowiedzi, niezależnie od tego, czy wystąpił błąd. Więcej informacji i przykład znajdziesz w sekcji Zmienna wiadomości.
Sterowanie sygnaturą czasową wiadomości w Edge for Private Cloud
Domyślnie sygnatura czasowa we wszystkich komunikatach logowania ma format:
yyyy-MM-dd'T'HH:mm:ss.SSSZ
Ta domyślna wartość systemowa może zostać zastąpiona w przypadku miejsc docelowych syslog za pomocą elementu DateFormat
. Sposób działania tego szablonu jest opisany w dokumentacji klasy SimpleDateFormat w języku Java. Zgodnie z tą definicją yyyy
zostanie zastąpione 4-cyfrowym rokiem, MM
– 2-cyfrowym numerem miesiąca itd.
Powyższy format może spowodować powstanie ciągu znaków w tym formacie:
2022-09-28T22:38:11.721+0000
Aby kontrolować ten format, możesz użyć właściwości conf_system_apigee.syslogger.dateFormat w procesorze wiadomości Edge. Na przykład zmiana formatu wiadomości na:
yy/MM/dd'T'HH:mm:ss.SSSZ
..zastąpienie myślników ukośnikami i skrócenie roku do 2 cyfr, rejestruje sygnaturę czasową w formacie:
22/09/28T22:38:11.721+0000
Aby zmienić format:
- Otwórz plik message-processor.properties w edytorze. Jeśli plik nie istnieje, utwórz go:
> vi /opt/apigee/customer/application/message-processor.properties - Ustaw właściwości zgodnie z potrzebami:
conf_system_apigee.syslogger.dateFormat=yy/MM/dd'T'HH:mm:ss.SSSZ - Zapisz zmiany.
- Upewnij się, że właścicielem pliku właściwości jest użytkownik „apigee”:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Uruchom ponownie Edge Message Processor:
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Lokalizacja pliku z logami w Edge for Private Cloud
Edge for Private Cloud w wersji 4.16.01 lub nowszej
Domyślnie logi wiadomości z chmury prywatnej znajdują się w tym katalogu na węzłach procesora wiadomości:
/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 pliku message-logging.properties w usługach przetwarzających wiadomości:
- bin_setenv_data_dir –
ustawia ścieżkę katalogu głównego do przechowywania plików dziennika. Na przykład:
bin_setenv_data_dir=/opt/apigee/var/log
- conf_message-logging_log.root.dir – jeśli ustawisz ś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.
, a jeśli ustawisz ścieżkę bezwzględną, np.conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages
, dzienniki wiadomości będą przechowywane w/opt/apigee/var/log/messages/messagelog/
. Ścieżka bezwzględna ma pierwszeństwo przedbin_setenv_data_dir
.
Pamiętaj, że musisz odwołać się do właściwości jako conf/message-logging.properties+log.root.dir, ponieważ domyślnie jest ona skomentowana. Więcej informacji znajdziesz w sekcji Ustawianie tokena, który jest obecnie skomentowany.
Jeśli chcesz przechowywać pliki dziennika w strukturze plików prostych, aby wszystkie pliki dziennika były umieszczane w tym samym katalogu, ustaw wartość conf/message-logging.properties+enable.flat.directory.structure na true w pliku message-logging.properties. Wiadomości są przechowywane w katalogu określonym przez te 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:
- Otwórz plik message-processor.properties w edytorze. Jeśli plik nie istnieje, utwórz go:
> vi /opt/apigee/customer/application/message-processor.properties - Ustaw odpowiednie właściwości:
conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages - Zapisz zmiany.
- Upewnij się, że właścicielem pliku właściwości jest użytkownik „apigee”:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Ponownie uruchom komponent Edge:
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Edge for Private Cloud w wersji 4.15.07 i starszych
Domyślnie dzienniki wiadomości znajdują się w tych procesorach wiadomości:
/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 pliku message-logging.properties w procesorach wiadomości:
- data.dir – określa ścieżkę do katalogu głównego, w którym są przechowywane pliki dziennika. Na przykład data.dir=/opt/apigee4/var/log.
- log.root.dir – jeśli ustawisz tę opcję jako ścieżkę względną, np. log.root.dir=custom/folder/, ścieżka zostanie dołączona do lokalizacji data.dir.
Na przykład połączenie tych 2 usług spowoduje ustawienie katalogu rejestrowania na poziomie /opt/apigee4/var/log/custom/folder/messagelog/ (uwaga: parametr /messagelog jest dodawany automatycznie).
Jeśli ustawisz ścieżkę bezwzględną, np. log.root.dir=/opt/apigee4/var/log/messages, dzienniki wiadomości będą przechowywane w katalogu /opt/apigee4/var/log/messages/messagelog/. Ścieżka bezwzględna w log.root.dir ma pierwszeństwo przed ścieżką data.dir.
Jeśli chcesz przechowywać pliki dziennika w strukturze plików prostych, aby wszystkie pliki dziennika były umieszczane w tym samym katalogu, ustaw właściwość enable.flat.directory.structure na wartość true w pliku message-logging.properties na procesorach wiadomości. Komunikaty są przechowywane w katalogu określonym przez te właściwości, a nazwy plików mają postać {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}.
Domyślne wartości zmiennych w szablonie wiadomości
Wartości domyślne można określić oddzielnie dla każdej zmiennej w szablonie wiadomości. Jeśli na przykład nie uda się rozwiązać zmiennej request.header.id
, jej wartość zostanie zastąpiona wartością unknown
.
<Message>This is a test message. id = {request.header.id:unknown}</Message>
Wspólna wartość domyślna może być określana dla wszystkich nierozwiązanych zmiennych przez ustawienie atrybutu defaultVariableValue
w elemencie Message
:
<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>
Konfigurowanie zewnętrznych usług zarządzania logami
Polityka MessageLogging umożliwia wysyłanie wiadomości syslog do zewnętrznych usług zarządzania logami, takich jak Splunk, Sumo Logic i Loggly. Jeśli chcesz wysyłać syslog do jednej z tych usług, zapoznaj się z dokumentacją tej usługi, aby skonfigurować hosta, port i protokół tej usługi, a następnie odpowiednio skonfiguruj element Syslog w tej polityce.
Aby dowiedzieć się więcej o konfiguracji zarządzania logami w usłudze innej firmy, zapoznaj się z tą dokumentacją:
- Splunk (wybierz wersję usługi)
Zobacz też ten post na forum społeczności Apigee: https://community.apigee.com/content/kbentry/13298/log-messages-into-splunk.html -
Sumo
Logic
- Zapoznaj się też z tym wpisem w społeczności 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 rejestrowania logów znajdziesz w tym poście na forum społeczności Apigee. Rozwiązanie korzysta z pojedynczej reguły JavaScript do wysyłania żądań HTTP POST do źródła danych Sumo Logic HTTP Collector: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
- Loggly
Jeśli używasz Loggly, w zasadach musisz umieścić element<FormatMessage>true</FormatMessage>
jako element podrzędny elementu<Syslog>
.
Aby dowiedzieć się więcej o rejestrowaniu wiadomości w Loggly, przeczytaj ten post na forum społeczności Apigee: https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html
Odniesienie do błędu
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.
Kod błędu | Stan HTTP | Przyczyna |
---|---|---|
steps.messagelogging.StepDefinitionExecutionFailed |
500 | Zobacz ciąg błędu. |
Błędy wdrażania
Te błędy mogą wystąpić podczas wdrażania serwera proxy zawierającego tę zasadę.
Nazwa błędu | Przyczyna | Napraw |
---|---|---|
InvalidProtocol |
Wdrożenie zasady MessageLogging może się nie udać z tym błędem, jeśli protokół
określona w elemencie <Protocol> jest nieprawidłowa. Prawidłowe protokoły to TCP i UDP.
W przypadku wysyłania komunikatów syslog przez TLS/SSL obsługiwany jest tylko protokół TCP. |
build |
InvalidPort |
Wdrożenie zasady MessageLogging może się nie udać z tym błędem, jeśli numer portu
nie jest określony w elemencie <Port> lub jest nieprawidłowy. Numer portu musi być
liczbą całkowitą większą od zera. |
build |
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.
Zmienne | Gdzie | Przykład |
---|---|---|
fault.name="fault_name" |
fault_name to nazwa błędu podana w tabeli Błędy czasu działania powyżej. Nazwa błędu to ostatnia część kodu błędu. | fault.name Matches "StepDefinitionExecutionFailed" |
messagelogging.policy_name.failed |
policy_name to określona przez użytkownika nazwa zasady, która spowodowała błąd. | messagelogging.ML-LogMessages.failed = true |
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
Po wystąpieniu błędu w zasadach są wypełniane te zmienne:
messagelogging.failed
messagelogging.{stepdefinition-name}.failed
Powiązane artykuły
- Zmienne udostępnione przez Edge: odwołania do zmiennych