Posted on 2008-07-18 10:03
Fox 阅读(2050)
评论(8) 编辑 收藏 引用 所属分类:
T技术碎语
一个好的日志系统，除了可以记录尽可能多的必要信息，方便trace bugs、提供data analysis source这些基本功能之外，其他的貌似不必太在意。但真正当bugs冒出来的时候，要命的是既没有dump，也没有有价值的日志，更要命的是日志居然已经记录了那么多，居然让你查了半天，居然都是没有价值的！
悲剧啊！
日志需要记录的信息大概分为两类：
1) 系统运行情况：启动、加载、读写、关闭、异常；
2) 用户使用情况：进入、操作、离开、异常。
我可以想到的关于日志系统的要求大致以下几点：
1) 日志系统使用目录树结构：系统日志和用户日志分别记录，正常日志和异常日志分别记录，不置于同一文件夹下，日志文件命名做到令观者一目了然；
2) 记录详尽但不冗余：正确记录日志时间、位置、事件、因果，有可能的话，记录上下文（这要求有点高了）；
3) 格式统一但严禁千篇一律：格式统一是指记录内容遵循一定格式，方便查看，严禁千篇一律是指记录要有层次、轻重，不同事件导致的“同一”异常日志不应不加区别，同样是为了方便查看；
4) 与异常处理相辅相成：有dump时，以日志辅助快速定位，没有dump时，日志应尽可能提供有效信息，离系统崩溃的地方越近越好（这一点似乎也有难度）。
________________________________________________
突然想到的，也还没有动手去做，先记下了，欢迎补充。
_____Added on Jul.25th, 2008_______________________
还看到一位兄弟在为我说话，谢谢！
今天在考虑实现时，想到一个很现实的问题，日志几乎是无处不在的，随时随地会有日志记录。不知道有谁对I/O（当然主要是Output）消耗和对系统的影响做过专门测试，猜测就算了:-)，我很想知道有没有必要放到专门的线程中，如果放到独立线程中的话，问题就出来了，多长时间写一次？毕竟，记录日志的主要目的就是为了全面记录系统运行和用户使用情况，如果在服务器crash的时候，还有日志（尤其是crash上下文日志）没有被顺利写入，日志的意义也就大打折扣。
谁给点建议？