随着大量云原生技术的应用，IT系统越来越复杂，难以实现主动感知和预测故障，快速定位和排除故障越来越大，传统的监控方式已经跟不上需求。由此产生的可观测性被视为未来云环境生产和部署不可或缺的技术支撑。目前，大部分传统企业对可观察性的理解还处于初级阶段，而很多互联网公司才刚刚开始构建可观察性。因此，本期dbaplus话题转播专栏围绕“如何从监控向可观察性转型升级”这一话题，特地采访了知乎全链路可观察性体系和接入层网络负责人熊宝和虎牙，直播SRE平台研发团队负责人，好大富基础设施部高级工程师方勇，希望通过他们在可观察性领域的研究经历和实践经验，帮助技术从业者准确理解可观察性，提出建议以及对企业构建适应自身发展的可观察系统的启示。Q1监控和可观察性之间的关系是什么？有什么不同？能否分析一下两者的侧重点、应用场景、功能、局限性等？雄宝的“发生了什么，为什么会发生”的监控是一种常见的运维方式。一般是指通过观察系统外部资源使用情况和接口性能来推测系统的运行状态，即感知“正在发生什么”。可观察性是一种可以感知系统当前运行状态的属性。提高系统的可观察性有助于我们理解“正在发生什么”和“为什么会这样”。云原生架构在业界逐步落地，给稳定性建设带来了更多新的挑战：更快的迭代发布、更大的业务系统、更复杂的网络链路、更动态的运行环境。在这样一个混乱的系统中，仅仅知道发生了问题是不够的。在如此复杂的环境中，我们很难徒手对问题进行追溯和追溯。我们需要依托层次化、多维度的观测数据，构建更加立体化、智能化的诊断系统，从更加多元的视角来观察和解读系统。况令轩“可观察性更多是对业务应用系统本身的要求。”我认为监控是可观察性能力的一部分。初期监控主要是业务应用系统的外部活动行为。运维是传统监控的主体，如：通过对业务流程状态、系统资源等监控数据的分析和告警发现问题。现在，可观察性更多是业务应用系统本身的需求。如何设计暴露更多可观察的应用运行时数据，并建立这些数据之间的关联，例如：微服务框架在请求处理中提供一些RPC调用时的AOP扩展设计，可以更方便的对请求进行Metric测量和Trace跟踪，以及异常情况的上下文相关性。方勇《从局部到全局可用性视角的扩展》两者的关系：监控和可观察性，都是为了辅助构建高可用服务，缩短故障排查时间。两者往往密切配合，界限相对模糊。两者的区别：监控往往关注告警触发的瞬时状态，一般围绕告警事件展开，涉及从告警事件产生到应急响应的一系列动作。关注的角度一般是本地可用性，关注每一个具体的监控项，比如CPU负载，剩余内存等。监控是一个常见的话题，最常见的场景是系统资源监控、进程或服务状态的粗粒度监控。对自定义业务指标的监控不是很友好。另外，传统监控系统对云原生和微服务系统监控的支持也不是很友好。可观察性可以看作是监控的延续，涉及面很广，包括全链路分析（APM）、业务服务质量（SLA）、业务能力等，关注的是服务的整体可用性。attention的视角一般是全局可用性，一些不影响服务质量的指标会被忽略。比如CPU负载高，整体业务时延波动不大，这个CPU负载指标会被忽略。可观察性应用场景一般会与业务能力绑定，通过可视化聚合展示影响SLA的相关指标（SLI），再配合监控告警，在可观察性大盘上通过下钻分析异常根因。此外，可观察性与Metrics/Traces/Logs打通后，可以主动识别服务的潜在风险，抢在用户之前发现问题。可观察性也是有限的。由于需要采集业务数据，对业务有一定的侵入性，搭建可视化平台的投入成本比较高。此外，可观察性整体处于起步阶段，许多工具链还不完善，因此价值预期实际上被高估了。Q2从监控到可观察性有哪些变化？对运维、开发、架构师等岗位人员提出了哪些新要求？熊豹“将可观察性的概念渗透到架构和程序设计中”的目标则不同。除了知道“发生了什么”之外，我们还必须尝试解释“为什么会这样”。我们需要将可观察性的概念融入到架构和程序设计中，而不是事后补救或事后补救。我们需要有意识地设计一些机制来观察业务指标的关联变化，系统架构的数据漏斗模型，程序中逻辑分支的运行开销，外部资源依赖的健康状态，暴露一些资源并发在program,pool的填充率和命中率，运行时状态等条件，当发生错误时，错误信息中也应该携带足够的上下文信息。运维同学要为可观察的场景提供更坚实的工具基础，在上述庞大数据的压力下，保障和解决数据存储和查询性能、资源开销、集群扩展性和稳定性等问题。况令轩《从被动监控到主动发现和定位问题的转变》我觉得最大的变化是应用系统本身的角色发生了变化，从被动监控到主动发现和定位问题，需要考虑系统本身在应用系统架构设计之初进行了Observability构建。运维、开发、架构师都是各个环节设计的参与者，协作方式也发生了一定的变化：运维：深入熟悉产品业务和应用服务，定义和关联业务指标、应用服务指标、系统资源指标等。开发：在框架层设计实现分布式应用服务运行时的Metric、Trace、Log数据采集。架构师：业务应用系统和可观测系统的整体架构设计，需要关注非侵入式采集上报、多维维度聚合、错误寻根分析、海量数据整体处理和存储等。总体而言，每个角色需要有更多的跨技术知识储备、商业思维和模型抽象能力。方勇的“职责分工、认知意识、排查效率转型升级”个人认为，主要变化包括以下几个方面：职责分工的转变，研发聚焦服务质量后，部分职责开始从运维端到研发端。研发上线后，他不再做手把手的掌柜，开始自己负责服务。认知意识的提升，从被动响应告警到主动提升服务质量。排查效率的提升，从原来的黑盒排查方式，逐渐发展到可视化。对不同岗位的人员也有新的要求：运维需要摆脱传统监控意识的束缚，拥抱云原生监控体系，与其他岗位达成共识，共同打造高可用服务。开发，承担部分运维职责，关注服务可用性，需要MDD（Metrics-DrivenDevelopment）的思想来构建高弹性的服务。架构师在架构设计过程中需要暴露可观察性指标，同时需要提升数据分析能力，对Metrics/Traces/Logs数据进行建模分析，识别服务中的潜在风险。围绕可观察性构建相应的工具链和服务治理平台。Q3可观测性的核心方法论/关键技术是什么？熊豹“数据的采集、存储、分析是核心重点。”可观测性建设的核心重点仍然在数据采集、存储和分析环节。数据采集??的覆盖面可以从多个角度来看：尽量梳理出完整的数据链路，覆盖从终端发起、网关、业务、基础设施的每一层组件；可以从不同的观察角度覆盖，比如已经构建了Metrics、Traces、Logs、ExceptionCollection、Profiler、Debuger、Changelog等类型的数据或能力；系统可以从业务维度、资源瓶颈、关联组件等多个维度进行观察。覆盖建设。在数据存储环节，要注意各类数据的存储和查询系统的选择。最常见的是Metrics、Traces和Logs相关的存储系统，它们都有非常广泛的基础软件选择。其中，相对困难的问题是索引维度爆炸、日志和跟踪存储成本以及与性能相关的问题。一般需要预聚合、预采样、后采样、存储分类策略来解决。在数据分析过程中，需要关联不同数据源的元信息，从多维度的角度构建查询接口。同时，我们还需要关注如何在海量原始数据中发现一些突出异常的数据。一般我们需要构建一些流式检测和聚类分析能力。况令轩关于“收集数据、建立关联、设计模型”的可观测性核心思想：需要收集什么数据，如何建立关联，如何设计模型。以应用服务场景为例：采集：请求量、耗时、错误、容量等，以及线程池、队列、连接池等资源指标。关联：纵向关联请求的上下游链路和调用栈，横向关联请求和处理请求所消耗的应用资源。模型：数据采集与关联、异常定义与分析、全链路错误寻根三个方面的统一模型设计。以上可以指导我们针对不同的业务应用系统进行合理的抽象，构建更加标准的可观察性能力。方勇的《MDD思想提倡指标驱动开发》常用方法论：1.SLI选择：参考GoogleVALET（Volume,Available,Latency,Error,Ticket）模型。Netflix的USE方法，USE是Utilization（使用）、Saturation（饱和度）、Error（错误）。WeaveCloud的RED方法，Request-Rate（每秒接收的请求数）/Request-Errors（每秒失败的请求数）/Request-Duration（每次请求花费的时间，以时间间隔表示）。2.MDD（Metrics-DrivenDevelopment）思想：MDD提倡整个应用开发过程由度量驱动，用实时的度量来驱动快速、准确、细粒度的软件迭代。指标驱动开发的理念，不仅可以让程序员实时感知生产状态，及时定位和终止问题，还可以帮助产品经理和运维人员关注相关业务指标。关键技术：1.数据采集：如果是基于Prometheus生态，有丰富的Exporter可供选择，也可以自己开发相应的Exporter。如果基于文件日志收集，可以考虑Flume、Fluentd等。2、数据分析：基于ClickhouseSQL分析，提取日志指标。如果是Prometheus系统，也有丰富的PromQL可以用来分析相关指标。对于Traces和Logs的分析，一般使用自研的分析引擎，与Metrics打通。3、数据存储：Prometheus本身是一个不错的时序数据库，但是不支持分布式存储。一般会搭配使用远程存储引擎，比如Clickhouse、InfluxDB。跟踪和日志通常可以使用Elasticsearch存储。4、数据展示：数据最终的展示形式需要符合可视化设计方案，支持滚动/下钻。大部分需求都可以通过Grafana呈现。Grafana提供了丰富的插件，支持多种数据库类型，也可以基于Echarts自行开发。如果托管公有云，可以充分利用公有云自带的系统，但有些需要单独付费。Q4Metrics、Traces、Logs如何打通，发挥最大价值？雄宝《基于时间范围内的统计关系或者Label和TraceID关联》我们知道有两种方法：1.基于时间范围内的统计关系：一般的使用习惯是在时间区间内找对应关系MetricexceptionTracesandLogs在时间间隔内有异常行为，这种方法将依赖于对Traces和Logs进行聚类分析的能力。2、基于Label和TraceID关联：基于OpenTelemetryCollector可观察数据采集框架，我们可以通过插件的形式生成访问指标，使用TraceSpan元数据Label，同时将TraceID携带记录到元数据中日志的信息，以便您可以使用相同的TraceID或Label维度进行关联查看。此外，Prometheus目前实现了一个范例特性，可以关联存储Metric和TraceID。这个设计也是蛮有意思的。况令轩“全链接错误的根本原因在于三者之间连接的最大价值。”三个环节最大的价值在于能够找到全链路错误的根源，即从发现请求指标指标异常，通过指标关联分析，逐层下钻。详细的Trace跟踪和具体的ErrorLog，从宏观到详细的错误发现和根本原因定位全过程自动化。虎牙为三者设计了统一的应用监控模型，包括应用服务透明零成本SDK接入，三者数据自动采集关联，以及在虎牙大规模分布式上充分实践的全链路错误寻根算法系统。就整体实践经验而言，最终的商业价值在于帮助研发和运维提升应用服务的故障排查和治理效率。方勇从投入成本（CapEx）、运维成本（OpEx）、响应能力（Reaction）、问题排查有效性等方面，立体全息地分析了整个服务在打通后的可用性（调查）。Metrics、Logs、Traces有以下特点：Logs和Traces一般使用trace_id打通，trace_id一般在尾入口处生成，贯穿整个请求的生命周期，业务记录时可以记录当前的trace_idLogs，让Logs和Traces可以连接起来。Tags模式一般用于和Metrics对接。例如某个服务servername产生的metrics可以关联到Traces中的servername。打通之后就可以在服务名的维度上立体全息的分析整个服务的可用性。Q5如何选择可观测性工具？有通用标准吗？雄宝“高可用、可扩展、降低成本、易运维”我们关注observable工具系统的这些特性：高可用性：observable系统本身作为稳定性的卫士，对可靠性要求更高。可扩展性：我们专注于存储写入和查询能力的可扩展性，以支持更大的数据量。降低成本：观测数据会随着时间的推移逐渐失去价值，最好让历史数据以低成本作废或降级存储介质。易运维：具备一定的自动化能力或自身结构足够简单。况令轩“是不是基于行业标准，容易扩展？”虎牙主要是在OpenTracing标准的基础上深入自研和扩展。通过行业标准，会有足够的开源代码和社区支持，可以省去很多基础代码工作，让我们更加关注自己的业务系统特性和模型设计。现在OpenTelemetry对Metrics、Traces、Logs提供了统一的标准，开源社区也比较流行，是一个值得研究和实践的方向。选择可观察性工具需要考虑两个方面：是否基于行业标准，是否有更多的社区和供应商支持。是否方便扩展，是否更容易将共性和个性结合起来，最终在此基础上构建符合自身业务特点的可观测系统。方勇“根据现有技术栈的需求进行选择，不盲目跟风”。整个技术栈的可观察性分析可以参考下图：工具选择：Metrics：常用的Zabbix、Nagios、Prometheus，以及Prometheus-operator、Thanos等相关高可用部署方案。日志记录：ELKStack、Fluentd、Loki等。跟踪：常用的Jaeger、SkyWalking、Pinpoint、Zipkin、SpringCloudSleuth等。可视化：Grafana。事实上，技术选择并没有具体的标准。每个企业在不同的阶段可能会有不同的选择，适合自己的才是最好的。这里有几点感悟：企业要控制成本预算，一般需要考虑自身发展阶段的实际情况，没必要在一开始就把可观察性全链接起来，可能前期只有传统的Zabbix才能满足需求。根据需要理性选择，没必要盲目跟风。拥抱开源。前期一般使用开源产品，开箱即用，搭顺风车。此外，在选型时还需要考虑周边生态的丰富程度。根据团队的技术栈选择，中间件、业务服务、云原生、物理机监控等的选择必须符合团队现有的技术栈。
