实时日志
随着业务增长，服务器增多，最开始是登陆服务器查看日志，这对于几台服务器的需求，还是勉强能应付过去的。但有两个不好的方面，一是零散，不够集中高效查看日志，寻找根源；二是不安全，要对开发，测试等同学开帐号权限。因此日志系统就应运而生了，集中高效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写入数据慢，目前还没发现
客户端产生一条消息，小于1s时就在web端展示出来。
目前采用的方案是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
?
?
?
这两套方案都引入消息队列，有两个作用：(1)系统解藕(2) 消息缓冲FIFO。直接从redis采用数据过滤归档，解藕的好处。日志峰期采集最高400条/s,平均100条/s,避免冲跨接收端。
总结：优化客户端采集的效率，目前的消息队列暂不用优化，优化接收端的处理效率，由于我们对数据展示作了归类，采用if else写法，对cpu性能还是有一定消耗，所以优化。elasticsearch优化有：内存，节点，索引刷新时间，分片。
20160215写实时日志文档
20160216-18优化，配置到各节点
20160219测试，验收
elk整体方案是比较消耗资源的，后续引入：
a. 轻量级rsyslog作为客户端采集，高效级flunted作业客户端采集。
b. kafka替代redis,redis是基于内存，数据量大是顶不住的。没有kafka基于磁盘数据结构，每秒百万级别的吐吞量强。
c. elaticsearch优势是搜索，虽也支持分布式存储，目前按服务器规模，引入一些小而精的组合，如influxdb,mongodb只负责存储，elastic只负责搜索。
e. 目前的需求，kibana是满足，如一些统计数据,cellectd采集系统性能数据，漂亮的ui展示，再加入grafana，更专业。
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
原文：http://hugo3.iteye.com/blog/2277592