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

从零搭建一个基于 ELK 的日志、目标收集与监控系统 在当前的项目中，我们已经使用了 Elasticsearch 作为业务的数据储存，同时利用 ansible、docker、jenkins 组合了一套快速部署的工具。在配置好需要部署主机的 ssh 连接信息后，我们可以通过 jenkins 一键部署一个 Elasticsearch 和 Kibana。 这套系统遵照以下的设计准绳： Self-Contained Deployment：我们把全部的部署脚本、配置文件、Jenkins 任务都打包到一个标准化的 Jenkins docker 包中，只需安装到目标的环境上，即可把全部部署所需的工具都一次性带入。 Single Source of Truth：在 Jenkins 中内嵌一个 yaml 格式的配置文件管理器，对于全部部署需要依靠的变量进行统一管理，例如 xx 系统后端对外暴露的端口号，只在 Jenkins 中配置一次，全部的脚本都会自动读取该变量。 Configuration as Code, Infrastructure as Code：当全部的配置确定下来后，后续的流程理论上是可以做到全自动化的，所以全部的安装都通过脚原来完成。 需求分析 在私有化部署的环境中，日志的收集使用有几个特点： 需要能快速部署。由于客户的数量较多，我们需要能快速地部署监控系统，监控系统本身的运维压力需要较小。 部署组件要简约，且健壮性强。由于部署环境较为简单，期望每个组件本身是健壮的，同时组件之间的交互尽量简约，避开简单的网络拓扑。 功能性优于稳定性。由于日志和目标信息本身在宿主主机和应用上是有副本的，所以即时监控系统的数据丢失了，影响也不大。但是假如系统能供应更多强大的功能，对于分析是很有挂念的。 功能要求不高。由于私有化环境对接系统的容量和简单度可控，可以使用单机部署，同时查询慢一些也没关系。 同时需要满足几个需求： 需要能采集分布式的日志，并且集中式地查看。 需要能采集机器的基本信息，例如 CPU、磁盘，并进行监控。 最好能采集应用的数据，例如导入数据的条目数，并进行监控。 最好能实现特别目标的告警功能。 方案分析 方案上有 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) 依据我们的需求进一步细化： 需要能快速部署：通过我们的 Jenkins 可以实现一键部署的功能。 部署组件简约：我们只部署 Elasticsearch 和 Kibana 组件，同时 Elasticsearch 本身作为最基础的组件是自包含的，不依靠任何外部组件。而我们也不使用集群，只用单机部署，保证 Elasticsearch 部署的简约和稳定。 功能性优于稳定性：虽然业务使用的 Elasticsearch 停留在 5.5.3 版本，我们日志采集和分析使用的 Elasticsearch 直接升级到 7.6.0 版本，同时后续的版本升级也可以较为激进，假如遇到不兼容的情况，也不需要保留已有数据，删除数据重新部署即可。 功能要求不高：使用单机部署，Elasticsearch 和 Kibana 部署在同一台机器上。 日志公用的 Elasticsearch、Kibana、Beat 为了避开日志使用的 ES 和业务使用的 ES 在资源或者配置上发生冲突，日志公用的 ES 单独做了一个部署，使用约 3G 内存。 日志采集： 我们在全部相关主机上使用 ansible 部署 filebeat 进行日志的采集，为了简化系统，我们也没有使用 logstash 做日志的预处理，只是简约地配置了 filebeat 的配置文件，并加入了我们的 jenkins 一键部署套件中。 日志的查看： 由于日志直接通过 filebeat 收集到了 es 中，我们使用 Kibana 就能直接进行查看了。 系统目标收集： 我们在全部相关主机上使用 ansible 部署 metricbeat 进行目标