随着大量云原生技术的应用，IT系统日益复杂，主动感知、预测故障并迅速定位、排障的难度变得越来越大，传统监控方式已无法跟上需求，由此应运而生的可观测性，被视为未来云环境生产部署不可或缺的技术支撑。
目前大多数传统企业对可观测性仍处于初步了解阶段，不少互联网公司在可观测性建设上也是起步不久。因此，围绕“从监控到可观测性应如何转变与升级”这一话题，本期dbaplus话题接力专栏，特别采访到知乎全链路可观测系统和接入层网络负责人-熊豹、虎牙直播SRE平台研发团队负责人-匡凌轩、好大夫基础架构部高级工程师-方勇三位老师，希望能通过他们在可观测性领域的研究心得和实践经验，帮助广大技术从业者准确认识可观测性、给企业搭建适配自身发展的可观测体系提供建议和启发。
熊豹：“正在发生什么 与 为什么会这样”
监控是常见的运维手段，一般是指以观测系统的外部资源使用情况和接口表现来推测系统运行状态，即感知到“正在发生什么”。
可观测性是一种属性，是指在可以感知系统当前运行状态的性质，提升系统的可被观测的性质有助于我们了解“正在发生什么”以及“为什么会这样”。
云原生架构在业内逐步落地，给稳定性建设带来了更多新的挑战：迭代发布更迅速、业务系统更庞大、网络链路更复杂、运行环境更动态。在这样的混沌系统中仅仅只是知道问题发生是不够的，在这样纷繁复杂的环境下赤手空拳的我们很难去进行问题的追踪和溯源。我们要依托分层、多维度的观测数据来构建更立体和智能的诊断系统，以更多样的视角来观察和解读系统。
匡凌轩：“可观测性更多是对业务应用系统自身的要求”
我认为监控是可观测性能力的一部分，初期监控主要是外部对业务应用系统的主动行为，运维是传统监控的使用主体，如：通过业务进程状态、系统资源等监控数据的分析和告警来发现问题。而现在可观测性更多是对业务应用系统自身的要求，如何设计去暴露出更多可被观测的应用运行时的数据，并为这些数据之间建立关联，如：微服务框架在请求处理和RPC调用时提供一些AOP扩展的设计，可以更方便地对请求进行Metric度量和Trace追踪，以及异常情况的上下文关联。
方勇：“从局部到全局可用性视角的延伸”
**两者的关系：**监控和可观测性都旨在辅助建设高可用的服务，缩短故障处理时长，两者往往是密切协作的，界限相对模糊。
**两者的区别：**监控往往关注告警触发的瞬时状态，一般围绕告警事件展开，涉及从告警事件的产生到应急响应等一系列动作。关注的视角一般是局部可用性，关注每个具体的监控项，如CPU负载、剩余内存等。监控是个老生常谈的话题，最常见的场景是系统资源监控、进程或服务状态的粗粒度监控。对定制化的业务指标监控不太友好，另外传统的监控体系对云原生的支持、对微服务体系监控的支持也不太友好。
可观测性可以看作是监控的一种延续，涉及面较广，包括全链路分析（APM）、业务服务质量（SLA）、业务容量等，聚焦服务的整体可用性。关注的视角一般是全局可用性，会忽略不影响服务质量的一些指标，如CPU负载高，服务整体时延波动不大就会忽略这个CPU负载指标。
可观测性的应用场景一般与业务能力相绑定，通过可视化聚合展示影响SLA的相关指标（SLI），再配合监控告警，通过可观测性看板下钻分析异常根因。另外可观测性打通Metrics/Traces/Logs后可主动识别出服务的潜在风险，能先于用户发现问题。
可观测性也有所局限，由于需要收集业务数据，对业务具有一定的侵入性，加上打造可视化平台投入成本较高。另外可观测性整体处于初期阶段，很多工具链还不太完善，价值预期其实是被高估了。
熊豹：“要把可观测性理念贯穿到架构和程序设计中”
目标不一样了，除了要知道“正在发生什么”，还要尝试解释“为什么会这样”。**我们需要把可观测性的理念贯穿到架构和程序设计中，而不是到事发或事后再来补救。**我们需要有意识地设计一些机制来观察业务指标的关联变化、系统架构的数据漏斗模型、程序内逻辑分支的运行开销、外部资源依赖的健康状态，还要暴露程序内的一些资源并发度、池的填充率和命中率、运行时的状态等情况，当运行错误时也要在错误信息中携带足量的上下文信息。
运维同学要为可观测场景提供更坚实的工具基础，在上述庞大的数据压力下，保障和解决数据存储和查询的性能、资源开销、集群的拓展性和稳定性等问题。
匡凌轩：“从被动监控向主动发现与定位问题的转变”