基于开源日志管理系统的设计与构建--构建数据中心一体化运维平台第四篇

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获取信息进行统一的展示

• HEAPSTER用于监控数据的采集https://github.com/kubernetes/heapster
• HAWKULAR METRICS属于开源监控解决方案Hawkular，基于JSON格式管理、展示监控数据http://www.hawkular.org/
• Apache Cassandra是一个开源的分布式数据库，专门用于处理大数据量业务http://cassandra.apache.org/

部署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是个啥

它是实时的日志收集、处理引擎。它做一下几件事：

• 汇聚数据到Elasticsearch
• 支持多种 input, filters 和output插件
• 日志过滤

所以说，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）

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方案还可以提供定制化服务：