一、单机应用阶段
有赖于本地日志文件，将系统的运行过程中的关键信息，以日志文本的形式，记录在日志文件中。
在这个阶段，诞生了Commons Logging，Log4j，Logback，SLF4j，JDK Logging等一系列的日志框架，辅助大家进行日志打印，让开发人员能够聚焦于日志消息本身，而日志格式，线程信息，日期时间，上下文，日志级别控制与调整，文件滚动等功能则交个日志框架来进行处理，大大方便了开发人员。
应用出现故障后，开发人员可以登录到服务器上，打开日志文件，进行日志分析与故障定位。
二、集群部署阶段
进入集群部署阶段，应用部署的实例数陡增，去服务器上一个个查看应用日志也还能继续，但是已经非常困难，因为服务器数量众多。首先出现问题时，不一定问题出现在哪一台服务器上，如果是普遍问题还好，如果是个别问题，就要首先找到这个问题的日志所在的服务器，然后再登录，打开日志，分析。
日志分散没法方便查看，怎么办？直接的思路是日志采集与汇聚。
开源的ELK，以及各种商业化的产品，都有不少能够做日志采集与汇聚的。在日志采集与汇聚工具的支持下，可以集中的进行日志的人工查看以及分析，搜索等，比登录到服务器上去自己grep日志，要高级和方便的多了。
对于一些标准软件产品以及系统层软件，日志采集与汇聚，是无可奈何的事情，系统层软件的日志格式，又不是自己想调整就调整的，一般是系统层软件自己定义好的，没法轻易改变。所以日志采集与汇聚，在这类软件面前是必须，而且是比较好的一种解决思路。
对于业务层的应用软件，日志采集与汇聚，可以比较直接的从单机日志文件，过渡到集群部署形式下的集中日志分析。是一个能够快速实施和快速见效的方案。但未必是最好的方案。为何这样说呢？集群部署形式的下一个阶段，分布式阶段已经在各个公司是非常流行的应用架构，而集群部署形态下遇到的问题，分布式形式一样会遇到，而且更加突出。
三、分布式应用阶段
既然应用进入了分布式阶段，实例数的增多只是一个方面，更多的情况是各种中间件以及系统软件依赖的增多，交易链路的复杂化，故障场景的复杂化，这时需要的，何止是日志的集中分析能力呢？而是对于整个应用集群的可观测可运维能力提出了新的要求。
在这个阶段，集中化的应用分析与监控体系，才是解决分布式形式下的应用运维问题的灵丹妙药。
比如大众点评的CAT。对于应用的性能，链路采样，典型中间件的支持，都非常不错。在自己的业务应用部署容器中集成CAT，是快速建立集中化的应用分析与监控体系的非常好的一种手段。
四、相关商用产品
在应用分析与监控方面，比较知名的商用产品。
国内产品：
天旦BPC：https://www.netis.com/products/bpc/
国外产品：
DynaTrace：https://www.dynatrace.cn/platform/application-performance-management/
五、回看本地日志在新阶段的必要性
在最前沿的分布式架构下，本地日志，这种最古老的应用分析工具，是否还有存在的必要？其发展趋势是怎么样的？
应用不仅有复杂的生产部署形态，还有在开发阶段的本地调试阶段，以及测试环境的简单部署形态，这开发以及测试简单部署情况下，集中的监控工具有没有都不一定，即便是有的话，去集中的工具上看日志或者分析问题，对于一个开发测试阶段的简单问题来讲，并不比本地日志查看和分析快多少，这种场景，不是集中式的日志分析与应用监控工具所要面对和解决的问题。
在这些场景下，本地日志，依然是最有效和最直接的辅助工具，因此在很长的时间段内，只要还存在本地开发调试阶段以及测试环境的简单部署形态，则本地日志作为直接快速的支持手段，会长期存在且不可替代或者磨灭。
而应用一旦进入生产部署阶段，大规模的分布式架构形态存在，则集中式的日志采集汇聚以及引用分析支持，则成为生产稳定运行以及故障发现与排查所必不可少的工具与依赖。
同时，在生产环境，本地日志是否可以被集中式的监控系统所取代呢？也很难完全取代，对于非大面积的问题与故障，日志文件的原始且忠实的记录，依然是分析问题不可少的现场。而这种现场的记录形式，可能并不能很好的结构化为集中的应用监控工具所抽象出的有限的概念上。
所以不必纠结。生产环境的长治久安需要集中的日志采集与应用监控分析平台，对于大面积功能故障与性能故障做出快速反应与分析，也需要有本地日志配合日志采集工具，完整呈现非结构化的现场信息，来帮助运维人员以及开发人员来定位非典型问题，个别问题等情况。