这是一个创建于 3114 天前的主题，其中的信息可能已经有所发展或是发生改变。
Java 。交易系统记录日志，监控系统每隔 5 分钟读一次交易系统的日志，把物理错误的交易(诸如网络中断、交易系统无响应等)挑出来做统计。
目前的解决方案有三个问题：
一个是交易系统分布式部署，监控系统每次分析前需要先批量下载日志到监控的服务器，尽管交易系统日志已经到小时级别，但整个下载过程依旧需要耗点时间；
一个是分析日志的时候每次要从头开始，随着每个小时逐渐结束，无用功越来越多；
一个是每个小时的开始需要再分析一下上个小时的日志，防止末尾没有分析到，又是无用功；
还没测过，但我觉得 5 分钟分析完都够呛，因为那个分析过程挺复杂的...不知道有什么好的方案没。
目前的解决方案有三个问题：
一个是交易系统分布式部署，监控系统每次分析前需要先批量下载日志到监控的服务器，尽管交易系统日志已经到小时级别，但整个下载过程依旧需要耗点时间；
一个是分析日志的时候每次要从头开始，随着每个小时逐渐结束，无用功越来越多；
一个是每个小时的开始需要再分析一下上个小时的日志，防止末尾没有分析到，又是无用功；
还没测过，但我觉得 5 分钟分析完都够呛，因为那个分析过程挺复杂的...不知道有什么好的方案没。
 |
1
server 2016-06-17 10:42:34 +08:00  1
elk
|
 |
2
Jaylee 2016-06-17 10:43:02 +08:00
elk
|
 |
3
ksupertu 2016-06-17 12:28:40 +08:00 1
开源的就 ELK ，有钱就上 splunk
|
 |
4
depress OP |
|
5
ksupertu 2016-06-17 15:45:07 +08:00 via Android
elk 新浪的做法是通过 java 写入日志到 syslog ，利用系统 syslog 推送到中间件服务器，写入 elasticsearch 做实时分析，已经是目前解决方案开源界用的差不多最大的，可以每秒打 2w 多个日志过去，能达到 tb 级日志秒级搜索，新浪微博用的就是这一套系统，其它解决方案大同小异无非是换个日志收集 agent ，这还不行只能自己造轮子了
|
|
6
depress OP @ksupertu 目前只能在项目里做手脚，不行的话只能先按手写代码这么走了，还一周的时间了，我其实早点问就好了，越写越觉得不对劲。 elk 只能二期评估看看上不上了。
|
 |
7
dongxiaozhuo 2016-06-19 22:59:25 +08:00
别自己做日志分析系统！
别自己做日志分析系统！ 别自己做日志分析系统！ 当前公司，最开始有日志查询需求，脚本给满足，后来要实时，上 redis 进队列。 再后来。。。就全职做日志相关了。 现在先开始从 ELK 的 filebeta 日志收集部分开始推了。 PS ：当前团队对 ELK 不是非常认可，之前一直不愿意采用。。。然后我就被搭进去好几个月做这一件事情了。。。 |
|
8
depress OP @dongxiaozhuo 哈哈哈，血的教训啊，不过我这个不复杂，纯手写不到 2K 行就搞定了，比你那个几个月的规模小的多。不过以防万一，还是得和团队评估一下 ELK ，能上就上了，一了百了。
|
Select Language