华为云 AOM 立体运维系列 -- 云上 CMDB 设计与应用全景可视化运维

上一期分享了华为云 AOM 立体运维的架构与设计目标，接下来从各子模块的角度，持续的解析下立体运维的特性。本篇从应用运维可视化的出发，分享一下 AOM 的服务自动发现功能以及基于云应用特点的 CMDB 的设计思想。

一、立体运维可视化之应用全景视图

通常情况下，企业在云上可以部署多个应用，站在运维管理员的视角，需要能够快速判断整体资源的运行情况，基于这个诉求，AOM 推出了一个涵盖了企业全部应用资源运行状态的分层全景视图，我们称为应用全景图。在应用全景中，您可以选中任意一段时间来查看历史资源的快照及最新资源的运行状态。通过双击任意一个资源标识，可以快速查看关联资源状态及各种指标，这个场景对于快速分析故障影响的资源范围非常有用，可以快速缩短定位时间。

如下为应用全景的截图，可以看到界面上分层展示了资源的列表及蜂巢图表示的资源运行状态。

通过双击异常节点，快速关联出受影响的资源，如下所示，通过双击异常服务，关联出当前异常涉及到的实例异常，但实例所在主机并无异常，因此可以进一步通过实例的指标来进行分析

通过单击实例节点上的详情图标（如下）

打开资源指标详情界面，查看实例的各类指标是否正常，这里发现指标已经没有了，因此可以跳转到这个实例的详细监控界面去查看对应的日志及告警和阈值等信息。另外在这个界面，可以将用户常用的指标创建为一个视图模板保存起来以便下次分析，还可以直接加入到仪表盘中进行日常运维。

实例监控详情界面示意，可以同时查看实例的告警，日志及指标数据：

以上应用全景图将用户的云应用分为了应用、服务、实例、主机及云服务五层，这五层称为 AOM 的业务模型，通过将用户的容器实例或者 VM 进程按逻辑分组，分别对应到这五层中去运维。

因为应用全景中有大量的资源，如果不能自动将应用发现并匹配到对应的业务模型中去，对用户使用来说这个将是巨大的障碍。所以在这个功能的背后，有两个问题需要解决：

1）服务自动发现

2）存量资源（CMDB）管理及模型匹配

二、为什么需要服务自动发现

容器技术正在快速改变着公司和用户创建，发布，运行分布式应用的方式。容器技术改变了开发者的能力，对于公司来说，投入产出比大大提高。华为提供的云容器引擎服务（CCE）正越来越快的向各种领域提供支持，如游戏、视频，电商及汽车等领域，已经大规模的应用容器技术。但是，基于容器技术(docker)支持的服务通常监控起来更加复杂，首先容器比传统的虚拟机应用相比，相同配置主机可以运行更多容器，其次对于管理容器的 Kubernetes，Mesos 和 ECS 等编排系统，用户只需要按规则部署，甚至可能不知道容器在任何给定时刻的运行位置(参考下图中所示的副本管理机制)，因此当容器出现问题时，如果不能获取容器当时的快照，对于问题分析或者定位都造成一定程度的困难。这种场景下，传统的手动监控配置很难满足需求。

一个 Kubernetes 按副本数管理容器的示例

另外，当我们构建面向容器监控的服务发现能力时，虚拟机上的普通服务也应当被考虑到，需要支持用户按同样的业务模型去运维应用，基于以上背景，我们设计了服务自动发现的功能。

三、服务自动发现的功能设计

服务发现的功能被设计为一个运行于采集器之中的插件，通过执行服务端下发的规则进行动态的扫描，以匹配哪些容器或者进程满足被监控的条件，部署示意图如下：

要动态执行服务发现规则，首先要解决的就是规则下发问题。采集器不能一直请求服务端来获取最新规则，而是以如下方式去获取。采集器会以管理员权限运行，在与服务端保持心跳的过程中，通过服务端返回的状态码来判断是否需要更新插件或者某些配置，如果发现有服务端有新的服务发现规则，就会在心跳返回后，再发起一次请求来获取当前主机需要执行的最新的服务发现规则列表。

下发通道打通后，接下来通过对服务发现规则进行抽象建模，设计规则本身的模型。见下图：

服务发现规则由发现规则与命名规则两部分组成，分别完成不同阶段的不同功能。

规则被定义后，接着分析规则的执行流程

通过以上分析，我们抽象出的服务发现规则的模型如下（JSON 格式）：

一个完整的服务发现规则，包括应用类型的定义，进程发现规则的定义，进程属性的抽取，命名规则的定义。

完成以上模型设计后，针对服务自动发现还要解决以下问题：

1. 0 配置发现容器应用

2. 通过插件监控 docker 的 unix socket 接口curl --unix-socket /var/run/docker.sock
   

3. 来监控是否有容器变更的事件，通过具体的容器详情接口，获取容器编排的属性，如 Kubernetes 属性。

4. 支持容器的自定义指标及日志采集

5. 当前仅支持对于 Kubernetes 编排的容器，通过 POD 属性中的 annotation 标签获取自定义指标的采集 Endpoint。

配置方法示例：

annotations:metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"prometheus","path":"/metrics","port":"9121","names":[" redis_used_cpu_user "," redis_used_cpu_user_children "]}]'

通过 POD 中定义的 logploicy 来获取自定义日志的采集路径

配置方法示例：

3.免配置或少配置支持非容器的普通 VM 进程发现

对于常见语言开发的应用，如 java, go, python 提供默认发现规则，通过运行时容器或者二进制中的版本信息来决定匹配哪种技术栈，然后执行对应的默认发现规则，通过常见的方法如 jar 包名称或者 main 方法名称来命名发现的服务，然后支持别名和改名的操作。也给非容器用户开箱即用的良好体验。

4.支持发现范围配置

对于某些规则来讲，可能不需要在全局生效，用户可以指定在某些主机上去执行，通过发现规则中的 scope 及 hostID 配置，使主机在收到规则时可以检测规则的支持范围，如果不支持则不再执行。

5.支持发现规则优先级管理

配置多条服务发现规则后，可能由于不同规则的匹配规则发生交叉，将影响匹配到的结果，因此对于多条规则的执行顺序，要能通过优先级进行排序，执行流程参考上述的执行流图。通过在规则中增加 priority 来设置优先级。

四、如何使用服务发现功能

AOM 提供了向导式的配置功能，通过 4 步完成服务发现的设置功能。

第一步：如下图所示，首先通过一个预探测的节点来为后续规则提供验证环境

第二步：通过在这个主机上执行定义好的发现规则来发现进程（这一步同时可以关联到进程默认打开的日志文件，用户可以在这里决定是否采集日志文件进行分析）

第三步：通过命名规则来为每一个实例生成一个服务名称，以便发现后在对应的业务模型下去监控用户的进程

第四步：通过设置优先和探测范围来管理这一条规则

基于以上四步即可完成一个规则的配置及最终效果的预览

五、存量资源的管理（CMDB）

服务被发现后，服务的详细信息将被发送到 AOM 的管理面，在上一篇文章的介绍中，AOM 中有一个 INV 的存量服务用于管理这些信息，这个服务也称为 AOM 的 CMDB，这个服务需要实现以下功能：

• 分离业务模型与存量资源模型

• 存量模型能表述不同的云服务下的不同云资源

• 支持对云服务内云资源建立映射关系

• 支持对跨云服务的资源建立映射关系

• 支持云资源标签管理（打标签，同步标签，按标签查询）

• 支持历史资源快照

下面通过几张图描述下 AOM 的 CMDB 是如何支撑这个功能的

1、存量模型与业务模型的概念

首先，我们认为各种应用及不同的编排系统都有其各自的模型（我们称为存量模型），因此在资源的配置 config 里我们提供了一种弹性的 schema，用来描述每个资源的不同的模型，因此，后端的数据库选用了 ES，在 schema 中通过 alias 标记的范围的 kv 字段来实现打标签的功能。

业务模型在第一节已经有所界面，当前在 AOM 中分为五层模型，但是这个模型不是固定不变的，随着业务发展可能出现新增模型的场景，所以在设计中，对于业务模型也要求支持扩展。

下图所示为一个存量模型与业务模型的映射关系。

因此，对于不同资源，我们可以通过设置映射规则来将存量模型与业务模型匹配到一起。

大量的资源的匹配，对于检索来讲会相当复杂，如何能在最快的时间内通过 ES 将各种关联资源检索出来成为下一个要解决的问题，这里我们采用了图数据库的思想，将上述的存量模型按以下规则存储

1）通过两张表分别来存储存量类型，业务类型并编号，再通过一张表来保存映射关系

2）通过将资源视为点，关系视为边，构建一个图数据库模型

3）在边的关系生成时，通过存量模型 ID 与业务模型 ID 分别放置在 Long 的高低位上的设计，来使查询请求能按规则生成出 edgeType 的值，从而直接根据边去找点，快速查询出关联资源。

通过上述几个关键的设计点，我们实现了第一小节您所看到应用全景的视图展示与关联查询。更多的功能也在设计中。

本文转载自 华为云产品与解决方案 公众号。

原文链接：https://mp.weixin.qq.com/s/EcD9oWwXkp6YJGiK-xR3wg