服务介绍

随着实时分析技术的发展及成本的降低,用户已经不仅仅满足于离线分析。目前我们服务的用户包括微博,微盘,云存储,弹性计算平台等十多个部门的多个产品的日志搜索分析业务,每天处理约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公司的免费版本,中国的信息尤其不准。解决方案:使用我浪较新较全的IP库生成能适配maxmind geoip2 api的二进制格式IP库(maxmindDB),再开发logstash-filter-geoip2来解析IP。实测不仅IP解析准确率与公司IP库 相同了,解析速度也提高了。

(2)然后我们与用户都发现日志接入流程复杂,沟通困难。

人做不到机器那样分毫不差,有啥说啥。接入用户日志的时候,例如常常因为用户对日志格式表达的不全面,模棱两可,导致日志解析失败,服务对接人多 次重写配置。从用户提需求到用户可以看到数据可视化效果或搜到日志,需要几个小时到几天。一来二去,用户和我们都烦了,只能求变。为此,我们正在逐步实现 用户数据接入的自动化,减少接入时间和沟通成本这个过程需要3个关键:A.用户配置日志格式的界面,尽可能简洁简单;B.根据用户配置自动生成 logstash config, index管理需要的配置;C.自动部署配置(logstash config等),打通日志流。

后来我们做了一个简单的用来协商日志格式的界面:

目前我们已完成了A的一部分:用户日志格式配置界面;B的全部:开发了自动生成logstash conf的 python api;C即将开始,并且考虑使用docker技术为我们提供一些便利。

(3)部分数据可视化需求得不到满足,Kibana配置难度大

我们起初采用官方Kibana v3, 用户提出的类似SQL中的多个group by,画百分比,求指定区间占比等常见需求无法满足。之后通过三斗大神(微博@argv)定制版的 Kibana 3 满足了一些用户需求。Kibana 4诞生后,代码几乎是对Kibana3的重写,做了大幅改进,通过 Elasticsearch Aggregation 的强大数据统计功能及灵活的配置从Kibana 3解放出来。近期我们将迁移到Kibana 4。

三、提供新功能

我们为Elasticsearch安装了国内medcl大神开发的ik中文分词插件 elasticsearch-analysis-ik 。之前被分词为”中“和”国“的中国,现在终于可以被当做一个完整的词汇,否则搜索”中国“,“美国”也会出现。微盘的一些离线搜索需求使用了我们的服务,也用到了中文分词,Elasticsearch的搜索天赋满足了他们的需求,减少了他们的痛苦。

我们经历过的坑和坎儿:

(1)elasticsearch 进程JVM Heap High Usage( >90% )

很长一段时间,我们都在应对JVM Heap High Usage,他带了的问题是Old GC次数多,时间长,es节点频繁退出集群,整个集群几乎停止响应。现在我们的主要策略是开启doc_values;限制query执行时占用的JVM Heap size;analyzed string只允许做query, 不允许facets或者aggs;定期close 用户不需要的index。

(2) Elasticsearch Query DSL, Facets, Aggs学习困惑

有人为此开发了使用SQL执行ES Query的插件,一定程度上减轻了进入门槛。我们给出的学习他们的建议是观察Kibana的Request Body或试用Marvel的Senese插件,它有自动完成Query,Facets, Aggs的功能。另外最常用的query是 query string query ,最常用的aggs是 Terms , Date Histogram ,可以应付大部分需求。

(3)logstash不工作

非官方的问题插件,及使用logstash-filter-ruby时未考虑到的异常等,导致Logstash运行时工作线程(worker thread)异常退出,Logstash僵死。我们的建议是尽可能不要在config中使用logstash-filter-ruby,尽量使用官方插 件。不过我们也遇到过复杂的日志,写过250行+的config,用尽了ruby filter。当前未发现Logstash有好的成熟的监控方案,Logstash的内部状态也获取不到。我们目前通过间接的监控Kafka topic consumer是否落后或elasticsearch indexing rate来检验logstash的工作情况。

(4)Kibana没有用户的概念,不同用户的数据无法隔离

多个用户共享的Kibana Dashboard, 误操作或误删时常影响其他用户,保存的dashboard太多,找到特定的dashboard很困难。官方到目前为止,未在这方面做过改进。有很多非官方 的改进,我们也曾经用过三斗大神定制的Kibana3,也对Kibana index做了snapshot储存到Hdfs里面。

(5)与用户沟通成本高

与我们的用户协商日志格式,数据可视化配置时,由于人的不确定性容易造成多次来回确定和修改,效率低下。我们毕竟是提供日志分析服务的,不给用户 做日志运维,所以近期也在探索通过日志接入自动化、推荐用户提供给我们json格式数据,定期组织用户的Kibana培训来减少沟通成本。

---

Q & A:

问:logstash连es出现timeout的情况有没?如何解决的?

答:我们常见的是ES Jvm Heap Usage比较高的时候会timeout,如果是服务内存小换大内存。另外不要对analyzed的string做aggs,facets ,开启doc_values。

问:关于日志中异常报警的,有哪些方式?关键字过滤?

答:对于日志解析失败的情况,logstash 常见的是_grokparsefailuer,和_jsonparsefailure,数据写入es后,执行query查询这两个关键词的数量即可。对于 报警方案,watch是官方刚出的,其实比它早的实现方案,如Yelp的elastalert。

问:大数据分析平台(基于hdfs)跟kibana的展现会有很大区别吗?或者说最大的区别会在哪些方面?

答:你说的区别,我理解是hadoop与elasticsearch的区别,一个是离线分析,以job为单位,一个是实时搜索和统计,以 query为单位。这里有三个关键词:实时,搜索,统计。hadoop是离线的,es是实时的;es本质上是一个搜引擎,可以用来做全文检索等工 作,hadoop显然于此无关。统计是hadoop与es都能做的,我不了解hadoop有没有像Kibana这样的数据可视化组件。

问:你们的ES集群数据节点和查询节点做了分离吗?logstash是直接把数据写入查询节点还是数据节点?另外你们直接用的node模式还是transport模式呢?

答:(1)还没有做分离。(2)我们还在用http protocol模式

参考资料:

Python 多进程日志记录:http://itindex.net/detail/14658-python-%E8%BF%9B%E7%A8%8B-%E6%97%A5%E5%BF%97

Better ELK, 新浪实时日志分析服务进化:http://www.open-open.com/news/view/1bbf9

Kafka实战-实时日志统计流程:http://www.open-open.com/lib/view/open1434523721208.html

基于fluem和kafka的实时日志收集系统:http://www.colabug.com/thread-1099061-1-1.html?pp=2

fluent/fluentd:https://github.com/fluent/fluentd/

日志客户端(Logstash,Fluentd, Logtail)横评:https://yq.aliyun.com/articles/3228

Logstash and Log Monitoring With Nagios:https://www.nagios.com/solutions/logstash/

How can we monitor performance of Kafka, Logstash and elasticsearch? Is there any tool available for monitoring their performance?:https://www.quora.com/How-can-we-monitor-performance-of-Kafka-Logstash-and-elasticsearch-Is-there-any-tool-available-for-monitoring-their-performance

Send Nagios metrics to Graphite via Logstash:http://philippe.lewin.me/2014/10/02/nagios-metrics-to-graphite-via-logstash/

报警到 Nagios:http://logstash-best-practice.readthedocs.io/zh_CN/latest/output/nagios/

Logstash and Log Monitoring With Nagios:https://www.nagios.com/solutions/logstash/

scribe、chukwa、kafka、flume日志系统对比:http://www.ttlsa.com/log-system/scribe-chukwa-kafka-flume-log-system-contrast/

http://jasonwilder.com/blog/2013/11/19/fluentd-vs-logstash/

http://logz.io/blog/fluentd-logstash/

https://yq.aliyun.com/articles/3228

http://www.tuicool.com/articles/7FzqeeI

https://segmentfault.com/q/1010000002894783

http://blog.csdn.net/benpaobagzb/article/details/50903323

【日志处理、监控ELK、Kafka、Flume等相关资料】的更多相关文章

  1. kafka负载均衡相关资料收集(二)

    [转]关于kafka producer 分区策略的思考 from:http://blog.csdn.net/ouyang111222/article/details/51086037 今天跑了一个简单 ...

  2. kafka负载均衡相关资料收集(一)

    key为null时Kafka会将消息发送给哪个分区? 当你编写kafka Producer时, 会生成KeyedMessage对象. 1 KeyedMessage<K, V> keyedM ...

  3. kafka负载均衡相关资料收集(三)

    apache kafka系列之Producer处理逻辑 下文是转载的,原文链接地址:点这儿 [转] Kafka ProducerKafka Producer处理逻辑kafka生产者处理逻辑apache ...

  4. 日志收集ELK+kafka相关博客

    SpringBoot+kafka+ELK分布式日志收集 使用 logstash + kafka + elasticsearch 实现日志监控 Kibana 安装 与 汉化 windows系统安装运行f ...

  5. ELK+Kafka集群日志分析系统

    ELK+Kafka集群分析系统部署 因为是自己本地写好的word文档复制进来的.格式有些出入还望体谅.如有错误请回复.谢谢! 一. 系统介绍 2 二. 版本说明 3 三. 服务部署 3 1) JDK部 ...

  6. ELK+kafka构建日志收集系统

    ELK+kafka构建日志收集系统   原文  http://lx.wxqrcode.com/index.php/post/101.html   背景: 最近线上上了ELK,但是只用了一台Redis在 ...

  7. ELK+Kafka 企业日志收集平台(一)

    背景: 最近线上上了ELK,但是只用了一台Redis在中间作为消息队列,以减轻前端es集群的压力,Redis的集群解决方案暂时没有接触过,并且Redis作为消息队列并不是它的强项:所以最近将Redis ...

  8. 企业日志大数据分析系统ELK+KAFKA实现【转】

    背景: 最近线上上了ELK,但是只用了一台Redis在中间作为消息队列,以减轻前端es集群的压力,Redis的集群解决方案暂时没有接触过,并且Redis作为消息队列并不是它的强项:所以最近将Redis ...

  9. ELK + kafka 日志方案

    概述 本文介绍使用ELK(elasticsearch.logstash.kibana) + kafka来搭建一个日志系统.主要演示使用spring aop进行日志收集,然后通过kafka将日志发送给l ...

随机推荐

  1. Linux下的两个经典宏定义【转】

    转自:http://www.linuxidc.com/Linux/2015-07/120014.htm 本文首先介绍Linux下的经典宏定义,感受极客的智慧,然后根据该经典定义为下篇文章作铺垫. of ...

  2. python实战===石头剪刀布,简单模型

    #石头剪刀布 import random import time win_list = [("石头","剪刀"),("布","石头 ...

  3. 白话TCP三次握手

    在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接. 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认: 第二次握 ...

  4. 无法解析的DNS服务地址

    如果DNS服务器地址设置不当,可能会导致网速慢.出现弹窗广告.网址打不开.打开不是自己想要的网站等一系列问题. 请参考: DNS的作用是什么,怎样设置DNS? https://jingyan.baid ...

  5. python中进程池的应用

    #原创,转载请联系 假设我们写的一个程序需要运行100个子进程的时候,那么写程序时,不可能循环创建销毁100个进程吧?进程的创建与销毁是很耗系统的资源的. 进程池的作用就体现出来了. 进程池可以控制进 ...

  6. CSDN博客用Windows Live Writer方法,终于可以离线编辑了!

    以下是安装WLW 和相关设置: 1. 下载安装WLW (步骤略,可自行下载,官方下载地址:http://www.microsoft.com/zh-cn/download/details.aspx?id ...

  7. hdu 5170(数学)

    GTY's math problem Time Limit: 1000/1000 MS (Java/Others)    Memory Limit: 65536/65536 K (Java/Other ...

  8. Codeforces 810 A.Straight «A»

    A. Straight «A»   time limit per test 1 second memory limit per test 256 megabytes input standard in ...

  9. CF 862A Mahmoud and Ehab and the MEX【数组操作】

    A. Mahmoud and Ehab and the MEX time limit per test 2 seconds memory limit per test 256 megabytes in ...

  10. 17、Flask实战第17天:Flask-cookie

    cookie的基本概念 在网站中,http请求是无状态的.也就是说即使第一次和服务器连接并且登录成功后,第二次请求服务器依然不能知道当前请求的是哪个用户. cookie的出现就是为了解决这个问题,第一 ...