Hey Vignesh, there aren't really strict rules but I would suggest:

- TRACE: Can be used to document every step in a flow, most people never use this in Mendix.

- DEBUG: Add here the more technical details of an issue/bug, like stacktraces and error messages you usually don’t need to see only during debugging.

- INFO: The regular information you want to show in your app, but usually you try to limit this to show only during development. From here and higher is usually visible by the user (they can also see the DEBUG and TRACE when they change the log levels).

- WARNING: When there was an issue but the code didn't fail/stop, this text will appear in yellow.

- ERROR: These are the real issues, failed microflows/actions that limits the functionality of your application.

- CRITICAL: The app doesn't work (proper) anymore, some serious issues happened. Shit hit the fan!

I would suggest in general: put the things you want to always see on INFO, WARNING, ERROR and CRITICAL and the things you want to hide most of the time to DEBUG and TRACE. Know that everything you put in the logs can be read by the end user, so don't post anything sensitive. 

https://docs.mendix.com/howto/monitoring-troubleshooting/log-levels/#level 

Hi 

Few suggestions from my side ,

1. Initializing Your Log Nodes

   Because log nodes are dynamically registered, you will need to register your log node . This is achieved by creating a sub-microflow that logs a message for each log node in your module. This microflow should then be called in your After startup microflow. It’s best practice to create a separate microflow for log node registration because usually the After startup microflow is used for other things as well. 

2.  Use an enumeration when defining log node names.to keep it consistent through out.
3. When creating your own log messages it’s important to have the log levels and their descriptions meaningful ,short and handy
4. Do not overdo the logging , as it may impact on the performance also.

Thanks