<ph type="x-smartling-placeholder"></ph>
Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur
Apigee X-Dokumentation. Weitere Informationen
Was
Eine der besten Möglichkeiten, Probleme in der API-Laufzeitumgebung zu ermitteln, besteht darin, Nachrichten zu protokollieren. Sie können eine MessageLogging-Richtlinie an Ihre API anhängen und diese konfigurieren, um benutzerdefinierte Nachrichten an eine auf einem lokalen Laufwerk (nur Edge für Private Cloud) oder in syslog.
<ph type="x-smartling-placeholder">Beispiele
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>
Die Art des Benachrichtigungstyps wird häufig in einem Syslog-Konto protokolliert. Wann? für Syslog konfiguriert, leitet ein API-Proxy Log-Nachrichten von Apigee Edge an eine Remote- Syslog-Server. Der Syslog-Server muss bereits vorhanden sein. Ist dies nicht der Fall, sind öffentliche Log-Verwaltungsdienste wie Splunk, Sumo Logic und Loggly verfügbar. Weitere Informationen finden Sie unter Dienste von Drittanbietern für die Logverwaltung konfigurieren.
Beispiel: Sie möchten Informationen zu jeder Anfragenachricht protokollieren, die Ihre API von Nutzeranwendungen empfängt. Der Wert 3f509b58
stellt einen Schlüsselwert dar, der für den Loggly-Dienst spezifisch ist. Wenn Sie ein Loggly-Konto haben, ersetzen Sie Ihren Loggly-Schlüssel. Die generierte Lognachricht enthält vier Werte: die Organisation, den API-Proxy und den Umgebungsnamen der Transaktion sowie den Wert für einen Abfrageparameter in der Anfragenachricht.
Wenn Sie eine Edge für Private Cloud-Bereitstellung haben, können Sie auch Log-Nachrichten in eine -Datei.
Syslog über 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>
Mit dem Block <SSLInfo>
können Sie Nachrichten über Drittanbieter-Logging für Nachrichten über TLS/SSL senden.
Dateirotation: Größe
<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>
Dateirotation basierend auf der Dateigröße.
Dateirotation: Zeit
<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>
Dateirotation basierend auf der Zeit.
Dateirotation: Zeit und Größe
<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>
Dateirotation basierend auf Zeit und Größe.
Für den Stream aktiviert
<MessageLogging name="LogPolicy"> <File> .... .... </File> <BufferMessage>true</BufferMessage> </MessageLogging>
Nachrichtenprotokollierung mit Stream
Elementverweis
Verwenden Sie die folgenden Elemente, um den Richtlinientyp „MessageLogging“ zu konfigurieren.
Feldname | Feldbeschreibung | |
---|---|---|
Lokales Dateiziel. (Datei-Logging wird nur in Edge für Private Cloud unterstützt deployments.) Informationen zum Speicherort der Dateien finden Sie unter Protokolldatei. Speicherort in Edge für Private Cloud. |
Message |
Erstellen Sie die Nachricht, die an die Protokolldatei gesendet werden soll, indem Sie mit Variablen, um die gewünschten Informationen zu erfassen. Beispiele |
FileName |
Name der Protokolldatei, in der die Nachricht protokolliert wird. | |
FileRotationOptions |
||
rotateFileOnStartup |
Attribut. Gültige Werte: Bei Einstellung auf "true" wird die Protokolldatei jedes Mal rotiert, wenn die Nachrichten-Engine neu gestartet. |
|
FileRotationType |
Gibt die Rotationsrichtlinie an (size oder
time ) einer Protokolldatei. |
|
MaxFileSizeInMB |
(Bei Auswahl von size als Rotationstyp)
Gibt die Größe einer Protokolldatei an, die den Server das Verschieben von Protokollnachrichten in eine
in einer separaten Datei. Nachdem die Protokolldatei die angegebene Größe erreicht hat, benennt der Server die
aktuelle Protokolldatei. |
|
RotationFrequency |
(Bei Auswahl von time als Rotationstyp)
Gibt die Zeit in Minuten an, die den Server veranlasst, Protokollnachrichten in einen separaten
-Datei. Nach Ablauf des angegebenen Intervalls wird die aktuelle Protokolldatei umbenannt. |
|
MaxFilesToRetain |
Gibt die maximale Anzahl von Dateien an, die im Kontext der Rotation aufbewahrt werden sollen Einstellungen. Der Standardwert ist 8. Wenn Sie Null (0) angeben, werden die Protokolldateien auf unbestimmte Zeit aufbewahrt, unterliegen jedoch Ihrer Datei Rotationseinstellungen, wobei jedoch keine der Dateien gelöscht oder umbenannt wird. Daher sollten Sie auf einen Wert größer null setzen oder eine reguläre automatisiertes System zum dauerhaften Löschen oder Archivieren älterer aufbewahrter Protokolldateien. |
|
BufferMessage |
Wenn HTTP-Streaming aktiviert ist, werden Anfrage-/Antwortnachrichten nicht gepuffert. Wenn Sie Protokollinhalt, für den die Flussnachricht geparst werden muss, und setzen Sie BufferMessage auf "true". Unter „Stream-fähig“ findest du Beispiel-Tab. Standardwert: false |
|
Ein Syslog-Ziel. So senden Sie Syslog an Splunk, Sumo Logic oder Loggly: Siehe Drittanbieter-Logverwaltungsdienste konfigurieren. |
Message |
Erstellen Sie die Nachricht, die an den Syslog gesendet werden soll. Kombinieren Sie Text mit Variablen, um die gewünschten Informationen zu erfassen. Beispiele Hinweis: Antwortvariablen sind nach einem Fehlerfluss nicht in PostClientFlow verfügbar. Verwenden Sie Nachrichtenvariablen, um Antwortinformationen sowohl für Fehler- als auch für Erfolgsszenarien zu protokollieren. Siehe auch Nutzungshinweise. |
Host |
Der Hostname oder die IP-Adresse des Servers, an den der Syslog gesendet werden soll. Wenn Sie dieses Element nicht angeben, wird "localhost" als Standard verwendet. | |
Port |
Port, an dem der Syslog ausgeführt wird. Wenn Sie dieses Element nicht angeben, ist der Standardwert 514. | |
Protocol |
TCP oder UDP (Standardeinstellung). UDP ist leistungsfähiger, aber das TCP-Protokoll garantiert die Zustellung von Nachrichtenlogs an den Syslog-Server. Zum Senden von Syslog-Nachrichten über TLS/SSL wird nur TCP unterstützt. | |
FormatMessage |
Optional, für die Verwendung mit Loggly ist jedoch Mit diesem Element können Sie das Format von Apigee-generierten Inhalten steuern, die der Nachricht vorangestellt werden. Ist die Richtlinie auf "true" gesetzt, wird der Syslog-Nachricht eine feste Anzahl von Zeichen vorangestellt, sodass Sie diese Informationen aus den Nachrichten herausfiltern können. Hier ist ein Beispiel für das feste Format:
Die von Apigee generierten Informationen umfassen:
Bei Einstellung auf "false" (Standardwert) werden der Nachricht diese festgelegten Zeichen nicht vorangestellt. |
|
PayloadOnly |
Mit diesem Element wird das Format von Apigee generierten Nachrichten so festgelegt, dass sie nur den Text der Syslog-Nachricht enthalten, ohne die von FormatMessage angegebenen vorangestellten Zeichen. Wenn Sie dieses Element nicht einfügen oder leer lassen, wird der Standardwert Siehe FormatMessage. |
|
DateFormat |
Optional. Ein String für eine Formatierungsvorlage, die zum Formatieren des Zeitstempels für jede Lognachricht verwendet wird.
Standardmäßig verwendet Apigee |
|
SSLInfo |
Ermöglicht die Protokollierung von Nachrichten über SSL/TLS. Wird mit dem Unterelement Wenn Sie dieses Element nicht angeben oder es leer lassen, ist der Standardwert "false" (kein TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> Sie können das <SSL-Info>-Tag genauso konfigurieren wie auf einem TargetEndpoint, einschließlich der Aktivierung von bidirektionalem TLS/SSL, wie in der API-Proxy-Konfigurationsreferenz beschrieben. Es wird nur das TCP-Protokoll unterstützt. |
|
logLevel |
Optional: Gültige Werte: Sie können eine bestimmte Informationsmenge festlegen, die im Nachrichtenprotokoll enthalten sein soll. Wenn Sie das Element |
Schemas
Nutzungshinweise
Wenn Sie eine MessageLogging-Richtlinie an einen API-Proxy-Flow anhängen, sollten Sie diesen in die ProxyEndpoint-Antwort in einem speziellen Ablauf namens PostClientFlow einfügen. Der PostClientFlow wird ausgeführt, nachdem die Antwort an den anfordernden Client gesendet wurde. Dadurch wird sichergestellt, dass alle Messwerte für Logging verfügbar sind. Weitere Informationen zur Verwendung von PostClientFlow finden Sie in der API-Proxy-Konfigurationsreferenz.
Der PostClientFlow hat zwei Möglichkeiten:
- Es wird nur als Teil des Antwortflusses ausgeführt.
- Es ist der einzige Fluss, der ausgeführt wird, wenn der Proxy den Fehlerstatus erreicht.
Da sie unabhängig davon ausgeführt wird, ob der Proxy erfolgreich war oder fehlgeschlagen ist, können Sie MessageLogging-Richtlinien in den PostClientFlow einfügen und so dafür sorgen, dass sie immer ausgeführt werden.
Das folgende Trace-Image zeigt eine MessageLogging-Richtlinie, die als Teil des PostClientFlow ausgeführt wird, nachdem die DefaultFaultRule ausgeführt wurde:
In diesem Beispiel hat die Richtlinie "API-Schlüssel überprüfen" den Fehler aufgrund eines ungültigen Schlüssels verursacht.
Im Folgenden sehen Sie die ProxyEndpoint-Definition mit PostClientFlow:
<ProxyEndpoint name="default"> ... <PostClientFlow> <Response> <Step> <Name>Message-Logging-1</Name> </Step> </Response> </PostClientFlow> ... </ProxyEndpoint>
Edge protokolliert Meldungen als einfachen Text und Sie können das Logging so konfigurieren, dass Variablen enthalten sind, z. B. Datum und Uhrzeit des Eingangs der Anfrage oder Antwort, die Nutzeridentität in der Anfrage die Quell-IP-Adresse, von der die Anfrage gesendet wurde, usw. Nachricht mit Edge-Protokollen asynchron, sodass keine durch das Blockieren von Callouts verursachte Latenz eintritt. zu Ihrer API hinzufügen.
Die MessageLogging-Richtlinie schreibt protokollierte Nachrichten im Speicher in einen Zwischenspeicher. Der Nachrichten-Logger liest Nachrichten aus dem Zwischenspeicher und schreibt sie in das von Ihnen konfigurierte Ziel. Jedes Ziel hat einen eigenen Zwischenspeicher.
Wenn die Schreibrate für den Zwischenspeicher über die Leserate hinausgeht, schlagen das Pufferüberlauf und das Logging fehl. In diesem Fall kann die Logdatei eine Meldung mit folgendem Inhalt enthalten:
Log message size exceeded. Increase the max message size setting
Wenn dieses Problem in Edge for Private Cloud 4.15.07 und früher auftritt, suchen Sie nach dem
message-logging.properties
-Datei und verwenden Sie diese Lösung:
Erhöhen Sie das Attribut max.log.message.size.in.kb
(Standardwert = 128 KB) in der Datei message-logging.properties
.
Legen Sie für Edge for Private Cloud 4.16.01 und höher das Attribut conf/message-logging.properties+max.
log.message.size.in.kb
in der Datei /opt/apigee/customer/application/message-processor.properties fest und starten Sie den Message Processor neu. Diese Eigenschaft ist anfänglich standardmäßig auskommentiert.
Hinweis: Die Antwortnachricht Variablen in Edge sind nicht im Fehlerfluss verfügbar. Diese Variablen sind auch nicht im PostClientFlow verfügbar, wenn der vorherige Ablauf der Fehlerfluss war. Wenn Sie Antwortinformationen aus dem PostClientFlow protokollieren möchten, verwenden Sie das message-Objekt. Mit diesem Objekt können Sie Header und andere Informationen aus der Antwort abrufen, unabhängig davon, ob ein Fehler aufgetreten ist oder nicht. Weitere Informationen und ein Beispiel finden Sie unter Nachrichtenvariablen.
Lognachricht steuern Zeitstempel in Edge für Private Cloud
Der Zeitstempel in allen Logeinträgen hat standardmäßig folgendes Format:
yyyy-MM-dd'T'HH:mm:ss.SSSZ
Dieser systemweite Standard kann für Syslog-Ziele überschrieben werden mithilfe der Methode
DateFormat
-Element. Das Verhalten dieser Vorlage wird in der
Dokumentation zur SimpleDateFormat-Klasse von Java. Gemäß dieser Definition wird yyyy
ersetzt
durch eine vierstellige Jahresnummer, MM
wird durch eine zweistellige Monatsnummer usw. ersetzt.
Das obige Format kann zu einem String der folgenden Form führen:
2022-09-28T22:38:11.721+0000
Sie können das conf_system_apigee.syslogger.dateFormat im Edge Message Processor, um dieses Format zu steuern. Wenn Sie z. B. die Mitteilung ändern, Format in:
yy/MM/dd'T'HH:mm:ss.SSSZ
...die Bindestriche durch Schrägstriche ersetzen und auf ein zweistelliges Jahr gekürzt werden, wird ein Zeitstempel in folgendem Format erfasst:
22/09/28T22:38:11.721+0000
So ändern Sie das Format:
- Öffnen Sie die Datei message-processor.properties in einem
Editor. Wenn die Datei nicht vorhanden ist, erstellen Sie sie:
> Vi /opt/apigee/customer/application/message-processor.properties - Legen Sie die Eigenschaften wie gewünscht fest:
conf_system_apigee.syslogger.dateFormat=yy/MM/dd'T'HH:mm:ss.SSSZ - Speichern Sie die Änderungen.
- Achten Sie darauf, dass die Eigenschaftendatei dem Apigee gehört Nutzer:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Starten Sie den Edge Message Processor neu:
> /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor neustart
Speicherort der Logdatei in Edge für die Private Cloud
Edge für Private Cloud 4.16.01 und höher
Standardmäßig befinden sich die Nachrichtenlogs der privaten Cloud im folgenden Verzeichnis in Message Prozessorknoten:
/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/
Sie können den Standardspeicherort für das Protokoll ändern, indem Sie Attribute in der message-logging.properties in den Message Processors:
- bin_setenv_data_dir –
Legt den Stammpfad für den Logdateispeicher fest. Beispiel:
bin_setenv_data_dir=/opt/apigee/var/log
- conf_message-logging_log.root.dir – wenn
legen Sie dafür einen relativen Pfad fest, z. B.
conf/message-logging.properties+log.root.dir=custom/folder/
, the path is appended to the bin_setenv_data_dir location.
Wenn Sie dafür einen absoluten Pfad wieconf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages
, Nachricht Protokolle werden in/opt/apigee/var/log/messages/messagelog/
gespeichert. Ein absoluter Pfad hat Vorrang vorbin_setenv_data_dir
.
Beachten Sie, dass Sie auf die Eigenschaft als conf/message-logging.properties+log.root.dir verweisen müssen, weil standardmäßig auskommentiert. Weitere Informationen finden Sie unter Festlegen eines Token, das derzeit auskommentiert ist, um weitere Informationen zu erhalten.
Wenn Sie Protokolldateien in einer flachen Dateistruktur speichern möchten, sodass alle Protokolldateien im Ordner
im selben Verzeichnis den Wert conf/message-logging.properties+enable.flat.directory.structure
true in der Datei „message-logging.properties“ fest. Nachrichten werden in dem Verzeichnis gespeichert, das durch
und die Dateinamen haben folgendes Format:
{org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}
So legen Sie diese Eigenschaften fest:
- Öffnen Sie die Datei message-processor.properties in einem
Editor. Wenn die Datei nicht vorhanden ist, erstellen Sie sie:
> Vi /opt/apigee/customer/application/message-processor.properties - Legen Sie die Eigenschaften wie gewünscht fest:
conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages - Speichern Sie die Änderungen.
- Achten Sie darauf, dass die Eigenschaftendatei dem Apigee gehört Nutzer:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Starten Sie die Edge-Komponente neu:
> /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor neustart
Edge für Private Cloud 4.15.07 und frühere Versionen
Standardmäßig befinden sich die Meldungsprotokolle an folgendem Speicherort in der Nachricht: Prozessoren:
/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/
Sie können den Standardspeicherort für Protokolle ändern, indem Sie die folgenden Eigenschaften in der message-logging.properties in den Nachrichtenprozessoren an:
- data.dir – Legt das Stammverzeichnis fest Pfad für den Logdateispeicher. Zum Beispiel: data.dir=/opt/apigee4/var/log
- log.root.dir – wenn Sie in einen relativen Pfad angeben, wie z. B. log.root.dir=custom/folder/, wird der Pfad an den data.dir-Speicherort.
Durch die Kombination der beiden Attribute würde beispielsweise das Logging-Verzeichnis auf /opt/apigee4/var/log/custom/folder/messagelog/ (beachten Sie, dass /messagelog hinzugefügt wird) automatisch).
Wenn Sie dies auf einen absoluten Pfad festlegen, wie z. B. log.root.dir=/opt/apigee4/var/log/messages, Meldungsprotokolle werden in /opt/apigee4/var/log/messages/messagelog/ gespeichert. Ein absoluter Pfad in log.root.dir hat Vorrang vor data.dir.
Wenn Sie Protokolldateien in einer flachen Dateistruktur speichern möchten, sodass alle Protokolldateien im Ordner im selben Verzeichnis, setzen Sie das Attribut "enable.flat.directory.structure" auf "true" in der Datei message-logging.properties in Message Prozessoren. Nachrichten werden in dem Verzeichnis gespeichert, das durch die oben angegebenen Eigenschaften festgelegt wurde, und in der Datei Namen haben das Format {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}.
Standardwerte für Variablen in Nachrichtenvorlagen
Standardwerte können für jede Variable in der Nachrichtenvorlage separat angegeben werden. Wenn beispielsweise die Variable request.header.id
nicht aufgelöst werden kann, wird der Wert durch den Wert unknown
ersetzt.
<Message>This is a test message. id = {request.header.id:unknown}</Message>
Für alle nicht aufgelösten Variablen kann ein gemeinsamer Standardwert angegeben werden. Dazu legen Sie das Attribut defaultVariableValue
für das Element Message
fest:
<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>
Dienste für die Logverwaltung von Drittanbietern konfigurieren
Mit der MessageLogging-Richtlinie können Sie Syslog-Nachrichten an Dienste von Drittanbietern für die Logverwaltung wie Splunk, Sumo Logic und Loggly senden. Wenn Sie Syslog an einen dieser Dienste senden möchten, lesen Sie in der Dokumentation dieses Dienstes nach, wie Sie den Host, den Port und das Protokoll des Dienstes konfigurieren. Legen Sie dann das Syslog-Element für diese Richtlinie entsprechend fest.
Weitere Informationen finden Sie in der folgenden Dokumentation zum Konfigurieren der Konfiguration von Drittanbieter-Logs:
- Splunk (Produktversion auswählen)
Siehe auch diesen Apigee-Community-Beitrag: https://community.apigee.com/content/kbentry/13298/log-messages-into-splunk.html -
Sumo
Logic
- Außerdem können Sie sich auch folgenden Beitrag zur Apigee-Community ansehen: https://community.apigee.com/questions/5226/setting-up-logging-with-sumo-logic-which-host-shou.html
- Ein vollständiges Beispiel für die Verwendung von Sumo Logic als Logging-Dienst finden Sie im folgenden Beitrag zur Apigee-Community. Die Lösung verwendet eine einzige JavaScript-Richtlinie, um HTTP POST-Anfragen an Sumo Logic HTTP Source Collector zu senden: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
- Loggly
Bei der Verwendung von Loggly ist<FormatMessage>true</FormatMessage>
in der Richtlinie als untergeordnetes Element des<Syslog>
-Elements erforderlich.
Weitere Informationen zum Logging von Nachrichten finden Sie in diesem Beitrag der Apigee-Community unter https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html
Fehlerreferenz
Dieser Abschnitt beschreibt die Fehlercodes und Fehlermeldungen, die zurückgegeben werden, und die Fehlervariablen, die von Edge festgelegt werden, wenn diese Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.
Laufzeitfehler
Diese Fehler können bei Ausführung der Richtlinie auftreten.
Fehlercode | HTTP-Status | Ursache |
---|---|---|
steps.messagelogging.StepDefinitionExecutionFailed |
500 | Siehe Fehlerstring. |
Bereitstellungsfehler
Diese Fehler können auftreten, wenn Sie einen Proxy bereitstellen, der diese Richtlinie enthält.
Fehlername | Ursache | Beheben |
---|---|---|
InvalidProtocol |
Die Bereitstellung der <Protocol> MessageLogging-Richtlinie kann mit diesem Fehler fehlschlagen, wenn das im -Element angegebene Protokoll nicht gültig ist. Gültige Protokolle sind TCP und UDP.
Zum Senden von Syslog-Nachrichten über TLS/SSL wird nur TCP unterstützt. |
build |
InvalidPort |
Die Bereitstellung der MessageLogging-Richtlinie kann mit diesem Fehler fehlschlagen, wenn die Portnummer nicht im Element <Port> angegeben oder ungültig ist. Die Portnummer muss eine Ganzzahl größer als null sein. |
build |
Fehlervariablen
Diese Variablen werden bei Laufzeitfehlern festgelegt. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen.
Variablen | Wo | Beispiel |
---|---|---|
fault.name="fault_name" |
fault_name ist der Name des Fehlers, der in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes. | fault.name Matches "StepDefinitionExecutionFailed" |
messagelogging.policy_name.failed |
policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgelöst hat. | messagelogging.ML-LogMessages.failed = true |
Beispiel für eine Fehlerantwort
{ "fault":{ "detail":{ "errorcode":"steps.messagelogging.StepDefinitionExecutionFailed" }, "faultstring":"Execution failed" } }
Beispiel für eine Fehlerregel
<FaultRule name="MessageLogging"> <Step> <Name>ML-LogMessages</Name> <Condition>(fault.name Matches "StepDefinitionExecutionFailed") </Condition> </Step> <Condition>(messagelogging.ML-LogMessages.failed = true) </Condition> </FaultRule>
Ablaufvariablen
Die folgenden Variablen werden bei einem Richtlinienfehler ausgefüllt.
messagelogging.failed
messagelogging.{stepdefinition-name}.failed
Weitere Informationen
- Von Edge sichtbare Variablen: Variablenreferenz