GLog是Google开发的一套日志输出框架。由于其具有功能强大、方便使用等特性，它被众多开源项目使用。本文将通过分析其源码，解析Glog实现的过程。
该框架的源码在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灵活的应用于产品中，其实还有很多事情可以做。比如我们可以将参数放到配置文件中，这样不至于我们每次修改参数时要重新编译代码。