这是一个创建于 3432 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在要做到每天处理亿级的日志文件,公司根本没有现成的系统.日志是由nginx打下的请求日志,要在日志中筛选需要的信息,有些还是加密的请求,需要解密.
我当时用python 搭建起一套系统,一天可以处理完,但是随着数据的增加,我为了提高查询数据库的速度,将一些内容放到了内存中,但是随着数据的增加,内存已经爆掉.
mongo,多维数组什么的都已经尝试过了,已经无能为力了,我刚刚毕业,没有那么多的经验,手中只有两台服务器可用,而且内存一个4G,一个1G,cpu最多的一个也才是双核的.
请教该怎么搞?
 |
1
xujif 2015-06-30 18:10:30 +08:00
内存问题，只能队列处理啊，一次处理一部分，如果处理不及，只能加机器或者cpu
|
 |
2
repus911 2015-06-30 18:10:34 +08:00
这是服务器么 估计还没我的本本配置好
|
 |
3
whnzy OP @xujif 我已经用了队列了,因为要进行数据挖掘,所以存储结构复杂.每次存库要查询mysql,导致速度越来越慢,所以我将信息存到了内存中.现在内存不够用了哦
|
 |
5
nullcc 2015-06-30 18:15:48 +08:00
elasticsearch+logstash+kibana
|
 |
6
zhicheng 2015-06-30 18:17:35 +08:00
都用 AWS 了，还有什么解决不了的。开 spot instance 超大内存多核的机器，一个小时跑满不就好了。这个量级上，不是应该用人去解决的。
|
 |
7
omi4399 2015-06-30 18:18:32 +08:00
买买买买买，花钱就能解决的问题
|
|
9
whnzy OP 烦烦烦死
|
 |
10
julypanda 2015-06-30 18:42:29 +08:00
splunk
|
 |
11
xdeng 2015-06-30 18:55:19 +08:00
golang
|
 |
14
jason52 2015-06-30 19:02:12 +08:00 via Android
莫非是渣浪～知乎有个开发2g怎么玩的问题
|
 |
15
em70 2015-06-30 19:09:09 +08:00 via Android
awk 专注处理日志文件三十年
|
 |
16
20150517 2015-06-30 19:10:00 +08:00 via Android
弄个hive不就好了？
|
 |
21
kaneg 2015-06-30 19:33:13 +08:00 via iPhone
想要马儿跑得快，还要马儿不吃草。玩QQ游戏的电脑配置也比你的要好吧
|
 |
22
Septembers 2015-06-30 19:34:54 +08:00
忽然想到了这东西。。。
see https://github.com/zhihu/kids/blob/master/README.zh_CN.md |
 |
23
qsl0913 2015-06-30 19:39:30 +08:00
日志的查询需求具体是，查明细？做统计？
|
|
24
em70 2015-06-30 19:42:09 +08:00 via Android
@whnzy 只能用一种工具解决吗，awk可以帮你快速筛选记录，然后给Python后续处理啊，你用python去查找那不慢死，awk命令完全可以达到数据库的性能
另外可以创建一个内存盘，把当前处理的日志拷贝到内存盘里让awk处理，那更加酸爽 |
 |
25
paulw54jrn 2015-06-30 20:17:24 +08:00
丢Redshift吧..
|
 |
26
rssf 2015-06-30 20:33:55 +08:00
这已经不是技术能解决的了，给老大提，这算毛的服务器啊。如果老板1毛钱都不想花在硬件上，趁早换地
|
 |
27
yghack 2015-06-30 20:36:05 +08:00
ELK
|
 |
28
sunchen 2015-06-30 20:44:45 +08:00
aws的话试试redshift
|
|
29
sunchen 2015-06-30 20:45:33 +08:00
@paulw54jrn 赞同，redshift谁用谁知道
|
 |
30
scys 2015-06-30 20:54:42 +08:00
服务器性能不足，请最少配置16G的内存给日志服务器。
|
 |
32
summic 2015-06-30 21:20:55 +08:00
分而治之
|
 |
33
ms2008 2015-06-30 21:40:36 +08:00
elk妥妥的
|
 |
34
msg7086 2015-06-30 21:55:05 +08:00
|
 |
35
hitsmaxft 2015-06-30 22:12:28 +08:00
额。。我跑工具脚本的虚拟机都都是 6g 内存， 你这玩意用4g的。。
|
 |
36
daoluan 2015-06-30 23:09:56 +08:00
这些日志用来做什么？
|
 |
37
sophymax 2015-06-30 23:13:25 +08:00 via iPad
明显要上集群啊
|
 |
38
xiawinter 2015-06-30 23:17:24 +08:00  2
@nullcc 很多人用这个方案，但这个方案题主跑不起来，太慢了。 题主可以考虑 heka， 我们数据量比这还要高点，两台机器往 elasticsearch里扔， elasticsearch 需要 12G 内存， 未用 SSD， 不过能用 ssd 速度快很多。
logstash 是 jruby 来做正则解析的，不知道为什么他们会用这么个方案，百思不得其解的慢。 heka 做法非常好， 如果不能及时处理数据，会缓存到 /var/cache/hekad/ 下面，这样不会造成机器卡死。 数据传输和处理有点延迟很正常，硬盘做大点， 准备 100G 应当就差不多。 几天不做都死不了。 如果转运过程还需要去查询 mysql， 那么我认为设计方案可能可以优化一下，类似日志的数据分析不应该做即时分析的，可以先把数据格式化后，之后开始做计算。 否则可能让数据阻塞在原来的地方。 请求加密是指传过来的数据是加密的，然后解密这部分数据？ 感觉很多东西都混在一起，耦合有点高。 |
 |
39
chinabrowser 2015-07-01 01:26:00 +08:00
赶快GCE 这个同等配置可比AWS便宜
|
 |
40
9 2015-07-01 01:39:32 +08:00
最近在做跟楼主一样的东西，ELK 是很适合的方案，不要把数据放数据库中去，那是自杀的做法。
其中 logstash 可以换成 fluentd，不多说了，直接看这个 kibana 的 demo 吧，http://demo.elastic.co/packetbeat/ |
 |
41
darrenxyli 2015-07-01 01:43:51 +08:00
elasticsearch+logstash+kibana
|
 |
42
YORYOR 2015-07-01 08:49:32 +08:00
这tm 比我们渣浪还惨啊 擦
|
|
46
whnzy OP @paulw54jrn 这个在infoQ上看到过一次,研究下
|
|
47
whnzy OP 真是谢谢大家了,感觉要重新设计下了,题主也是开发经验不足,架构的东西现在出现的问题,向前找原因,一开始就错了.
|
 |
48
c89758972 2015-07-01 09:40:39 +08:00
@realpg 麻蛋啊,我之前的公司就是.我倒是想过拿回自己的,可那行政balabala的,当时内存也便宜啊,4G99,就没在意.
|
 |
49
popok 2015-07-01 09:43:13 +08:00
处理啥啊，直接删。哈哈
|
 |
53
fxxkgw 2015-07-01 10:23:42 +08:00
ELK太占内存了 logstash匹配速度太慢 配置这么点的服务器根本承受不了
|
 |
54
loryyang 2015-07-01 11:08:32 +08:00
亿级别的话，简单的还是用批处理吧，kafka+hadoop
实时流的技术难度太高了，而且稳定性是个很大的难题。 数据先用kafka导到hdfs，然后每天运行mr任务，可以上面架一个hive，写写sql就行。hadoop的整套实践方案，还是相对简单一些 不过一个应届生，要搞定这整一套环境，还是有点困难的。。 |
|
55
loryyang 2015-07-01 11:09:55 +08:00
额，没看到你只有两台服务器，那忽略我吧。。。
|
 |
56
fengyqf 2015-07-01 11:19:16 +08:00
亿级日志的规模，竟然用1G 4G的服务器
|
 |
57
lunaticus7 2015-07-01 11:26:41 +08:00
没折腾过nginx日志，不过对原始数据做好预处理，很多情况下可以极大的提高系统的性能，awk sed都可以用，一个比较通用的思路是，在进入流程中大运算量步骤之前，尽量筛掉无用的数据
由于机器配置低，所以做好分治+流式的规划，同时可以看看负载是耗在那一块了，可以考虑多线程，把cpu尽量用起来 |
 |
58
Chip 2015-07-01 11:29:29 +08:00
花钱能解决的问题，Splunk大法好。
|
 |
59
typcn 2015-07-01 11:56:30 +08:00
直接 fopen 全部读一遍，然后 fseek 到文件尾部，流式读取这个日志，插入队列
这个 CPU 基本 0% ，内存超不过 5MB 数据库如果无需复杂功能的话可以简单实现一个，挂个 epoll ，异步拿数据，然后转成 binary 每隔几秒 append 一次磁盘，这个 CPU 不会超过 5%，内存超不过 100MB |
|
60
typcn 2015-07-01 12:02:02 +08:00
看错了，，，是离线日志，直接 while(line = getline())
|
 |
62
EF0718 2015-07-01 12:32:20 +08:00
elasticsearch+logstash+kibana
|
 |
63
smileawei 2015-07-01 12:36:58 +08:00 via iPhone
即使你现在勉强解决了，等下次性能瓶颈的时候怎么办，老板会觉得，上次都搞定了，这次也可以的。然后。。。
|
 |
64
minotaur 2015-07-01 12:57:24 +08:00
流处理，内存中只保留热门数据，冷门数据都持久化到磁盘。
一毕业就做这个还挺有意思的。 |
|
65
whnzy OP 不知道有没有人用过GoAccess,想请教下.
|
 |
66
9hills 2015-07-01 15:41:20 +08:00
上面说elasticsearch的，lz那点内存还敢跑elasticsearch？我32G内存的机器都OOM。。
|
|
67
9hills 2015-07-01 15:42:08 +08:00
ES的文档里说了：A machine with 64 GB of RAM is the ideal sweet spot
64G为佳。。 |
 |
68
Pacer 2015-07-01 15:46:07 +08:00
首先~~ 把机器内存和 CPU 升级一下吧~
跟老板要 16GB 4核 吧 |
 |
69
Clarencep 2015-07-01 16:04:31 +08:00
这么多log肯定有很多是冗余的，垃圾信息的，清理下，然后免费版的splunk就够用的了
|
 |
70
paw 2015-07-01 18:58:23 +08:00
kafka spark
不要求实时的话 mapreduce去 PS：不管咋样，跟BOSS说加机器去。。。。 |
 |
71
luw2007 2015-07-01 19:47:15 +08:00
看日志处理完干嘛。
错误日志可以使用全文搜索引擎报错。 |
 |
72
hb1412 2015-07-01 21:31:23 +08:00
可以看看sumologic
|
 |
73
loading 2015-07-01 21:33:34 +08:00 via Android 1
花十万开发工具 vs 花一万上新机器
|
Select Language