基于es构建实时日志检索平台-.pptxVIP

基于es构建实时日志检索平台系统架构核心技术日志采集日志转发日志搜索ES优化日志采集日志采集文件监控监控文件的新增、删除、修改、备份事件，及时响应并生成采集任务有限资源的最大化利用：根据文件的变更频率动态调整采集任务的采集频率，如：文件超过1小时未变更，则每分钟执行一次文件状态监控，文件变更频率较高的，每秒钟执行一次文件状态监控并生成采集任务文件采集采集内容的准确性：摘要算法—文件唯一标识，在文件备份事件发生时，保证文件内容的连续性、准确性数据发送流量均衡：通过统一调度中心（统一服务）获取流量最小的转发中心地址，并将数据发送到该转发中心，确保各转发中心的流量均衡。日志转发转发中心：日志生产方与日志消费方的桥梁四种发送策略基于日志分类的流量均衡发送同一段时间内，转发中心集群所有主机将同一种数据类型发送到接收器集群的同一个IP，比如：HDFS或JSS的接收器基于日志分类的轮询发送同一数据类型在同一转发器上一段时间内只往接收器的一个IP发送，不同转发器可以发送到不同的IP上，比如日志查询接收器日志转发基于IP地址的轮询发送向接收器的所有IP轮询发送数据，如果某IP不可用，将被剔除轮询队列，等到监测OK后，又自动添加到轮询发送数据IP队列中，比如UMP心跳数据基于IP地址的并发发送同一种数据并发发送到指定接收器，比如：UMP的JVM数据支持将一份数据同时转发到多个消费方（接收器）日志搜索应用索引策略：减少日志创建索引压力的有效手段按应用所属的系统级别定制索引策略日志搜索ES优化内存优化有限的机器资源第一个跳出来出问题是内存，lucene查询与建索引的模块jvm 分配16G内存，经常out of memory。优化方向：1.lucene cache使用方式调整为filter cache2.gc 优化ES优化lucene merge的困扰有限的机器资源第二个跳出来出问题是cpu，24 core 机器 cpu load达到200，最高500。问题根源：1.Lucene 索引同时只能由一个线程执行写操作2.lucene要根据条件进行索引段合并(merge)，以提高查询效率当如此大的数据量一旦触发merge滚雪球效应的时候，可能会持续几分钟。导致后续发送过来的数据等待写入，同时数据也会挤压在内存，也会导致内存问题。ES优化lucene merge的困扰优化方向： 1.将一次长merge合并操作尽量分散在多次merge合并操作中调整lucene merge操作相关参数 2.将日志量大的应用分布到多个lucene 索引中，同时避免不同大应用分布到相同lucene 索引上。调整参数说明调整前值调整后值mergeFactor当大小几乎相当的段的数量达到此值的时候，开始合并2010maxMergeSize当一个段的大小大于此值的时候，就不再参与合并4G3G谢谢