实时日志
1.需求/问题
需求
随着业务增长,服务器增多,最开始是登陆服务器查看日志,这对于几台服务器的需求,还是勉强能应付过去的。但有两个不好的方面,一是零散,不够集中高效查看日志,寻找根源;二是不安全,要对开发,测试等同学开帐号权限。因此日志系统就应运而生了,集中高效web方式搜索查看日志。
问题
a.采集延时15s。这是由于logstash默认机制造成的,每隔1秒检查文件状态,每隔15s检查是否有新文件产生,每隔15s写入
b.消息队列延时。redis版本升经到3.0.6消息队列阻塞问题基本没有了。
c.检索展示延时;(1)elasticsearch节点与分片,索引有关(2)与搜索时间范围深度有关(3)数据量大小,由于采用归类合并展示方式,mobile_info一个月数据量约是180G,最小19M。
d.网络延时;分两部分,第一部分日志节点间数据传输;第二部分客户端加载数据延时。这里暂不考虑。
e.服务器资源消耗;目前有两台服务器,cpu,men峰值利用率75%,如果应用节点再增加,为了达到实时日志效果,加入新资源支撑。
f.减少数据量的加载;去掉不必要的数据,如_id,@version,path
g.减少数据合并时间;提高cpu计算能力,目前合并数是采用if else写法,寻找更高效逻辑处理写法。
h. ELK版本升级,提高处理效率;通过对比,上次版本1.7 与现在的版本2.1对比,2.1版本没down过。
i.优化服务器性能;如磁盘换成ssd;避免内存swap,预留多一点内存;避免cpu上下文切换,目前logstash线程数开到512
j.elastic写入数据慢,目前还没发现
2. 验收指标
客户端产生一条消息,小于1s时就在web端展示出来。
3. 技术方案
A方案ELK+Redis
目前采用的方案是elk+redis+mongodb,elasticsearch集群读写分离模式,mongdo是用来归档数据。这次是在此方案基础上进行优化,具体做法,参考第一章已列出了的问题。
优化各个环节
(1)优化服务器的读写能力
(2)客户端采集优化,客户端默认内存是1g,目前分配是300M,检查,更新,写入等配置都是默认的,要参数化配置到毫秒级别。
(5) elasticsearch优化。写入慢,目前没发现,因为是采取读写分离模式,相对于而言还是单节点模式。目前分配的内存是3g,为了下一步高效搜索,把内存提高到4g。
(6)kibana优化,这是web直接面向用户,新版本采取nodejs这样非阻塞模式,官方对效率的优化已经很高了。再寻找一下别的方法。
S索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用tranlog进行各节点之间的数据平衡。所以从上我可以通过索引的settings进行第一优化:
“index.translog.flush_threshold_ops”: “100000″
“index.refresh_interval”: “-1″,
这两个参数第一是到tranlog数据达到多少条进行平衡,默认为5000,而这个过程相对而言是比较浪费时间和资源的。所以我们可以将这个值调大一些还是设为-1关闭,进而手动进行tranlog平衡。第二参数是刷新频率,默认为120s是指索引在生命周期内定时刷新,一但有数据进来能refresh像lucene里面commit,我们知道当数据addDoucment会,还不能检索到要commit之后才能行数据的检索所以可以将其关闭,在最初索引完后手动refresh一之,然后将索引setting里面的index.refresh_interval参数按需求进行修改,从而可以提高索引过程效率。
另外的知道ES索引过程中如果有副本存在,数据也会马上同步到副本中去。我个人建议在索引过程中将副本数设为0,待索引完成后将副本数按需量改回来,这样也可以提高索引效率。
“number_of_replicas”: 0
上面聊了一次索引过程的优化之后,我们再来聊一下检索速度比较慢的问题,其实检索速度快度与索引质量有很大的关系。而索引质量的好坏与很多因素有关。
一、分片数
分片数,与检索速度非常相关的的指标,如果分片数过少或过多都会导致检索比较慢。分片数过多会导致检索时打开比较多的文件别外也会导致多台服务器之间通讯。而分片数过少为导至单个分片索引过大,所以检索速度慢。
在确定分片数之前需要进行单服务单索引单分片的测试。比如我之前在IBM-3650的机器上,创建一个索引,该索引只有一个分片,分别在不同数据量的情况下进行检索速度测试。最后测出单个分片的内容为20G。
所以索引分片数=数据总量/单分片数
目前,我们数据量为4亿多条,索引大小为近1.5T左右。因为是文档数据所以单数据都中8K以前。现在检索速度保证在100ms 以下。特别情况在500ms以下,做200,400,800,1000,1000+用户长时间并发测试时最坏在750ms以下.
二、副本数
副本数与索引的稳定性有比较大的关系,怎么说,如果ES在非正常挂了,经常会导致分片丢失,为了保证这些数据的完整性,可以通过副本来解决这个问题。建议在建完索引后在执行Optimize后,马上将副本数调整过来。
大家经常有一个误去副本越多,检索越快,这是不对的,副本对于检索速度其它是减无增的我曾做过实现,随副本数的增加检索速度会有微量的下降,所以大家在设置副本数时,需要找一个平衡值。另外设置副本后,大家有可能会出现两次相同检索,出现出现不同值的情况,这里可能是由于tranlog没有平衡、或是分片路由的问题,可以通过?preference=_primary 让检索在主片分上进行。
三、分词
其实分词对于索引的影响可大可小,看自己把握。大家越许认为词库的越多,分词效果越好,索引质量越好,其实不然。分词有很多算法,大部分基于词表进行分词。也就是说词表的大小决定索引大小。所以分词与索引膨涨率有直接链接。词表不应很多,而对文档相关特征性较强的即可。比如论文的数据进行建索引,分词的词表与论文的特征越相似,词表数量越小,在保证查全查准的情况下,索引的大小可以减少很多。索引大小减少了,那么检索速度也就提高了。
四、索引段
索引段即lucene中的segments概念,我们知道ES索引过程中会refresh和tranlog也就是说我们在索引过程中segments number不至一个。而segments number与检索是有直接联系的,segments number越多检索越慢,而将segments numbers 有可能的情况下保证为1这将可以提到将近一半的检索速度。
$ curl -XPOST ‘ http://localhost:9200/twitter/_optimize? max_num_segments =1′
五、删除文档
删除文档在Lucene中删除文档,数据不会马上进行硬盘上除去,而进在lucene索引中产生一个.del的文件,而在检索过程中这部分数据也会参与检索,lucene在检索过程会判断是否删除了,如果删除了在过滤掉。这样也会降低检索效率。所以可以执行清除删除文档。
$ curl -XPOST ‘ http://localhost:9200/twitter/_optimize? only_expunge_deletes =true
$ curl -XPOST 'http://localhost:9200/twitter/_optimize'
管理索引优化
optimize API允许通过API优化一个或多个索引。优化过程的操作基本上优化的索引搜索速度更快(和涉及到Lucene索引内保存每个碎片的段数)。优化操作允许减少的段数,把它们合并。
$ curl -XPOST 'http://localhost:9200/twitter/_optimize'
名称 描述
max_num_segments |
段数优化。要全面优化索引,将其设置为 。【经过测试越小速度越快】 |
only_expunge_deletes | 优化过程中应该只抹去段删除。在Lucene中,不会被删除的文件从段,只是标记为删除。分部在合并过程中,创建一个新的分部,没有那些删除。此标志只允许合并段删除。默认为 false 。【设置为true docs才会合并】 |
refresh | 如果刷新后进行优化。默认为 true 。 |
flush | 如果冲洗后进行优化。默认为 true 。 |
wait_for_merge | 申请应等待合并结束。默认为 true 。注意,合并有可能是一个非常繁重的操作,所以它可能是有意义运行它设置为 假 。【最好设置为false,默认true请求就会阻塞在那里,直到完成】 |
优化API一个调用,可以应用到多个索引,或者所有索引
$ curl -XPOST 'http://localhost:9200/kimchy,elasticsearch/_optimize' $ curl -XPOST 'http://localhost:9200/_optimize'
参数使用方法: http://localhost:9200/indexName/_optimize?only_expunge_deletes=true&wait_for_merge=false
速度可以提高n倍, n>=2
2. 如果有多台机器,可以以每台设置n个shards的方式,根据业务情况,可以考虑取消replias
curl -XPUT 'http://10.1.*.*:9200/dw-search/' -d '{
"settings" : {
"number_of_shards" : 20,
"number_of_replicas" : 0
}
}'
这里设置20个shards, 复制为0,如果需要replicas,可以完成index后再修改为replicas>=1
原文:http://www.elasticsearch.org/guide/reference/api/admin-indices-create-index.html
3. 提高ES占用内存
内存适当调大,初始是256M, 最大1G,
调大后,最小和最大一样,避免GC, 并根据机器情况,设置内存大小,
$ bin/elasticsearch -f -Xmx4g -Xms4g -Des.index.storage.type=memory
原文:http://www.elasticsearch.org/guide/reference/setup/installation.html
4. 减少shard刷新间隔
curl -XPUT 'http://10.1.*.*:9200/dw-search/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'
完成bulk插入后再修改为初始值
curl -XPUT 'http://10.1.*.*:9200/dw-search/_settings' -d '{
"index" : {
"refresh_interval" : "1s"
}
}'
5. 设置一个shard的段segment最大数
可以减少段文件数,提高查询速度
curl -XPOST 'http://10.1.*.*:9200/dw-search/_optimize?max_num_segments=5'
注意:有时候可能需要多次执行
原文:http://www.elasticsearch.org/guide/reference/api/admin-indices-update-settings.html
原文:http://www.elasticsearch.org/guide/reference/index-modules/merge.html
6. 去掉mapping中_all域
Index中默认会有_all的域,这个会给查询带来方便,但是会增加索引时间和索引尺寸
"_all" : {"enabled" : false}
原文:http://www.elasticsearch.org/guide/reference/mapping/all-field.html
curl -XPOST 'http://10.1.*.*:9200/dw-search/pt_normal/_mapping' --data-binary @pt_normal_properties.mapping
7. 设置source为压缩模式或者disable
compress=true这个能大大减少index的尺寸
disable将直接没有_source域
8. 增加merge.policy.merge_factor数
设置merge.policy.merge_factor到30,初始是10
增加这个数需要更多的内存,bulk index可以调大这个值.
如果是即时索引,应该调小这个值
B.备选方案是elk+redis(kafka)
这两套方案都引入消息队列,有两个作用:(1)系统解藕(2) 消息缓冲FIFO。直接从redis采用数据过滤归档,解藕的好处。日志峰期采集最高400条/s,平均100条/s,避免冲跨接收端。
总结:优化客户端采集的效率,目前的消息队列暂不用优化,优化接收端的处理效率,由于我们对数据展示作了归类,采用if else写法,对cpu性能还是有一定消耗,所以优化。elasticsearch优化有:内存,节点,索引刷新时间,分片。
4. 时间表
20160215写实时日志文档
20160216-18优化,配置到各节点
20160219测试,验收
5. 后续规划
elk整体方案是比较消耗资源的,后续引入:
a. 轻量级rsyslog作为客户端采集,高效级flunted作业客户端采集。
b. kafka替代redis,redis是基于内存,数据量大是顶不住的。没有kafka基于磁盘数据结构,每秒百万级别的吐吞量强。
c. elaticsearch优势是搜索,虽也支持分布式存储,目前按服务器规模,引入一些小而精的组合,如influxdb,mongodb只负责存储,elastic只负责搜索。
e. 目前的需求,kibana是满足,如一些统计数据,cellectd采集系统性能数据,漂亮的ui展示,再加入grafana,更专业。
6. 参考资料
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
http://www.redis.cn/topics/memory-optimization.html
(2)kafka
http://kafka.apache.org/documentation.html#introduction
(3)ElasticSearch 权威指南
https://www.gitbook.com/book/fuxiaopang/learnelasticsearch/details
(4)collectd收集各数据类型的配置参考资料
相关推荐
问题:在微服务中如何对请求日志统一输出? 新建日志组件,日志组件对请求进行拦截处理,输出请求入参、出参。其他各微服务引用日志组件,对日志统一输出 日志组件如下: 工具类 1、新建TimeCostEnum 请求耗时类,...
ISA日志统计的整体方案及实施过程 ...2、问题二:由于月日志的追加和统计,造成程序效率太低。 三、新方案 1、思路: 因ISA自身的REPORT功能不太全面,故日统计报告仍使用SQL方式,月统计报告采用ISA的REPORT功能。
大数据搜索与日志挖掘及可视化方案 ELK Stack Elasticsearch Logstash Kibana 第2版
网络安全服务中有很多服务项,浩二给大家拆解程了各服务项的独立方案,每个独立方案都可单独成为一个项目内容,也可以整合到各类大的解决方案中,本人纯原创,替换关键词可直接用,都是工作实践中的实用方案,跟随处...
NULL 博文链接:https://killeraction.iteye.com/blog/1431486
由于使用了LOGRETAIN=ON数据库配置,所以数据库日志文件将不会被数据库从活动日志目录中自动删除或循环利用,活动日志目录中的日志文件将会越来越多,所以需要对该目录下的日志文件进行归档。
网上找了下解决方案,大体是扩大临时库的日志文件的大小解决的 解决过程: 查看了下数据库的属性,是自动增长,不指定文件大小上限。 在网上Google了很久,试了些方法都不行;数据库所在磁盘还有很大的可用空间,试...
统一监控平台方案(日志监控、方法监控、调用链路监控) 包含flume采集数据、kafka缓存数据、spark计算、es索引数据
4 支持布局及日志文件方案保存及还原; 5 支持自定义布局 并排布局;">很多程序 Tomcat JBoss MQ 运行时会输出日志文件 但是每次需要重新打开日志文件才能看到最新的日志信息 太不方便了 而且有时候想同时监控多...
分析windows系统DCOM错误日志及解决方案.docx
使用Slf4j集成Log4j2构建项目日志系统的完美解决方案.docx
2.es集群.flv 3-logstash快速入门.flv 4-logstash收集系统日志-file.flv 5-logstash收集java日志-codec.flv 6-kibana介绍.flv 7-logstash收集nginx访问日志-json.flv 8-logstash收集syslog日志.flv 9-logstash收集...
大数据搜索与日志挖掘及可视化方案——ELK Stack:Elasticsearch Logstash Kibana(第2版)
《MonkeyOnline》数据备份方案 备份方式 主从复制+完整备份(Mysqldump或winrar压缩备份DATA目录)+增量备份(启用从服 务器二进制日志文件) 备份策略 在主服务器上启用二进制日志实现主从复制做实时在线热备份;...
15.监理日志(共56份).zip监理报告工作总结规划实施细则方案等技术资料下载15.监理日志(共56份).zip监理报告工作总结规划实施细则方案等技术资料下载15.监理日志(共56份).zip监理报告工作总结规划实施细则方案...
管理数据库日志的工作可以手工完成,也可由编写USEREXIT程序自动维护。由于DB2对所有平台都提供了相应的USEREXIT示例程序,而且非常易于修改和使用,所以IBM建议用户使用USEREXIT程序来管理日志文件。本文介绍了使用...
(2) 测试方案 210 4.1.9.2.5. 测试人员名单 211 4.1.10 本期项目完成交付后,技术服务计划、维护、承诺及费用 212 4.1.10.1. 概述 212 4.1.10.2. 服务内容 213 1. 咨询服务 213 2. 应用系统的故障响应 213 ...
日志是应用程序中不可缺少的一部份,不仅可以记录应用程序的运行状态,还可以记录一些BUG,便于应用程序的更新与修改。 在.Net有好几种方法可以对日志进行管理。...2、文本日志。 3、系统事件日志。
解决方案为单独再部署一个xxl-job-read-log服务,将读日志的请求都转到这个服务上,由这个服务统一读取日志。 具体步骤: 1.将执行日志通过nfs存储到一个统一路径,由于文件名是数据库id,所以不会有覆盖问题。 2....
K3数据库日志文件过大分析及解决方案