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的。
方法:无解,慢慢改吧。