新浪是如何分析处理32亿条实时日志.docxVIP

【编者的话】我从2014年初入职新浪后就开始接触实时日志分析相关的技术，主要是ELK（Elasticsearch、Logstash、Kibana），当时是学习+ELK优化，接一些日志，小打小闹。从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，这个功能目前主要用于备份Kibana的配置index，用以恢复用户查看或配置可视化界面时的错误操作。监控报警方面，System Level的监控报警（如硬盘满、损坏、服务器宕机）直接使用了在新浪内部提供了多年服务的sinawatch；App Level（如Elasticsearch JVM Heap Usage过高，Kibana能否正常访问，Kafka topic的consumer offset lag），我们开发了对应的监控报警脚本。User Level（如日志解析失败数量），主要通过elasticsearch python client执行query去统计或搜索。常见的报警是Logstash-filter-grok，logstash-filter-json解析日志失败会输出的json中添加_grokparserfailure、_jsonparsefailure，我们执行query判断解析错误的量。要说明的是，Marvel是Elasticsearch很好的监控工具和插件，但是它们是商业软件，我们没有采用。Marvel是基于Kibana做的，里面对一些重要指标（如index bulk reject number）的展示很有价值。二、增强易用性增强服务的易用性就是给用户更好的用户体验，减少用户的抱怨。ELK性能优化是一方面，但它是远远不够的，我们遇到的实际情况是，用户在其他方面抱怨更多，如下：1，用户最先抱怨的是IP解析成地区、ISP信息一点都不准，完全没有参考意义。如对于CDN这种服务，我们解析用户IP不准，定位问题边缘节点错误，问题没法查，这是帮倒忙。原因：Logstash默认自带的IP库是国外maxmind公司的免费版本，中国的信