日志整改方案

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的。

方法：无解，慢慢改吧。