随着云原生、微服务等新架构、新生态的引入和发展，可观测性（Observability）越来越多地被提及和重视。
1. 为什么云原生一定需要可观测性
- 架构复杂
在云原生时代，容器化的基础设施使应用自身变得更快、更轻，一台主机上可以快速部署和运行几十个甚至上百个容器[1]，而Kubernetes等容器编排平台又提供了良好的负载均衡、任务调度、容错等管理机制。这样，在云原生中，一台主机上应用程序的部署密度及变化频率较传统环境有着巨大的变化。因此，需要可观测性来清晰地发现和记录主机快速变化的应用行为。
另外，应用架构的微服务化使应用之间的访问关系变得异常复杂，客户端的一次服务请求通常会产生包括服务和中间件在内的众多调用关系。清晰地观察到这种调用关系，无论是对于应用性能提升、故障定位还是安全检测，都有着重要的意义。
- 知彼知己
正所谓“未知攻焉知防”，面对云原生架构下的大规模集群以及海量灵活的微服务应用，如果不知道集群中都运行了什么，服务都在做什么，又何谈保护和防范？云原生的最终目标是通过自动化手段，实现敏捷的松耦合系统。因此，云原生安全也一定是符合这种自动化目标的。自动化的安全检测就需要有详细准确的运行状态数据作为支撑，为自动化的云原生安全提供充足的决策依据。可观测性恰恰天然地提供了这样的能力。
- 合规满足
“等保2.0”的四级要求尤其对应用可信提出了明确的动态验证需求，如何在不影响应用的功能、性能，保证用户体验的前提下，做到应用的动态可信验证成为重要的挑战。在云原生中，解决这个问题的核心在于准确地选择应用的可信度量对象，高性能地确定指标的度量值，以及收集和管理验证这些基准值，这些都是对云原生实现可观测的重要意义和应用价值。
2. 需要观测什么
要实现对整个云原生的可观测性，可以逐层实现对应的可观测性。
从基础设施层来看，这里的可观测性与传统的主机监控有一些相似和重合的地方，比如对计算、存储、网络等主机资源的监控，对进程、磁盘IO、网络流量等系统指标的监控等。
对于云原生的可观测性，这些传统的监控指标依然存在，但是考虑到云原生中采用的容器、服务网格、微服务等新技术、新架构，其可观测性又会有新的需求和挑战。例如，在资源层面要实现CPU、内存等在容器、Pod、Service、Tenant等不同层的识别和映射；在进程的监控上要能够精准识别到容器，甚至还要细化到进程的系统调用、内核功能调用等层面；在网络上，除了主机物理网络之外，还要包括Pod之间的虚拟化网络，甚至是应用之间的Mesh网络流量的观测。
从应用层来看，在微服务架构下，主机上的应用变得异常复杂，这既包括应用本身的平均延时、应用间的API调用链、调用参数等，还包括应用所承载的业务信息，比如业务调用逻辑、参数等信息。
3. 如何观测
实现云原生可观测性通常有多种手段和方法，不同手段的侧重点往往略有差别。主要从日志、指标、追踪三个方面来实现。
- 日志
日志（Logging）展现的是应用程序运行产生的事件或记录，可以详细解释其运行状态。日志描述了一些离散的、不连续的事件，对于应用程序的可见性是很好的信息来源，也为应用程序的分析提供了精确的数据源。但是日志数据存在一定的局限性，它依赖于开发者暴露出来的内容，而且其存储和查询需要消耗大量的资源。
- 指标
指标（Metrics）与日志有所不同，日志提供的是显式数据，而指标是通过数据的聚合，对一个程序在特定时间内的行为进行衡量。指标数据是可累加的，它们具有原子性，每个都是一个逻辑计量单元。指标数据可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。
- 追踪
追踪（Tracing）面向的是请求，可以分析出请求中的异常点，但与日志有相同的资源消耗问题，通常需要通过采样等方式减少数据量。追踪的最大特点是它在单次请求的范围内处理信息，任何数据、元数据信息都被绑定到系统中的单个事务上。
最后在CNCF给出的云原生全景图（Cloud Native Landscape）中，将可观测性（Observability）和分析（Analysis）放在了同一个维度。一方面通过实现可观测性的工具，获取系统中各个维度的运行数据，从而对整个云原生架构下的应用运行情况有全面深入的了解；另一方面，在拥有了这些数据之后，可以进行安全性分析、运维故障分析、性能分析等。
