可观测性对于软件系统以及软件工程领域都是一个比较新的概念。为什么云原生可观测性在传统的单体软件系统中这个概念没有引起大家的注意呢？这主要是由于系统规模、复杂性以及生态化等多个方面的差异造成的。
首先，传统的单体软件系统规模和复杂度没那么高，开发人员可以通过IDE一次性加载全部或部分代码，并使用断点设置、单步调试等方法定位缺陷的根因和位置。云原生软件系统包含大量分布式的服务，难以一次性加载并进行调试，而且大量的服务间跨进程调用也使得单步调试无法进行。
其次，传统的单体软件系统运行环境的复杂性和不确定性没那么高，故障或问题一般都与代码自身或数据相关，较容易在开发环境下重现问题并进行调试。云原生软件系统往往涉及复杂的大规模分布式运行环境而且其中的服务实例可以动态创建和销毁，因此运行时故障或问题可能与非常复杂的环境因素相关，难以在开发环境中重现。
再次，传统的单体软件系统运行时监控和观测手段较为单一，依赖于代码插桩的动态分析手段开销较大因此在生产环境中使用较少，与此同时软件的模块和组件结构不清晰、隐式交互难以捕捉等问题也限制了可观测性手段的作用。云原生可观测性
软件系统中各个服务实现了物理隔离，服务间通过跨进程通信进行交互，因此服务间边界清晰、服务间交互以一种显式和外化的方式实现。此外，云原生可观测性软件系统持续在线运行，同时有着完善的基础设施支持，因此较容易实现分布式链路
追踪、指标和日志监控体系等可观测性手段。
最后，传统的单体软件系统可以以一种自顶向下的方式掌握整体体系结构设计并通过静态分析（例如分析模块和组件间依赖关系）和演化分析（例如分析模块和组件间的演化耦合）实现架构看护，从而确保软件实现与高层架构设计保持一致。作为
一种复杂的生态系统，云原生可观测性软件系统的持续演化难以通过一种自顶向下的方式进行掌控，各个局部的应用及相关服务以一种相对独立和自主的方式演化。例如，一些大规模微服务系统中出现长达四五百跳的服务调用链路以及依赖环路，
这并不是因为开发人员技术能力和经验不足，而是由于“只见树木、不见森林”的局部视野带来的问题。此外，各个服务独立开发、部署和运行，因此传统的静态分析和演化分析手段无法有效捕捉到服务之间的依赖和交互关系。