简介

随着最近几年云原生技术的火热，可观测问题正在悄然成为 IT 行业的热门话题。尤其是从 2021 下半年开始到现在，对可观测问题的讨论，大有愈演愈烈之势。

当前，云原生技术主要是以容器技术为基础围绕着 Kubernetes 的标准化技术生态。两层标准化推进了细化的社会分工，各领域进一步提升规模化和专业化，全面达到成本、效率、稳定性的优化。在这样的背景下，大量公司都使用云原生技术来开发运维应用。正因为云原生技术带来了更多可能性，当前业务应用出现了微服务众多、多语言开发、多通信协议的特征，同时云原生技术本身将复杂度下移，给可观测性带来了更多挑战。

Databuff 提供了云原生环境下的可观测性的一栈式解决方案。通过简单的一键配置安装，即可完成对 K8S 集群的全面性观测。具有业界领先的自动化注入能力以及可观测数据采集和关联分析能力。

K8S 集群可观测

借助于 Databuff 产品，我们可以轻松地实现 K8S 集群本身的组件可观测能力。

前置条件

1. 安装一套 Databuff 平台。

2. 准备一个用于测试的 K8S 集群，上面运行了一些测试应用。

安装步骤

登录到 Databuff 平台，点击访问 “采集中心” 下的 “OneAgent” 二级菜单。选择“操作系统类型” 为 “Kubernetes”。我们看到在安装步骤中，包含了“自动安装”和“手动安装”。我们推荐使用“自动安装”的方式来部署监控。将“自动安装”中的安装命令拷贝出来。

使用 ssh 工具登录到 k8s 集群的任意一个节点上。执行拷贝的安装命令。

等个一分钟左右，我们就能够在 Databuff 平台上看到集群的整体监控效果。

自动探测 K8S 主机节点

点击访问“基础设施”下的“主机”，可以看到目前有三台主机被自动监控到。三台主机分别对应的是 K8S 集群的三个节点。

点击访问其中一个节点，可以查看到这个节点的所有主机元信息；关键机器资源指标的性能趋势图；以及在该节点上运行的所有 Pod 列表。

点击 Pods 列表中的其中一个 Pod，就可以进入该 Pod 的详情页面。

自动收集 K8S 集群信息

点击访问“基础设施”下的“Kubernetes”，可以看到当前产生了一条 K8S 集群的监控信息。该条信息展示了 K8S 集群所有的基本统计数据指标。

点击第一列的名称“++cluster-68a964d99f6b++”，进入到了 K8S 集群分析页面。

在该页面中，可以观测到该 K8S 集群的多方面维度的指标数据。“集群概况”展示了当前集群的资源使用宏观概况；“集群利用分析”展示了当前集群的资源使用趋势图；“集群工作负载”展示了每个时刻集群的工作负载数量统计；Namespace 展示了集群各命名空间下的资源使用状态。

在 Kubernetes 集群监控列表中，分别点击“Namespace”，“Workloads”，“Node 节点” 以及 “操作”，进入到各自的统计概览页面。并且支持从 Workload 下钻到 Pod，并再次下钻到 Container。

K8S 应用可观测

前置条件

1. 安装一套 Databuff 平台。

2. 准备一个用于测试的 K8S 集群，上面运行了一些测试应用。

3. 已经完成对 K8S 集群本身的监控。

应用的自动化注入能力

Databuff 提供了业界首发的基于 webhook 的 k8s 环境下应用的 apm 监控的自动化注入能力。

将自动化注入工程放置在 K8S 集群的任一节点上（master 节点或者普通节点都可）。

执行 init-and-start-webhook.sh 脚本，会自动在 K8S 集群安装我们的 webhook 模块。

从后台访问 k8s 集群的 databuff 命名空间，发现生成了很多 pod。

其中 databuff-agent-cluster-agent-* 用于采集 K8S 集群指标；databuff-agent-* 用于采集 K8S 集群主机节点的指标；databuff-agent-webhook-deployment-* 用于向应用 pod 分发自动化注入的配置。

现在，这个 K8S 集群拥有了自动化注入的能力，我们接下来需要对命名空间进行配置，使得自动化注入能力对于某一个或多个特定的命名空间生效。

kubectl label namespace easytravel databuff-agent-webhook=enabled

通过上面这个命令，easytravel 这个命名空间下的所有业务 pod 在重启后，都会自动注入 databuff 的 apm 探针。

应用性能的可观测能力

点击访问“应用性能”下的“服务”列表，可以看到已经自动化监控到了大量的服务实例。

这些服务实例都是通过运行在 K8S 集群中的业务 pod 采集得到的。在这个列表显示中，每个服务实例的关键性能指标统计信息实时展现出来。

点击访问其中一个服务实例“shop-web-0.0.1-*”，进入服务实例详情页面，这个服务实例的详情信息就展现出来了。

在详情页面中，服务实例的基本信息，上下游调用关系，每个上游服务实例对该服务实例的调用次数，该服务实例对每个下游服务实例的调用次数都能够通过点击上下游服务实例图标展现出来。

通过服务实例在“响应时间”，“错误率"，"请求数"三个关键指标趋势图的展现，业务人员可以直观的感受到该服务实例的运行稳定性状态，以及被外部其他服务调用的整体情况。

我们还发现，系统自动对该服务实例生成了两个应用性能监控，以此来对该服务实例的应用访问情况进行及时的监控。从监控本身的状态上来看，目前该服务实例的运行状态是正常的。从右上角的提示信息来看，服务实例的健康状态良好，并且该服务实例没有产生任何告警事件。

右下角的服务依赖分析功能，提供了从更深的角度分析服务本身的应用性能方面的特点。“服务流分析”是一种宏观角度上的全链路分析工具。可以查看到以该服务为起点的所有下游服务实例。以有序的方式展现链路上所有服务对上游服务的响应时间的影响和贡献度，以及每个服务对下游服务的调用次数规律。通过这种方式，可以辅助发现当前一个批次的链路上存在的性能瓶颈问题。

进入服务流详情页面的信息如上图所示。

点击服务详情页中的“资源调用分析”，可以看到该服务实例的总体响应时间分布。下侧的资源分析，展示了该服务的所有接口，内部调用性能分析情况。例如，我们可以了解一个业务接口近段时间的性能总体情况。

点击进入一个接口的详情页面，查看到该接口历史的每一笔调用记录结果。包括调用产生时间，调用是否成功，耗时，请求状态码等信息。

点击展开进入其中一条调用链信息，可以看到这次调用在全链路中每个服务实例节点上产生的关键动作的性能详细信息。包括接口调用，以及关键服务内部调用性能。由此，我们可以了解到全链路下，哪个服务的哪个模块出现了性能瓶颈，或者是出现了内部错误。

访问“应用性能”下的“业务拓扑”，可以看到在 K8S 集群中，所有服务实例之间的全局访问拓扑图关系。鼠标悬浮到其中一个服务实例节点，我们看到该服务对其他服务的所有访问关系。

例如，我们看到上图中，有五个服务实例对 nacos-server 产生了调用关系。一段时间的访问量如图所示。单击其中一个服务实例，会在右侧边栏显示该服务的性能统计情况。