乐趣区

关于云原生:详聊微服务观测｜从监控到可观测性我们最终要走向哪里

jiezi


作者|刘浩杨
​

导读：为了让大家更好的理解 MSP 中 APM 零碎的设计实现，咱们决定编写一个《详聊微服务观测》系列文章，深刻 APM 零碎的产品、架构设计和根底技术。本文为该系列文章的第一篇，次要分享了咱们在可观测性上的一些思考。
​

前言

Erda Cloud 是咱们行将公布的一站式开发者云平台，为企业开发团队提供 DevOps (_DevOps Platform, DOP_)、微服务治理 (_MicroService Platform，MSP_)、多云治理 (_Cloud Management Platform，CMP_) 以及快数据管理 (_FastData Platform，FDP_) 等云原生服务。
​

作为 Erda Cloud 中的外围平台，MSP 提供了托管的微服务解决方案，包含 API 网关、注册核心、配置核心、利用监控和日志服务等，来帮忙用户解决业务零碎进行微服务化而带来的技术复杂度难题。随同着产品的降级，咱们也全新设计了 以服务观测为核心 的 APM (利用性能监控) 产品，摸索可观测性在利用监控畛域中落地的最佳实际。
​

为了让大家更好的理解 MSP 中 APM 零碎的设计实现，咱们将编写一个《详聊微服务治理》系列文章，深刻 APM 零碎的产品、架构设计和根底技术。本文为该系列文章的第一篇，次要分享了咱们在可观测性上的一些思考。
​

从监控到可观测性

随着近年来云原生概念和云原生架构设计的风行，越来越多的开发团队开始应用 DevOps 模式进行零碎开发，并把大型零碎拆解成一个个渺小的服务模块，以便零碎能更好地进行容器化部署。基于 DevOps、微服务、容器化等云原生的能力，能够帮忙业务团队疾速、继续、牢靠和规模化地交付零碎，同时也使得零碎的复杂度成倍晋升，由此带来了前所未有的运维挑战，比方：
​

  • 模块之间的调用从过程内的函数调用变为过程间的调用，而网络总是不牢靠的。
  • 服务的调用门路变长，使得流量的走向变得不可控，故障排查的难度增大。
  • 引入 Kubernetes、Docker、Service Mesh 等云原生零碎，基础设施层对业务开发团队来说变得更加黑盒。

​

在传统的监控零碎中，咱们往往会关注虚拟机的 CPU、内存、网络、应用服务的接口申请量、资源使用率等指标，但在简单的云原生零碎中，仅仅关注单点或者单个维度的指标，并不足以帮忙咱们把握零碎的整体运行状况。在此背景下，对分布式系统的“可观测性”应运而生。通常，咱们认为可观测性绝对于过来监控，最大的变动就是，零碎须要解决的数据从指标为主，扩大到了更广的畛域。综合起来，大概有几类数据被看作是可观测性的支柱：
​

  • Metrics
  • Tracing
  • Logging

​


Metrics, tracing 和 logging 的关系
​

为了对立可观测性零碎中的数据采集和标准规范，同时提供与供应商无关的接口，CNCF 把 OpenTracing 和 OpenCensus 合并成 OpenTelemetry 我的项目。OpenTelemetry 通过 Spec 标准了观测数据的数据模型以及采集、解决、导出办法，但对于数据如何去应用、存储、展现和告警是不波及的，官网目前的举荐计划是：
​

  • 应用 Prometheus 和 Grafana 做 Metrics 的存储和展现。
  • 应用 Jaeger 做分布式追踪的存储和展现。

​

得益于云原生开源生态的蓬勃发展，技术团队能够轻而易举地建设一套监控体系，比方应用 Prometheus + Grafana 搭建根底监控，应用 SkyWalking 或 Jaeger 搭建追踪零碎，应用 ELK 或 Loki 搭建日志零碎。但对于可观测性零碎的用户来说，不同类型的观测数据扩散存储在不同的后端，排查问题仍须要在多个零碎之间跳转，效率和用户体验都得不到保障。为解决可观测性数据的交融存储和剖析，咱们自研的对立存储和查问引擎，提供了指标、追踪和日志数据的无缝关联剖析。在本文的其余局部，将具体介绍咱们是如何提供针对服务的可观测性剖析能力。
​

观测入口：可观测性拓扑

可观测性提出了三种数据之间的关系，让咱们能够应用标签关联 Metrics 和 Tracing，应用申请上下文去买通 Tracing 和 Log。因而，通常能够应用上面的办法去定位线上利用零碎的接口异样：_应用 Metrics 和 告警发现问题，而后应用 Tracing 定位到可能产生异样的模块，最初应用 Logging 定位到谬误本源_。
​

尽管在大多数工夫里这个办法是卓有成效的，但咱们并不认为这是一个对系统进行观测的最佳实际：
​

  • 尽管基于 Metrics 能够帮忙咱们及时发现问题，但往往咱们发现的是大量单点问题，没有一个全局的视角来观测整个零碎的状态。
  • 业务开发团队须要去相熟 Metrics、Tracing 和 Logging 零碎的各种概念和应用。如果是基于开源组件搭配的监控零碎，还须要在各个系统之间一直跳转能力实现一次问题的排查，明天这在很多公司里是很常见的。

​

咱们在不同畛域用户的监控需要实际中，发现拓扑能够人造的作为观测零碎的入口。不同于常见的分布式追踪平台，咱们不仅仅把拓扑作为利用零碎的运行时架构展现，在基于 100% 采样的实在申请关系绘制出拓扑后，更进一步在拓扑节点上透出服务的申请和服务实例状态（将来还会透出更多的观测数据，比方流量比例、物理节点的状态等）。
​


​

在拓扑页面的布局上，咱们把页面切分为左右两栏，左边的状态栏会显示咱们须要观测的零碎要害指标，如服务实例数、服务的谬误申请、代码异样和告警次数等。当咱们点击拓扑节点时，状态栏会检测节点类型的不同而显示不同的状态数据。以后咱们反对展现状态的节点类型有 API Gateway、服务、内部服务和中间件。
​

当点击服务节点时，状态栏会显示服务的状态概览、事务调用概览和 QPS 折线图
​

如何观测服务？

基于可观测拓扑，咱们能够很容易在全局的视角下察看零碎的整体状态，同时咱们还提供了一种从拓扑下钻到服务以便疾速定位服务故障的观测形式。当发现服务异样时，咱们容许链接到_服务剖析_，在该页面提供了事务、异样和过程三个维度的观测剖析。
​

拿下面提到的接口异样为例，咱们的故障排查形式为：
​

  1. 在事务剖析页查问触发异样的接口 */exception。
  2. 而后点击申请或提早趋势图上的数据点关联接口采样到的慢事务追踪和谬误事务追踪。
  3. 在弹出的追踪列表中查看申请链路详情和申请关联的日志定位谬误本源。

​

找到故障的事务申请
​

主动关联该申请的调用链路
​

为申请链路主动关联日志上下文
​

咱们要走向哪里？

基于本文篇幅的限度，本文将不再过多地去展现产品细节，咱们借助下面的场景，抛砖引玉提出一个可观测性 APM 产品设计的方向：基于零碎和服务观测的角度把不同数据在后端交融剖析，而不是刻意强调零碎反对可观测性三种数据的别离查问，在产品性能和交互逻辑上尽可能对用户屏蔽 Metrics、Tracing、Logging 的割裂。除此之外，咱们也将持续摸索代码级诊断、全链路剖析和智能运维在可观测性畛域的有限可能性。
​

参考

  • 《DevOps 专题 | 监控，可观测性与数据存储》
  • 《Metrics, tracing 和 logging 的关系》

​

欢送参加开源

Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云治理以及快数据治理等平台级能力。点击下方链接即可参加开源 ，和泛滥开发者一起探讨、交换，共建开源社区。 欢送大家关注、奉献代码和 Star！
​

  • Erda Github 地址：https://github.com/erda-project/erda
  • Erda Cloud 官网：https://www.erda.cloud/
退出移动版