货拉拉监控报警的UI设计

货拉拉监控平台是一款服务货拉拉所有技术、运维的一站式监控系统，覆盖了应用监控、基础资源监控、云监控、业务监控，支持链路、指标、日志、报警。

本文介绍货拉拉监控平台从开源到自研过程中，我们在监控可视化方向上积累的设计经验。

1. 前言

监控报警系统在现代企业 IT 技术环境中扮演着非常重要的角色，在每一个互联网产品的生命周期中，可能会存在各种异常情况：系统性能的瓶颈、系统运行阶段的故障，系统所依赖资源的故障等种种问题，这些问题可能会导致业务资损与用户体验下降。

为了满足各个企业数字化转型过程中对 IT 基础设施可靠性的要求，业界涌现出大量的可观测性工具，如前云原生时代被广大运维熟知的 Nagios、Zabbix、StatsD，云厂商提供的各种云监控，开源的 InfluxDB、Grafana、Prometheus，以及 SaaS 形式的 DataDog、Dynatrace、New Relic 等。

当公司业务规模上升至一定规模时，通常便不会局限于某一套监控系统。其中，日志可能跑在 ELK、Loki、SLS，链路可能用是 CAT、Skywalking 等，指标可能是各种 TSDB。此时，监控开发相当一部分工作便会集中于整合各套子系统的胶水层上，这也是各种一体化 APM 系统努力的方向：致力于提供一站式、端到端的完整体验。在国内的这个领域，我们有观测云、博睿、乘云等厂商。除以上的商业公司外，也有一些开源产品在做类似的事情，如 SigNoz、Grafana。

从可视化能力的角度来看，Grafana 是目前行业内最强的产品，在指标展示上有着最强的统治力，但 Grafana 旗下的 Tempo、Loki 方案实际使用效果差强人意。为了适配这两个子产品，用户需要牺牲太多。因此，在这种现实背景下，多数公司会走上这条路：指标用 Grafana、链路和日志选择其他产品，如果开发资源充足，便自建 web 端，以整合部分核心应用看板、大盘、报警、链路等。

2. 货拉拉监控演进

在《一年实现降本 60%，货拉拉全链路监控演进史》一文中，以链路为主线介绍了货拉拉监控的演进史。

2.1 监控 1.0：全开源UI

18、19 年期间，货拉拉基础设施监控主要采用 Zabbix，随着时间推移，逐渐迁移至不同的 Prometheus，并根据业务属性进行划分：如基础设施、Java、PHP 等，前端则使用 Grafana，日志使用 ELK，此时还没有应用全链路 Trace，总体处于刀耕火种的蛮荒时代，很多时候，客服比技术更先发现线上问题。

2.2 监控 2.0：自研+开源UI

在 20 年时，货拉拉正处于 PHP 转 Java 的阶段，并开始进行统一化监控建设，推动业务基础监控全面覆盖。其中包括：

•使用标准化 Java SDK 框架及字节码增强技术推动全链路覆盖；

•使用 VictoriaMetrics 集群版来承接 Prometheus 指标数据；

•开发 LalaMonitor 来提供应用大盘（不包括看板自助配置）；

此时的前端UI使用的是Vue.js开发的，为了快速上线，采用了后端驱动的看板（dashboard）查询方式：后端负责每个监控项（chart）数据的 ql 查询、数据解析，传给前端进行页面绘制。

研发通过点击每个 chart 右上角的小蓝标，便可以创建该应用指标的报警规则，报警规则的 ql 由后端计算生成，并分发到不同的 Prometheus 节点上运行；

在货拉拉SOA框架JAF落地推广后，LaLaMonitor也初步的集成了Trace的查询与展示：研发在页面上通过点击指标曲线进入Trace搜索页面，然后可以指定标签做进一步过滤；

经历一年半的开发与迭代，LaLaMonitor 从 0-1 的提供了应用监控、链路、报警等能力，为货拉拉业务的稳定运行立下汗马功劳。

2.3 监控 3.0：全自研UI

在 21 年中，为了应对业务的增长带来的稳定性风险，货拉拉成立了监控研发组。监控团队逐渐收拢并统一管理了以前各个团队分别负责的指标、日志、链路，并立项进行了一站式监控系统的开发（以下简称 Monitor）。我们对新的UI的设计目标是：

•提供对标 Grafana 的强大且简单的看板自助配置能力；

•提供 Prom 生态下领先的报警体验；

•强化不同数据类型的内联性，并提供更丰富的统一化应用监控；

3. 看板的挑战

Monitor UI的前端是源于 etrace-ui 开源的单页应用，在此基础上进行了二次开发，主要技术栈采用的是 AntDesign，React 和 ChartJS，使用 webpack 进行构建。

在看板数据源上我们支持了货拉拉在用的 Prometheus、ClickHouse 两种，相较于 Grafana，重点做了几项优化：

•简化 PromQL 的配置复杂性；

•结合货拉拉全球化的业务场景，开发跨区域报警规则、看板同步及复制；

•集成 SSO 与员工组织架构信息；

•引入应用 Appid 的概念，以服务 SOA 体系下的微服务架构；

•提供H5的飞书小程序；

3.1 PromQL 配置简化

Prometheus 内置的 Promql 查询组件比较简陋，仅提供单一的文本输入框，在用户输入过程中，先输入指标名` ，再输入{ ，提示label key 列表，用户选择后再提示对应的 label value，每填写完一个查询条件后，便会再次建议下一个条件。这种模式的主要门槛是用户必须具备充足的 PromQL 语法，并掌握充足的函数。

因此在开发指标看板时，我们先支持了近原生的PromQL模式和Origin模式，Origin模式和 Grafana 在此之后推出的 PromQL 构造器类似，该方法是通过将 Prometheus 指标中的 Metric、Labels 与函数结构化，并进行线性组合来简化构造的难度。可以较明显的降低 Prometheus 查询的使用门槛，用户不需了解较多的语法，但仍需掌握函数的层级关系。

在经过几个月的使用后，我们觉得 Origin 模式的使用对于用户仍存在一定门槛，如 Counter 型指标，用户通常需要 2 个函数结合，对于 Histogram 指标，用户需要 3 个函数，配置成本较高。并且在业务场景下，相同类型的指标查看姿势基本一致，配置多个指标时重复度较高。

因此，我们开发了一套模拟 SQL 结构的配置机制，根据指标类型，自动提供不同的查询方式。使用From查询指标名， Select 指定聚合类型， Where 控制指标的过滤条件， Group By 控制聚合函数 by 的字段， Limit控制查询结果数量。

在 SQL 模式下，用户便只需在页面上点击操作，便能完成指标的完整构建。对于业务研发，可以满足 90%的场景，更复杂的 ql 可以继续使用原生的 PromQL 模式来进行配置。

3.2 计算指标

有一定PromQL基础的人都知道，Prometheus 是单值型数据库，以上结构化的配置仅能实现单个指标的展示，无法实现复合指标的加减乘除。因此，我们需要引入计算指标，通过对配置好的指标项进行四则运算，来生成一条新的复合 ql。

计算指标 的作用在于强制引导用户进行 ql 分层，在接下来的报警配置里它会发挥更大的作用。

3.3 应用看板

由于 Monitor 是内部产品，我们的技术团队已经确定了通用的中间件，无需像 DataDog、Dynatrace 等产品那样适配过多的开源框架。相比之下，我们只需要投入较少的资源就可以实现高度的组件指标覆盖率。因此，我们的应用看板 可以治理的更完善和更全面的数据，同时，它也是 Monitor 上PV最高的模块。

应用看板是基于普通的看板能力构建的，它实质上是一个具备应用变量的普通看板，开发人员选择自己的应用后，即可查看到相应的指标数据，包括 Exception、HTTP、SOA、连接池和基础资源方面的指标数据。

在应用看板上，支持快速按类型查看 Max、Avg、P99 等多种聚合方式。

4. 日志与链路

在 monitor 中，我们提供了两种日志查询方式。

4.1 ELK 日志

上面提到，在货拉拉 ELK 根据业务类型划分了多个集群。再加上同一个应用会存在着业务日志、访问日志、定时任务日志、守护进程日志等多种日志，业务自身还存在着灰度、版本、泳道等概念，在此基础上我们将部分日志的前端页面集成到 monitor 中。用 antlr 实现了部分 lucene 的语法，在前端上提供了原生的查询语法。

为了便于按照各种维度查看日志数据，我们提供了 Exception、Ecs、Pod 等维度查看日志的快速方式；

由于链路和日志实质上都是明细数据，彼此间很容易关联，在 Java 应用中，业务的日志都会自动附带上 TraceID 来建立关联，这样开发在分析链路时便可以定位到对应的日志。

4.2 ClickHouse 日志

众所周知，全文检索的日志方案其存储成本居高不下。然而，当前业界也有不少公司已经尝试了 CK 的日志方案。在货拉拉，我们没有将 Clickhouse 用在普通业务日志的全文检索，而是利用 Clickhouse 强大的分析能力来存储标准化的结构日志，利用我们 Monitor 的组件，实现了日志转指标的功能，并在看板中进行集成展示。

以下是一个日志报警的 sql 配置。

在货拉拉，我们主要使用CK 日志监控来补偿Prometheus无法满足的场景：时序膨胀（高基数）、秒级。如可用于：前端监控、Kong监控（具备大量路由数量的情况）

4.3 链路

相较于原生的Skywaling APM UI，我们在链路可视化上并未提供那么丰富的可视化能力。我们通过裁剪只保留了其中精华的Trace能力。

一个典型的开发排障流程是：开发浏览指标，当指标在某个时间点出现波动时，再通过链路进行分析。为此我们提供了通过指标曲线点击链路的功能，比如下图，开发看到在该时间点出现了Exception，便能点击到相应的Trace页面。

5. 报警的挑战

5.1 指标、报警的关联

原生的Prometheus 报警缺乏一个完善的子系统，功能简陋。Grafana选择将 Alert 功能集成到图表中，并提供了一些简单的条件配置来解决这个问题。然而，其在中大型规模场景下仍然存在一些痛点：

•如何快捷的按应用管理报警规则、查看报警记录；

•如何快捷的从应用指标衍生出报警；

•如何在报警配置时实时预览效果；

其中，简化报警配置是最具有挑战性的问题，这里有两个思路可以参考：

•屏蔽promql：先指定应用，再选择指标类型，封装几种算法（用户不需要知道promql的存在）；

•租户化数据、语义化指标：按数据源划分不同类型的指标，提供更可读的指标、标签（在前期设计好指标，或者在后期加映射层）；

完全屏蔽promql在短时间内可以快速上线，但损失了promql的灵活性，在后续更高要求的场景下可能无法满足用户需求。因此，我们设计了一种新的指标与报警规则的新建机制：每一个图的右上角都有一个新建报警的按钮，点击它可以跳转到报警的编辑页面。无论用户处于什么水平，都可以满足他们的需求：

•初级用户：无需关注promql的设置，直接配置；

•中级用户：二次编辑promql结构，进行筛选过滤，复制粘贴；

•高级用户：完全自定义。

通过这种方式，用户可以从应用看板直接创建报警，不再需要了解框架指标的具体结构。对于自己埋点的业务指标，用户可以了解其细节，配置起来也不困难。因此，租户化与语义化的意义相对弱化了。

5.2 触发条件

上面提到，在看板里，我们有计算指标，在报警中，我们可以使用模板表达式 来定义报警触发条件。原生的 promtheus 中，只能使用完整的 promql 来配置报警，当存在多个条件，如阈值、同环比等多种条件共存时，promql的复杂性会使其难以维护。为了解决这个问题，我们引入模板表达式来作为中间层。在模板表达式中，可以引用上面配置好的指标，可以对某个指标进行加减乘除联合计算，方便我们更灵活的配置报警规则。

对于更复杂的多层级 ql，相较于Grafana，我们也可以使用裸写 模板表达式 的方式来支持。以下即是一个双层的 ql 结构。

5.3 卡片消息

报警卡片，也针对性的做了大幅的强化，以引导开发配置出更可读的报警规则：

•支持飞书的 Markdown 语法；

•支持 Prom 原生的 label 变量；

•废弃原生的值渲染， 引入了T{} 函数以渲染模板表达式，解决 Promql 原生模板渲染的局限性（其中一些技术细节在下篇文章中详细介绍），在报警触发及报警恢复时，都能渲染出正确的值。

•支持 at 指定的用户；

•支持一些内置函数，如通过weather(${city_id}) 查看指定城市的天气；

6. 后续规划

受限于文章的主题，本文未对监控底层的实现展开，今年我们还会推出数篇文章，分别介绍指标、报警、链路、日志等能力。