1. 日志系统搭配配置系统使用
1.1 改动：LogManager:getLogger(name)函数
目的：当寻找的name:Logger不存在时，直接返回LogManager::Logger::ptr m_root默认的日志器(智能指针)。改动后要实现寻找不存在的日志器时候会自动创建。
原来的写法： ```cpp Logger::ptr LogManager::getLogger(const std::string &name) { auto it = s_loggers.find(name);
//注意：当指定一个name之后找不到对应的Logger 返回的是默认的日志器 return it == s_loggers.end() ? m_root : it->second;
}
- **改动1：**```cppLogger::ptr LogManager::getLogger(const std::string &name){//改动:auto it = s_loggers.find(name);if(it != s_loggers.end())return it->second;Logger::ptr logger(new Logger(name));//为其默认分配一个 输出到控制台的 日志输出器logger->addAppender(LogAppender::ptr(new StdoutLogAppender));s_loggers[name] = logger;return logger;}
改动2： ```cpp class Logger { … private: … //默认日志器的智能指针 Logger::ptr default_root;
…
};
Logger::ptr LogManager::getLogger(const std::string &name) { //改动: auto it = s_loggers.find(name); if(it != s_loggers.end()) return it->second;
Logger::ptr logger(new Logger(name));s_loggers[name] = logger;//借用LogManager中的默认日志器，为的是有LogAppender可以使用logger->default_root = m_root;return logger;
}
用意：改动2是注意到原本`LogManager`中就有一个创建好的默认日志器的实体，日志输出器也为其默认配备`StdoutLogAppender`控制台的输出。在没有特别指明需要将新创建的日志输出到特定的地方时候，可以考虑直接借用这个默认的日志器，避免每一次不确定输出到哪时，就盲目的创建一个日志输出器`LogAppender`浪费一部分内存。<br /><a name="xzyKB"></a>### 1.1.1 最终解决的问题：假设：名为"system"的Logger日志器不存在<br />` auto temp = KIT_LOG_NAME("system");`<br />`#define KIT_LOG_NAME(name) kit_server::LoggerMgr::GetInstance().getLogger(name)`**原本**：`getLogger("ststem")`--->得到的是 `LogManager::Logger::ptr m_root`一个默认的日志器<br />**改动**：`getLogger("ststem")`--->创建一个名为 "system"的`Logger`返回出来。但是并没有给该Logger分配对应的日志输出器`LoggerAppender`，于是就是先借用原本默认的日志器`Logmanager::m_root`来完成日志输出。直到给`Logger("system")`重新定义了新的输出器，比如`FileLogAppender`输出到文件，就不会再借用默认日志器。<br /><a name="AZ8IB"></a>## 1.2 定义从.yaml接收配置项的自定义结构体，并进行偏特化**来自**`**Log.cpp**`**文件中**- **定义**`**LogDefine**`**和**`**LogAppenderDefine**`**两个自定义类型分别用于存储**`**Logger**`**的配置和**`**LogAppender**`**的配置。定义如下：**```cppstruct LogAppenderDefine{//0：StdOut 1:Fileint type = -1;LogLevel::Level level = LogLevel::UNKNOW;std::string formatter;std::string file;bool operator==(const LogAppenderDefine& d) const{return type == d.type && level == d.level &&formatter == d.formatter && file == d.file;}};struct LogDefine{std::string name;LogLevel::Level level = LogLevel::UNKNOW;std::string formatter;std::vector<LogAppenderDefine> appenders;bool operator==(const LogDefine& d) const{return name == d.name && level == d.level &&formatter == d.formatter && appenders == d.appenders;}bool operator<(const LogDefine& d) const{return name < d.name;}};
注意：由于LogAppenderDefine在LogDefine中是用vector存储，需要重载operator==用于比较；在LogDefine中重载operator<是因为：ConfigVar<std::set<LogDefine> >使用set容器作为存储容器红黑树有排序、去重。
偏特化如下，方法和配置开发（二）中一样的，参考即可： ```cpp //自定义类型偏特化 string————->LogAppenderDefine 序列化 template<> class LexicalCast
LogAppenderDefine operator()(const std::string &val) {
LogAppenderDefine p;YAML::Node node = YAML::Load(val);std::string str = node["type"].as<std::string>();if(str == "FileLogAppender")p.type = 1;else if(str == "StdoutLogAppender")p.type = 0;elsep.type = -1;
p.level = LogLevel::FromString(node["level"].as<std::string>());p.formatter = node["formatte"].as<std::string>();p.file = node["file"].as<std::string>();return p;}
};
//自定义类型偏特化 LogAppenderDefine————->string 反序列化
template<>
class LexicalCast
node["type"] = str;node["level"] = LogLevel::ToString(p.level);node["formatter"] = p.formatter;node["file"] = p.file;std::stringstream ss;ss << node;return ss.str();}
};
//自定义类型偏特化 string————->LogDefine 序列化
template< >
class LexicalCast
LogDefine operator()(const std::string &val){LogDefine d;YAML::Node node = YAML::Load(val);d.name = node["name"].as<std::string>();d.level = LogLevel::FromString(node["level"].as<std::string>());d.formatter = node["formatter"].as<std::string>();auto t = node["appender"][0];for(size_t i = 0;i < node["appender"].size();++i){std::stringstream ss;ss << node["appender"][i];d.appenders.push_back(LexicalCast<std::string, LogAppenderDefine>()(ss.str()));}return d;}
};
//自定义类型偏特化 LogDefine————->string 反序列化
template<>
class LexicalCast
node["name"] = p.name;node["level"] = LogLevel::ToString(p.level);node["formatter"] = p.formatter;for(size_t i = 0;i < p.appenders.size();++i){node["appender"].push_back(LexicalCast<LogAppenderDefine, std::string>()(p.appenders[i]));}std::stringstream ss;ss << node;return ss.str();}
};
<a name="EdZVN"></a>### 1.2.1 BUG:错误的类型转换，简单将枚举类型当做int型处理（注意：模板错误提示非常隐晦，很难找出真正错误的地方，要谨慎）<br />原因：虽然`LogLevel::Level`作为枚举类型，内部元素是int型。但是在进行`.yaml`序列化和反序列化的过程中，错误的将其作为int型处理，实际上应该是`string`和`int`之间的相互转换。<a name="mtOix"></a>#### 1.2.1.1 问题代码：<br /><br />显然，从序列化代码过程能够看到：从`.yaml`文件读入的应该是一个字符串`string`但是却直接转化为`LogLevel::Level`明显不对，`yaml-cpp`内部不会支持这种转换。<a name="UnizR"></a>#### 1.2.1.2 修改代码：（多加一层`LogLevel::Level`与`string`之间的相互转换）- **小技巧：使用宏替换简化代码量：**```cppconst char* LogLevel::ToString(LogLevel::Level level){switch(level){#define XX(name)\case LogLevel::name:\return #name;\break;XX(DEBUG);XX(INFO);XX(WARN);XX(FATAL);XX(ERROR);#undef XX //用完一个宏XX 希望下面的代码不再使用到它default:return "UNKNOW";}return "UNKNOW";}LogLevel::Level LogLevel::FromString(const std::string& val){#define XX(name)\if(#name == val)\{\return LogLevel::name;\}XX(DEBUG);XX(INFO);XX(WARN);XX(FATAL);XX(ERROR);#undef XXreturn LogLevel::UNKNOW;}
1.2.1.3 编译结果：通过
1.2.2 BUG:配置系统+日志系统联调时，出现段错误
- 使用gdb调试，现象如下：
- 使用
**where**命令进一步定位出错位置，现象如下：
- 其他提示地点出现在库函数文件中，红框标识出来的是自己写的代码的问题地点，点击追踪后，跳到了一个不知道为啥出现的地方：
Config.h:494
1.2.2.1 问题解决：静态变量初始化的问题：未初始化却被先调用
冷知识：静态变量的构建在程序进入到main()之前，并且静态变量构建的顺序是不确定的，因此造成段错误的原因很可能就是需要使用的静态变量m_datas还未被构建，就先被Config::LookUp()函数所使用造成的段错误问题。
- 原本代码：（静态变量
Config::m_datas初始化在config.cpp中）
- 修改后代码：将其改为返回静态变引用的函数，每次请求即使还没初始化，也会在函数里初始化后再返回，杜绝了未初始化先调用的情形
1.3 约定日志系统的配置，利用静态全局变量初始化
1.3.1 约定针对日志系统配置的配置项ConfigVar<std::set<LogDefine> >::ptr
1.3.2 定义全局静态变量static LogIniter __log_init (核心)
在LogIniter结构体的构造函数中完成初始化工作：
① 利用之前的配置系统事件机制，定义一个回调函数(lambda表达式)：key值=0x123456。一旦发生
与”logs”有关的修改，就会触发该函数的调用。
② 回调函数中针对三种情况作出修改：新增日志器、对原有日志器修改、删除原有日志器
③”删除”日志器，并非真的将其内存空间立马释放，而是将其日志级别设置为足够大，且清空日志器
中所有的输出器，让其不再能够被输出则认为完成”删除”。目的：防止频繁的创建和销毁，将原有资
源保留一段时间。
1.3.2.1 改动 viod addListener(uint64_t key, on_change_cb cb)—>uint64_t addListener(on_change_cb cb)
在函数内部定义一个static静态变量，采用累加的方式来给回调函数赋key值。避免了原本手动传入key值会有重复传入而导致回调函数间的相互覆盖。
kit_server::ConfigVar<std::set<LogDefine> >::ptr g_log_defines =kit_server::Config::LookUp("logs", std::set<LogDefine>(), "logs configs");//冷知识:全局变量在main函数之前构建struct LogIniter{LogIniter(){//设置好 key值="logs"的配置项的触发事件，一旦从.yaml文件读到"logs"相关配置就会进入到该lambda函数中来g_log_defines->addListener([](const std::set<LogDefine> &old_value, const std::set<LogDefine> &new_value){/* 1.有新增日志* 2.有旧日志修改* 3.有旧日志删除*/KIT_LOG_INFO(KIT_LOG_ROOT()) << "logger configs changed!";for(auto &x : new_value){auto it = old_value.find(x);Logger::ptr logger;if(it == old_value.end()) //新增日志器{//新创建一个日志器并以.yaml中读取的名字命名//logger.reset(new kit_server::Logger(x.name));logger = KIT_LOG_NAME(x.name);}else //修改日志器 旧的日志器存在 新的日志器也存在{//判断一下内容是否发生变化if(!(x == *it)) //有变化{logger = KIT_LOG_NAME(x.name);}else //无变化continue;}//设定日志级别logger->setLevel(x.level);//设定日志格式if(x.formatter.size()){logger->setFormatter(x.formatter);}//清空原有的日志输出器 重新根据.yaml文件设置输出器logger->clearAppender();for(auto &k : x.appenders){LogAppender::ptr p;if(k.type == 0) //输出到控制台{p.reset(new StdoutLogAppender);}else if(k.type == 1) //输出到文件{p.reset(new FileLogAppender(k.file));}//设置输出器级别p->setLevel(k.level);//设置输出器格式if(k.formatter.size()){//只有在文件中手动设置过的才展示//从Logger继承过来的不展示LogFormatter::ptr f(new LogFormatter(k.formatter));//如果配置的formatter不合法也不能进行初始化 那么就会继续使用Logger的formatterif(!f->isError()){p->setIsFormatter();p->setFormatter(f);}elsestd::cout << "[ERROR]: " << "yaml Logger name= "<< logger->getName() << " include LogAppender name= " <<k.name << " formatter= " << k.formatter << " is invaild" << std::endl;}//添加到日志器的输出队列中 会将Logger的formatter也默认给LogAppenderlogger->addAppender(p);}}//老日志器存在而新日志器没有//删除不是真的将空间释放，打一个标记或者使用别的方法让其不再写日志//不真正删除的理由:防止添加回来又要重新创建，开销大for(auto &x : old_value){auto it = new_value.find(x);if(it == new_value.end()){auto t_logger = KIT_LOG_NAME(x.name);t_logger->setLevel((LogLevel::Level)100);t_logger->clearAppender();}}});}};static LogIniter __log_init;
1.3.3 小改动：希望LogAppender在没有进行配置时不输出没配置的配置信息
现象：当我们在.yaml文件配置StdoutLogAppender这一个输出器时，只写了相关的type，没有写level、formatter等信息，但是打印时候依旧打印了。
目的：希望不是我们自己配置的formatter不要出现在打印中，在我们没有手动配置时候，LogAppender会默认使用Logger的一些配置，以实现正常输出。
- 改动代码：
在类LogAppender中添加一个标志位LogAppender::is_set_formatter，用于标识当前的
LogFormatter::ptr指向的内容是否是通过文件配置完成的。如果是，则可以打印；否则不打印。
LogAppender类中：
**LogIniter()**构造函数中：
1.4 改动：日志输出文件路径使用相对路径即可
原因：输出绝对路径比较暴露一部分隐私，这个和CMake的设置有关系。CMake默认输出文件绝对路径。
2.配置系统考虑线程安全
实现目标：保证线程安全前提下，尽量对减少性能损失，采用读写锁RWMutex作为配置系统的安全保障。因为对于系统的配置项来说，大多数时候是”约定”即不改动，改动的时候偏少。因此符合，读多写少的场景。
若有收获，就点个赞吧
0 人点赞
