Waarom is het loggen van berichten belangrijk?
Bij het ontwikkelen van bedrijfsapplicaties is loggen een essentieel onderdeel om beveiligingsbedreigingen, fouten en gebruikspatronen van de systemen te identificeren. Met betrekking tot het loggen van berichten relevant voor integratie en berichtbemiddeling, is het van cruciaal belang om problemen te debuggen in zowel de inkomende als de uitgaande flows van de bemiddeling, inclusief het gedrag van externe eindpuntaanroepen bij service-orkestratie.
WSO2 log bemiddelaar
De WSO2-logbemiddelaar wordt gebruikt om berichten in de bemiddelingsflow te loggen. De functie ondersteunt verschillende logniveaus en categorieën. De logbemiddelaar is voorwaardelijk inhoudsbewust, wat inhoudt dat het opbouwen van het bericht door de logbemiddelaar in de bemiddelingsflow afhankelijk is van het geselecteerde logniveau.
Syntax:
<log [level=”string”] [separator=”string”]> <property name=”string” (value=”literal” | expression=”[XPath|json-eval(JSON Path)]”)/>* </log>
Wat zijn de verschillende logniveaus van de logbemiddelaar?
OFF | Het hoogst mogelijke logniveau. Dit is bedoeld om het loggen uit te schakelen. |
FATAL | Geeft serverfouten aan die voortijdige beëindiging veroorzaken. Van deze logs wordt verwacht dat ze direct zichtbaar zijn op de opdrachtregel die u hebt gebruikt om de server op te starten. |
ERROR | Geeft andere runtime-fouten of onverwachte omstandigheden aan. Van deze logs wordt verwacht dat ze direct zichtbaar zijn op de opdrachtregel die u hebt gebruikt om de server op te starten. |
WARN | Geeft het gebruik van verouderde API’s, slecht gebruik van de API, mogelijke fouten en andere runtime-situaties aan die ongewenst of onverwacht zijn, maar niet noodzakelijkerwijs verkeerd. Van deze logs wordt verwacht dat ze direct zichtbaar zijn op de opdrachtregel die u hebt gebruikt om de server op te starten. |
INFO | Geeft belangrijke runtime-gebeurtenissen aan, zoals het opstarten/afsluiten van de server. Van deze logs wordt verwacht dat ze direct zichtbaar zijn op de opdrachtregel die u hebt gebruikt om de server op te starten. Het wordt aanbevolen om deze logs tot een minimum te beperken. |
DEBUG | Biedt gedetailleerde informatie over de flow door het systeem. Deze informatie wordt naar verwachting alleen naar logs geschreven. Over het algemeen moeten de meeste regels die door uw applicatie worden vastgelegd, worden geschreven als DEBUG-logs. |
TRACE | Biedt aanvullende details over het gedrag van gebeurtenissen en services. Deze informatie wordt naar verwachting alleen naar logs geschreven. |
Wat zijn de verschillende logcategorieën van de logbemiddelaar?
- Volledig: als deze categorie is geselecteerd, worden alle op het niveau Eenvoudig gelogde standaardheaders evenals de volledige payload van het bericht gelogd. Dit logniveau zorgt ervoor dat de inhoud van het bericht wordt geparseerd, wat leidt tot een prestatieoverhead.
- Eenvoudig: als deze categorie is geselecteerd, worden de standaardheaders (zoals To, From, WSAction, SOAPAction, ReplyTo en MessageID) gelogd.
- Headers: als deze categorie is geselecteerd, worden alle SOAP-headerblokken gelogd.
- Aangepast: als deze categorie is geselecteerd, worden alleen de eigenschappen die zijn toegevoegd aan de logbemiddelaarconfiguratie gelogd.
Belangrijke punten om rekening mee te houden bij het loggen van berichten
- Berichtcorrelatie-id
Berichtcorrelatie-ID is een unieke ID die is toegewezen aan het inkomende HTTP-verzoek. Dezelfde ID wordt gebruikt in alle inkomende en uitgaande flows van het specifieke verzoek in de bemiddelingsflow. Alle logvermeldingen kunnen verwijzen naar de correlatie-ID om de retournering van het HTTP-verzoek duidelijk te identificeren. Het is nuttig om het gedrag van de berichtenflow te analyseren en de berichtbemiddeling te debuggen.
Opmerking:
wanneer een HTTP-verzoek wordt ontvangen door het gateway-knooppunt van het connext-platform, wordt een correlatie-ID gegenereerd en ingesteld op de HTTP-header ‘correlationId’ voordat deze naar de backend wordt verzonden.
- Loggen minimaliseren
We proberen het loggen van berichten altijd tot een minimum te beperken, omdat dit rechtstreeks van invloed is op de prestaties van het systeem. Het schrijven van logs naar een bestand is een I/O-bewerking en gebruikt aanzienlijke middelen van het systeem. Daarom wordt aanbevolen om logs tot een minimum te beperken door alleen noodzakelijke informatie te loggen en onnodige informatie te vermijden.
Opmerking:
de ELK-stack is al ingesteld met het Connext-platform voor monitorings- en logdoeleinden. Voor de Connext 2.3 is het maximale aantal tekens per INFO- en DEBUG-logregel in het servicelogboek gedefinieerd.
INFOLOGS- 1024 tekens
appender.INFOLOGS.layout.pattern = [CNXT2][%d] %5p %.-1024m {INFOLOGS}%n
DEBUGLOGS- 1048576 tekens
appender.DEBUGLOGS.layout.pattern = [CNXT2][%d] %5p %.-1048576m {DEBUGLOGS}%n
Deze beperking is ingesteld om ervoor te zorgen dat het ELK-systeem probleemloos werkt met de bestaande middelentoewijzing en om de I/O-kosten van het integratiesysteem te minimaliseren.
- Volgorde van het logniveau
De kern van WSO2-logboekregistratie is gebaseerd op Log4j2 en hetzelfde bestelmechanisme is van toepassing.
DEBUG < INFO < WARN < ERROR < FATAL < OFF
Voorbeeld: als INFO-logs zijn ingeschakeld in het bestand log4j2.properties, worden alle logniveaus gelogd behalve het DEBUG-niveau.
- Logsjablonen
Ter minimalisering van redundantie is het mogelijk om een sequentiesjabloon te definiëren als een gemeenschappelijk logsjabloon dat kan worden hergebruikt door relevante parameterwaarden door te geven. De sequentiesjabloon kan worden aangeroepen vanuit de ‘aanroepsjabloon’ met behulp van de volgende syntaxis:
Syntax: sequence sjabloon
<?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: aanroepsjabloon
<?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>
- Het loggen van payload minimaliseren
In sommige situaties kan het nodig zijn om de payload te loggen voor debuggingsdoeleinden. Het wordt echter niet aanbevolen om de payload op een ander niveau dan DEBUG te loggen. Een reden hiervoor is de prestatie-impact van I/O-bewerkingen voor logboekregistratie. Een andere reden is dat de payload in een productiesysteem gevoelige informatie kan bevatten en het geen optimale werkwijze is om de payload te loggen.
Bij het debuggen is het identificeren van problemen met de gegevens in de payload de belangrijkste reden om de payload te loggen. In plaats van de payload te loggen, kunnen we echter gebruikmaken van validatiestappen om de gegevens op verschillende bemiddelingsniveaus te controleren. Deze aanpak kan helpen de hoeveelheid logs van payload te minimaliseren en het risico te verkleinen dat gevoelige informatie wordt opengesteld.
- Validatie van HTTP-verzoeken
- Validatie na payloadverbetering of -transformatie (zoals met verrijkende bemiddelaar, XSLT-bemiddelaar, enz).
- Validatie van in/uit service-orkestratie
- Validatie van HTTP-antwoorden
WSO2 heeft de validatiebemiddelaar geïntroduceerd, die XML- of JSON-payloads kan valideren op basis van vooraf gedefinieerde validatieschema’s.
Syntax:
<validate [source=”xpath”]> <property name=”validation-feature-id” value=”true|false”/>* <schema key=”string”/>+ <on-fail> mediator+ </on-fail> </validate>
Het volgende diagram illustreert de verschillende niveaus van payloadvalidatie in de bemiddelingsflow.
Integratievoorbeeld om de payload in de bemiddelingsflow te valideren
Stap 1:
Maak een API-definitie in de Publisher met behulp van de volgende API-definitie.
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
- De API-bron die wordt opengesteld door de gateway https://<Gatewayhost>/logger_test/1.0/employee
- Het productie-eindpunt is een API die is gemaakt in de WSO2 EI
https://:8243/yenlo
Stap 2:
Maak de volgende API in WSO2 EI. Dit is de API waarnaar we hebben verwezen als het productie-eindpunt van de API die wordt opengesteld in de gateway.
<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>
Stap 3:
Maak de onderstaande bemiddelingsreeks en sla deze op in het register
<?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>
De sequentielogica voert validatie in feite uit in twee verschillende fasen. Zodra het verzoek is ontvangen, valideert de eerste validatiebemiddeling het verzoek ten opzichte van de RequestValidator.xsd. De tweede validatiebemiddelaar voert payloadvalidatie uit na de berichttransformatie met behulp van de Payload Factory-bemiddelaar ten opzichte van TransformationValidator.json.
Step 4:
Maak de volgende logsjabloon om deze opnieuw te gebruiken in de bemiddelingslogflow
<?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 kunt u zien dat het loggen van payload is toegevoegd onder het DEBUG-logniveau. Alleen als we DEBUG-logs voor een bepaalde service hebben ingeschakeld, kunnen we debug-logs verkrijgen met het loggen van payload.
Step 5:
Maak de volgende validatieschema’s en sla ze op in het register
Xml-validatieschema
<?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-validatieschema
{
"$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"
]
}
Step 6:
Testen met verschillende gebruiksscenario’s
- HTTP-verzoek met correcte payload
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
Uitvoerlog:
[CNXT2][2023-03-08 07:22:14,424] INFO correlation = 9f30a322-13d3-470d-b80a-37431a10799e, direction = IN, method = POST, resource = /yenlo/employee, correlationOrder = 1 {INFOLOGS} [CNXT2][2023-03-08 07:22:14,424] INFO SequenceName = Test_Api, Correlation-Id = 9f30a322-13d3-470d-b80a-37431a10799e, HTTP_CODE = null, Message = Test_Api : started {INFOLOGS} [CNXT2][2023-03-08 07:22:14,443] INFO SequenceName = MessageTransformationSequence, Correlation-Id = 9f30a322-13d3-470d-b80a-37431a10799e, HTTP_CODE = null, Message = Started {INFOLOGS} [CNXT2][2023-03-08 07:22:14,447] INFO SequenceName = MessageTransformationSequence, Correlation-Id = 9f30a322-13d3-470d-b80a-37431a10799e, HTTP_CODE = null, Message = Cmpleted {INFOLOGS} [CNXT2][2023-03-08 07:22:14,447] INFO SequenceName = Test_Api, Correlation-Id = 9f30a322-13d3-470d-b80a-37431a10799e, HTTP_CODE = null, Message = Test_Api : completed {INFOLOGS} [CNXT2][2023-03-08 07:22:14,448] INFO correlation = 9f30a322-13d3-470d-b80a-37431a10799e, direction = OUT, response = 0, correlationOrder = 2 {INFOLOGS}- HTTP-verzoek met onjuiste payload (ontbrekend essentieel element – 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
Uitvoerlog:
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}
[CNXT2][2023-03-08 07:24:26,665] INFO SequenceName = Test_Api, Correlation-Id = 1fddb17e-6776-4ef7-ba86-516502326c2d, HTTP_CODE = null, Message = Test_Api : started {INFOLOGS} [CNXT2][2023-03-08 07:24:26,666] INFO SequenceName = MessageTransformationSequence, Correlation-Id = 1fddb17e-6776-4ef7-ba86-516502326c2d, HTTP_CODE = null, Message = Started {INFOLOGS} [CNXT2][2023-03-08 07:24:26,670] ERROR ServiceName = null, SequenceName = MessageTransformationSequence, Correlation-Id = 1fddb17e-6776-4ef7-ba86-516502326c2d, ERROR_CODE = null, HTTP_CODE = null, Message = Invalid request received, ERROR_MESSAGE = cvc-complex-type.2.4.b: The content of element ‘employee’ is not complete. One of ‘{mobileNumber}’ is expected., 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}
[CNXT2][2023-03-08 07:24:26,670] INFO correlation = 1fddb17e-6776-4ef7-ba86-516502326c2d, direction = OUT, response = 400, correlationOrder = 2 {INFOLOGS}- Payload validatie na transformatie (mobileNumber minder dan 10 karakters )
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
Uitvoerlog:
[CNXT2][2023-03-08 07:29:28,249] INFO correlation = c4ff4a79-fb4b-4032-879f-7f6dcded7a00, direction = IN, method = POST, resource = /yenlo/employee, correlationOrder = 1 {INFOLOGS} [CNXT2][2023-03-08 07:29:28,250] INFO SequenceName = Test_Api, Correlation-Id = c4ff4a79-fb4b-4032-879f-7f6dcded7a00, HTTP_CODE = null, Message = Test_Api : started {INFOLOGS} [CNXT2][2023-03-08 07:29:28,250] INFO SequenceName = MessageTransformationSequence, Correlation-Id = c4ff4a79-fb4b-4032-879f-7f6dcded7a00, HTTP_CODE = null, Message = Started {INFOLOGS} [CNXT2][2023-03-08 07:29:28,255] ERROR ServiceName = null, SequenceName = MessageTransformationSequence, Correlation-Id = c4ff4a79-fb4b-4032-879f-7f6dcded7a00, ERROR_CODE = null, HTTP_CODE = null, Message = Failed to validate the payload after transformation, ERROR_MESSAGE = string “071” is too short (length: 3, required minimum: 10), ERROR_DETAIL = Error while validating Json message error: string “071” is too short (length: 3, required minimum: 10)level: “error”
schema: {“loadingURI”:”#”,”pointer”:”/properties/mobileNumber”}
instance: {“pointer”:”/mobileNumber”}
domain: “validation”
keyword: “minLength”
value: “071”
found: 3
minLength: 10
, ERROR_EXCEPTION = null {INFOLOGS}
[CNXT2][2023-03-08 07:29:28,255] INFO correlation = c4ff4a79-fb4b-4032-879f-7f6dcded7a00, direction = OUT, response = 500, correlationOrder = 2 {INFOLOGS}Conclusie
Het wordt niet aanbevolen om de payload op INFO- of FOUT-logniveau te loggen om problemen met payloads op te lossen. Probeer het loggen van de payload altijd te minimaliseren voor debuggingsdoeleinden. Zoals eerder vermeld, voegt dit extra kosten toe aan het systeem en heeft het invloed op de prestaties. De validatiebemiddelaar is een goede optie om de payload in verschillende fasen van bemiddeling te valideren en geeft beschrijvende informatie over de validiteit van de payload en gegevens. In sommige situaties kan het echter nodig zijn om de payload te loggen voor verdere analyse van het probleem. De payload moet voor specifieke doeleinden echter worden gelogd op het DEBUG-logniveau.