日志用什么做存储会比较好?

2011-09-26 21:33:33 +08:00
 ayanamist
一个应用系统的日志采用什么作为存储引擎比较好?
纯文本的方式无论是阅读还是查找都很不方便。
使用MySQL数据库等又怕性能影响……
7686 次点击
所在节点    问与答
24 条回复
Livid
2011-09-26 21:40:25 +08:00
可以试试用 Splunk 来索引和搜索日志(不过这个东西相当耗资源):

http://www.splunk.com/
zhuang
2011-09-26 21:44:10 +08:00
如果怕 MySQL 影响性能的话,配置一个单独的远程数据库作为 log 存储引擎吧。
我自己的经验,*nix 还是纯文本作为数据记录比较方便,配合脚本处理更灵活。
只是需要特定的人来维护吧,或者详细做文档,不然交给其他人做的时候很容易乱套……
另外大部分轻量化的日志程序似乎都是这个思路,纯文本记录加一个整合的处理前端,内部是类似脚本的实现。
hooopo
2011-09-26 21:45:59 +08:00
按照unix哲学,纯文本的阅读和查找都方便。
ssword
2011-09-26 21:47:29 +08:00
纯文本吧,查找用ack,肉眼监控用tail -f
ayanamist
2011-09-26 22:06:08 +08:00
@ssword @hooopo @zhuang @Livid 谢谢各位,纯文本的主要弊端是如果单个日志项目超过多行,在程序中就比较难进行区分了。尤其是在记录了traceback(多行数据)以及堆栈的一部分值的时候。所以才考虑数据库……关于这个,纯文本有什么好办法吗?
另外如果要用数据库的话,用什么数据库会比较好?
summic
2011-09-26 22:09:30 +08:00
首选mongodb,搜索 mysql archive 得到livid的一篇blog,美用过archive引擎,不好说
ayanamist
2011-09-26 22:24:37 +08:00
@summic MongoDB吃内存和占用磁盘都太厉害了,上MongoDB的话,估计日志服务器会比应用服务器配置还要高……
ratazzi
2011-09-26 22:36:19 +08:00
MongoDB 的 Capped Collection 就是专门存日志、缓存之类的
ayanamist
2011-09-26 22:39:21 +08:00
@ratazzi 内存和磁盘文件占用还是一样可怕吧。麻烦你回帖前先看下之前的回帖
ratazzi
2011-09-26 22:49:32 +08:00
@ayanamist 光是写入,性能不会差的,现在磁盘白菜价了,而且 capped collection 是预分配空间固定大小的,不会出现 log 撑爆磁盘的情况
summic
2011-09-26 22:51:31 +08:00
@ayanamist 优势是检索、查询比较方便,毕竟没用过,没有实际经验
zhuang
2011-09-27 03:00:21 +08:00
@ayanamist
我刚才想了个纯文本的解决方案,不知道能不能帮上忙。
一个文件 log 记录原始文本,一个文件 index 记录 event id 和 line number 的映射。event id 形式不确定,可以是自增或者任意的 unique id 吧。
这样记录日志的同时,同时记录一个对应行。算是模拟了个数据库……
好处是实现起来比较简单,占用资源比较少,同时可以利用纯文本的优势。
坏处是某些情形下需要改动,比如日志定期分割,分卷查找之类的,不过这些都是一次性的开发。
ayanamist
2011-09-27 09:59:06 +08:00
@summic @ratazzi 我不担心MongoDB的性能,而是担心由于这种基于内存映射原理的NoSQL,加上log的高速写入,于是需要给日志机更大更多的内存,甚至超过应用服务器本身。
@zhuang 你这个方案很好呀~让我想起Windows的日志系统了。我去研究下Windows日志系统是怎么弄的。话说Windows哪有那么不堪,注册表机制和日志系统比*nix下优秀很多。
Platinum
2011-09-27 10:17:41 +08:00
取决于你的系统的复杂程度

比方说 log 很少,一年也就上百 MB,那就直接存 MySQL 了

如果量大、对实时性要求不高,可以先统统存到文本里,再下载到本地机器上做各种复杂分析。曾经做的一套系统是需要从各种服务器上下载几十 G apache log,再在本地分析约 20小时,所以永远只能看到前天的数据,但实时性要求不高是因为那是个广告联盟,结算的时候查作弊的。

另外建议熟悉各种 GNU 工具,帮助你更好的做决定,诸如 awk sed grep wc 管道 cronolog gzip sort
fanxuan
2011-09-27 11:20:34 +08:00
我们公司的习惯都是直接写文件,然后通过gawk,python来进行统计入库。。
ratazzi
2011-09-27 12:15:11 +08:00
@ayanamist 这一点我觉得你大可不必担心,你的日志每分钟的数据量还不至于那么大吧
ayanamist
2011-09-27 13:17:46 +08:00
@ratazzi 但是时间长了就不好说了啊,日志长期占用着内存……而且对MongoDB的配套工具也很匮乏……
我想了想,还是决定采纳上面几位纯文本同学的建议,不过用XML把日志wrap起来,应该各方面都要好一些
summic
2011-09-27 13:35:47 +08:00
@ayanamist xml不必要吧?会占用更多空间
napoleonu
2011-09-27 13:43:09 +08:00
Infobright 不知道怎么样,嘿嘿。
ratazzi
2011-09-27 13:54:57 +08:00
@ayanamist 日志长期占用着内存,难道日志也加了很多索引?MongoDB 内存里的主要内容是索引啊

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/18644

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX