The document provides an overview of a presentation on logging services with Log4j2 and on-premises deployment. The agenda includes introductions to Log4j2 architecture and custom logging, a demo, and trivia. Best practices for logging are discussed such as using standardized formats, request identifiers, and informative messages. Excessive logging is addressed along with the importance of relevance and readability. The presentation emphasizes planning a logging strategy, chaining complex systems, keeping logs simple, and having support personnel review logs.

1. 1

2. November 24, 2022
Mysore MuleSoft Meetup
Log4j2 –
A deep dive into the logging services with
On-Prem deployment

3. Safe Harbour Statement
● Both the speaker and the host are organizing this meet-up in individual capacity only.
We are not representing our companies here.
● This presentation is strictly for learning purposes only.
● Organizer/Presenter do not hold any responsibility that same solution will work for
your business requirements.
● This presentation is not meant for any promotional activities.
3

4. A recording of this meetup will be uploaded to events page within 24 hours.
Questions can be submitted/asked at any time in the Chat/Questions & Answers Tab.
Make it more Interactive!!!
Give us feedback! Rate this meetup session by filling feedback form at the end of the day.
We Love Feedbacks!!! Its Bread & Butter for Meetup.
Housekeeping
4

5. Introduction
● About the Organizers
5
Shubham Chaurasia
Billennium India
Professional Integration Developer
A SHOW OF HANDS:
Who is new to this Meetup?
Giridhar Meka
Sr. Technical Architect

6.  Certified MuleSoft Developer
 1.8 years of Total Experience
 Working as Specialist I at HashedIn By Deloitte
 Certified AWS Cloud Practitioner
● About the Speaker
Speaker
6
Robin Sinha
Specialist I

7. 7
● Introductions
o What is Log4j2?
o Log4j2 Architecture
o Customised Logging with on premises deployment
o Integration of third-party logging tools with MuleSoft
● Demo
● Trivia
● Wrap-Up
Agenda

8. Why Log In the First Place?
8
• Debugging
• Supportability
• System visibility
• System traceability

9.  Configuration in src/main/resources/log4j2.xml
 Components
 Configuration
 Appenders
 Use Log4J2CloudhubLogAppender to continue
to log to MuleSoft server logs
 Loggers
 Async Logger
 Log level
Log4j2
9

10. Appenders essentially describe how to deliver the logging events to a destination. Think about
where you typically see log events outputted from your Mule applications — the Console view in
Anypoint Studio and the log files of the application itself — both of these are examples
of Appenders
Appenders
10

11. The RollingFile appender ensures that all log events are routed to a specified file, but there are
alternative options, such as writing events to a relational database, submitting messages to topics
for Kafka integration, or over SMTP
RollingFile
11

12. fileName: the location and the name of the log file to create and write to the default location
of the log file
RollingFile: File Name
12

13. PatternLayout: pattern attribute: Essentially, this is what dictates the format and presentation of
the rolling log file. It is a combination of conversion specifiers (pre-fixed with ‘%’) and hard coded
text.
Ex:
pattern= "%-5p %d [%t] [event: %X{correlationId}] %c: %m%n”
%p – the priority level of the logging event.
%d – the default format for the date and time.
%t – the thread name that generated the logging event.
RollingFile: PatternLayout
13

14. Loggers can be configured to determine what specific packages are to be logged — and to what
depth — where packages are a grouped set of classes and interfaces, represented by a namespace.
Loggers
14

15. One of the main considerations for the Loggers section is to choose whether to log your
events synchronously or asynchronously. It’s recommended to select asynchronous logging in
production to improve the application’s performance, i.e., low latency.
Loggers: AsyncRoot
15

16. This references the name element value from the appender, and thus links an appender
configuration (discussed next) to the logger configuration, i.e., it instructs upon the logger the log’s
output destination format, and its configuration
Loggers: Appender Reference
16

17. • Deploying to CloudHub
• Disable CloudHub logging to allow log4j2 configuration to take over
• Documentation: https://docs.mulesoft.com/runtime-manager/custom-log-appender
• Apache documentation: https://logging.apache.org/log4j/2.x/
Logging With Log4j CloudHub
17

18. Log4j 2 Integration with third-party tools
18

19. Logging Best Practices
19
• Standards
 JSON
 Key-value pairs
 Other formats
• Request identifier
 Ability to calculate latency
 Trace transaction from end to end
• Informative messages
 Enhance debugging
 Visibility into the system
 Before & after external system calls
• Dynamic error messages
• Persisting logs to system
 Maintain historical logs
 Allows non-technical users to access & support
applications
• Not too much logging, not too little

20. Logging Best Practices in Enterprise Environment
20
Characteristics of EE
• 24/7 monitoring
• Some sensitive data
• Vast amount of integrations
• Network of complex systems
 SAP, Salesforce, etc.,
• Managed systems, networks, etc.,
 Databases, VPNs, etc.,
• Dedicated support & development

21. Logging Best Practices in Enterprise Environment
21
• Different log styles
• Logs usually vary by many factors
 Tools capabilities
 Pressure, time allowed to polish
 Developer, guidelines, maturity, etc.,

22. Logging Best Practices in Enterprise Environment
22
• Log levels
• Are errors always errors?
• Warnings are your friend
• Detailed log in debug or even trace
 Not all levels need to be enabled in log4j2
Fatal
• Least verbose
Error
Warn
Info
• Default log level
Debug
Trace
• Most verbose

23. Logging Best Practices in Enterprise Environment
23
● Excessive logging?
○ 1.440 times in a day
○ 10.080 times in a week
○ 525.600 times in a year

24. Logging Best Practices in Enterprise Environment
24
● Excessive logging?
○ 1.440 times in a day
○ 10.080 times in a week
○ 525.600 times in a year
● How to solve?
○ Log only errors?
○ 1.440 + errors in a day

25. Logging Best Practices in Enterprise Environment
25
● Excessive logging?
○ 1.440 times in a day
○ 10.080 times in a week
○ 525.600 times in a year
● How to solve?
○ Log only errors?
○ How about problem solving?
● With payload 100
○ 145.440 + errors in a day

26. Logging Best Practices in Enterprise Environment
26
● Excessive logging?
○ 1.440 times in a day
○ 10.080 times in a week
○ 525.600 times in a year
● With payload of 100
○ 144.000 times in a day
+ all errors
○ Still a lot

27. Logging Best Practices in Enterprise Environment
27
More Less
Readability
Performance
Costs
Legal
Guaranteed
delivery
Context
● Excessive logging?
● No need to log received payload?
● Need to consider what is relevant
● Do you really have to know if something went through? Or just failed ones?
It's all about balance

28. Logging Best Practices in Enterprise Environment
28
● Stakeholders
○ Did order xyz go to system A
○ Who are the people asking questions?
○ Data ownership/restrictions – when logging payload
● Integrations are between systems therefore someone is interested about data
○ Try to solve during development most relevant support cases and try to overcome with
brilliant logging
● Knit together multiple apps or even systems with correlationIds
○ Can be unique document id from source system
○ Not always need to use Mule’s generated correlationId
● Custom logger
○ Requires often external logging system
○ When logging becomes too complex to handle with default logger component
● Not always needed since
○ Log4J2 can handle some nifty stuff

29. Logging Best Practices in Enterprise Environment
29
● Logging strategy
○ Do this once and reuse
○ Should give answer to questions
■ Where to log?
■ What to log / What not to log?
■ Sensitive data handling?
● Best Practices
1. Plan ahead and create a big picture how to do logging – Logging strategy
2. Take in consideration of whole picture and utilize chaining systems together with
correlationId and readable logs – Chain complex systems together
3. Keep logging simple and streamlined so it won’t be bottleneck for solution and your support
personnel will thank you – Keep logs readable and simple
4. Logging and sample of logs should be reviewed not by developer but also by support
personnel as they know if it is enough – Review logs

30. Logging Bad Practice
30
• Hard coding
• Empty loggers
• No logging standards
• Beware: CloudHub logs are limited by size
 100MB or 30 days, whichever comes first

31. Demo

32. Q&A

33. Take a stand !
33
● Nominate yourself for the next meetup speaker and suggest a topic as well.

34. 34
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Join Mysore Group: https://meetups.mulesoft.com/mysore/
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
○ Reach out to Mysore Meetup Leaders (Shubham/Giridhar) to suggest topics
for next Meetup
What’s next?

35. Get ready to WIN a MuleSoft Voucher from MuleSoft
Quiz Time

36. Thank you