Introduction

The application logging process is an extended version of Log4net logging. The logging process starts immediately after an incident occurs and is an asynchronous process that does not require the application to be awake. In this article, we will provide you with an overview of how the logging process works in Znode.

What is the logging process?

The logging process is a way to capture and store information about an application's behavior, events, and actions. This information is then used to identify and troubleshoot issues that may arise during the application's lifecycle.

1. In OOTB Znode, Log4net to use the MongoDB appender. This can be seen in the application's configuration file (e.g. web. config or app. config) by specifying the appender type, connection string, and other settings. Please refer to the below screenshot 
2. Next, you need to define the logging format and levels. Log4net supports multiple logging levels, such as DEBUG, INFO, WARN, and ERROR, which can be used to filter messages based on their severity.

   1. DEBUG: Use this level for very detailed and verbose messages that are intended for debugging and diagnosing problems. In production environments, these messages are not usually needed. They are typically used for development and testing only

   2. INFO: Use this level for tracking the application's progress or activity, but not necessarily for errors or warnings. You can use these messages to troubleshoot and analyze performance.

   3. WARN: Use this level for messages that indicate potential problems or issues that could cause errors or unexpected behavior. These messages are not necessarily errors, but they do require attention and may need to be addressed to prevent more serious issues from occurring.

   4. ERROR: Use this level for messages that indicate errors or exceptions that occur during the application's execution. These messages can be used to track down and diagnose bugs and issues in the application.    

3. Once the configuration is set up, you can log messages using the Log4net API. For example, you can use the ILogger interface to log messages with a specific level and category.
4. When a log message is generated, Log4net creates a LogEvent object that contains the message details, such as the timestamp, level, category, and message text.
5. The LogEvent is then passed to the MongoDB appender, which converts the message into a BSON document and stores it in the specified MongoDB collection. The appender can also handle errors and retry failed writes.
6. Finally, you can use tools like the MongoDB Compass or the MongoDB shell to query and analyze the logged messages. This can help you identify issues, performance bottlenecks, or usage patterns in your application.
7. Depending on your configuration, you can store application log files in a variety of places on an Internet Information Service server. Below is one of the default locations
   1. File system: You can configure IIS to store application logs in specific directories on the server's file system. By default, IIS stores logs in the %SystemDrive%\inetpub\logs directory. The specific subdirectory will depend on the site and log type. For example, the W3SVC (World Wide Web Publishing Service) logs for the default website might be stored in the following directory
      
      

How does the logging process work in Znode?

The logging process is based on what is provided by the Log4net logging library. The logging process starts immediately after an incident occurs and is an asynchronous process that does not require the application to be awake.

When an incident occurs, such as an error or exception, the Log4net logging library captures the relevant information and stores it in a buffer. The buffer then waits until a certain threshold is reached, such as the number of log entries or a specific time interval, before sending the information to the logging destination.

The logging destination has multiple configurable options including a file, a database, or a remote server. Znode uses MongoDB as the default destination for storing logs.

Below is the default setting of the buffer size value in the Log4net file in the API admin and webstore, refer to the screenshot below.

Why is there a delay in logging events in different environments?

Logging events may be delayed in some environments due to the default value of the bufferSize key in Log4net.config. For example, The default value is set to 100, which means that log entries are only sent to the logging destination after the buffer reaches 100 entries or a certain time interval.

To reduce the delay in logging events, you can increase the value of the bufferSize key in the Log4net.config file to a value greater than the default value. This will allow the buffer to hold more log entries before sending them to the logging destination, reducing the delay in logging events.

If the default buffer value is set to 100, we must wait until there are 100 logs in the mongoDB before retrieving the logs.

Different Types of Appenders Are Used in the Znode for Log4net:

In Log4net, an appender is responsible for the output of log messages to various destinations.

In Znode, Log4net provides several built-in appenders, such as:

1. RollingLogFileAppender
2. SmtpAppender

RollingLogFileAppender

RollingLogFileAppender is for writing log messages to a file to use a RollingLogFileAppender, you need to configure it in your application's configuration file (e.g, Log4net.config) for reference added the screenshot 

SmtpAppender

SmtpAppender for sending log messages via email. To use a SmtpAppender, you need to configure it in your application's configuration file (e.g, Log4net.config) for reference added the below screenshot 

Reference Link

User Guide| Application Log