共计 7492 个字符，预计需要花费 19 分钟才能阅读完成。
KubeVela 是一个开箱即用的现代化利用交付与治理平台，它通过对立的利用模型、可编程可扩大的架构，帮忙企业构建对立的平台，向上为不同场景的业务团队按需提供差异化、且开箱即用的平台层能力，大大降低了云原生技术的应用门槛。除了外围的云资源交付、利用治理、多集群、工作流等技术，KubeVela 还提供了全栈的申明式可观测能力，帮忙业务开发者灵便定制，轻松洞察各类简单的云原生工作负载。
本文咱们将聚焦 KubeVela 的可观测体系，介绍云原生时代的可观测挑战及 KubeVela 的解决方案。
01 云原生可观测的挑战
通常状况下，为了给下层业务提供可观测性能力，运维团队会通过“熟练掌握”业务团队的应用场景，而后将运行应用服务的基础设施与各类可观测性基础设施连接，通过绝对固化的脚本和零碎，将采集指标、收集日志、聚合解决、图表剖析等一系列流程合并，从而将最底层的运行态实时反馈到监控报警零碎中，为运维团队本身及下层业务团队做预警，并在第一工夫发现异常、排查故障。
（图 1）CNCF landscape 的插件曾经达到 1000+，且每天都在新增
随着云原生生态的一直凋敝，平台工程的理念逐步深入人心，一个根底平台团队往往须要服务下层多个微服务化的业务团队，而业务团队的架构也随着基础设施的丰盛逐步产生了多样性，这就突破了传统保姆式地从“熟练掌握”到“硬编码”的可观测体系建设门路。举例而言，业务团队刚开始构建业务的时候可能应用根底的 ingress 做服务网关，而半年之后可能随着需要的复杂化会切换成以 istio 为外围的流量治理计划，这意味着从 API 到下层架构相干的可观测能力都要跟着扭转。如图 1 所示，在 CNCF landscape 的凋敝生态里，每个子畛域都能找到多个替换计划。传统模式下绝对固定的可观测性体系构建形式不再实用，平台团队须要依据业务层的架构灵便定制和扩大可观测计划。
而“割裂”则是可观测畛域面临的第二个微小挑战，这通常会体现在三个维度。第一个维度是不同业务间数据的割裂，从基础设施（计算 / 存储 / 网络）、容器、利用到业务，从挪动端、前端、后端到数据库和云服务，企业的不同部门通常会采纳不同的监控计划，监控数据彼此造成孤岛，无奈买通。第二个维度是不同基础设施配置的割裂，随着云时代到来，企业面临多云、多集群、多账号的治理，可观测数据分布在不同云和集群内，多云多集群的可观测无奈对立配置。第三个维度是数据链路的割裂，例如开源社区的 Prometheus(Exporter)、Grafana 别离有本人凋敝的社区，但他们的采集源和大盘往往没有很好的连贯在一起，经常是一头输入大量有效数据占用存储资源，另一头则展现谬误或者提早很高的数据。
（图 2）社区找到的具备对应关系的大盘和 Exporter 通常无奈间接应用
而传统监控零碎采纳的基于图形界面点击的配置形式显然也不再实用，尽管上手简略，然而迁徙、复制老本极高。在多集群治理下，监控配置不易于复制，漏采、漏配很常见。也难以与利用交付的配置绑定，无奈实现监控随着利用生命周期而被动变动。
如果沿着云原生申明式对立 API 的理念去思考，你就会发现咱们也须要一套申明式的配置形式，让咱们可能以对立的形式、灵便的对接可观测基础设施，按需串联和定制全套的可观测能力，主动实现监控探针装置、采集、存储、展示、告警等配置的多环境对立下发和治理。这个模式咱们也能够称之为全栈申明式可观测（Full Stack Observability as Code）。
02 全栈申明式可观测
尽管云原生时代的可观测存在诸多挑战，然而也得益于云原生开源技术的倒退，以 Prometheus、Grafana、OpenTelemetry 为代表的可观测基础设施正在逐步成为各自畛域的事实标准，周边生态的集成正在以滚雪球的态势累积，这让可观测基础设施的对立成为了可能。选型这些开源我的项目为外围构建可观测解决方案成为了十分天然的抉择，不仅帮忙咱们对立了技术和数据，还能够让咱们借力生态，疾速满足业务场景的须要。
对立的申明式可观测 API
一个要害的挑战是如何将可观测基础设施的能力变成申明式的？你可能容易想到 Kubernetes 的 CRD（自定义资源）Operator 技术，的确曾经有相当一部分可观测能力能够间接应用 CRD 这样的申明式 API。比方 Prometheus 就能够通过装置 Prometheus-Operator 取得 ServiceMonitor 这个申明式 API。然而还有一部分其余我的项目（比方 Grafana），以及大量的云服务，他们并不具备成熟的 CRD Operator。为每个服务都编写 CRD Operator 存在不小的技术难度，不仅费时费力，同时还要耗费额定的 Pod 资源，整体老本比拟高。
咱们天然会想，是否有一种形式能够这些服务的 API 主动转换成合乎 Kubernetes 规范的申明式 API？针对这种状况，Kubernetes 的 Aggregated API Server（简称 AA）模式提供了答案，即通过开发合乎 Kubernetes API 标准的 REST 服务，通过 APIService 对象将其注册到 Kubernetes apiserver 上，从而达到扩大 Kubernetes apiserver 能解决的申请类型的成果。相较于 CRD + Operator 的模式，AA 模式提供了与 CRD 对立的 API，但处理过程并不是面向终态的，它可能提供同步的申请解决，灵活性和交互性较高。而 AA 模式的毛病则是它本身不具备调谐重试的能力，须要配合额定的伎俩针对出错等异样状态做面向终态的重试。
而 KubeVela 中的 Prism 子项目正是这样一个基于 AA 模式将第三方 API 转换成 Kubernetes 规范 API 的服务，它对接 Kubernetes 的 AA 机制，向上提供对立的 K8s API，向下对接 Grafana 本身的 API，将数据源创立、大盘导入等操作对立融入到了 Kubernetes 用户习惯的 YAML 操作中。比方用户想要在 Kubernetes 上查问已有的 Grafana Dashboard，它能够应用 kubectl get grafanadashboard 命令，调用 Kubernetes API 的 GrafanaDashboard 资源，该申请通过 Prism 后会转换位申请 Grafana API，查问后果则会再次通过 Prism 转回原生的 GrafanaDashboard 资源，从而用户就能够失去和操作 Deployment、Configmap 等原生资源统一的应用体验。
（图 3）KubeVela 通过提供原生 API 接口及 Addon 体系，反对多种形式接入可观测性基础设施
如图 3 所示，Prism 就像一座桥梁，它能够对接用户自建、应用 KubeVela 插件主动装置、应用云服务这三种不同部署状态的差别。不仅如此，因为 AA 模式不强制要求数据存储在 etcd，咱们能够以 Grafana 自身的存储作为数据的源头（Source of Truth），这意味着无论用户是在 Kubernetes API 操作，还是通过 Grafana 的 API，亦或是通过 Grafana 的 UI 进行变更批改，相应的变动都可能即刻反映在各种客户端上。在权限解决上，因为 Grafana API 通过 KubeVela Prism 曾经被映射成了原生的 Kubernetes 资源，因而用户能够齐全依赖在 Kubernetes 的 RBAC 权限管制体系上来调节不同 Kubernetes 用户对于 Grafana 上数据的拜访权限，不须要放心数据穿透及透露问题。
而 AA 模式本身不具备的谬误重试，则能够联合利用自身的生命周期，交由 KubeVela 控制器对 Kubernetes API 返回状态对立做调谐，从而达到面向终态的申明式解决模式。
围绕利用生命周期的灵便编排
当基础设施的能力都能通过 Kubernetes API 用对立的形式形容时，咱们还剩下两个外围问题须要解决：
1. 如何灵便编排这些可观测的申明式 API，融入利用的生命周期中？
2. 如何针对不同的可观测场景，做到灵便扩大、按需定制？
而这两个外围问题与 KubeVela 始终以来保持的设计准则绝对应。
- 以工作流为外围的利用交付模型。基于 Kubernetes API 做编排的轻量级工作流引擎始终是 KubeVela 的“杀手锏”，它不仅可能以 DAG 的形式实现各种带上下文的简单工作流编排场景，还能围绕利用的生命周期对资源做治理，包含利用删除时对资源的回收。与此同时，它自身不耗费额定的 pod 资源，是一个线程级工作流，非常适合利用交付这类管控面的应用场景。
- 按需定制、可编程，一套配置残缺形容可观测需要。KubeVela 在设计之初就抉择了 Infra as Code（IaC）的可编程扩大形式，KubeVela 的开发者和企业的平台工程师能够通过 CUE 配置语言 按需定制，对接各类 Kubernetes API，最终将其转化成用户易于装置、应用和了解的模块化插件，最重要的是能够通过申明式 API 的形式在一套配置中残缺的形容可观测需要。丰盛的插件市场也是 KubeVela 的一大生态特色。
具体而言，KubeVela 的开发者或者平台运维人员能够应用 CUELang 编写各式定制化的 Definition 形容文件，以 IaC 的形式去定义可观测的场景，比方采集 metrics、收集日志、创立数据源、导入大盘等。而业务的开发者则只须要选用这些现成的模块（通常被定义为运维特色“Trait”或者工作流步骤“WorkflowStep”）去绑定利用配置。
（图 4）通过 KubeVela 的 X-Definition 体系扩大模块化可插拔的利用观测能力
如图 5 所示，KubeVela 的最终用户在形容利用时，形容了 metrics 和日志收集的信息，同时在工作流步骤中定义了在部署实现后去创立可观测大盘。这个流程的编排过程全副由 KubeVela 控制器主动实现，包含流程的程序执行、可观测 API 和工作负载 API 的绑定、对立版本和标签、状态检查和异样重试、多集群治理，以及维持资源面向终态的一致性。更为重要的是，KubeVela 很好的均衡了可扩展性和易用性，最终用户在灵便抉择不同可观测模块的同时无需关怀上层的配置参数细节。
（图 5）围绕利用的全栈申明式可观测
多集群 / 混合云的可观测对立配置
KubeVela 本身也人造反对古代利用的多集群、混合云需要，所以当咱们满足了对立通过利用交付申明式可观测需要时，也能够借助 KubeVela 多集群交付的能力，满足多集群、混合云可观测的对立配置，如图 6 所示，咱们能够针对不同的集群配置不同的可观测需要。
（图 6）多集群 / 混合云的差异化可观测配置和对立交付
KubeVela 的可观测性能力除了高度可定制化之外，还能够通过对立的接口与云厂商的可观测性服务进行对接。以指标采集为例，如果用户的零碎中曾经存在了其余 Prometheus 实例，或者采纳了云厂商的 Prometheus 服务（如阿里云的 ARMS 产品），你也能够通过注册 Grafana 数据源的形式将 Prometheus 实例接入到 Grafana 监控大盘中。KubeVela Prism 提供的 Grafana API 接口中反对以原生的形式创立 GrafanaDatasource 资源，KubeVela 上的利用也能够应用 grafana-datasource 这种组件来治理数据源的配置。
另一方面，如果用户的零碎中曾经存在了其余的 Grafana 实例，用户也能够通过应用 grafana-access 这种类型的组件，将已有的 Grafana 实例注册在 KubeVela 零碎中，实现集成。集成后，KubeVela 的利用就能够通过应用 grafana-dashboard 这种类型的组件，将监控大盘以利用资源的形式进行配置及治理。
至此咱们能够看到，一个“全栈申明式可观测”的解决方案曾经造成，为了进一步晋升用户体验，咱们在灵便定制和可扩大的根底上，针对 Kubernetes 中的外围场景做了大量开箱即用的可观测能力。另一方面，KubeVela 自身微内核高可扩大的架构能够疾速通过插件（Addon）机制扩大周边生态，咱们将可观测性能力做成了插件，能够取得十分晦涩的装置体验。
03 KubeVela 开箱即用的可观测体验
接下来，让咱们从接入、应用、定制三个方面看看理论的应用过程是怎么样的。
接入可观测性基础设施
在 KubeVela 中，用户既能够从零开始搭建可观测性体系，也能够对接已有的可观测性基础设施与 KubeVela 零碎。
对于从零开始搭建的 KubeVela 用户，只需几行简略的 vela addon enable 语句，即可疾速将所需的插件装入本人的 Kubernetes 环境中，而且人造反对多集群架构，这意味着如果你有多个集群须要治理，通过 KubeVela，你能够很轻松地将雷同的配置与服务装入所有集群中。当然你也能够按需只抉择装置局部须要的服务，或者只对于某一部分集群进行装置，具体命令能够参考官网文档，流程如图 7 所示。
（图 7）在多集群中装置可观测性插件目前 KubeVela 官网反对的可观测性 Addon 曾经笼罩了指标、日志、可视化等畛域，为运维人员和利用开发者提供了开箱即用的部署办法，同时与已有自建基础设施，甚至是云厂商提供的 SaaS 服务进行无缝连接。为了简化用户上手老本，晋升体验，KubeVela 的可观测性 Addon 针对各类应用场景提供了高度可定制化的解决方案。例如，在多集群场景下，为了提供和单集群场景下具备统一体验的跨集群指标，KubeVela 的 Prometheus Addon 默认蕴含了基于 Thanos 的分布式采集部署计划。而在日志畛域，KubeVela 的 Loki Addon 则是提供了包含 Promtail 和 Vector 在内的多种 Agent 采集计划，辅以 vector-controller 等运维工具，帮忙运维人员在日志配置上取得与 Kubernetes 原生资源统一的体验。官网文档中蕴含了更为具体的介绍。
开箱即用的可观测大盘
KubeVela 提供的可观测性基础设施内置了一系列监控大盘，不便用户从零碎及利用两个不同的维度监控运维 KubeVela 及其上利用的运行状态。
洞察 Kubernetes 和 KubeVela 零碎
零碎维度上，内置的 Kubernetes System 监控从根底的集群角度向用户展现了 KubeVela 管控的各个集群状态，包含 Kubernetes APIServer 的负载、申请量、响应提早、etcd 存储量等指标。这些指标可能帮忙用户疾速发现整个零碎的异样状态，或者是用于排查零碎响应慢的起因。
（图 8）Kubernetes 系统监控大盘
另一方面，KubeVela 还内置了针对于本身 Controller 零碎的监控大盘，这一大盘被广泛应用在各种 KubeVela 零碎的压力测试中，能够用来排查控制器性能的负载情况及瓶颈点。比方如果控制器的解决队列开始沉积，阐明目前的控制器无奈应答如此宏大规模的利用申请数量，长时间的沉积会导致利用无奈被及时处理。而沉积的起因，则能够通过资源使用量、各类资源申请提早、不同类型操作的提早来排查，并根据不同监控体现来进行相应的优化。
（图 9）KubeVela 系统监控大盘
面向利用的可观测大盘
除了零碎大盘外，KubeVela 还内置了面向利用的根底数据可视化界面，针对 Deployment 等原生工作负载类型资源的可观测界面，以及面向 nginx 日志剖析这类场景化的可观测界面，如图 10-12 所示。这些大盘为利用提供了通用化的监控指标，便于运维人员排查常见的危险点（如利用资源有余、配置谬误等）。将来，更多根底资源类型的监控大盘也会被进一步继承到内置的监控体系中。
（图 10）KubeVela 利用可视化界面
（图 11）Deployment 资源的监控大盘
（图 12）基于 Nginx 日志的剖析大盘
定制你的可观测性流程
除了 KubeVela 插件体系提供的一系列内置监控外，KubeVela 的用户还能够通过多种形式定制其观测体系。比方，通过为 Prometheus 实例配置 RecordingRules 或者 AlertingRules 来加强 Prometheus 的能力，提供预聚合或报警能力。而这些规定的配置在 KubeVela 体系中也能很轻易的进行多集群同步和差异化配置。
另一方面，运维人员也能够通过编写 CUE 来开发 KubeVela 的工作流步骤，为开发者提供便捷的利用监控自动化生成能力。如此一来，利用的开发者便可能专一在性能或业务自身的指标或运行状态上，而不须要关怀这些指标是如何采集、存储并出现在监控大盘上。
（图 13）部署 KubeVela Application 后主动创立相应的 Grafana 监控大盘
更多的定制性能详见官网文档。
（图 14）应用 KubeVela Pipeline 编排你本人的可观测性基础设施
除了可观测性插件自身的定制化和可扩展性之外，你还能够应用 KubeVela Pipeline 来自在编排你所须要的可观测性基础设施及配置，对接已有服务。KubeVela Pipeline 能够帮忙你将简单简短的编排过程串联在一起，从而实现便捷疾速的“一键部署”。
04 将来
可观测性体系是零碎稳定性的基石，而云原生时代下，简单多样的应用服务以及相应的观测需要对于运维和开发团队之间的合作也提出了更高的要求。本文中提出的 KubeVela 全栈申明式可观测，可能自动化地构建面向利用的可观测性体系，既能够加重开发团队对于基础设施应用的认知累赘，也能够缩小运维团队对于下层业务逻辑的了解需要。现实状况下，开发团队无需了解底层资源的排布，只须要在配置文件中申明所需部署的服务以及关注的指标，他们便能够在相应的基础设施上看到服务的部署状态以及相应的业务指标。而运维团队则无需理解服务及业务指标的具体内容，只须要聚焦在底层资源的运行状态和通用指标上。
目前，KubeVela 的内置可观测性体系次要集中在各类指标、日志的采集和出现上。将来，KubeVela 还会进一步将利用探针等可观测技术集成到插件体系中，为用户提供便捷的装置、治理和应用体验。此外，目前的 KubeVela 体系反对应用工作流步骤来实现利用监控的自动化发现及报表生成，KubeVela 团队还将持续摸索 Dashboard as Code 并总结更多最佳的自动化部署实际计划，推动可观测性与利用模型的进一步联合。
作者介绍：殷达，KubeVela Maintainer，阿里云高级工程师，深度参加了 KubeVela 混合云多集群治理、可扩大工作流、可观测等外围能力体系的建设。
原文链接
本文为阿里云原创内容，未经容许不得转载。