存可用率数据，我们称为数据点，比如上图，2022-08-25 15:05:22 这个时刻，每个机器都有 一个可用率数据点，共计 5 个数据点。 上面的图是查询的最近一小时的，我们切换到 Table 视图，得到如下结果： 这个表格的内容，是这 5 台机器在当前这个时间点的最新值，当前我做查询的时刻是：2022- 08-25 15:48:03 用 Chrome 开发者工具可以看到发的请求参数： 但是，监控数据是周期性上报的，比如每 分钟之间的数据，然后返回最新的那个。 查询类型 上例中的 mem_available_percent{app="clickhouse"} 称为查询表达式，不同的表达式，会返 回不同的内容，返回的内容总共有 4 种格式，分别是：Instant vector（瞬时向量）、Range vector（范围向量）、Scalar（标量）、String（字符串）。返回瞬时向量的查询表达式，我们 称为 Query，相当于在某个时刻返回多个点，这就无所适从了。 Prometheus 文档中有一个章节专门介绍函数，各个函数的介绍中，都会写明是用于 instant- vector，还是用于 range-vector，如果不理解查询类型，就无法很好的应用这些函数。 查询选择器 PromQL大括号里的部分是 selector，查询选择器，用于从一大堆监控数据中，过滤出真正关心 的数据，在 Prometheus 生态里，

每个告警都应该合理分级 基本每个监控系统都支持为告警规则配置不同的级别，基本上每个监控系统的用户也都知道应该做分级告 警。但是具体怎么分级，却没有一个行业共识，大家各做各的。这里我也分享一下我的理解，你可以参考 借鉴。 首先，不同级别的告警应该对应不同的处理逻辑，这样分级才有意义，比如通知渠道不同，通知范围不 同，或者介入处理的人的范围不同，处理时效不同 ，如果某两个级别对应完全一样的处理逻辑，就可以 的工具可以沉淀最佳实践，沉淀经验，假设由你来设计 一款 OnCall 产品，处理告警分发相关的这一系列需求，你会如何设计呢？接下来，我们站在设计者的角 度，来讲解产品设计逻辑和实践方法，会更容易理解。 空间管理 通常来讲，一个公司不但会使用多个监控系统，而且会有很多个团队，如果所有的告警事件都在一个地方 查看、管理，就会相互打扰。所以，OnCall 中心首先要设计一个协作空间的概念，来归类处理不同的事