来源：_https://www.cnblogs.com/dengb...本文主要介绍如何使用ELKStack帮助我们搭建一个配套日产TB级日志监控系统。在企业级微服务环境中，运行数百或数千个服务被认为是一个相对较小的规模。在生产环境中，日志起着非常重要的作用。排查异常需要日志，性能优化需要日志，业务需要查业务等等。但是，生产中运行着数十万个服务，每个服务都只能存储在本地。当需要日志帮助排查问题时，很难找到日志所在的节点。业务日志的数据价值也难以挖掘。然后将日志输出到一个地方集中管理，然后对日志进行处理，将结果输出为可供运维、研发使用的数据。这是解决日志管理和辅助运维的可行方案，也是企业解决日志的迫切需求。我们的解决方案基于以上需求，我们推出了日志监控系统，如上图所示：日志统一采集、过滤、清洗。生成可视化界面、监控、告警、日志查询。功能流程概览如上图所示：在各个服务节点上埋点，实时收集相关日志。统一的日志采集服务、过滤、日志清洗生成可视化界面和告警功能。我们的架构①我们使用FileBeat作为日志文件收集端。运维通过我们的后台管理界面进行配置。每台机器对应一个FileBeat，每个FileBeat日志对应的topic可以是一对一，也可以是多对一。根据每天日志卷配置的不同策略。除了收集业务服务日志，我们还收集了MySQL慢查询日志和错误日志，以及其他第三方服务日志，比如Nginx等。最后结合我们的自动化发布平台，自动发布每个FileBeat进程并开始。②调用栈、链路、进程监控指标我们采用代理方式：ElasticAPM，这样业务端就不需要改程序了。对于已经在运行的业务系统，为了增加监控而更改代码是不可取的，也是不可接受的。ElasticAPM可以帮助我们收集HTTP接口调用链接、内部方法调用栈、使用的SQL、进程CPU、内存使用指标等，可能有人会有疑问。有了ElasticAPM，其他的日志基本就采集不到了。您还打算用FileBeat做什么？是的，ElasticAPM收集的信息确实可以帮助我们定位80%以上的问题，但是并不是所有的语言都支持，比如：C。其次，它不能帮您收集您想要的非Error日志和所谓的关键日志，例如：调用接口时发生错误，您想查看错误时间点之前和之后的日志；还有打印业务相关方便分析日志。三、自定义业务异常。该异常为非系统异常，属于业务类。APM会将此类异常报告为系统异常。如果以后对系统异常进行告警，这些异常会干扰告警的准确性，并且不能过滤业务异常，因为自定义的业务异常种类很多。③同时，我们对Agent进行了二次开放。收集更详细的GC、堆栈、内存、线程信息。④我们使用Prometheus进行服务器采集。⑤因为我们是Saas服务化的，服务很多，很多服务日志无法统一标准化。这也与历史问题有关。与业务系统无关的系统可以直接或间接连接到现有的业务系统。让它自己改代码去适配，推不过去。牛逼的设计就是让自己和别人兼容，把对方当成攻击自己的目标。许多日志没有意义。例如，在开发过程中，为了方便排查和跟踪问题，ifelse中只打印符号日志，表示是否留下了if代码块或else代码块。一些服务甚至打印调试级别的日志。在成本和资源有限的情况下，所有的日志都是不现实的。就算资源允许，一年下来也是一笔比较大的开销。因此，我们采用了日志优先级收集的过滤、清洗、动态调整等解决方案。首先，将所有日志收集到Kafka集群中，并设置一个较短的有效期。我们目前设置的是一小时，一小时的数据量，我们的资源暂时还是可以接受的。⑥LogStreams是我们用于日志过滤和清洗的流处理服务。为什么要使用ETL过滤器？因为我们的日志服务资源是有限的，但这是不对的。分散在各个服务本地存储介质上的原始日志也需要资源。现在我们只是收集它。收集后，每个服务上的原有资源可以释放日志占用的部分资源。没错，这个计算确实是把每个服务原来的资源分配给日志服务资源，并没有增加资源。然而，这只是理论上的。对于在线服务来说，扩容容易，缩容就没那么容易了。实施起来极其困难。因此，不可能在短时间内将每个服务上使用的日志资源分配给日志服务。在这种情况下，日志服务的资源是所有服务日志当前使用的资源量。存储时间越长，资源消耗越大。如果解决一个非业务或不可解决的问题需要在短时间内投入比解决当前问题带来的收益更多，我想没有领导或公司愿意采用有限资金的解决方案。所以在成本上，我们在LogStreams服务中引入了过滤器，过滤掉有价值的日志数据，从而降低日志服务使用的资源成本。技术我们采用KafkaStreams作为ETL流处理。通过接口配置实现动态过滤清洗的规则。一般规则如下：接口配置日志收集。默认错误级别的日志是完整收集的。以error时间点为中心，在流处理中开一个窗口，收集N个时间点的非Error级别的日志，可以上下配置。默认情况下，只收集信息级别的日志。每个服务可配置100条关键日志，默认收集所有关键日志。在慢SQL的基础上，根据业务分类配置不同耗时的重过滤。根据业务需求实时统计业务SQL，例如：高峰期，统计一小时内类似业务SQL的查询频率。它可以为DBA优化数据库提供依据，比如根据查询的SQL创建索引。在高峰时段，根据业务类型的权重指标、日志级别指标、时段内每项服务的最大日志限制指标、时间段指标，对日志进行动态清洗过滤。根据不同时间段动态缩小时间窗口。日志索引生成规则：根据服务生成的日志文件规则生成对应的索引，例如：一个服务日志分为：debug,info,error,xx_keyword，那么生成的索引也是debug,info,error,xx_keyword加上日期作为后缀。这样做的目的是为了研发习惯使用日志。⑦可视化界面我们主要使用Grafana。在其支持的众多数据源中，有Prometheus和Elasticsearch，与Prometheus可谓无缝对接。而Kibana主要用于APM的可视化分析。日志可视化我们的日志可视化如下：
