Boost研究：Boost Log

2年前浏览1918

日志系统用于记录软件运行过程中的关键信息，是大型CAx软件系统的一个重要的组件。

本文拟对Boost.Log模块进行分析，旨在记录其技术要点。

注1：限于笔者研究水平，难免有理解不当，欢迎批评指正。

注2：文章内容会不定期更新，欢迎交流讨论。

一、工作原理

Boost.Log大体上可以由Logging Sources、Logging Core、Logging Sinks等组成：Logging Sources创建log records；Logging Core对log records进行处理；Logging Sinks则完成最终格式化与输出。

Ref. from Boost.Log Design Overview

Logging sources

Getting back to the figure, in the left side your application emits log records with help of loggers - special objects that provide streams to format messages that will eventually be put to log. The library provides a number of different logger types and you can craft many more yourself, extending the existing ones. Loggers are designed as a mixture of distinct features that can be combined with each other in any combination. You can simply develop your own feature and add it to the soup. You will be able to use the constructed logger just like the others - embed it into your application classes or create and use a global instance of the logger. Either approach provides its benefits. Embedding a logger into some class provides a way to differentiate logs from different instances of the class. On the other hand, in functional-style programming it is usually more convenient to have a single global logger somewhere and have a simple access to it.

Generally speaking, the library does not require the use of loggers to write logs. The more generic term "log source" designates the entity that initiates logging by constructing a log record. Other log sources might include captured console output of a child application or data received from network. However, loggers are the most common kind of log sources.

Logging core and filtering

When the set of attribute values is composed, the logging core decides if this log record is going to be processed in sinks. This is called filtering. There are two layers of filtering available: the global filtering is applied first within the logging core itself and allows quickly wiping away unneeded log records; the sink-specific filtering is applied second, for each sink separately. The sink-specific filtering allows directing log records to particular sinks. Note that at this point it is not significant which logging source emitted the record, the filtering relies solely on the set of attribute values attached to the record.

Sinks and formatting

If a log record passes filtering for at least one sink the record is considered to be consumable. If the sink supports formatted output, this is the point when log message formatting takes place. The formatted message along with the composed set of attribute values is passed to the sink that accepted the record. Note that formatting is performed on the per-sink basis so that each sink can output log records in its own specific format.