1. 前 言
本文在书写过程中,咨询了红帽技术专家郭跃军、李春霖、张亚光,并借鉴了他们提供的技术文档,在此表示感谢! 此外,在书写过程中,笔者也借鉴了红帽官方技术文档以及互联网上的一些信息,文中会列出引用链接。
2.构建全数据中心日志管理系统的必要性
在一个数据中心内部,构建一体化运维平台时,其中一个中间的部分就是构建全数据中心监控和日志管理。
在集中监控方面,zabbix是一个不错的工具。Zabbix分为server和agent两部分。
2.1 Zabbix的作用
Zabbix可以监控硬件、系统和应用。目前Zabbix agent支持的OS平台有:Linux,Solaris,HP-UX,AIX,Free BSD,Open BSD, OS X, Tru64/OSF1, Windows NT4.0, Windows (2000/2003/XP/Vista)。Zabbix有很多模板,详见:https://monitoringartist.github.io/zabbix-searcher/
实际上,很多应用软件,也自带监控软件,如JBoss的Jconsole
2.2 红帽Openshift的监控
红帽的Openshift,是基于Docker+K8S的容器云解决方案。它的默认使用kubenetes的监控信息收集机制,在每个节点上部署cadvisor的代理,负责收集容器级别的监控信息。然后将所有信息汇总到heapster。
heapster后台的数据持久化平台是Cassandra。最后由hawkular从Cassandra获取信息进行统一的展示
部署Metrics组件后,在Openshift的Web控制台,可以看到监控信息。
点击pod的Metrics按钮,可以看到一段时间内监控信息的变化数据:
所以说,在监控这块,目前业内已经有一些成型的工具。
那么在日志管理这块,能否构建数据中心统一日志收集和管理平台呢?包含从操作系统到应用的日志收集和分析呢?
3.基于开源的日志管理系统的架构
基于开源的日志管理系统构建,有很多种方式,但离不开一下几种技术:Elasticsearch、Logstash/Fluentd、Kibana这几种技术。有时候,我们经常会看到ELK这个词,其实就是Elasticsearch、Logstash、Kibana三个缩写。
所以简单而言,Elasticsearch是搜索引擎、Logstash是日志收集工具、Kibana是日志展示工具。
3.1 Elasticsearch到底是个啥?
谈起Elasticsearch,简称ES,这可是个大名鼎鼎的工具。
ES可以帮助你用前所未有的速度去处理大规模数据。它可以用于全文搜索,结构化搜索以及分析。目前有很多ES的使用案例:
•维基百科使用 Elasticsearch 来进行全文搜索并高亮显示关键词,以及提供search-as-you-type、did-you-mean等搜索建议功能。
•英国卫报使用 Elasticsearch 来处理访客日志,以便能将公众对不同文章的反应实时地反馈给各位编辑。
•StackOverflow 将全文搜索与地理位置和相关信息进行结合,以提供more-like-this相关问题的展现。
•GitHub 使用 Elasticsearch 来检索超过1300亿行代码。
•每天,Goldman Sachs 使用它来处理5TB数据的索引,还有很多投行使用它来分析股票市场的变动。
3.2 Logstash是个啥
它是实时的日志收集、处理引擎。它做一下几件事:
所以说,Logstash收集完日志并进行过滤后,最终是要吐出到ES的。
我们来看一个配置文件例子,描述的就是
Logstash输出到Elasticsearch
3.3 Logstash扩展方案
在实际运用中,logstash 进程会被分为两个不同的角色。运行在应用服务器上的,尽量减轻运行压力,只做读取和转发,这个角色叫做shipper,目前shipper可以用各种Beats来实现;运行在独立服务器上,完成数据解析处理,负责写入Elasticsearch的角色,叫 indexer。
在目前的方案中,我们可以用Filebeat来做logstash的shipper。Filebeat运行在每个要收集日志的节点上。收集完以后,汇总到redis里,由indexer将日志写入ES。实际上Filebeat就是一个agent。logstash可以接受很多收集器发来的数据,fliebeat就是在被管机读取日志文件发出来,也可以理解成收集器。
看到这里,细心的朋友肯定会想到:如果Filebeat过多,那么indexer往ES中写日志的时候,在日志量大的时候,很容易发生阻塞,形成瓶颈点。怎么办?
可以考虑利用kafka替换上图中的redis。相比于redis来说,kafka的吞吐量大很多。
谈到了Logstash,就不得不提到Fluentd。实际上,它俩的作用是类似的。Logstash产生较早,因此插件较多,Fluentd更为轻量级。fluentd有轻量级的fluentd-bit专门用来发送日志,消耗资源很低,类似与filebeat。
互联网上对Logstash和fluentd进行了对比,我们进行参考:
(https://yq.aliyun.com/articles/3228)
功能项 | logstash | fluentd | logtail |
---|---|---|---|
日志读取 | 轮询 | 轮询 | 事件触发 |
文件轮转 | 支持 | 支持 | 支持 |
Failover处理 (本地checkpoint) | 支持 | 支持 | 支持 |
通用日志解析 | 支持grok(基于正则表达式)解析 | 支持正则表达式解析 | 支持正则表达式解析 |
特定日志类型 | 支持delimiter、key-value、json等主流格式 | 支持delimiter、key-value、json等主流格式 | 支持key-value格式 |
数据发送压缩 | 插件支持 | 插件支持 | LZ4 |
数据过滤 | 支持 | 支持 | 支持 |
数据buffer发送 | 插件支持 | 插件支持 | 支持 |
发送异常处理 | 插件支持 | 插件支持 | 支持 |
运行环境 | JRuby实现,依赖JVM环境 | CRuby、C实现,依赖Ruby环境 | C++实现,无特殊要求 |
线程支持 | 支持多线程 | 多线程受GIL限制 | 支持多线程 |
热升级 | 不支持 | 不支持 | 支持 |
中心化配置管理 | 不支持 | 不支持 | 支持 |
运行状态自检 | 不支持 | 不支持 |
3.4 Kibana到底是个啥?
它是实时的日志收集、处理引擎、前端展示工具
Kibana支持如下几种搜索模式:
•全文搜索
搜索短语要用双引号“ansibletower”
•字段
field: value 例如:http.code:404, _exists_:http:返回结果中需要有http字段
•通配符
?匹配单个字符,*匹配0个或多个字符
•正则
mes{2}age, error*
•模糊搜索
~: 在一个单词后面加上~启用模糊搜索,还可以指定相似度,范围从0.0到1.0,越大越接近搜索的原始值,cromm~0.3会匹配到from和chrome
•逻辑操作
AND OR, +:搜索结果中必须包含此项;-:不能包含此项
+error +hostname –warning*
•范围搜索
[]表示端点数值包含在范围内,{}表示端点数值不在范围内。length:[100TO 200], date:{“now-6h” TO “now”}
Kibana的界面展示十分丰富:
3.5 红帽Openshift日志管理系统
应对分布式环境下日志分散的解决办法是收集日志,将其集中到一个地方。收集到的海量日志需要经过结构化处理,进而交给需要的人员分析,挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的,运营人员关注访问日志,运维人员关注系统日志,开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。
OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力:
● 日志采集,将日志集中在一起
● 索引日志内容,快速返回查询结果
● 具有伸缩性,在各个环节都能够扩容
● 强大的图形查询工具、报表产出工具
EFK是Elasticsearch(以下简写为ES)+ Fluentd+Kibana的简称。ES负责数据的存储和索引,Fluentd负责数据的调整、过滤、传输,Kibana负责数据的展示。
Fluentd无论在性能上,还是在功能上都表现突出,尤其在收集容器日志领域更是独树一帜,成为众多PAAS平台日志收集的标准方案。
4. 红帽客户提供的日志管理/挖掘系统
如前文所述,红帽目前Openshift使用EFK方案。
在非容器化化环境中,红帽有ELK的实施经验,并形成了整体打包方案,对于客户来讲,是开箱即用的。
构建ELK的意义在于:
本方案的三大优势:
ELK方案不仅可以收集、分析、展示几乎所有操作系统以及上面应用的日志。并且还能够对数据进行建模,形成智能化分析报表,而这些报表,对应用人员是十分有帮助的。
如如,针对操作系统:
针对Apache的应用:
针对JBoss应用
还可以分析和挖掘tomcat的日志。详细图标不再展示。
除了标准的应用,红帽ELK方案还可以提供定制化服务: