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