使用ELK可以构建TB级别的日志监测体系

这篇文章将告诉你如何利用ELK栈构建高可扩展的日志管理系统以支持每天亿级数据监控。在企业级的微服务环境中，跑着成百上千个服务都算是比较小的规模了。在生产环境上，日志扮演着很重要的角色，排查异常需要日志，性能优化需要日志，业务排查需要业务等等。

然而在生产上有着成百上千个服务，每个服务都只会简单的本地化存储，当需要日志协助排查问题时，很难找到日志所在的节点。也很难真正的挖掘包含业务运作日志的数据背后的价值。

那么将日志统一输出到一个地方集中管理，然后将日志处理化，把结果输出成运维、研发可用的数据是解决日志管理、协助运维的可行方案，也是企业迫切解决日志的需求。

日志文件采集端我们使用 FileBeat，运维通过我们的后台管理桌面化配置，每个机器对应一个 FileBeat，每个 FileBeat日志对应的 Topic 可以是一对一、多对一，根据日常的日志量配置不同的策略。

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

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

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

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

由于我们是 Saas 服务化，服务 N 多，很多的服务日志做不到统一规范化，这也跟历史遗留问题有关，一个与业务系统无关的系统去间接或直接地去对接已有的业务系统，为了适配自己而让其更改代码，那是推不动的。所以，我们需要一个可以自动更新代码的系统，这样才能保证系统的稳定性，同时也不会影响业务系统的正常运行。

（编辑：银川站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!