文档介绍：【编者的话】我从 2014 年初入职新浪后就开始接触实时日志分析相关的技术, 主要是 ELK ( Elasticsearch 、 Logstash 、 Kibana ), 当时是学****EL K 优化, 接一些日志, 小打小闹。从 2015 年起, 我们正式得把实时日志分析作为服务提供给公司的其他部门。今天要给大家分享的是在服务化的道路上, 我们的想法,方案和疑问。服务介绍随着实时分析技术的发展及成本的降低,用户已经不仅仅满足于离线分析。目前我们服务的用户包括微博、微盘、云存储、弹性计算平台等十多个部门的多个产品的日志搜索分析业务,每天处理约 32 亿条( 2TB )日志。技术架构简单介绍一下服务的技术架构: 这是一个再常见不过的架构了: (1) Kafka :接收用户日志的消息队列。(2) Logstash :做日志解析,统一成 JSON 输出给 Elasticsearch 。(3) Elasticsearch :实时日志分析服务的核心技术,一个 schemaless ,实时的数据存储服务,通过 index 组织数据,兼具强大的搜索和统计功能。(4) Kibana :基于 Elasticsearch 的数据可视化组件,超强的数据可视化能力是众多公司选择 ELK stack 的重要原因。努力提供更好的服务我这次分享的重点不是这种架构的优劣或为什么选择这样的架构,而是在如此的架构上如何更好地传递实时日志分析的价值。为用户做好服务也不是修改几个配置文件,调优几个程序运行参数就能搞定的。为了提供更好的服务,我们在下面三个方向做了努力: 一、提升服务质量我们首先做了 Elasticsearch 优化, Hardware Level 由于我们当时拿到机器没有选择余地,只开启了超线程; System Level 的优化如关闭 swap ,调整 max open files 等; App Level 的优化如 Java 运行环境版本的选择, ES_HEAP_SIZE 的设置,修改 bulk index 的 queue size 等,另外还设置了默认的 index template ,目的是更改默认的 shard , replica 数并将 string 改为 not_analyzed ,开启 doc_values 以应对 elasticsearch 进程 OOM 。详细的优化内容见 Elasticsearch Optimization Checklist 。随着用户数据的不断增长, index 管理也成了大问题,我们需要基于大量不同的用户配置定期的 create 、 optimize 、 close 、 delete 、 snapshot 不同的 index ,在某个服务器上手工配置 crontab 已是不可能,而且 cron 是单点。于是我们开发了一个独立的 Elasticsearch Index 管理系统,负责以上任务的调度及执行。这个管理系统背后使用的技术是 Celery , 一个用 Python 开发的任务队列及执行系统, 提供了类似 crontab 的定时任务配置语法, 并且实现了分布式,可用性更高的架构。最近的服务升级,我们为 Elasticsearch 安装了 HDFS Snapshot 插件,可以定期将 index 备份到 HDFS ,这个功能目前主