从传统部署移到云部署时,应用程序不再锁定到特定的预定义机器。虚拟机和容器与应用程序之间并没有强制的关联关系,这意味着用于部署的机器可能会随时更改。特别是像Docker这样的容器,通常来说都是非常短暂的,这基本上意味着不能依赖磁盘的持久状态。一旦容器停止并重新启动,写入磁盘的日志文件将会丢失。所以不能依靠本地机器的磁盘来写日志文件。
事务跨越了多个服务
=========
在微服务架构中,微服务实例将运行在孤立的物理或虚拟机上。在这种情况下,跟踪跨多个微服务的端到端事务几乎是不可能的。跨多个微服务的事务如图12-1所示。
在图12-1中,每个微服务都将日志发送到本地文件系统。在这种情况下,事务1先调用应用1,然后调用应用3。由于应用Ⅰ和应用3运行在不同的物理机器上,它们都将各自的日志写入不同的日志文件。这使得难以关联和理解端到端的事务处理流程。另外,由于应用Ⅰ和应用3的两个实例在两台不同的机器上运行,因此很难实现服务级别的日志聚合,最终导致了日志文件的碎片化。
日志集中化的意义
========
为了解决前面提到的日志管理的挑战,首先需要对传统的日志解决方案进行认真的反思。因此需要新的日志管理解决方案,除了解决上述挑战外,还需要考虑以下的功能。
-
能够收集所有日志消息并在日志消息之上运行分析。
-
能够关联和跟踪端到端的事务。
-
能够保存更长时间的日志信息,以便进行趋势分析和预测。
-
能够消除对本地磁盘系统的依赖。
-
能够聚合来自多个来源的日志信息,如网络设备、操作系统、微服务等。
解决这些问题的方法是集中存储和分析所有日志消息,而不考虑日志的来源。这种新的日志解决方案中采用的基本原则是将日志存储和处理从执行环境中分离出来。
在集中式日志解决方案中,日志消息将从执行环境发送到中央大数据存储。日志分析和处理将使用大数据解决方案进行处理。因为相比与在微服务执行环境中存储和处理大数据而言,大数据