云原生相关技术「设计行业的现状和发展前景」
最近很多人关注云原生相关技术「设计行业的现状和发展前景」，山东创新网小沐从网上搜集一些关于云原生相关技术「设计行业的现状和发展前景」内容，希望对您有用。
当前，主流可观测性系统主要基于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之家的朋友 来源:CIO之家的朋友们
CIO之家 www.ciozj.com 微信公众号:imciow
