版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/breaksoftware/article/details/51363353 </div>
<link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/ck_htmledit_views-f57960eb32.css">
<link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/ck_htmledit_views-f57960eb32.css">
<div class="htmledit_views" id="content_views">
<p> GLog是Google开发的一套日志输出框架。由于其具有功能强大、方便使用等特性，它被众多开源项目使用。本文将通过分析其源码，解析Glog实现的过程。</p>
该框架的源码在https://github.com/google/glog上可以获取到。本文将以目前最新的0.3.3版本源码为范例进行分析。（转载请指明出于breaksoftware的csdn博客）
首先我们介绍下Glog简单的使用方法。Glog暴露了很多方法供使用者调用，一般它们都是通过宏的形式提供的。这些方法的功能包括：参数设置、判断、日志输出、自定义行为。基于重要性的考虑，我并不准备在本文中介绍参数设置和判断两个特性的函数。而将重点放在Glog的核心——日志输出和自定义行为上。而且在日志输出环节，我们将重点关注于文件形式的输出。下文中很多未加设定的场景一般都是以文件输出为例说明的。
我们以一个简单的例子作为开始
-
int _tmain(
int argc, _TCHAR* argv[])
-
{
-
google::InitGoogleLogging(argv[
0]);
-
FLAGS_log_dir =
"D:\\Dev\\glog-0.3.3\\glog-0.3.3\\Debug\\log";
-
LOG(INFO) <<
"INFO";
-
LOG(INFO) <<
"INFO1";
-
LOG(WARNING) <<
"WARNING";
-
LOG(WARNING) <<
"WARNING1";
-
LOG(ERROR) <<
"ERROR";
-
LOG(ERROR) <<
"ERROR1";
-
LOG(FATAL) <<
"FATAL";
-
google::ShutdownGoogleLogging();
-
return
0;
-
}
第3和12行是对称的，用于初始化和关闭Glog系统。这两个过程的实现也非常简单，其比较有意义的是ShutdownGoogleLogging中实现了对过程中新建对象的清理。即调用了
-
static LogDestination* log_destinations_[NUM_SEVERITIES];
-
void LogDestination::DeleteLogDestinations() {
-
for (
int severity =
0; severity < NUM_SEVERITIES; ++severity) {
-
delete log_destinations_[severity];
-
log_destinations_[severity] =
NULL;
-
}
-
}
LogDestination是是GLog非常核心的一个类。按英文翻译过来，它就是“日志目标”类。正如它名称，我们对日志的输出最终将落到该类上去执行。之后我们将一直和它打交道。
上面main函数的04行对Glog的全局变量重新赋值，它用于标记日志文件的生成路径。这类全局变量在logging.h中暴露了很多，它们很多是以DECLARE_bool、DECLARE_int32或DECLARE_string等宏声明的。这些就是我前文所述的“参数”。我们先只要知道FLAGS_log_dir的作用就行了。
05到11行向GLog系统中输出了4中类型的日志，即INFO、WARNING、ERROR和FATAL。GLog框架一共提供了上述四种类型的日志，这些日志将被分别输出到四个文件中。如本例我们将生成如下四个文件：
glog_test.exe.computername.username.log.ERROR.20160510-153013.9704
glog_test.exe.computername.username.log.FATAL.20160510-153013.9704
glog_test.exe.computername.username.log.INFO.20160510-153013.9704
glog_test.exe.computername.username.log.WARNING.20160510-153013.9704其中computername是设备的ID，username是登录用户的名称。
这种设计是非常有意义的。在我们开发过程中，我们可以通过INFO类型的日志进行过程分析。在自测阶段，我们可能更多要关注于是否存在WARNING类型的日志。而上线后，可能会出现一些我们认为不合法或者异常的场景，则这个时候就要关注ERROR和FATAL类型的日志了。这四种日志并不是相互独立的，而是存在包含关系。按照重要性，INFO日志文件将包含INFO、WARNING、ERROR和FATAL日志，因为在开发过程中我们需要关注所有信息。WARNING日志文件将包含WARNING、ERROR和FATAL日志。ERROR日志将包含ERROR和FATAL日志。FATAL日志文件里只有FATAL类型的日志。这种层级关系将非常有助于我们在不同时期关注不同性质的问题。我们看下INFO日志文件的内容
Log file created at: 2016/05/10 15:30:13
Running on machine: COMPUTERNAME
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I0510 15:30:13.564411 11392 glog_test.cpp:11] INFO
I0510 15:30:13.566411 11392 glog_test.cpp:12] INFO1
W0510 15:30:13.566411 11392 glog_test.cpp:13] WARNING
W0510 15:30:13.566411 11392 glog_test.cpp:14] WARNING1
E0510 15:30:13.567411 11392 glog_test.cpp:15] ERROR
E0510 15:30:13.567411 11392 glog_test.cpp:16] ERROR1
F0510 15:30:13.568413 11392 glog_test.cpp:17] FATAL 眼尖的同学可能发现INFO、ERROR和WARNING日志都有两条，而FATAL日志只有一条。这个地方引出FATAL类型日志的使用场景问题。一般情况下，如果出现程序已经无法执行的场景才使用FATAL日志用于记录临死之前的事情。所以如果我们在项目中发现日志中出现一连串的FATAL日志，往往是对Glog的错误使用。
Glog的基本使用我们讲完了，我们开始进行源码的讲解。
我们先看下LOG宏的定义
#define LOG(severity) COMPACT_GOOGLE_LOG_ ## severity.stream()
可以见得，LOG宏的等级参数和COMPACT_GOOGLE_LOG_联合在一块组成一个宏。比如INFO则对应于COMPACT_GOOGLE_LOG_INFO；FATAL对应于COMPACT_GOOGLE_LOG_FATAL。这些宏最终都将对应于一个google::LogMessage对象，比如
-
#define LOG_TO_STRING_ERROR(message) google::LogMessage( \
-
__FILE__, __LINE__, google::GLOG_ERROR, message)
通过对不同日志类型的LogMessage构造对象对比说明，它们是通过LogMessage的第三个参数进行区分的，上例中ERROR日志的等级就是google::GLOG_ERROR。在log_severity.h文件中，定义了GLog四个等级对应的值。
-
const
int GLOG_INFO =
0, GLOG_WARNING =
1, GLOG_ERROR =
2, GLOG_FATAL =
3,
-
NUM_SEVERITIES =
4;
这四个值并非随便定义的。它们这样设计，将有助于完成之前所说的日志包含输出问题。在将日志输出到文件的函数LogDestination::LogToAllLogfiles中
-
for (
int i = severity; i >=
0; --i)
-
LogDestination::MaybeLogToLogfile(i, timestamp, message, len);
-
}
这段简单的for循环，让日志输出到自己以及低于自己等级的日志文件中。
在现实使用中，我们往往会通过一个临时变量或者宏，来区分开发环境和线上环境。比如开发环境我们需要INFO级别的日志，而线上环境我们需要ERROR及其以上等级的日志。当我们测试完毕，准备上线前，我们不可能将输出INFO类型日志的语句删掉——因为可能很多、很分散且删除代码是不安全的。那么我们就需要使用一种手段让INFO和WARNING等级的日志失效。GLog是这么做的
-
#if GOOGLE_STRIP_LOG == 0
-
#define COMPACT_GOOGLE_LOG_INFO google::LogMessage( \
-
__FILE__, __LINE__)
-
#define LOG_TO_STRING_INFO(message) google::LogMessage( \
-
__FILE__, __LINE__, google::GLOG_INFO, message)
-
#else
-
#define COMPACT_GOOGLE_LOG_INFO google::NullStream()
-
#define LOG_TO_STRING_INFO(message) google::NullStream()
-
#endif
-
-
#if GOOGLE_STRIP_LOG <= 1
-
#define COMPACT_GOOGLE_LOG_WARNING google::LogMessage( \
-
__FILE__, __LINE__, google::GLOG_WARNING)
-
#define LOG_TO_STRING_WARNING(message) google::LogMessage( \
-
__FILE__, __LINE__, google::GLOG_WARNING, message)
-
#else
-
#define COMPACT_GOOGLE_LOG_WARNING google::NullStream()
-
#define LOG_TO_STRING_WARNING(message) google::NullStream()
-
#endif
-
-
#if GOOGLE_STRIP_LOG <= 2
-
#define COMPACT_GOOGLE_LOG_ERROR google::LogMessage( \
-
__FILE__, __LINE__, google::GLOG_ERROR)
-
#define LOG_TO_STRING_ERROR(message) google::LogMessage( \
-
__FILE__, __LINE__, google::GLOG_ERROR, message)
-
#else
-
#define COMPACT_GOOGLE_LOG_ERROR google::NullStream()
-
#define LOG_TO_STRING_ERROR(message) google::NullStream()
-
#endif
-
-
#if GOOGLE_STRIP_LOG <= 3
-
#define COMPACT_GOOGLE_LOG_FATAL google::LogMessageFatal( \
-
__FILE__, __LINE__)
-
#define LOG_TO_STRING_FATAL(message) google::LogMessage( \
-
__FILE__, __LINE__, google::GLOG_FATAL, message)
-
#else
-
#define COMPACT_GOOGLE_LOG_FATAL google::NullStreamFatal()
-
#define LOG_TO_STRING_FATAL(message) google::NullStreamFatal()
-
#endif
我们可以通过定义GOOGLE_STRIP_LOG的值，来控制相应宏的定义。比如我们给GOOGLE_STRIP_LOG赋值2，则COMPACT_GOOGLE_LOG_WARNING会被定义为google::NullStream()，从而不会进行输出。ERROR和FATAL都将定义为LogMessage的临时对象进行之后的业务逻辑。
以一个常用的LogMessage的构造函数来看临时对象的初始化
-
LogMessage::LogMessage(
const
char* file,
int line, LogSeverity severity)
-
: allocated_(
NULL) {
-
Init(file, line, severity, &LogMessage::SendToLog);
-
}
该函数中传入了执行语句所在的文件名和行号，这些我们都将在输出的日志中见到过。第三个参数是日志等级，即GLOG_INFO等值。Init传入的第四个参数是该类的一个成员函数地址。它才是我们关注的重点。
LogMessage::SendToLog函数主要执行的是下面这段代码
-
// log this message to all log files of severity <= severity_
-
LogDestination::LogToAllLogfiles(data_->severity_, data_->timestamp_,
-
data_->message_text_,
-
data_->num_chars_to_log_);
-
-
LogDestination::MaybeLogToStderr(data_->severity_, data_->message_text_,
-
data_->num_chars_to_log_);
-
LogDestination::MaybeLogToEmail(data_->severity_, data_->message_text_,
-
data_->num_chars_to_log_);
-
LogDestination::LogToSinks(data_->severity_,
-
data_->fullname_, data_->basename_,
-
data_->line_, &data_->tm_time_,
-
data_->message_text_ + data_->num_prefix_chars_,
-
(data_->num_chars_to_log_
-
- data_->num_prefix_chars_ -
1));
这段代码分别是：尝试向文件中输出、尝试向标准错误流中输出、尝试发送邮件、尝试向用户自定义池中输出。
尝试发送邮件的方式我们很少使用到，它实际是借用了linux系统上/bin/mail程序去发送邮件，所以对这块有兴趣的同学，可以主要关注下邮件内容的组装和发送命令的使用。
LogToAllLogfiles函数不仅具有向文件输出的能力，还有向标准错误流中输出的能力。
-
inline
void LogDestination::LogToAllLogfiles(LogSeverity severity,
-
time_t timestamp,
-
const
char* message,
-
size_t len) {
-
-
if ( FLAGS_logtostderr ) {
// global flag: never log to file
-
ColoredWriteToStderr(severity, message, len);
-
}
else {
-
for (
int i = severity; i >=
0; --i)
-
LogDestination::MaybeLogToLogfile(i, timestamp, message, len);
-
}
-
}
else中的for循环就是之前我们讲解的日志包含的实现。
MaybeLogToLogfile方法将让一个全局的LogDestination对象执行日志输出逻辑
-
inline
void LogDestination::MaybeLogToLogfile(LogSeverity severity,
-
time_t timestamp,
-
const
char* message,
-
size_t len) {
-
const
bool should_flush = severity > FLAGS_logbuflevel;
-
LogDestination* destination = log_destination(severity);
-
destination->logger_->Write(should_flush, timestamp, message, len);
-
}
log_destination方法将通过日志等级新建并返回或者获取一个保存在全局区域中LogDestination指针
-
LogDestination* LogDestination::log_destinations_[NUM_SEVERITIES];
-
-
inline LogDestination* LogDestination::log_destination(LogSeverity severity) {
-
assert(severity >=
0 && severity < NUM_SEVERITIES);
-
if (!log_destinations_[severity]) {
-
log_destinations_[severity] =
new LogDestination(severity,
NULL);
-
}
-
return log_destinations_[severity];
-
}
如此可见，我们的测试代码将新建四个LogDestination对象，并将指针保存在全局数组log_destinations_中。这四个指针分别对应于INFO、WARNING、ERROR和FATAL日志的输出目标对象。所以，不管在多线程还是在单线程环境中，我们日志输出都将调用到这四个对象指针。
LogDestination类有个用于实际输出日志的成员变量
-
LogFileObject fileobject_;
-
base::Logger* logger_;
// Either &fileobject_, or wrapper around it
Logger是个接口类，其暴露出来的方法都是纯虚。所以实际操作的是其继承类。LogFileObject继承于Logger接口，对于文件类型的输出，logger_指向fileobject_对象。
-
LogDestination::LogDestination(LogSeverity severity,
-
const
char* base_filename)
-
: fileobject_(severity, base_filename),
-
logger_(&fileobject_) {
-
}
LogFileObject的Write的实现非常简单，除了在文件不存在的情况下新建了日志文件，还有就是日志个格式化输出。它的整个逻辑是在锁内部完成的，这样可以保证多线程写操作是安全的。
我们分析完LogToAllLogfiles的实现，再探索下它是在何处被调用的。之前我们讲过LOG宏构建了一个LogMessage临时对象。这个临时对象的生命周期就是C++语句中其所在的那一行的执行周期。
-
LOG(ERROR) <<
"ERROR";
-
LOG(ERROR) <<
"ERROR1";
上述两行，就构建了两个LogMessage临时对象。第一行的临时对象在第二行执行之前就消亡了，第二行的临时对象在之后一行执行之前就消亡了。而对LogToAllLogfiles的调用就是在LogMessage的析构函数中（实际是Flush中）。
-
LogMessage::~LogMessage() {
-
Flush();
-
delete allocated_;
-
}
Flush中的核心代码是
-
{
-
MutexLock l(&log_mutex);
-
(
this->*(data_->send_method_))();
-
++num_messages_[
static_cast<
int>(data_->severity_)];
-
}
-
LogDestination::WaitForSinks(data_);
注意在调用send_method_所指向的函数（保存为文件时默认的就是LogToAllLogfiles方法）之前上了锁。这个锁非常必要，可以保证之后的操作是受到保护的。否则之前在全局区域保存LogDestination对象指针的逻辑就存在多线程访问的问题。
我们可以总结下，每条日志的输出都通过一个LogMessage临时对象的析构，传递到全局变量log_destinations_中相应等级对应的LogDestination指针所指向的对象。那么LogDestination对象又是在何时进行日志写入文件的呢？我们知道文件的Write方法并不一定马上把内容写入文件，而是存在一定的缓存中，再根据系统的判断或者用户主动调用fflush，将数据实际写入文件。LogFileObject提供了两个Flush方法
-
void LogFileObject::Flush() {
-
MutexLock l(&lock_);
-
FlushUnlocked();
-
}
-
-
void LogFileObject::FlushUnlocked(){
-
if (file_ !=
NULL) {
-
fflush(file_);
-
bytes_since_flush_ =
0;
-
}
-
// Figure out when we are due for another flush.
-
const int64 next = (FLAGS_logbufsecs
-
*
static_cast<int64>(
1000000));
// in usec
-
next_flush_time_ = CycleClock_Now() + UsecToCycles(next);
-
}
一个是通过锁保证多线程安全的版本，一个是不安全的版本。它们都是执行了fflush，并计算了下一次flush时间。在LogFileObject的Write方法末尾，通过该时间的判断，确定是否真的将缓存写入文件中。
-
// See important msgs *now*. Also, flush logs at least every 10^6 chars,
-
// or every "FLAGS_logbufsecs" seconds.
-
if ( force_flush ||
-
(bytes_since_flush_ >=
1000000) ||
-
(CycleClock_Now() >= next_flush_time_) ) {
-
FlushUnlocked();
-
#ifdef OS_LINUX
-
if (FLAGS_drop_log_memory) {
-
if (file_length_ >= logging::kPageSize) {
-
// don't evict the most recent page
-
uint32 len = file_length_ & ~(logging::kPageSize -
1);
-
posix_fadvise(fileno(file_),
0, len, POSIX_FADV_DONTNEED);
-
}
-
}
-
#endif
-
}
还有一种强制写入文件的方法，就是LogDestination::FlushLogFilesUnsafe和LogDestination::FlushLogFiles方法，它们的实现是
-
inline
void LogDestination::FlushLogFilesUnsafe(
int min_severity) {
-
// assume we have the log_mutex or we simply don't care
-
// about it
-
for (
int i = min_severity; i < NUM_SEVERITIES; i++) {
-
LogDestination*
log = log_destination(i);
-
if (
log !=
NULL) {
-
// Flush the base fileobject_ logger directly instead of going
-
// through any wrappers to reduce chance of deadlock.
-
log->fileobject_.FlushUnlocked();
-
}
-
}
-
}
-
-
inline
void LogDestination::FlushLogFiles(
int min_severity) {
-
// Prevent any subtle race conditions by wrapping a mutex lock around
-
// all this stuff.
-
MutexLock l(&log_mutex);
-
for (
int i = min_severity; i < NUM_SEVERITIES; i++) {
-
LogDestination*
log = log_destination(i);
-
if (
log !=
NULL) {
-
log->logger_->Flush();
-
}
-
}
-
}
使用者可以通过这两个函数人为主动的刷新缓冲区，让内容落地。
以上，我们讲解了GLog主要使用方法及其实现原理。实际GLog作为一个框架，也不失灵活性。
比如我们可以通过SetLogger方法修改不同等级的日志输出方法。
-
base::Logger* base::GetLogger(LogSeverity severity) {
-
MutexLock l(&log_mutex);
-
return LogDestination::log_destination(severity)->logger_;
-
}
-
-
void base::SetLogger(LogSeverity severity, base::Logger* logger) {
-
MutexLock l(&log_mutex);
-
LogDestination::log_destination(severity)->logger_ = logger;
-
}
下面代码是其使用的一个实例
-
struct MyLogger :
public base::Logger {
-
string data;
-
-
virtual void Write(bool /* should_flush */,
-
time_t
/* timestamp */,
-
const
char* message,
-
int length) {
-
data.append(message, length);
-
}
-
-
virtual void Flush() { }
-
-
virtual uint32 LogSize() {
return data.length(); }
-
};
-
-
static void TestWrapper() {
-
fprintf(
stderr,
"==== Test log wrapper\n");
-
-
MyLogger my_logger;
-
base::Logger* old_logger = base::GetLogger(GLOG_INFO);
-
base::SetLogger(GLOG_INFO, &my_logger);
-
LOG(INFO) <<
"Send to wrapped logger";
-
FlushLogFiles(GLOG_INFO);
-
base::SetLogger(GLOG_INFO, old_logger);
-
-
CHECK(
strstr(my_logger.data.c_str(),
"Send to wrapped logger") !=
NULL);
-
}
我们还可以使用AddLogSink和RemoveLogSink方法自定义处理日志的逻辑。AddLogSink最终会调用到
-
inline
void LogDestination::AddLogSink(LogSink *destination) {
-
// Prevent any subtle race conditions by wrapping a mutex lock around
-
// all this stuff.
-
MutexLock l(&sink_mutex_);
-
if (!sinks_) sinks_ =
new
vector<LogSink*>;
-
sinks_->push_back(destination);
-
}
其中sinks_是全局vector指针。它是独立于之前介绍的log_destinations_数组管理的日志输出方式。
-
// arbitrary global logging destinations.
-
static
vector<LogSink*>* sinks_;
最终它会在SendToLog方法中的LogToSinks中被调用。
-
inline
void LogDestination::LogToSinks(LogSeverity severity,
-
const
char *full_filename,
-
const
char *base_filename,
-
int line,
-
const struct ::tm* tm_time,
-
const
char* message,
-
size_t message_len) {
-
ReaderMutexLock l(&sink_mutex_);
-
if (sinks_) {
-
for (
int i = sinks_->size() -
1; i >=
0; i--) {
-
(*sinks_)[i]->send(severity, full_filename, base_filename,
-
line, tm_time, message, message_len);
-
}
-
}
-
}
作为使用者，我们需要定义send方法，并根据日志等级的不同，处理不同的逻辑。下面是GLog测试代码中的一个例子
-
virtual void send(LogSeverity severity, const char* /* full_filename */,
-
const
char* base_filename,
int line,
-
const struct tm* tm_time,
-
const
char* message,
size_t message_len) {
-
// Push it to Writer thread if we are the original logging thread.
-
// Note: Something like ThreadLocalLogSink is a better choice
-
// to do thread-specific LogSink logic for real.
-
if (pthread_equal(tid_, pthread_self())) {
-
writer_.Buffer(ToString(severity, base_filename, line,
-
tm_time, message, message_len));
-
}
-
}
最后介绍LOG_TO_SINK和LOG_TO_SINK_BUT_NOT_TO_LOGFILE宏，它是设置单个Sink的方式（AddLogSink是设置一个到多个sink的方式）
-
#define LOG_TO_SINK(sink, severity) \
-
google::LogMessage( \
-
__FILE__, __LINE__, \
-
google::GLOG_ ## severity, \
-
static_cast<google::LogSink*>(sink), true).stream()
-
#define LOG_TO_SINK_BUT_NOT_TO_LOGFILE(sink, severity) \
-
google::LogMessage( \
-
__FILE__, __LINE__, \
-
google::GLOG_ ## severity, \
-
static_cast<google::LogSink*>(sink), false).stream()
它调用的是5个参数版本的LogMessage构造函数
-
LogMessage::LogMessage(
const
char* file,
int line, LogSeverity severity,
-
LogSink* sink,
bool also_send_to_log)
-
: allocated_(
NULL) {
-
Init(file, line, severity, also_send_to_log ? &LogMessage::SendToSinkAndLog :
-
&LogMessage::SendToSink);
-
data_->sink_ = sink;
// override Init()'s setting to NULL
-
}
构造函数中true或false标识是否需要调用之前分析过的SendToLog()方法，还是只是调用SendToSink方法
-
void LogMessage::SendToSink() EXCLUSIVE_LOCKS_REQUIRED(log_mutex) {
-
if (data_->sink_ !=
NULL) {
-
RAW_DCHECK(data_->num_chars_to_log_ >
0 &&
-
data_->message_text_[data_->num_chars_to_log_
-1] ==
'\n',
"");
-
data_->sink_->send(data_->severity_, data_->fullname_, data_->basename_,
-
data_->line_, &data_->tm_time_,
-
data_->message_text_ + data_->num_prefix_chars_,
-
(data_->num_chars_to_log_ -
-
data_->num_prefix_chars_ -
1));
-
}
-
}
至此，我们便将Glog的实现原理分析完毕了。
在阅读代码和实验其使用过程中，可以发现GLog是一个非常优秀的日志开源库。但是如果想让GLog灵活的应用于产品中，其实还有很多事情可以做。比如我们可以将参数放到配置文件中，这样不至于我们每次修改参数时要重新编译代码。再比如我们可以定制自己的Sink，将日志数据发送到指定机器。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
