云原生可观测性技术现状与发展趋势
CIO之家的朋友 CIO之家的朋友们

当前,主流可观测性系统主要基于Metrics、Traces、Logs三大数据类型构建,围绕着这三种数据类型,开源社区构建了多种多样的开源产品,像Prometheus, Cortex, Fluentd, ELK, Loki, Jaeger等。这些开源产品极大的丰富了人们在云原生可观测性实践中的选择。然而,这些开源组件大多专注于解决某个特定场景的可观测性问题,应对复杂业务场景往往会让开发运维人员陷入困境。


人们在云原生可观测性上遇到的困难,是云原生实践中必须克服的阻碍。


为了让客户的云原生之路更加顺畅,各大云计算厂商相继推出云原生可观测性产品。同时,业界主要的监控服务提供商也都迅速跟进,开始在自家产品中支持云原生可观测性能力。


云原生可观测性技术现状



在CNCF landscape中,可观测性相关产品分为Monitoring, Tracing, Logging三大类,这些产品有开源的,也有商业的,比如:

  • Monitoring: Prometheus,Cortex,ZABBIX,  Grafana,sysdig等。

  • Tracing: Jaeger, zipkin, SkyWalking、OpenTracing、OpenCensus等。

  • Logging: Loki, ELK, Fluentd, splunk等



利用这些产品的组合,我们可以比较快速的搭建一个可观测性系统。但是真正用起来会发现各种各样的问题。总结起来有如下几点:


  • 组件繁多: 针对Metrics, Traces, Logs三种数据,往往需要搭建三套独立的系统,内部涉及的组件更多,维护成本很高。

  • 数据不互通:同一个应用不同类型的数据被存储在相互独立的系统,数据不互通,难以发挥数据最大的价值。

  • 厂商绑定:一些商业产品没有遵守社区标准,在数据采集、传输、存储、可视化、告警等阶段都可能与厂商绑定。后续更换方案的成本巨大。



OpenTelemetry

针对以上问题,CNCF社区推出了OpenTelemetry项目。该项目雄心勃勃,旨在统一Metrics、Logs、Traces三种数据,实现可观测性大一统。


OpenTelemetry 最核心的功能是产生、收集可观察性数据,并支持传输到各种的分析软件中,整体的架构如下图所示,其中 OTel SDK 用于产生统一格式的可观察性数据,OTel Collector 用来接收这些数据,并支持把数据传输到各种类型的后端系统。



OpenTelemetry的诞生给云原生可观测性带来革命性的进步,包括:

  • 统一协议:OpenTelemetry 为我们带来了 Metrics、Traces、Logs(规划中)的统一标准,三者都有相同的元数据结构,可以轻松实现互相关联。

  • 统一 Agent:使用一个 Agent 即可完成所有可观察性数据的采集和传输,不需要为每个系统都部署各种各样的 Agent,大大降低了系统的资源占用,使整体可观察性系统的架构也变的更加简单。

  • 云原生友好:OpenTelemetry 诞生在 CNCF,对于各类的云原生下的系统支持更加友好,此外目前众多云厂商已经宣布支持 OpenTelemetry,未来云上的使用会更加便捷。

  • 厂商无关:此项目完全中立,不倾向于任何一家厂商,让大家可以有充分的自由来选择、更换适合自己的服务提供商,而不需要收到某些厂商的垄断或者绑定。

  • 兼容性:OpenTelemetry 得到了 CNCF 下各种可观察性方案的支持,未来对于 OpenTracing 类、OpenCensus、Prometheus、Fluntd 等都会有非常好的兼容性,可以方便大家无缝迁移到 OpenTelemetry 方案上。


OpenTelemetry局限性

OpenTelemetry定位是作为可观测性的基础设施,解决数据产生、采集、传输的问题,后面数据的存储与分析还是依赖各个后端系统。最理想的情况是能有一个后端引擎同时存储所有的Metrics, Logs, Traces数据,并进行统一的分析、关联、可视化。不过目前还没有厂商或开源产品实现了OpenTelemetry统一后端,当前还是不同数据分开存储,数据的统一展示与关联分析依然是一个很大的挑战。


现在已经有一些厂商开始相关的尝试。比如Grafana Labs推出的云原生日志系统Loki, 主要设计理念来源于Prometheus。通过Loki, 用户可以像分析Prometheus指标一样分析日志,也可以基于相同的Labels来关联Metrics和Logs数据。如下图所示,在同一个Grafana面板中,左右分别展示了相关的Metrics和Logs,用户可以方便的对数据进行关联分析。



Metrics、Traces、Logs涵盖了一个应用所能产生的大部分可观测性数据,足以让开发运维人员洞察应用的运行状态。但是在云原生场景下,这些还远远不够,人们需要更加全面的可观测性能力。具体如下:

  • 容器洞察:除了容器应用的监控,人们往往还想知道集群拓扑是怎样的,依赖的底层基础设施和周边云服务是否运行正常。这些除了需要Metrics、Traces、Logs数据之外,还需要依赖云服务提供商去获取基础设施的信息。而这些信息的获取、清洗、存储、分析往往需要定制化的程序去构建。

  • 主动巡检:除了被动的接收监控系统的告警信息之外,主动的检查整个系统健康状态,可以让人们对整个系统运行状态有更全面的理解。主动巡检能力要求可观测软件具备了解整个系统运行细节的能力,并且具备足够的知识库去评判系统。

  • 容量规划与成本优化:云原生场景下,弹性给服务的运行带来了极大的灵活性,也带来了对容量规划和成本优化的需求。可观测性系统需要有能力给出最佳的容量规划与成本优化建议。


业界动态


根据上文的分析不难发现,可观测性问题相对复杂,并且没有开箱即用的最佳方案。为了应对云原生场景下复杂的可观测性问题,各大云计算厂商采用了不同的策略。有些采用多种产品组合的方式,针对不同场景,为客户提供不同的解决方案,比如AWS有CloudWatch、AMP、AMG等产品组合,而阿里云有ARMS、链路追踪、日志服务SLS等;有些厂商则提供了统一的解决方案,比如Azure monitor,Vmware Tanzu Wavefront,华为云CIE等。


AWS:从CloudWatch到AMP/AMG,全面拥抱开源

CloudWatch一直以来都是AWS最主要的监控服务,包含了监控、告警、日志、事件等功能。为了应对云原生可观测性场景,CloudWatch推出了Container Insights功能,并支持Prometheus指标接入。Container Insights为用户构建了Prometheus指标面板,应用性能监控、集群拓扑图等功能。


另外,AWS还与Grafana Labs合作,推出了两款云原生容器监控服务。一款是完全托管的Grafana服务Amazon Managed Service for Grafana(AMG),一款是完全托管兼容Prometheus的监控服务Amazon Managed Service for Prometheus (AMP)。同时,AWS跟进OpenTelemetry项目,发布了定制版的Otel Collector: AWS Distro for OpenTelemetry(ADOT)。通过ADOT、AMP、AMG的组合,AWS解决了安全性、高可用性、扩展性等问题,让客户在AWS上可以借助开源社区的优势与力量实现云原生可观测性。

从CloudWatch Container Insights到AMG/AMP,再到AWS Distro for OpenTelemetry,可以看出AWS在不断增强CloudWatch能力的同时,积极主动的与开源社区合作,并利用社区生态构建云原生可观测性产品。


阿里云ARMS:以应用监控为核心,构建全链路监控能力

阿里云ARMS主要能力围绕应用监控构建,包括前端监控、后端监控、移动端监控、业务监控,云拨测等。整体功能如下图:


为了补足云原生可观测性能力,ARMS又陆续发布了Prometheus监控、容器监控(Container Insights)等功能。


ARMS Prometheus监控采用轻量PromAgent+托管存储的策略,具备更轻量、更稳定、完全兼容开源生态等优点。如下图所示:


ARMS 容器监控借助ARMS Prometheus监控的能力,实现对阿里云容器服务的深度洞察。如下图:


阿里云ARMS不支持日志、链路追踪能力,需要与日志服务SLS,链路追踪服务配合使用才能实现完整的可观测性体验。不过ARMS依托强大的全链路应用监控能力,依然具备很强的市场竞争力。


Azure Monitor:发布Container Insights,兼容Prometheus开源生态

Azure Monitor是Azure统一的监控服务,支持Metrics, Logs, Traces等多种数据类型接入,为客户提供可视化、分析、告警、洞察等功能。总体功能如下图:


与AWS CloudWatch类似,为了更好的支撑云原生可观测性,Azure Monitor推出了Container Insights功能,支持Prometheus类型的Metrics接入。


Azure Monitor也没有直接使用Prometheus,而是基于自研的统一Agent(Log Analytics Agent)支持Prometheus类型Metrics抓取。Azure Monitor Container Insights架构图如下:

Azure Monitor通过自研Agent的方式兼容开源Prometheus,来实现容器洞察。这种做法与AWS Distro for OpenTelemetry和阿里云PromAgent异曲同工,有利于与开源生态整合。同时,统一Agent不仅负责Metrics指标抓取,还负责Logs数据写入。这种统一数据接入能力,有利于节省租户资源和整体可观测性能力统一构建,用户体验较好。


Vmware Tanzu: 收购Wavefront,打造混合云可观测性竞争力

Wavefront是Vmware收购的云计算监控初创公司,以满足VMware将其监控功能扩展到云和容器应用程序的愿景。收购Wavefront也给Vmware带来大量的用户,包括Box、思杰、Clover、Groupon、Intuit、Lyft、SpaceApe、Snowflake和Yammer等。


Wavefront定位为高性能流式分析平台,支持metrics, histograms, traces/spans等多种数据类型,同时也对容器洞察做了专门支持。Wavefront架构图如下:

Wavefront有如下特点:


  • 接入灵活:对多云混合云支持较好,同时支持Metrics, Traces等多种数据接入。

  • 用户体验好:相比于传统云计算厂商中规中矩的UI设计,Wavefront UI设计更加美观,用户体验较好。

  • 集成度高:Wavefront支持Kubernetes容器监控,并且对AWS、Azure,GCP等厂商的云服务以及很多开源中间件做了默认集成,开箱即用。



华为云CIE:云原生可观测性统一解决方案

CIE(CloudNative Insight Engine)是华为云容器团队打造的可观测性统一解决方案。CIE提供跨集群集中统一的云原生容器化应用监控运维能力,支持多集群集中告警、事件管理,指标管理和分布式调用链跟踪能力。借助CIE,用户可以在华为云上获得容器化应用的全栈易用的可观测性能力。CIE有如下产品特点:

1)全面兼容云原生技术

  • 基于原生K8s+Prometheus的监控架构体系,特性增强的开箱即用能力

  • 从容应对容器生命周期动态变化、海量指标的挑战


2)以应用为中心,聚焦业务指标

  • 聚焦应用Golden Signal(RPS,Error,Duration)等,并适时关联资源指标


3)Everything in One Place, 快捷排障

  • 应用全景视图和资源映射,无缝关联告警、事件、日志

  • 分布式调用链和依赖拓扑,应对服务网格化,快速排障


4)一键诊断,主动预测预警

  • 一键式集群业务诊断,关键指标主动预测,提前预警


总结与展望


可观测性是云原生场景必不可少的一环,关系到云原生实践能否在生产环境顺利实施。可观测性技术实施具有技术栈多样,场景复杂,数据规模大等特点,这给人们云原生实践带来了很大的障碍。开源社区针对这个问题,着手构建统一的云原生可观测性技术与规范;各大云厂商与监控服务提供商也都看到了需求和机遇,陆续推出云原生可观测性相关的产品或功能。


目前,云原生可观测性还在发展初期,很多产品都在探索阶段,还有很多问题亟待解决。未来人们对可观测性的需求只会越来越高,华为云CIE紧跟社区最新标准与方案,同时深度融合云原生场景,力图为客户打造云原生可观测性最佳实践。相信在云原生可观测性赛道上CIE一定会崭露头角,让我们拭目以待。



CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢