1
Livid MOD |
2
zhuang 2011-09-26 21:44:10 +08:00
如果怕 MySQL 影响性能的话,配置一个单独的远程数据库作为 log 存储引擎吧。
我自己的经验,*nix 还是纯文本作为数据记录比较方便,配合脚本处理更灵活。 只是需要特定的人来维护吧,或者详细做文档,不然交给其他人做的时候很容易乱套…… 另外大部分轻量化的日志程序似乎都是这个思路,纯文本记录加一个整合的处理前端,内部是类似脚本的实现。 |
3
hooopo 2011-09-26 21:45:59 +08:00
按照unix哲学,纯文本的阅读和查找都方便。
|
4
ssword 2011-09-26 21:47:29 +08:00 1
纯文本吧,查找用ack,肉眼监控用tail -f
|
5
ayanamist OP |
6
summic 2011-09-26 22:09:30 +08:00
首选mongodb,搜索 mysql archive 得到livid的一篇blog,美用过archive引擎,不好说
|
7
ayanamist OP @summic MongoDB吃内存和占用磁盘都太厉害了,上MongoDB的话,估计日志服务器会比应用服务器配置还要高……
|
8
ratazzi 2011-09-26 22:36:19 +08:00
MongoDB 的 Capped Collection 就是专门存日志、缓存之类的
|
10
ratazzi 2011-09-26 22:49:32 +08:00
@ayanamist 光是写入,性能不会差的,现在磁盘白菜价了,而且 capped collection 是预分配空间固定大小的,不会出现 log 撑爆磁盘的情况
|
12
zhuang 2011-09-27 03:00:21 +08:00
@ayanamist
我刚才想了个纯文本的解决方案,不知道能不能帮上忙。 一个文件 log 记录原始文本,一个文件 index 记录 event id 和 line number 的映射。event id 形式不确定,可以是自增或者任意的 unique id 吧。 这样记录日志的同时,同时记录一个对应行。算是模拟了个数据库…… 好处是实现起来比较简单,占用资源比较少,同时可以利用纯文本的优势。 坏处是某些情形下需要改动,比如日志定期分割,分卷查找之类的,不过这些都是一次性的开发。 |
13
ayanamist OP |
14
Platinum 2011-09-27 10:17:41 +08:00
取决于你的系统的复杂程度
比方说 log 很少,一年也就上百 MB,那就直接存 MySQL 了 如果量大、对实时性要求不高,可以先统统存到文本里,再下载到本地机器上做各种复杂分析。曾经做的一套系统是需要从各种服务器上下载几十 G apache log,再在本地分析约 20小时,所以永远只能看到前天的数据,但实时性要求不高是因为那是个广告联盟,结算的时候查作弊的。 另外建议熟悉各种 GNU 工具,帮助你更好的做决定,诸如 awk sed grep wc 管道 cronolog gzip sort |
15
fanxuan 2011-09-27 11:20:34 +08:00
我们公司的习惯都是直接写文件,然后通过gawk,python来进行统计入库。。
|
17
ayanamist OP @ratazzi 但是时间长了就不好说了啊,日志长期占用着内存……而且对MongoDB的配套工具也很匮乏……
我想了想,还是决定采纳上面几位纯文本同学的建议,不过用XML把日志wrap起来,应该各方面都要好一些 |
19
napoleonu 2011-09-27 13:43:09 +08:00
Infobright 不知道怎么样,嘿嘿。
|
21
ayanamist OP |
22
ratazzi 2011-09-27 16:29:59 +08:00
@ayanamist
内存里当然不光是索引,我简单测试了下 i3 2G ubuntu x86_64 一千万数据插入 7 分钟左右,最快的一次 3 分钟,内存最高只占到 14%,并且写入过程及写入完成以后都会有变化,不过 cpu 占用有点高,不知道是不是我用 wubi 装的原因 如果你有想存数据库的想法的话,还是自己测下比较准确 按照以前的使用来看 1.6.3 以前确实是有多少内存就使用多少,但是 1.8 以后不会 |
23
ayanamist OP @ratazzi 原来后来变化了,我是1.6的时候在Gentoo下测试的,当时的内存占用把我着实吓坏了……thx,会进一步做可行性分析~
|
24
ayanamist OP 现在在阿里做内部的日志系统,回头看这个帖子,真是有些感慨。
高写低读可以用HBase,多行的问题可以用正则匹配贪婪模式。 |