Location: file module.
var fileLog = new FileLog(new FileLogSettings());var dynamicallyConfiguredLog = new FileLog(() => ObtainSettings());
Customizable output templates.
Customizable rolling strategies:
By size (roll over to a new file when current one reaches given size)
By time (roll over to a new file every second/minute/hour/day)
Hybrid (both by size and time)
Automatic cleanup of stale files
FileLog instances inside a single process may write to the same file without performance penalties.
Log method is nonblocking: log events are placed into an internal queue, buffered and efficiently written to files in the background.
FileLog instances are configured with
FileLogSettings, exposing following options:
Path to the log file. If rolling is enabled, this path serves as a base path and gets combined with various suffixes determined by the rolling strategy.
Position of the rolling suffix can be customized by inserting a special
This path is interpreted as relative to current working directory, though absolute paths are supported too.
File path is not allowed to point to a directory.
Output template to render log events with.
An optional format provider used when applying custom format specifiers.
Specifies the way to treat an existing log file: append or rewrite.
Type of rolling strategy. Possible values are
Period of switching to the next file when using
Size threshold for switching to the next file when using
The number of most recent files to keep when using a rolling strategy: older files are automatically removed. Specify zero value to avoid removing old files.
Produced file's encoding.
File stream buffer size, specified in bytes.
A list of enabled log levels.
Capacity of the internal log events queue.
Cooldown for enforcing file-related settings (file path, rolling strategy, etc). This means that when conditions are met to switch to the next part of log file or reopen the file with another name/options due to change in settings, the switching may be delayed for up to value of this option.
All of these parameters are optional.
Most of listed options support dynamic reconfiguration when a constructor with
Func<FileLogSettings> is used and provided delegate returns different instances of
FileLog will react to these changes by either reopening the file, switching to a new file or simply using the new values where applicable.
The only notable exception to this rule is the
EventsQueueCapacity option: it has a per-file scope and can't be changed dynamically.
Keep in mind that log messages are written to files in the background. Use
FlushAsync methods of
FileLog to ensure that all logged events have been actually written at any given moment.
Remember to dispose of
FileLog instances when they are no longer needed in order to close file handles.
Dispose method also flushes all remaining messages before closing the file.
Internal queue with limited capacity implies that log messages may be lost in the event of overflow (see guarantees section for more on this topic). Use
EventsLost property of a single
FileLog instance or static
TotalEventsLost property to check if any events have been discarded.
If any log events are lost due to internal queue overflow,
FileLog emits a special diagnostic message that looks like this:
[FileLog] Buffer overflow. 100 log events were lost (events queue capacity = 50000).
When encountering any other severe internal error (such as inability to open the file),
FileLog reports it to console.
FileLog can be configured from any external source (such as a local settings file) with Vostok.Configuration: just construct the log with a delegate that obtains
FileLogSettings from a