资讯内容采集系统(【通讯技术】日志监控系统--如上图（一）)

　　资讯内容采集系统(【通讯技术】日志监控系统--如上图（一）)

　　本文文章主要介绍如何使用ELK搭建TB级日志监控系统。有一定的参考价值。有兴趣的朋友可以参考一下。希望大家看完这篇文章后，有所收获。小编带你一探究竟。

　　在企业级微服务环境中，运行数百个服务被认为是一个相对较小的规模。在生产环境中，日志起着非常重要的作用。排查异常需要日志，性能优化需要日志，业务检查需要业务检查。

　　然而，有数百个服务在生产中运行，每个服务都只是简单地本地化和存储。当需要日志帮助排查问题时，很难找到日志所在的节点。业务日志的数据价值也很难挖掘。

　　然后将日志统一输出到一个地方集中管理，然后对日志进行处理，并将结果输出为可供运维使用的数据，研发是解决日志管理和辅助运维的可行方案，解决日志也是企业的迫切需要。

　　我们的解决方案

　　通过以上需求，我们推出了一个日志监控系统，如上图所示：

　　日志统一采集、过滤和清理。

　　生成可视化界面，监控、报警、日志搜索。

　　功能流程概览如上图所示：

　　每个服务节点上的埋点，实时采集相关日志。

　　经过统一的日志采集服务、过滤、清理日志，生成可视化界面和告警功能。

　　我们的架构

　　①日志文件采集，我们使用FileBeat，运维通过我们的后台管理界面进行配置。每台机器对应一个FileBeat，每个FileBeat日志对应的Topic可以是*敏*感*词*、多对一，根据每天的日志量配置不同的策略。

　　除了采集业务服务日志，我们还采集了MySQL慢查询日志和错误日志，以及其他第三方服务日志，如Nginx等。

　　最后结合我们的自动化发布平台，自动发布并启动每个FileBeat进程。

　　②我们用于调用栈、链接、进程监控指标的代理方式：Elastic APM，这样业务端就不需要改程序了。

　　对于已经在运行的业务系统来说，为了加入监控而修改代码是不可取的，也是不可接受的。

　　Elastic APM 可以帮助我们采集 HTTP 接口调用链接、内部方法调用堆栈、使用的 SQL、进程 CPU、内存使用指标等。

　　有些人可能会有疑问。如果使用Elastic APM，其他日志基本可以不用采集。为什么要使用 FileBeat？

　　是的，Elastic APM采集的信息确实可以帮助我们定位80%以上的问题，但并不是所有语言都支持，比如C。

　　它的二、它帮不了你采集你想要的非错误日志和所谓的关键日志，比如：调用某个接口时发生错误，你想查看在错误发生之前和之后记录；还有打印业务相关的日志，方便分析。

　　三、 自定义业务异常属于非系统异常，属于业务范畴。APM 会将此类异常报告为系统异常。

　　如果后期出现系统异常告警，这些异常会干扰告警的准确性，并且由于自定义业务异常种类繁多，无法过滤业务异常。

　　③同时，我们开了两次Agent。采集更详细​​的GC、堆栈、内存、线程信息。

　　④Server采集 我们使用Prometheus。

　　⑤由于我们是Saas服务化，服务很多，很多服务日志无法统一和标准化。这也与历史问题有关。与业务系统无关的系统，直接或间接与现有业务系统相连。如果你让它改变代码以适应自己，它不能被推送。

　　厉害的设计就是让自己和别人兼容，把对方当成攻击的对象。许多日志毫无意义。例如，在开发过程中，为了方便排查和跟踪问题，在if else中打印出来只是一个签名日志，代表if代码块或else代码块是否消失了。

　　一些服务甚至打印调试级别的日志。在成本和资源有限的情况下，所有的日志都是不现实的。即使资源允许，一年下来也是一笔不小的开支。

　　因此，我们采用了过滤、清理、动态调整日志优先级等方案采集。首先将所有日志采集放入Kafka集群，并设置一个较短的有效期。

　　我们目前设定的是一小时，一小时的数据量，我们的资源暂时还可以接受。

　　⑥Log Streams是我们对日志过滤和清理的流处理服务。为什么需要 ETL 过滤器？

　　因为我们的日志服务资源是有限的，但是是不对的。原创日志分散在各个服务的本地存储介质上，同样需要资源。

　　现在我们只是采集它。采集后，每个服务上的原创资源可以释放日志占用的部分资源。

　　没错，这个计算确实是把原来的服务的资源化划分到了日志服务资源中，并没有增加资源。

　　然而，这只是理论上的。有了在线服务，资源很容易扩展，但收缩却不是那么容易。实施起来极其困难。

　　因此，不可能在短时间内将每个服务使用的日志资源分配给日志服务。在这种情况下，日志服务的资源就是当前所有服务日志使用的资源量。

　　存储时间越长，资源消耗越大。如果在短时间内解决一个非业务或不可或缺的问题的成本大于解决当前问题的收益，我认为在资金有限的情况下，没有领导或公司愿意采用解决方案。

　　因此，我们从成本的角度，在Log Streams服务中引入了过滤器来过滤没有价值的日志数据，从而降低日志服务的资源成本。

　　技术 我们使用 Kafka Streams 作为 ETL 流处理。动态过滤和清理的规则是通过接口配置来实现的。

　　一般规则如下：

　　基于接口的配置日志 采集。默认的错误级别日志都是 采集。

　　以error时间点为中心，在流处理中打开一个窗口，向上和向下辐射N个可配置的时间点采集非Error级别的日志。默认情况下，仅使用信息级别。

　　每个服务可以配置100个key log，默认key log都是采集。

　　在慢SQL的基础上，根据业务分类，用不同的耗时配置再次过滤。

　　根据业务需求实时统计业务SQL，如：高峰期，同类业务一小时内SQL查询频率统计。它可以为 DBA 提供优化数据库的基础，例如根据查询 SQL 创建索引。

　　在高峰时段，根据业务类型的权重指标、日志级别指标、时间段内各业务的最大日志限制指标、时间段指标对日志进行动态清理和过滤。

　　根据不同的时间段动态缩小时间窗口。

　　日志索引生成规则：根据服务生成的日志文件规则生成相应的索引，例如：一个服务日志分为：debug、info、error、xx_keyword，那么生成的索引也是debug、info、error、 xx_keyword 加上日期作为后缀。这样做的目的是为了习惯性地使用日志进行研究和开发。

　　⑦可视化界面我们主要使用Grafana。它支持的众多数据源中，有Prometheus和Elasticsearch，可谓与Prometheus无缝对接。我们主要使用 Kibana 进行 APM 的可视化分析。

　　日志可视化

　　我们的日志可视化如下：

　　感谢您仔细阅读这篇文章，也希望文章编者分享的《如何使用ELK构建TB级日志监控系统》对大家有所帮助，也希望大家将支持蜗牛。博客，关注蜗牛博客行业资讯频道，更多相关知识等你学习！