Apache log4net Documentation

log4net provides several built-in modules to handle different aspects of the logging pipeline:

• Appenders: Responsible for directing log events to specific destinations such as files, network sockets, databases, or SMTP servers.
• Layouts: Responsible for formatting the log output. Supported formats include Text, XML, JSON, and Syslog.
• Filters: Responsible for deciding which log events should be processed based on criteria like log levels or regular expressions.

log4net is actively built and tested against the following target frameworks:

• Microsoft .NET 8 (via .NET Standard 2.0)
• Microsoft .NET Framework 4.6.2

Filters are plugins that evaluate logging calls or log events. When a filter processes an event, it returns one of three results that determines the flow of the filter chain:

• ACCEPT: The event is accepted immediately. Other filters in the same stage are skipped, and the event is logged.
• DENY: The event is dropped immediately. No further filters are evaluated, and the event is not logged.
• NEUTRAL: The filter behaves as if it were not present. The event is passed to the next filter in the chain.

If an event reaches the end of the filter chain without being denied, it is implicitly accepted and logged. To prevent non-matching events from being logged, you can place a log4net.Filter.DenyAllFilter at the end of your filter chain.

log4net is designed for high-reliability and high-performance environments:

• Automatic Configuration Reloading: log4net can automatically reload its configuration when the configuration file is modified. This process is designed to occur without losing log events during the reconfiguration period.
• Performance: When configured correctly, log4net is optimized to deliver high performance while maintaining reliability.

Apache log4net follows Semantic Versioning (SemVer) 2.0.0. Release numbers follow the format <major>.<minor>.<patch>[-<pre-release>].

• Major version (<major>): Incremented for breaking changes. Upgrading typically requires code changes. A migration guide is provided for each new major release.
• Minor version (<minor>): Incremented for backward-compatible new features (e.g., new public API methods, new configuration attributes, or deprecations). Upgrading usually does not require code changes, but you should review the release-notes.adoc for behavioral changes.
• Patch version (<patch>): Incremented for backward-compatible bug fixes. This is the simplest upgrade path.

Loggers are named entities that follow a hierarchical structure similar to .NET namespaces (e.g., System.Text is a child of System). This hierarchy allows for fine-grained control over logging levels.

Level Inheritance

If a logger does not have an explicitly assigned level, it inherits the level of its closest ancestor in the hierarchy. The root logger sits at the top of the hierarchy, always exists, and always has an assigned level (defaulting to DEBUG).

Selection Rule

A logging request is enabled if its level is greater than or equal to the logger's assigned (or inherited) level.

Standard Level Order (Increasing Priority): DEBUG < INFO < WARN < ERROR < FATAL

You can define custom logic to turn specific objects into strings for your logs by implementing the log4net.ObjectRenderer.IObjectRenderer interface.

Renderers follow the class hierarchy: if you register a FruitRenderer, it will handle all types derived from Fruit unless a more specific renderer (like OrangeRenderer) is registered.

Use DynamicPatternLayout when your log headers or footers need to include information that changes over time, such as timestamps. Unlike the static PatternLayout, which renders headers and footers only once, DynamicPatternLayout re-evaluates its pattern every time it is invoked.

<layout type="log4net.Layout.DynamicPatternLayout">
  <header value="Log started at %date%newline" />
  <footer value="Log ended at %date%newline" />
  <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
</layout>

Because RemoteSyslogAppender uses the UDP protocol, there are inherent size limitations that can lead to message truncation (loss of message content):

• Maximum Message Size: 64 KB (includes both message content and headers).
• Practical Network Limit: On many networks (like Ethernet), the practical limit is typically around 1500 bytes.

To prevent data loss, ensure your log messages and layouts are sized to fit within your network's MTU/practical limits.