我的看法是：
日志一定要能够起到提供切实有效的信息的作用。
如果作为原有产品开发维护人员，
只要客户给你打个电话，报一下日志中的错误、警告号码或信息，你立即就可以知道具体哪个模块的哪个函数出错了，这是最好的。
没有产品是完美的，一个可以很快定位错误便于修正的产品是一个相对理想的选择。
那种产品卖出去就拉倒了，bug定位很慢，更新补丁不及时的公司，客户在暗叹倒霉的同时，会很生气的，后果会很严重！
我的建议是这样：
例如A模块调用B模块，B模块调用C模块
A模块中日志信息输出格式(假定为log级别，而不是error或fatal级别)：
log_A_001
log_A_002
log_A_003
...
B模块中日志信息输出格式：
log_B_001
log_B_002
log_B_003
...
C模块中日志信息输出格式：
log_C_001
log_C_002
log_C_003
...
这样，任何时候，看日志，就可以知道系统里出现了什么问题，可以精确定位到函数级别。
但是，对于公用模块，还需要考虑，是谁调用了它。
由A调用了D 还是 由B调用了D？这种问题怎么办？
可以考虑这样输出：log_D_begin_called by A 或者 log_D_begin_called by B。 换句话说：把调用者的名字传入进来。
如果使用面向对象的程序设计语言，也可以考虑传入调用者的类名称。
还有很重要的一点，那就是：大量输出日志，会导致系统负担很重。
应该允许通过设定文件等进行配置：可以指定专门针对某些模块来特殊输出详细的日志，而其它模块则输出少量的概要性的日志。
如果有可能，日志系统最好可以独立于整个应用，最好可以实现网络写日志方式，以缓解对系统造成的压力。