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