Vostok.Logging
HomeQuickstartModulesImplementations
1.0.0
1.0.0
  • Home
  • Quickstart
  • Guarantees
  • Configuration
  • Concepts and basics
    • Log interface
    • Log events
    • Syntax
      • Logging extensions
      • Message templates
      • Providing property values
    • Formatting
      • Output templates
      • Special properties
      • Format specifiers
    • Source context
    • Operation context
  • Modules
    • Abstractions
    • Configuration
    • Formatting
    • Console
    • File
    • Hercules
    • Context
    • Serilog
    • Log4net
    • NUnit
    • Microsoft
  • Implementations
    • Silent log
    • Console log
    • File log
    • Hercules log
  • Integrations
    • Serilog integration
    • Log4net integration
    • Microsoft logging integration
  • How-to guides
    • Using operation context
    • Using static log provider
    • Filtering events
    • Enriching events
    • Transforming events
    • Combining multiple logs
    • Custom output templates
    • External configuration rules
Powered by GitBook
On this page

Guarantees

PreviousQuickstartNextConfiguration

Last updated 6 years ago

This page lists the guarantees provided by built-in log implementations (, and ). These guarantees reflect the following design principle: logging system should not be able to affect overall application health and performance.

No exceptions from logging methods

If log events cannot be saved for any reason (ranging from incorrect to running out of disk space or experiencing remote backend unavailability), log method calls still complete successfully without throwing exceptions. If possible, a diagnostic message is produced via secondary means (console output for and any local log for ).

Asynchronous I/O

Log methods always return instantly (and are mostly lock-free). All the necessary I/O (writing to file/console or sending HTTP requests) happens in the background.

Limited resource usage

Async I/O implies buffering. Log implementations have configurable limits on internal buffer sizes to avoid allocating too much memory. CPU usage is generally bounded to a single core.

No guarantee of delivery

Logs delivery is maintained on a best effort basis. Events can be lost in following cases:

  • Internal buffers overflow due to unavailability of underlying storage or sheer volume of incoming logs.

  • Application terminates abruptly without flushing/disposing async loggers.

Reporting of events loss (metrics, diagnostic messages) is implementation-specific (see usage tips for , and logs).

console log
file log
Hercules log
message template
file log
Hercules log
console
file
Hercules