对使用开源Elastic Stack(ELK Stack)和Zabbix搭建新一代日志集中分析与告警集中监控平台的嘴上说说的研究

2018/12/17 21:57 下午 posted in 视角 comments

近期因需要搜集ELK资料比较频繁，加上道听途说Zabbix一搜发现是一个日志监控告警程序（PS: Web UI是PHP写的，果然PHP是世界上最好的语言~），搜集了下资料发现
ELK Stack中的logstash有Zabbix相关插件(Zabbix Output Plugin)，说明这个玩意跟ELK如果很好的利用起来的话，是能够建起来一个具有生产力的日志集中分析与告警集中监控平台的。

有如此想法的情况下，我又进一步搜了下资料，发现确实有人做了这个，但是实在是不多。现就这个话题简单写一下现在已有研究情况以及自己的想法。

注：本文在本站以“视角”为栏目发布，不涉及实际技术内容，文中所示代码为网上搜集，并未完全亲身验证，仅供资料积累参考。

一、简要介绍

（一）Elastic Stack(ELK Stack)介绍

ELK是三个开源软件的缩写，分别为：Elasticsearch 、 Logstash以及Kibana , 它们都是开源软件。不过现在还新增了一个Beats，它是一个轻量级的日志收集处理工具(Agent)，Beats占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具，目前由于原本的ELK Stack成员中加入了Beats工具所以已改名为Elastic Stack。

Elastic Stack包含：

Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。详细可参考Elasticsearch权威指南(参考文献11)。
Logstash主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往Elasticsearch上去。
Kibana也是一个开源和免费的工具，Kibana可以为 Logstash 和 Elasticsearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。
Beats在这里是一个轻量级日志采集器，其实Beats家族有6个成员，早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计。

###（二）Zabbix介绍

Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。Zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。

Zabbix由两部分构成，Zabbix Server与可选组件Zabbix Agent。

Zabbix Server可以通过SNMP，Zabbix Agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X等平台上。
Zabbix Agent需要安装在被监视的目标服务器上，它主要完成对硬件信息或与操作系统有关的内存，CPU等信息的收集。

二、官方情况

关于日志收集，其实Zabbix也可以，但是像做到Elastic公司这么大的成套程序的且具有一定社群基础的情况下，Zabbix定位为一个监控告警程序显然在日志收集方面有些鸡肋。而已经有ELK甚至称为ELKB技术栈的Elastic亦是有其官方提供的监控告警程序——“X-pack”，X-pack对Elastic Stack提供了安全、警报、监控、报表、图表于一身的扩展包，但是……这个玩意是收费的……

秉着薅资本主义羊毛与拿来主义，坚决不给洋鬼子交半毛钱的精神（手动斜眼），Zabbix映入了我们的眼帘。而Elastic也拿出了资本主义“仅有的风度”，提供了Zabbix Output Plugin插件(见参考文献1)，这个插件是官方文档给出的，因此是官方钦定的可以使用的插件。

而同时，Zabbix也有连接Elasticsearch API的相关官方测试文档给出(见参考文献3)，但是官方也标记了其仍在测试之中，并未正式正名，但是未来整合进Zabbix的正式版发布也是可期的。

因此从目前官方态度来看，两款工具在日志收集和集中监控方面可以强强联合，做到运维事件收集、告警监控、事后分析、经验总结“一条龙服务”。

三、当前实践与公开资料

下面是收集的几篇资料的内容，摘取了一些核心内容，其他的内容详见参考文献。

日志分析告警平台ELK+Zabbix的组合实践

Zabbix具有强大的告警策略，同时具有针对业务API 自定义配置告警触发器配置功能。结合已经部署的Zabbix告警系统（硬件监控以及自带的Zabbix API），因此采用该ELK+Zabbix告警策略。

该平台可以实现日志实时和离线分析、业务和硬件指标告警以及服务器性能指标查看等功能。架构如下图所示：

如上图所示，通过调度读写日志流可以做到采集与清洗，进而被logstash传输写入Elasticsearch，基于Elasticsearch 提供的API 我们封装自定义业务接口（监控探测接口、业务指标分析接口）；Zabbix一方面通过Zabbix agent 提供硬件指标检测功能，

另一方面通过配置自定义触发器去探测业务监控接口。同时，基于Zabbix 提供的Zabbix API 我们也可以封装Zabbix 用以监控硬件指标结果。

最后我们可以在webserver app 上展现各种业务指标分析以及基于ZabbixAPI 封装的硬件指标，这样做的好处是你可以自由定制化，在大屏上展现炫酷的效果。当然平常开发用，kibana 和 Zabbix 做扮演的图形化展示功能，倒也够用了。

这里多说一句，kibana 自定义的图形化展现配置方式功能的设计方案很赞，你可以在上面自定义数据源、自定义图形化展现方式，自定义维度与度量、自定义图形化属性，自定义配置仪表盘等等。这对于做olap的同学大有益处。

本小节为参考文献5.

利用ELK分析日志，以及通过Zabbix实现告警

该博主边学习实践边记录，内容较多且基本为配置代码，故不在这记录，请参见参考文献4.

ELK对Tomcat日志双管齐下-告警触发/Kibana日志展示

Tomcat，相信大家并不陌生，Tomcat是一个免费开源的web应用服务器，属于轻量级的应用服务器，在小型系统和并发不是很高的场景下被普遍使用，同时也是开发测试JSP程序的首选。也是处理jsp动态请求不错的选择。

我们都知道通过日志定位Tomcat的问题，那么，我们有真正了解过Tomcat的日志吗？如何做到对tomcat的日志实时监控，分析展示呢？

tomcat日志剖析

我们的Tomcat主要有两种日志类型，即访问日志（localhost_access_log.Y-M-D.txt）以及运行状态日志（catalina.out）。localhost_access_log.Y-M-D.log访问日志主要是记录访问的时间，IP以及访问的资料等相关信息，catalina.out其实记录了tomcat运行状态信息以及异常告警信息等。

我们如何对上面的日志进行监控和分析展示呢？首先我们可以通过logstash-output-Zabbix插件监控catalina.out的日志输出信息，过滤出异常关键词，并推送到Zabbix平台上，实时告警。第二，我们可以将访问日志localhost_access_log.Y-M-D.log进行收集推送到Kibana平台上进行展示，两者互不影响。

该博主文章中有一定实现，请参见参考文献6.

带你了解Zabbix整合ELK收集系统异常日志触发告警

今天来了解一下关于ELK的“L”-Logstash，没错，就是这个神奇小组件，我们都知道，它是ELK不可缺少的组件，完成了输入（input），过滤（fileter），output（输出）工作量，也是我们作为运维人员需要掌握的难点，说到这里，又爱又恨；“爱之好，恨之难”。这个Logstash拥有这强大的插件功能，除了帮我们过滤，高效的输出日志，还能帮我们与Zabbix监控相结合？

因为我们的Logstash支持多种输出类型，能够收集web服务日志，系统日志，内核日志；但是；竟然是有日志输出，肯定避免不了错误（error）日志的出现；当Error日志出现的时候，虽然可以通过ELK查找出来，但是ELK不能实时提供报警，这就有点尴尬了，我们要做的就是能够像Zabbix，nagios监控那样，不能要做到监控，还要做到报警，这一点，ELK只做到了监控，但是没有做到报警；不过没关系，我们的Logstash插件能够与Zabbix结合起来，将需要告警的日志收集起来（比如说有错误标识的日志）完成日志监控触发告警~

logstash支持多种输出介质，比如说syslog、http、tcp、Elasticsearch、kafka等，如果我们将logstash收集的日志输出到Zabbix告警，就必须要用到logstash-output-Zabbix插件，通过这个插件将logstash与Zabbix整合，logstash收集到的数据过滤出错误信息的日志输出到Zabbix中，最后通过Zabbix告警机制触发；

[root@localhost ~]# /usr/local/logstash/bin/logstash-plugin install logstash-output-Zabbix      #安装logstash-output-Zabbix插件
Validating logstash-output-Zabbix
Installing logstash-output-Zabbix
Installation successful

环境案例需求：

通过读系统日志文件的监控，过滤掉日志信息中的异常关键词，如ERR、error、Failed、warning等信息，将这些带有异常关键词的异常日志信息过滤出来，然后输出到Zabbix，通过Zabbix告警机制实现触发告警。下面环境是filebeat作为采集端，输出到kafaka消息队列，最后由logsatsh拉取日志并过滤，输出到Zabbix。

我们来捋一下思路：

我们的架构基本不变，仍然是filebat收集日志推送到kibana消息队列，然后由Logstash前去拉取日志数据，经过处理最后中转出去；只不过是中转输出到Zabbix上面而已；能够实现这个功能的，最核心的功臣就是Logsatsh的插件（logstash-output-Zabbix）。在这里需要注意的是：filebeat收集端的IP一定要与Zabbix监控主机的IP相对应，否则日志是过不来的~

该博主文章中有一定实现，请参见参考文献7.

四、个人思考与不负责任总结

目前从表面上来看，ELK+Zabbix的架构来实现日志集中分析与告警集中监控平台是有可能的，但是是否真的可以实际作为生产力使用还是有待商榷的。虽然ELK和Zabbix两个东西单独提溜出来都没什么大问题，但是一旦整合起来就需要考虑一下很多事情了。比如如下几个问题是至关重要的：

**作为Agent采集，采用哪个。**考虑的问题中，节约资源是一方面，另外还有出现故障的情况下Agent的反应以及Agent对两个程序的兼容性都应对用户以及服务器和应用体验良好才行。
**Agent采集完成之后，对于日志传输又是一个难题。**如何解决阻塞，尤其是因为ELK和Zabbix并不是原生兼容的，如何让其能够顺畅获取接收待处理的日志，也是一个比较关键的问题。
**接上面的问题，除了接收日志的速度，处理日志的速度也是一个方面。**当然可能与日志传输与接收的速度相比，处理日志的速度可能会更可控一点，但是仍然是因为ELK和Zabbix并不是原生兼容，所有东西都需要经过深层测试才能够清楚的知道程序是否可以承载生产力实际的需求。比如高容量多并发的情况。
**在传输端最后就是Zabbix的告警平台问题。**由于其最终Server是一台MySQL+PHP环境的设备，其告警发出的反应速度能否优化的比较好且不易出故障，这也是比较关键的问题。当然如果服务器性能足够，这个问题估计是可以解决的。
**最后就是整体兼容性。**据官方资料和有关博文，Zabbix的操作系统支持情况有些奇特，Linux家族下对于SUSE的支持明确提出需要手工编译才可以使用，因此对于部署其服务可能有一些麻烦事出现。另外还有ELK的日志采集Agent——Beat目前纷繁众多，分类繁杂，如何在系统内尽可能少的运行Agent来做最大效益的事也是需要研究的，虽然Elastic开源了Beat源码（官方称为libbeat）以供开发者定制，但是定制后的Beat稳定性情况如何，仍然是需要研究和测试的。

我猜测，这个架构的思路出现估计也就一两年，毕竟Zabbix是15、16年成熟起来，而Elastic也是在近两年成为分析平台的主流技术栈。哪怕是嗅觉最灵敏的开发者，ELK+Zabbix能够正式成为生产力的架构情况也不会超过两年，因此资料较少、技术支持与经验缺乏的情况是正常的。所以在这个架构没有稳定的测试与接触生产力下的试运行之前，到底这个架构是否可行，仍然是个问号。

但是我比较乐观，因为我是个理想主义者，对一切新事物的发展都充满希冀。哈哈哈。

参考文献

« Certbot泛域名自动续期(非Nginx默认安装路径可用)

离线安装git - 运维手记2018-12-05 »