Protokollierung und Korrelation in der Nachrichtenvermittlung

Warum ist die Nachrichtenprotokollierung wichtig?

Bei der Entwicklung von Unternehmensanwendungen ist die Protokollierung eine wesentliche Praxis, um Sicherheitsbedrohungen, Fehler und Nutzungsmuster der Systeme zu identifizieren. Wenn es um die Nachrichtenprotokollierung geht, die für die Integration und Nachrichtenvermittlung relevant ist, ist es entscheidend, Probleme sowohl bei eingehenden als auch ausgehenden Vermittlungsvorgängen zu debuggen, einschließlich des Verhaltens externer Endpunktaufrufe in der Dienstorchestrierung.

WSO2 log mediator

Der WSO2-Protokollvermittler wird verwendet, um Nachrichten im Vermittlungsablauf zu protokollieren. Er unterstützt verschiedene Protokollebenen und Kategorien. Der Protokollvermittler ist bedingt inhaltsbewusst, was bedeutet, dass das Erstellen der Nachricht durch den Protokollvermittler im Vermittlungsablauf von der ausgewählten Protokollebene abhängt.

Syntax:
<log [level=“string“] [separator=“string“]> <property name=“string“ (value=“literal“ | expression=“[XPath|json-eval(JSON Path)]“)/>* </log>

Was sind die verschiedenen Protokollebenen von Log Mediator?

Was sind die verschiedenen Protokoll-Kategorien von Vermittler protokollieren?

• Vollständig: Wenn diese Option ausgewählt ist, werden alle auf der einfachen Ebene protokollierten Standardheader sowie die vollständige Nutzlast der Nachricht protokolliert. Diese Protokollebene bewirkt, dass der Nachrichteninhalt analysiert wird, und führt daher zu einem Performance-Overhead.
• Einfach: Wenn dies ausgewählt ist, werden die Standardheader (d.h. To, From, WSAction, SOAPAction, ReplyTo und MessageID) protokolliert.
• Header: Wenn diese Option ausgewählt ist, werden alle SOAP-Header-Blöcke protokolliert.
• Benutzerdefiniert: Wenn diese Option ausgewählt ist, werden nur die Eigenschaften protokolliert, die der Log Mediator-Konfiguration hinzugefügt wurden.

Wichtige Punkte, die bei der Nachrichtenprotokollierung zu beachten sind

• Nachrichtenkorrelations-ID

Die Nachrichtenkorrelations-ID ist eine eindeutige ID, die der eingehenden HTTP-Abfrage zugewiesen wird. Dieselbe ID wird bei allen Ein- und Ausgängen einer bestimmten Anforderung im Vermittlungsablauf beibehalten. Alle Protokolleinträge können auf die Korrelations-ID verweisen, um den Roundtrip der HTTP-Anforderung eindeutig zu identifizieren. Es wäre hilfreich, das Verhalten des Nachrichtenflusses zu analysieren und die Nachrichtenvermittlung zu debuggen.

Hinweis:
Wenn eine HTTP-Anforderung vom Gateway-Knoten der Connext-Plattform empfangen wird, wird eine Korrelations-ID generiert und auf den HTTP-Header „correlationId“ gesetzt, bevor sie an das Backend gesendet wird.

• Protokollierung minimieren

Wir versuchen immer, die Meldungsprotokollierung zu minimieren, da sie sich direkt auf die Leistung des Systems auswirkt. Das Schreiben von Protokollen in eine Datei ist eine E/A-Operation und beansprucht beträchtliche Ressourcen des Systems. Daher wird empfohlen, Protokolle auf ein Minimum zu beschränken, indem nur notwendige Informationen protokolliert und unnötige Informationen vermieden werden.

Hinweis:
Der ELK-Stack wurde bereits mit der Connext-Plattform für Überwachungs- und Protokollierungszwecke eingerichtet. Connext 2.3 hat die maximale Anzahl von Zeichen pro INFO- und DEBUG-Protokollzeile im Dienstprotokoll definiert.

INFOLOGS- 1024 Zeichen

appender.INFOLOGS.layout.pattern = [CNXT2][%d] %5p %.-1024m {INFOLOGS}%n

DEBUGLOGS- 1048576 Zeichen

appender.DEBUGLOGS.layout.pattern = [CNXT2][%d] %5p %.-1048576m {DEBUGLOGS}%n

Diese Begrenzung soll sicherstellen, dass das ELK-System mit der vorhandenen Ressourcenzuordnung reibungslos läuft und die E/A-Kosten des Integrationssystems minimieren.

• Reihenfolge der Protokollebene

Das Herzstück der WSO2-Protokollierung basiert auf Log4j2, und der gleiche Bestellmechanismus ist anwendbar.

DEBUG < INFO < WARN < ERROR < FATAL < OFF

Beispiel: Wenn INFO-Protokolle in der Datei log4j2.properties aktiviert sind, werden alle Protokollebenen mit Ausnahme der DEBUG-Ebene protokolliert.

• Protokollierungsvorlagen

Um die Redundanz zu minimieren, ist es möglich, eine Sequenzvorlage als gemeinsame Protokollierungsvorlage zu definieren, die durch Übergabe der relevanten Parameterwertenwiederverwendet werden kann. Das Sequenz-Template kann aus dem „Call Template“ mit folgender Syntax aufgerufen werden:

Syntax: Sequenzvorlage

<?xml version=“1.0″ encoding=“UTF-8″?> <template name=“string“> <!– parameters this sequence template will be supporting –> ( <parameter name=“string“ /> ) * <!–this is the in-line sequence of the template –> <sequence>mediator+</sequence> </template>

Syntax: Vorlage aufrufen

<?xml version=“1.0″ encoding=“UTF-8″?> <call-template target=“string“> <!– parameter values will be passed on to a sequence template –> ( <!–passing plain static values –> <with-param name=“string“ value=“string“ /> | <!–passing xpath expressions –> <with-param name=“string“ value=“{string}“ /> | <!–passing dynamic xpath expressions where values will be compiled dynamically–> <with-param name=“string“ value=“{{string}}“ /> | ) * <!–this is the in-line sequence of the template –> </call-template>

• Nutzlastprotokollierung minimieren

In einigen Situationen kann es erforderlich sein, die Nutzdaten zu Debugging-Zwecken zu protokollieren. Es wird jedoch nicht empfohlen, die Nutzlast auf einer anderen Ebene als DEBUG zu protokollieren. Ein Grund dafür ist die Leistungsbeeinträchtigung von E/A-Vorgängen für die Protokollierung. Ein weiterer Grund ist, dass die Nutzdaten in einem Produktionssystem möglicherweise vertrauliche Informationen enthalten und es keine bewährte Methode ist, die Nutzdaten zu protokollieren.

Beim Debuggen besteht der Hauptgrund für das Protokollieren der Nutzdaten darin, Probleme mit den darin enthaltenen Daten zu identifizieren. Anstatt die Nutzdaten zu protokollieren, können wir jedoch Validierungsschritte verwenden, um die Daten auf verschiedenen Vermittlungsebenen zu überprüfen. Dieser Ansatz kann dazu beitragen, den Umfang der Nutzdatenprotokollierung zu minimieren und das Risiko zu verringern, dass vertrauliche Informationen offengelegt werden.

1. HTTP-Anforderungsvalidierung
2. Validierung nach Nutzdatenerweiterung oder -Transformation (z. B. mit Enriching Mediator, XSLT Mediator usw.)
3. Validierung In-/Out-of-Service-Orchestrierung
4. Validierung der HTTP-Antwort

WSO2 hat den Validator Mediator eingeführt, der XML- oder JSON-Nutzdaten anhand vordefinierter Validierungsschemata validieren kann.

Syntax:

<validate [source=“xpath“]> <property name=“validation-feature-id“ value=“true|false“/>* <schema key=“string“/>+ <on-fail> mediator+ </on-fail> </validate>

Das folgende Diagramm veranschaulicht die verschiedenen Ebenen der Nutzdatenvalidierung im Vermittlungsablauf.

Integrationsbeispiel zum Validieren der Nutzdaten im Vermittlungsablauf

Schritt 1:
Erstellen Sie eine API-Definition im Publisher, indem Sie die folgende API-Definition verwenden.

openapi: 3.0.1

info:

title: Logger_Test_Api

version: '1.0'

servers:

- url: /

security:

- default: []

paths:

/*:

get:

responses:

'200':

description: OK

security:

- default: []

x-auth-type: Application & Application User

x-throttling-tier: Unlimited

put:

responses:

'200':

description: OK

security:

- default: []

x-auth-type: Application & Application User

x-throttling-tier: Unlimited

post:

responses:

'200':

description: OK

security:

- default: []

x-auth-type: Application & Application User

x-throttling-tier: Unlimited

delete:

responses:

'200':

description: OK

security:

- default: []

x-auth-type: Application & Application User

x-throttling-tier: Unlimited

patch:

responses:

'200':

description: OK

security:

- default: []

x-auth-type: Application & Application User

x-throttling-tier: Unlimited

/employee:

post:

parameters: []

requestBody:

content:

application/xml:

schema:

type: object

required: false

responses:

'200':

description: ok

security:

- default: []

x-auth-type: None

components:

securitySchemes:

default:

type: oauth2

flows:

implicit:

authorizationUrl: 'https://test.com'

scopes: {}

x-wso2-auth-header: Authorization

x-throttling-tier: Unlimited

x-wso2-cors:

corsConfigurationEnabled: false

accessControlAllowOrigins:

- '*'

accessControlAllowCredentials: false

accessControlAllowHeaders:

- authorization

- Access-Control-Allow-Origin

- Content-Type

- SOAPAction

accessControlAllowMethods:

- GET

- PUT

- POST

- DELETE

- PATCH

- OPTIONS

x-wso2-production-endpoints:

urls:

- 'https://internal-esb.prod.yenlo.connext.com:8243/yenlo'

type: http

x-wso2-sandbox-endpoints:

urls:

- 'https://internal-esb.prod.yenlo.connext.com:8243/yenlo'

type: http

x-wso2-basePath: /logger_test/1.0

x-wso2-transports:

- http

- https

• Die vom Gateway verfügbar gemachte API-Ressource https://<Gatewayhost>/logger_test/1.0/employee
• Der Produktionsendpunkt ist eine in der WSO2 EI erstellte API

https://:8243/yenlo

Schritt 2:
Erstellen Sie die folgende API in WSO2 EI. Dies ist diejenige, auf die wir als Produktionsendpunkt der API hingewiesen haben, die im Gateway verfügbar gemacht wird.

<api xmlns="http://ws.apache.org/ns/synapse" name="Test_Api" context="/yenlo">

<resource methods="POST" uri-template="/employee">

<inSequence>

<call-template target="Logger_Template">

<with-param name="SequenceName" value="Test_Api"/>

<with-param name="Message" value="Request received by the API"/>

<with-param name="LogCategory" value="INFO"/>

</call-template>

<sequence key="gov:/MessageTransformationSequence"/>

<respond/>

</inSequence>

</resource>

</api>

Schritt 3:
Erstellen Sie die folgende Vermittlungssequenz und speichern Sie sie in der Registrierung.

<?xml version="1.0" encoding="UTF-8"?><sequence xmlns="http://ws.apache.org/ns/synapse">

<call-template target="Logger_Template">

<with-param name="SequenceName" value="MessageTransformationSequence"/>

<with-param name="Message" value="Started"/>

<with-param name="LogCategory" value="INFO"/>

</call-template>

<validate>

<schema key="gov:/schemas/RequestValidator.xsd"/>

<on-fail>

<call-template target="Logger_Template">

<with-param name="SequenceName" value="MessageTransformationSequence"/>

<with-param name="Message" value="Invalid request received"/>

<with-param name="LogCategory" value="ERROR"/>

</call-template>

<makefault version="soap12">

<code value="tns:Receiver" xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/>

<reason value="Invalid Request received!!!"/>

</makefault>

<property name="HTTP_SC" scope="axis2" value="400"/>

<respond/>

</on-fail>

</validate>

<property name="ContentType" scope="axis2" value="application/json"/>

<payloadFactory media-type="json">

<format>{ "employeeName": "$1", "company": "$2", "mobileNumber": "$3", "department": "engineering" }</format>

<args>

<arg evaluator="json" expression="$.employee.firstName" literal="false"/>

<arg evaluator="json" expression="$.employee.company" literal="false"/>

<arg evaluator="json" expression="$.employee.mobileNumber" literal="false"/>

</args>

</payloadFactory>

<property name="ContentType" scope="axis2" value="application/json"/>

<validate>

<schema key="gov:/schemas/TransformationValidator.json"/>

<on-fail>

<call-template target="Logger_Template">

<with-param name="SequenceName" value="MessageTransformationSequence"/>

<with-param name="Message" value="Failed to validate the payload after transformation"/>

<with-param name="LogCategory" value="ERROR"/>

</call-template>

<makefault version="soap12">

<code value="tns:Receiver" xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/>

<reason value="Failed in message transformation!!!"/>

</makefault>

<property name="HTTP_SC" scope="axis2" value="500"/>

<respond/>

</on-fail>

</validate>

<property name="messageType" scope="axis2" value="application/json"/>

<call-template target="Logger_Template">

<with-param name="SequenceName" value="MessageTransformationSequence"/>

<with-param name="Message" value="Cmpleted"/>

<with-param name="LogCategory" value="INFO"/>

</call-template>

<respond/>

</sequence>

Die Sequenzlogik führt die Validierung tatsächlich in zwei verschiedenen Stufen durch. Sobald die Anforderung empfangen wurde, validiert die erste Validierungsvermittlung die Anforderung anhand von RequestValidator.xsd. Die zweite Validierungsvermittlung führt die Nutzdatenvalidierung nach der Nachrichtentransformation mithilfe des Payload-Factory-Vermittlers anhand von „TransformationValidator.json“ durch.

Schritt 4:
Erstellen Sie die folgende Protokollierungsvorlage, um sie im Vermittlungsprotokollierungsablauf wiederzuverwenden.

<?xml version="1.0" encoding="UTF-8"?><template xmlns="http://ws.apache.org/ns/synapse" name="Logger_Template">

<parameter name="SequenceName"/>

<parameter name="Message"/>

<parameter name="LogCategory"/>

<sequence>

<switch source="$func:LogCategory" xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns2="http://org.apache.synapse/xsd">

<case regex="Error|ERROR|error">

<log category="ERROR" level="custom">

<property expression="$ctx:proxy.name" name="ServiceName"/>

<property expression="$func:SequenceName" name="SequenceName"/>

<property expression="$trp:correlationId" name="Correlation-Id"/>

<property expression="$ctx:ERROR_CODE" name="ERROR_CODE"/>

<property expression="$axis2:HTTP_SC" name="HTTP_CODE"/>

<property expression="$func:Message" name="Message"/>

<property expression="$ctx:ERROR_MESSAGE" name="ERROR_MESSAGE"/>

<property expression="$ctx:ERROR_DETAIL" name="ERROR_DETAIL"/>

<property expression="$ctx:ERROR_EXCEPTION" name="ERROR_EXCEPTION"/>

</log>

<log category="DEBUG" level="custom">

<property expression="$func:SequenceName" name="SequenceName"/>

<property expression="$trp:correlationId" name="Correlation-Id"/>

<property expression="$body" name="MessageBody"/>

</log>

</case>

<default>

<log level="custom">

<property expression="$func:SequenceName" name="SequenceName"/>

<property expression="$trp:correlationId" name="Correlation-Id"/>

<property expression="$axis2:HTTP_SC" name="HTTP_CODE"/>

<property expression="$func:Message" name="Message"/>

</log>

<log category="DEBUG" level="custom">

<property expression="$func:SequenceName" name="SequenceName"/>

<property expression="$trp:correlationId" name="Correlation-Id"/>

<property expression="$axis2:HTTP_SC" name="HTTP_CODE"/>

<property expression="$body" name="MessageBody"/>

</log>

</default>

</switch>

</sequence>

</template>

Hier sehen Sie, dass die Nutzdatenprotokollierung unter der Protokollebene DEBUG hinzugefügt wurde. Nur wenn Sie DEBUG-Protokolle für einen bestimmten Dienst aktiviert haben, können Sie Debug-Protokolle mit Nutzdatenprotokollierung erhalten.

Schritt 5:
Erstellen Sie die folgenden Validierungsschemata und speichern Sie sie in der Registrierung.

XML-Validierungsschema

<?xml version="1.0" encoding="utf-8"?>

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="employee">

<xs:complexType>

<xs:sequence>

<xs:element name="firstName" type="xs:string" />

<xs:element name="company" type="xs:string" />

<xs:element name="mobileNumber" type="xs:string" />

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Json-Validierungsschema

{

"$schema": "http://json-schema.org/draft-04/schema#",

"type": "object",

"properties": {

"employeeName": {

"type": "string"

},

"company": {

"type": "string"

},

"mobileNumber": {

"type": "string",

"minLength": 10,

"maxLength": 10

},

"department": {

"type": "string"

}

},

"required": [

"employeeName",

"company",

"mobileNumber",

"department"

]

}

Schritt 6:
Testen mit verschiedenen Anwendungsfällen.

• HTTP-Anforderung mit korrekten Nutzdaten

curl -X POST "https://api.prod.yenlo.connext.com/logger_test/1.0/employee" -H "accept: */*" -H "Content-Type: application/xml" -H "Authorization: Bearer 79933c7e-63fe-36f9-849b-25fc9aa7c46b" -d "<?xml version=\"1.0\" encoding=\"UTF-8\"?><!-- XML example cannot be generated; root element name is undefined --><employee><firstName>Randika</firstName><company>yenlo</company><mobileNumber>0718207205</mobileNumber></employee>" -v

Ausgabeprotokoll:

• HTTP-Anfrage mit falschen Nutzdaten (wesentliches Element fehlt – mobileNumber)

curl -X POST „https://api.prod.yenlo.connext.com/logger_test/1.0/employee“ -H „accept: */*“ -H „Content-Type: application/xml“ -H „Authorization: Bearer 79933c7e-63fe-36f9-849b-25fc9aa7c46b“ -d „<?xml version=\“1.0\“ encoding=\“UTF-8\“?><!– XML example cannot be generated; root element name is undefined –><employee><firstName>Randika</firstName><company>yenlo</company></employee>“ -v

Ausgabeprotokoll:

CNXT2][2023-03-08 07:24:26,664]  INFO correlation = 1fddb17e-6776-4ef7-ba86-516502326c2d, direction = IN, method = POST, resource = /yenlo/employee, correlationOrder = 1 {INFOLOGS}

, ERROR_DETAIL = org.xml.sax.SAXParseException; cvc-complex-type.2.4.b: The content of element ‚employee‘ is not complete. One of ‚{mobileNumber}‘ is expected.

        at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)

        at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)

        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)

        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)

        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)

        at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(Unknown Source)

        at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(Unknown S {INFOLOGS}

• Payload-Validierung nach der Transformation (mobilfunknummer weniger als 10 Zeichen)

curl -X POST "https://api.prod.yenlo.connext.com/logger_test/1.0/employee" -H "accept: */*" -H "Content-Type: application/xml" -H "Authorization: Bearer 79933c7e-63fe-36f9-849b-25fc9aa7c46b" -d "<?xml version=\"1.0\" encoding=\"UTF-8\"?><!-- XML example cannot be generated; root element name is undefined --><employee><firstName>Randika</firstName><company>yenlo</company><mobileNumber>071</mobileNumber></employee>" -v

Output log:

    level: „error“

    schema: {„loadingURI“:“#“,“pointer“:“/properties/mobileNumber“}

    instance: {„pointer“:“/mobileNumber“}

    domain: „validation“

    keyword: „minLength“

    value: „071“

    found: 3

    minLength: 10

, ERROR_EXCEPTION = null {INFOLOGS}

Fazit

Es wird nicht empfohlen, die Nutzdaten auf der Protokollebene INFO oder ERROR zu protokollieren, um Probleme mit Nutzdaten zu beheben. Versuchen Sie immer, die Protokollierung der Nutzlast zu Debugging-Zwecken zu minimieren. Wie bereits erwähnt, verursacht dies zusätzliche Kosten für das System und beeinträchtigt die Leistung. Der Validate Mediator ist eine gute Option, um die Nutzdaten in verschiedenen Stadien der Vermittlung zu validieren und liefert beschreibende Informationen über die Gültigkeit der Nutzdaten und Daten. In einigen Situationen kann es jedoch erforderlich sein, die Nutzdaten für eine weitere Analyse des Problems zu protokollieren. Aber sie sollten für bestimmte Zwecke auf der DEBUG-Protokollebene protokolliert werden.