日志来自正在运行的进程的事件流。对于传统的JavaEE应用程序而言,有许多框架和库可用于日志记录。Java Logging (JUL)是Java自身所提供的现成选项。除此之外,Log4j、Logback和SLF4J也是其他一些流行的日志框架。
这些框架都能很好地支持UDP及 TCP。应用程序将日志条目发送到控制台或文件系统。通常使用文件回收技术来避免日志填满所有磁盘空间。
日志处理的最佳实践之一是关闭生产中的大部分日志条目,因为磁盘IO的成本很高。磁盘IO不但会减慢应用程序的运行速度,还会严重影响它的可伸缩性。将日志写入磁盘也需要较高的磁盘容量。当磁盘空间用完之后,就有可能降低应用程序的性能。日志框架提供了在运行时控制日志记录的选项,以限制必须打印及不打印的内容。这些框架中的大部分不仅对日志记录控件提供了细粒度的控制,还提供了在运行时更改这些配置的选项。
另外,日志可能包含重要的信息,如果分析得当,则可能具有很高的价值。因此,限制日志条目本质上限制了用户理解应用程序行为的能力。所以,日志是一把“双刃剑”。
对于传统的单个架构而言,日志管理本身并不存在难点,毕竟所有的日志文件都存储在应用所部署的主机上,获取日志文件或搜索日志内容都比较简单。但分布式系统则不同,特别是微服务架构所带来的部署应用方式的重大转变,都使得微服务的日志管理面临很多新的挑战,主要有以下几种。
微服务架构所带来的直观结果,就是微服务实例数量的增长,伴随而来的就是日志文件的递增。
在微服务架构里,每个微服务实例都是独立部署的,日志文件分散在不同的主机里。如果还是按照传统的运维方式,登录到应用程序所在的主机来查看日志文件,这种方式基本上不可能在微服务架构中使用。所以需要有一套可以管理几种日志文件的独立系统。
从传统部署移到云部署时,应用程序不再锁定到特定的预定义机器。虚拟机和容器与应用程序之间并没有强制的关联关系,这意味着用于部署的机器可能会随时更改。特别是像Docker这样的容器,通常来说都是非常短暂的,这基本上意味着不能依赖磁盘的持久状态。一旦容器停止并重新启动,写入磁盘的日志文件将会丢失。所以不能依靠本地机器的磁盘来写日志文件。
在微服务架构中,微服务实例将运行在孤立的物理或虚拟机上。在这种情况下,跟踪跨多个微服务的端到端事务几乎是不可能的。跨多个微服务的事务如图12-1所示。
在图12-1中,每个微服务都将日志发送到本地文件系统。在这种情况下,事务1先调用应用1,然后调用应用3。由于应用Ⅰ和应用3运行在不同的物理机器上,它们都将各自的日志写入不同的日志文件。这使得难以关联和理解端到端的事务处理流程。另外,由于应用Ⅰ和应用3的两个实例在两台不同的机器上运行,因此很难实现服务级别的日志聚合,最终导致了日志文件的碎片化。
为了解决前面提到的日志管理的挑战,首先需要对传统的日志解决方案进行认真的反思。因此需要新的日志管理解决方案,除了解决上述挑战外,还需要考虑以下的功能。
解决这些问题的方法是集中存储和分析所有日志消息,而不考虑日志的来源。这种新的日志解决方案中采用的基本原则是将日志存储和处理从执行环境中分离出来。
在集中式日志解决方案中,日志消息将从执行环境发送到中央大数据存储。日志分析和处理将使用大数据解决方案进行处理。因为相比与在微服务执行环境中存储和处理大数据而言,大数据解决方案更适合及更有效地存储和处理大量的日志消息。
如图12-2所示,集中化日志管理系统解决方案中包含了许多组件。
这些组件如下。
集中化日志管理的好处是不仅没有本地IO或阻塞磁盘写人,也没有使用本地机器的磁盘空间。
这种架构与用于大数据处理的Lambda架构基本相似。
同时,每条日志信息都包含了上下文及相关ID。上下文通常会有时间戳、IP地址、用户信息、日志类型等。关联ID将用于建立服务调用之间的链接,以便可以跟踪跨微服务的调用。
本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。