在需要私有化部署的系统中，大部分系统只提供系统本身的业务功能，如用户管理、财务管理、客户管理等。管理等。但是系统本身还是需要收集日志，收集应用指标，比如请求率，宿主机磁盘，内存占用等。同时，分布式系统日志的便捷查看、指标监控和告警也是系统稳定运行的重要保障。为了在不增加额外的部署和运维工作量的情况下，让私有化部署系统更加健壮，本文提出了一种基于ELK的开箱即用的日志和指标采集方案。一、背景在目前的项目中，我们使用了Elasticsearch作为业务的数据存储，并使用ansible、docker、jenkins组合了一套快速部署工具。配置好需要部署的主机的ssh连接信息后，我们就可以通过jenkins一键部署一个Elasticsearch和Kibana了。本系统遵循以下设计原则：Self-ContainedDeployment：我们将所有的部署脚本、配置文件、Jenkins任务打包成一个标准化的Jenkinsdocker包，只要安装到目标环境就可以部署。所有必需的工具都会立即带入。SingleSourceofTruth：Jenkins中嵌入了yaml格式的配置文件管理器，统一管理所有需要部署的变量。脚本会自动读取这个变量。ConfigurationasCode，InfrastructureasCode：所有配置确认后，后续流程理论上可以完全自动化，所以所有的安装都是通过脚本完成的。2.需求分析在私有化部署环境中，日志的收集和使用有几个特点：需要能够快速部署。由于客户量大，我们需要能够快速部署监控系统，同时要求监控系统本身的运维压力要小。部署组件应该简单而健壮。由于部署环境复杂，希望每个组件本身是健壮的，组件之间的交互尽可能简单，避免复杂的网络拓扑。功能胜过稳定性。由于日志和指标信息本身在宿主机和应用上都有副本，实时监控系统的数据丢失，影响不大。但是如果系统能够提供更强大的功能，对分析会有很大的帮助。性能要求不高。由于私有化环境下对接系统的容量和复杂度是可控的，可以单机部署，查询慢一点也无所谓。同时，需要满足几个需求：需要能够对分布式日志进行收集和集中查看。需要能够采集机器的基本信息，如CPU、磁盘等，并进行监控。最好收集应用程序数据，例如导入数据条目的数量，并对其进行监控。最好能实现异常指标的报警功能。3、方案分析方案有3种备选方案：使用ELK（Elasticsearch、Logstash、Kibana）作为整体监控基础组件，使用Elastic新推出的beat系列作为采集工具。使用Zabbix、Open-Falcon等运维监控工具对系统基础组件进行监控。同时使用自定义指标对数据进行监控和预警。使用TICK（Telegraph、InfluxDB、Chronograf、Kapacitor）作为整体监控基础设施组件。目前只有开源的ELK和商业的Splunk能更好的满足日志的需求。如果Splunk的license费用在预算内可以接受，也可以将方案2和方案3与Splunk结合起来实现。但目前，Splunk高额的许可费用并不为大多数公司所接受。方案二和方案三不能满足收集查看日志的需要，故排除。方案一（ELK）根据我们的需求进一步细化：需要快速部署：通过我们的Jenkins可以实现一键部署。部署组件简单：我们只部署Elasticsearch和Kibana组件，Elasticsearch本身作为最基础的组件是自包含的，不依赖任何外部组件。而且我们不使用集群，我们只采用单机部署来保证Elasticsearch部署的简单性和稳定性。功能胜于稳定：虽然用于业务的Elasticsearch停留在5.5.3版本，但是我们用于日志采集和分析的Elasticsearch直接升级到了7.6.0版本。同时，后续的版本升级也可以更加激进。如果遇到不兼容的情况，有些情况下，不需要保留已有的数据，直接删除数据，重新部署即可。性能要求不高：采用单机部署，Elasticsearch和Kibana部署在同一台机器上。4.日志专用的Elasticsearch、Kibana、Beat为避免日志使用的ES和业务使用的ES发生资源或配置冲突，日志专用ES单独部署，使用内存约3G。日志采集：我们使用ansible在所有相关主机上部署filebeat，用于日志采集。为了简化系统，我们没有使用logstash进行日志预处理，只是简单的配置了filebeat配置文件，加入了我们的jenkins一键部署包。日志查看：由于日志是通过filebeat直接采集到es中的，我们可以直接使用Kibana查看。系统指标收集：我们使用ansible在所有相关主机上部署metricbeat来收集指标。通过配置文件的配置，我们可以收集docker的资源使用情况，系统CPU、内存、磁盘、网络的使用情况，同时也开启了statsd格式的metrics收集端口。现场状态检测：我们使用ansible在网关机器上部署heartbeat进行主动资源可用性检测，监控系统相关的数据库、http服务等相应的状态，并发送到默认的ES存储索引中。5、基于ES的告警Elasticsearch原生的告警是付费功能。为了搭建一个更通用的报警系统，这里使用了一个开源项目elastalert来实现报警。Elastalert是Yelp（美国大众点评）开发的基于python和Elasticsearch的报警系统。可以对接的告警方式有很多，但是大部分都是国外的工具，比如Slack、HipChat、PagerDuty，所以我们目前只使用最基本的邮件告警功能。Elastalert可以配置多种告警类型，例如：某个条件连续触发N次（频率类型）。指标出现的频率增加或减少（尖峰型）。一个metric（flatline类型）N分钟未检测等。每一个告警的配置核心其实是一条elasticsearch查询语句，通过查询语句返回的条目数来判断。目前，我们只使用最基本的频率型报警器。由于这个告警是针对几个具体的私有化部署系统，所以我们提前配置了几个告警配置文件。在部署脚本中，如果没有特殊要求，会全部复制到elastalert系统中，不需要任何手工操作。配置。6.监控仪表盘利用Kibana的可视化功能，我们可以为每个业务系统创建一个监控仪表盘，可以直观的看到所有系统组件的状态和宿主主机的健康状况：Kibana配置自动化Kibana中所有的持久化配置都是一个保存的对象，包括：快速搜索、监控面板、可视化面板、索引配置。我们在内测环境配置了一个用于监控的Kibana之后，通过CI系统定时将配置文件导出存放到git仓库中。下次更新基础组件时，更新脚本会自动导入对应的kibana配置到私有化部署环境中，部署时无需手动配置，实现InfrastructureasCode。7.扩展监控范围这套部署组件也有一个标准的扩展流程。监控更多的应用组件当我们需要监控新的应用组件时。对于服务状态，我们可以简单的在hearbeat的配置中添加应用组件的访问地址，然后我们就可以在监控面板上看到对应组件的状态。对于应用日志，我们可以将日志的文件路径添加到filebeat配置中，然后就可以在Kibana中进行搜索了。监控应用相关指标当我们需要监控应用相关指标时，可以通过statsd接口将指标发布到metricbeat，收集到Elasticsearch中。statsd的底层规则比较简单，所以每个编程语言都有相应的SDK，可以直接使用，不需要复杂的依赖：https://github.com/statsd/statsd/wiki但是目前metricbeat收集的statsd信息是它不支持标签，只能做一些简单的指标采集，不能对同一个指标的不同维度进行聚合分析。新增的服务tracingElasticsearch也带来了APM服务，暂时还没有尝试接入，如果能用的话，是性能监控分析的利器。8.小结在私有化部署环境下，日志采集和监控不像互联网产品那样需要强大的性能和扩展性，开箱即用和强大的功能更为重要。Elasticsearch和Kibana7.6.0版本可以很好的满足这方面的需求。只需提前规范部署流程，准备好配置文件，半小时内即可搭建完备的监控系统。
