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

This page lists the guarantees provided by built-in log implementations (console log, file log and Hercules log). 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 message template 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 file log and any local log for Hercules log).

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 file, console and Hercules logs).

PreviousQuickstartNextConfiguration

Last updated 6 years ago