写点什么

从零搭建一个基于 ELK 的日志、指标收集与监控系统

2020 年 5 月 18 日

从零搭建一个基于ELK的日志、指标收集与监控系统

在需要私有化部署的系统中,大部分系统仅提供系统本身的业务功能,例如用户管理、财务管理、客户管理等。但是系统本身仍然需要进行日志的采集、应用指标的收集,例如请求速率、主机磁盘、内存使用量的收集等。同时方便的分布式系统日志的查看、指标的监控和告警也是系统稳定运行的一个重要保证。


为了使得私有化部署的系统能更健壮,同时不增加额外的部署运维工作量,本文提出了一种基于 ELK 的开箱即用的日志和指标收集方案。


背景


在当前的项目中,我们已经使用了 Elasticsearch 作为业务的数据储存,同时利用 ansible、docker、jenkins 组合了一套快速部署的工具。在配置好需要部署主机的 ssh 连接信息后,我们可以通过 jenkins 一键部署一个 Elasticsearch 和 Kibana。



这套系统遵循以下的设计原则:


  1. Self-Contained Deployment:我们把所有的部署脚本、配置文件、Jenkins 任务都打包到一个标准化的 Jenkins docker 包中,只要安装到目标的环境上,即可把所有部署所需的工具都一次性带入。

  2. Single Source of Truth:在 Jenkins 中内嵌一个 yaml 格式的配置文件管理器,对于所有部署需要依赖的变量进行统一管理,例如 xx 系统后端对外暴露的端口号,只在 Jenkins 中配置一次,所有的脚本都会自动读取该变量。

  3. Configuration as Code, Infrastructure as Code:当所有的配置确定下来后,后续的流程理论上是可以做到全自动化的,所以所有的安装都通过脚本来完成。


需求分析


在私有化部署的环境中,日志的收集使用有几个特点:


  • 需要能快速部署。由于客户的数量较多,我们需要能快速地部署监控系统,监控系统本身的运维压力需要较小。

  • 部署组件要简单,且健壮性强。由于部署环境较为复杂,希望每个组件自身是健壮的,同时组件之间的交互尽量简单,避免复杂的网络拓扑。

  • 功能性优于稳定性。由于日志和指标信息本身在宿主主机和应用上是有副本的,所以即时监控系统的数据丢失了,影响也不大。但是如果系统能提供更多强大的功能,对于分析是很有帮助的。

  • 性能要求不高。由于私有化环境对接系统的容量和复杂度可控,可以使用单机部署,同时查询慢一些也没关系。


同时需要满足几个需求:


  1. 需要能采集分布式的日志,并且集中式地查看。

  2. 需要能采集机器的基本信息,例如 CPU、磁盘,并进行监控。

  3. 最好能采集应用的数据,例如导入数据的条目数,并进行监控。

  4. 最好能实现异常指标的告警功能。


方案分析


方案上有 3 个备选方案:


利用 ELK (Elasticsearch、Logstash、Kibana) 做整体的监控基础组件,同时使用 Elastic 新推出的 beat 系列作为采集工具。



利用 Zabbix、Open-Falcon 等运维监控工具进行系统基础组件的监控。同时利用自定义指标,进行数据的监控和告警。



利用 TICK (Telegraph、InfluxDB、Chronograf、Kapacitor) 做整体的监控基础组件。



目前日志方面能比较好满足需求的只有开源的 ELK 和商业化的 Splunk,如果 Splunk 的授权费是预算可接受的,也可以使用方案 2、3 结合 Splunk 的方式来实现。但是目前来看 Splunk 高昂的授权费并不是大部分公司可以接受的。方案 2 和 3 在需求上不能很好满足日志的收集和查看功能,所以排除掉了。


方案 1(ELK) 根据我们的需求进一步细化:


  1. 需要能快速部署:通过我们的 Jenkins 可以实现一键部署的功能。

  2. 部署组件简单:我们只部署 Elasticsearch 和 Kibana 组件,同时 Elasticsearch 本身作为最基础的组件是自包含的,不依赖任何外部组件。而我们也不使用集群,只用单机部署,保证 Elasticsearch 部署的简单和稳定。

  3. 功能性优于稳定性:虽然业务使用的 Elasticsearch 停留在 5.5.3 版本,我们日志采集和分析使用的 Elasticsearch 直接升级到 7.6.0 版本,同时后续的版本升级也可以较为激进,如果遇到不兼容的情况,也不需要保留已有数据,删除数据重新部署即可。

  4. 性能要求不高:使用单机部署,Elasticsearch 和 Kibana 部署在同一台机器上。


日志专用的 Elasticsearch、Kibana、Beat


为了避免日志使用的 ES 和业务使用的 ES 在资源或者配置上发生冲突,日志专用的 ES 单独做了一个部署,使用约 3G 内存。


日志采集:


我们在所有相关主机上使用 ansible 部署 filebeat 进行日志的采集,为了简化系统,我们也没有使用 logstash 做日志的预处理,只是简单地配置了 filebeat 的配置文件,并加入了我们的 jenkins 一键部署套件中。


日志的查看:


由于日志直接通过 filebeat 收集到了 es 中,我们使用 Kibana 就能直接进行查看了。



系统指标收集:


我们在所有相关主机上使用 ansible 部署 metricbeat 进行指标的收集,通过配置文件的配置,可以采集到 docker 的资源使用、系统 CPU、内存、磁盘、网络的使用状态,同时也开放了 statsd 格式的指标收集端口。



在现场状态检测:


我们在网关机器上使用 ansible 部署 heartbeat 进行主动的资源可用性探测,对系统相关的数据库、http 服务等监控其相应状态,并将其发送至默认的 ES 储存索引中。



基于 ES 的告警


Elasticsearch 的原生告警是付费功能,为了搭建一个更通用的告警系统,这里用了一个开源的项目 elastalert 实现告警。Elastalert 是 Yelp 公司(美国的大众点评)开发的基于 python 和 Elasticsearch 的告警系统,可以对接的告警途径很多,但是大部分都是国外的工具例如 Slack、HipChat、PagerDuty,所以我们目前只使用了最基础的邮件告警功能。


Elastalert 可以配置多种告警类型,例如:


  • 某条件连续触发 N 次(frequency 类型)。

  • 某指标出现的频率增加或者减少(spike 类型)。

  • N 分钟未检测到某指标(flatline 类型)等。


每个告警的配置核心其实是一个 elasticsearch 的查询语句,通过查询语句返回的条目数来进行判断。


目前我们也只使用了最基础的 frequency 类型告警。由于这个告警是针对特定几个私有化部署的系统,所以我们提前配置好了若干个告警的配置文件,在部署脚本中,如果没有特别需求,就全部复制到 elastalert 的系统中,不需要任何手工配置。


监控大盘


利用 Kibana 的可视化功能,我们可以针对每个业务系统创建一个监控大盘,直观地看到所有系统组件的情况,以及宿主主机的健康情况:





Kibana 配置自动化


Kibana 当中所有持久化了的配置都是一个 Saved Object,包括:快捷搜索、监控大盘、可视化面板、索引配置。


我们在内部的测试环境中配置好了一个监控用的 Kibana 后,将配置文件通过 CI 系统定期导出储存于 git 仓库中,下一次更新基础组件时,更新脚本就会自动将对应的 kibana 配置导入到私有化部署的环境中,在部署时不需要任何手工配置,实现 Infrastructure as Code。


扩展监控范围


这套部署组件在扩展上也是有一个标准流程的。


监控更多的应用组件


当我们需要监控新增的应用组件时。


  • 对于服务状态,我们可以简单地将应用组件的访问地址加入 hearbeat 的配置中,就可以在监控面板看到对应组件的状态了。

  • 对于应用日志,我们可以将日志的文件路径加入 filebeat 的配置中,就可以在 Kibana 中搜索到了。


监控应用相关的指标


当我们需要监控应用相关的指标时,我们可以通过 statsd 的接口,将指标发布至 metricbeat,统一收集至 Elasticsearch 当中。statsd 底层规则相对简单,所以在每个编程语言中都有相应的 SDK 可以直接使用,并没有复杂的依赖:


https://github.com/statsd/statsd/wiki


但是目前 metricbeat 收集来的 statsd 信息是不支持 tag 的,所以还只能做一些简单的指标收集,并不能对同一指标的不同维度做聚合分析。


增加服务 tracing


Elasticsearch 当中也带了 APM 服务这个暂时还没有尝试接入,如果可以使用的话,是一个性能监控和分析的利器。



总结


私有化部署的环境中,日志的收集和监控不像互联网产品一样需要较强的性能和可扩容性,开箱即用和功能的强大就较为重要。7.6.0 版本的 Elasticsearch 和 Kibana 在这方面能很好地满足需求,只需要对部署流程进行标准化,并提前准备好配置文件,就可以在半小时内搭建好一整套监控体系。


作者简介:


陈迪,熵简技术合伙人,毕业于上海交大,负责熵简科技大后台及产品架构相关研发工作。


2020 年 5 月 18 日 15:578649

评论 1 条评论

发布
用户头像
拜见大神!怎么加入熵简啊?
2020 年 05 月 18 日 16:33
回复
没有更多了
发现更多内容

第八周作业 (作业二)

Geek_83908e

极客大学架构师训练营

架构师训练营 - 第八周

袭望

「架构师训练营第 1 期」第八周作业

张国荣

MySQL主从复制的原理和注意事项都在这儿了!!

冰河

MySQL 分布式数据库 主从复制 读写分离 并行复制

架构第七周作业

Geek_Gu

极客大学架构师训练营

架构师训练营第八周作业

月殇

极客大学架构师训练营

极客大学架构师训练营第四周作业

井中人

极客大学架构师训练营

第八周作业 (作业一)

Geek_83908e

极客大学架构师训练营

第四周作业

willson

极客大学架构师训练营

Week 8 作业02

Croesus

第八周作业

熊桂平

极客大学架构师训练营

第八周作业

橘子皮嚼着不脆

【架构师训练营第 1 期 08 周】 作业

Bear在挨踢

极客大学架构师训练营

第四周作业

孤星

Week4 作业

evildracula

学习 架构

架构第七周总结

Geek_Gu

极客大学架构师训练营

第五周作业

willson

极客大学架构师训练营

架构师训练营第八周学习总结

文智

性能优化 极客大学架构师训练营

架构2期第4周作业

supersky6

架构师训练营第 1 期 week8 总结

张建亮

极客大学架构师训练营

week08学习总结

追风

架构师一期

第一次电话面试

escray

面经 面试经历 101次面试

架构师训练营第 8 周课后练习

叶纪想

第四周笔记

willson

极客大学架构师训练营

Week4 系统架构

evildracula

学习 架构

架构第八周总结

Geek_Gu

极客大学架构师训练营

[架构师训练营第 1 期] 第八周学习总结

猫切切切切切

极客大学架构师训练营

第四周总结

孤星

手把手教你在Idea中使用Git

jiangling500

git GitHub IDEA

第四周--学习总结

Mr_No爱学习

第四周-作业一

Mr_No爱学习

飞猪Flutter技术演进及业务改造的实践与思考

飞猪Flutter技术演进及业务改造的实践与思考

从零搭建一个基于ELK的日志、指标收集与监控系统-InfoQ