老大要我搭建一个TB级的日志监控系统，据说 ELK 不错

本文主要介绍怎么使用 ELK Stack 帮助咱们打造一个支撑起日产 TB 级的日志监控系统。

在企业级的微服务环境中，跑着成百上千个服务都算是比较小的规模了。在生产环境上，日志扮演着很重要的角色，排查异常须要日志，性能优化须要日志，业务排查须要业务等等。然而在生产上跑着成百上千个服务，每一个服务都只会简单的本地化存储，当须要日志协助排查问题时，很难找到日志所在的节点。也很难挖掘业务日志的数据价值。那么将日志统一输出到一个地方集中管理，而后将日志处理化，把结果输出成运维、研发可用的数据是解决日志管理、协助运维的可行方案，也是企业迫切解决日志的需求。

咱们的解决方案

经过上面的需求咱们推出了日志监控系统，如上图：

• 日志统一收集、过滤清洗。
• 生成可视化界面、监控，告警，日志搜索。

功能流程概览如上图：

• 在每一个服务节点上埋点，实时采集相关日志。
• 统一日志收集服务、过滤、清洗日志后生成可视化界面、告警功能。

咱们的架构

①日志文件采集端咱们使用 FileBeat，运维经过咱们的后台管理界面化配置，每一个机器对应一个 FileBeat，每一个 FileBeat日志对应的 Topic 能够是一对1、多对一，根据平常的日志量配置不一样的策略。

除了采集业务服务日志外，咱们还收集了 MySQL 的慢查询日志和错误日志，还有别的第三方服务日志，如：Nginx 等。

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

②调用栈、链路、进程监控指标咱们使用的代理方式：Elastic APM，这样对于业务侧的程序无需任何改动。

对于已经在运营中的业务系统来讲，为了加入监控而须要改动代码，那是不可取的，也是没法接受的。

Elastic APM 能够帮咱们收集 HTTP 接口的调用链路、内部方法调用栈、使用的SQL、进程的 CPU、内存使用指标等。

可能有人会有疑问，用了 Elastic APM，其它日志基本均可以不用采集了。还要用 FileBeat 干吗？

是的，Elastic APM 采集的信息确实能帮咱们定位 80% 以上的问题，可是它不是全部的语言都支持的好比：C。

其2、它没法帮你采集你想要的非 Error 日志和所谓的关键日志，好比：某个接口调用时出了错，你想看出错时间点的先后日志；还有打印业务相关方便作分析的日志。

其3、自定义的业务异常，该异常属于非系统异常，属于业务范畴，APM 会把这类异常当成系统异常上报。

若是你后面对系统异常作告警，那这些异常将会干扰告警的准确度，你也不能去过滤业务异常，由于自定义的业务异常种类也很多。

③同时咱们对 Agent 进行了二开。采集更详细的 GC、堆栈、内存、线程信息。

④服务器采集咱们采用普罗米修斯。

⑤因为咱们是 Saas 服务化，服务 N 多，不少的服务日志作不到统一规范化，这也跟历史遗留问题有关，一个与业务系统无关的系统去间接或直接地去对接已有的业务系统，为了适配本身而让其更改代码，那是推不动的。

牛逼的设计是让本身去兼容别人，把对方当成***本身的对象。不少日志是没有意义的，好比：开发过程当中为了方便排查跟踪问题，在 if else 里打印只是有标志性的日志，表明是走了 if 代码块仍是 else 代码块。

甚至有些服务还打印着 Debug 级别的日志。在成本、资源的有限条件下，全部全部的日志是不现实的，即便资源容许，一年下来将是一比很大的开销。

因此咱们采用了过滤、清洗、动态调整日志优先级采集等方案。首先把日志全量采集到 Kafka 集群中，设定一个很短的有效期。

咱们目前设置的是一个小时，一个小时的数据量，咱们的资源暂时还能接受。

⑥Log Streams 是咱们的日志过滤、清洗的流处理服务。为何还要 ETL 过滤器呢？

由于咱们的日志服务资源有限，但不对啊，原来的日志分散在各各服务的本地存储介质上也是须要资源的哈。

如今咱们也只是聚集而已哈，收集上来后，原来在各服务上的资源就能够释放掉日志占用的部分资源了呀。

没错，这样算确实是把原来在各服务上的资源化分到了日志服务资源上来而已，并无增长资源。

不过这只是理论上的，在线上的服务，资源扩大容易，收缩就没那么容易了，实施起来极其困难。

因此短期内是不可能在各服务上使用的日志资源化分到日志服务上来的。这样的话，日志服务的资源就是当前全部服务日志使用资源的量。

随存储的时间越长，资源消耗越大。若是解决一个非业务或非解决不可的问题，在短期内须要投入的成本大于解决当前问题所带来收益的话，我想，在资金有限的状况下，没有哪一个领导、公司愿意采纳的方案。

因此从成本上考虑，咱们在 Log Streams 服务引入了过滤器，过滤没有价值的日志数据，从而减小了日志服务使用的资源成本。

技术咱们采用 Kafka Streams 做为 ETL 流处理。经过界面化配置实现动态过滤清洗的规则。

大概规则以下：

• 界面化配置日志采集。默认 Error 级别的日志全量采集。
• 以错误时间点为中心，在流处理中开窗，辐射上下可配的 N 时间点采集非 Error 级别日志，默认只采 info 级别。
• 每一个服务可配 100 个关键日志，默认关键日志全量采集。
• 在慢 SQL 的基础上，按业务分类配置不一样的耗时再次过滤。
• 按业务需求实时统计业务 SQL，好比：高峰期阶段，统计一小时内同类业务 SQL 的查询频率。可为 DBA 提供优化数据库的依据，如按查询的 SQL 建立索引。
• 高峰时段按业务类型的权重指标、日志等级指标、每一个服务在一个时段内日志最大限制量指标、时间段指标等动态清洗过滤日志。
• 根据不一样的时间段动态收缩时间窗口。
• 日志索引生成规则：按服务生成的日志文件规则生成对应的 index，好比：某个服务日志分为：debug、info、error、xx_keyword，那么生成的索引也是 debug、info、error、xx_keyword 加日期做后缀。这样作的目的是为研发以原习惯性地去使用日志。

⑦可视化界面咱们主要使用 Grafana，它支持的众多数据源中，其中就有普罗米修斯和 Elasticsearch，与普罗米修斯可谓是无缝对接。而 Kibana 咱们主要用于 APM 的可视分析。

日志可视化

咱们的日志可视化以下图：

来源 | 8rr.co/6UEz