1 日志整改方案
1.1 日志信息不完整，无法支撑定位
1.1.1 问题描述
如果，如果失败，无法支撑业务定位
1.1.2 解决方案
一、类图设计
如上类图设计，业务类继承ClassLogMessage类。
类中有两个关键属性：
BaseLogMessage classLogMessage;// 表示类相关的日志信息，生命周期与类对象相同。
BaseLogMessage functionLogMessage; // 表示函数相关的日志信息，class里的这个变量，只是用于语法编译通过，这个属性打印出的字符串一直未空。
函数中的日志操作用宏处理，日志信息用局部变量保存，随函数结束释放。
具体的函数名，已经自注释了。
二、调用顺序
1、打印日志携带类信息调用顺序
在这个类获取到一个关键类属性的时候，调用AppendClassLogMessage方法，添加相关的日志信息。
需要打印信息时，调用SUPER_LOG_INFO宏打印数据。
2、打印日志携带函数信息调用顺序
在这个函数初始化时调用INIT_FUNCTION_LOG_MESSAGE，构造一个函数日志信息对象。
获取到一个关键类属性的时候，调用ADD_FUNCTION_LOG_MESSAGE，添加相关的日志信息。
需要打印信息时，调用SUPER_LOG_INFO宏打印数据。
1.2 日志过多
一、删除只有在第一次开发时才需要的日志。
二、默认不开启DEBUG日志
三、关键备查日志另外记录文件。
操作方式：
【VCM项目CPP代码基础能力提升】6、写日志工具及RollingFileWriter
http://3ms.huawei.com/km/blogs/details/7558497?l=zh-cn
四、无用日志降级为DEBUG，需要针对性打印的时候，使用DEBUG日志按需开启功能
操作方式：
【VCM项目CPP代码基础能力提升】2、按需开启DEBUG能力
http://3ms.huawei.com/km/blogs/details/7557699?l=zh-cn
1.3 高性能场景下的日志处理
当前采用了几分钟后自动关闭INFO日志的方法，这个方案对调试和定位历史问题不友好。
这个本质上是个流控问题，可以设置每秒允许打印INFO日志的条数上限为N，达到上限后，停止打印INFO日志。这样可以兼顾性能和历史问题定位。
实现也简单，秒定时器复位：
g_allowInfoNum=N
写日志时加个判断：
LOG(msg){
g_allowInfoNum—
if(g_allowInfoNum==1){
log(“info log limit”);
return;
}
if(g_allowInfoNum<1){
return;
}
log(msg);
}
1.4 日志格式不统一
如果使用了SUPER_LOG_INFO宏，把类信息统一打印了，应该也可以解决格式不统一的问题。
1.5 没按规范写的日志
问题：微云这边主要是debug日志打的太多了 有用的信息不多 而且很多error日志又不是错误的，是没关系的 还有些没有用标准的框架输出日志的，用的printf的。
方法：无解，慢慢改吧。