DQL 为观测而生的查询语言
12/24/2021
构建一个系统的可观测性需要很多类型的数据,包括“指标”、“链路”、“日志”,但事实上除了这些,我们可以进一步的细分,比如对象(主机,容器,pod)、事件、用户访问数据、应用性能数据等。目前的开源软件或商业软件,分别为这些场景提供了不同的查询语言,如:Prometheus 提供了 PromQL (Prometheus Query Language) 作为 Metrics 的查询;日志方面,Loki 提供了 LogQL;ELK 方案中则有 Kibana 提供的 KQL ,和 Splunk 提供的 SPL 。我们在描述一个可观测性场景的时候,使用者需要掌握海量的语言,存在很高的学习成本,且需要频繁的切换上下文,耗费了大量编辑的时间。因此在观测云平台中,我们提供 DQL(Debug Query Language),用统一的查询语言解决这些问题。

DQL的设计理念:为时间数据设计查询

我们通常使用 SQL 来查询关系数据库表,但是观测类的数据并不是一种关系数据,它们都是一种时间维度的连续记录的数据。不管哪一种类型,一般都包含以下的内容,时间,Tag,Content(Value),我们也可以统一将他们称之为日志形态的数据。所以我们要为这种类型的数据统一设计一种查询语言。

  • 简化SQL

    由于数据结构太丰富,且也没有表结构的概念,对于不同的类型只有不同的概念,比如:指标(metrics)有指标集、日志(log)有日志类型(source)、对于软件服务来说则是 Service。所以我们设计了类型::对应数据集的方式,取代了 select from 这种表达。包括 where 则是用类似 PromQL 的 {} 来表达。其他表达,如:Limit,Group by(简化为by)更符合 SQL 使用者的习惯。

  • 时间的表达

    在时序型记录数据下,基于时间的查询是必须的,包含三个因素:开始时间、结束时间、聚合的时间间隔(interval)。为什么有时间间隔,由于时序数据记录非常大,我们通常需要将其转化为可查看的图表。因此,需要进行时间聚合,如: 5分钟的用户访问平均延迟(5分钟可能有几百万的访问)。所以如果用 SQL 表达就非常复杂,如 where time>and time<and interval= 这种方式。所以我们在时间表达上采用了 [开始时间:结束时间:时间间隔] 这种表达,与表示条件的 {} 分开,更易读,也更方便书写。为了使用简便,在观测云中,我们其实也隐藏了时间表达,用户通过 UI 上的选择,会自动将时间表达加入最终的计算,如果使用 API 访问数据,则需要指定时间表达。

对结果进行统一计算的函数

由于时序数据和日志型数据以及其他类型的数据返回后是一个基于时间的序列,而我们针对这些序列的结果需要支持更强大的进一步计算能力,因此 DQL 也支持大量的对于结果集二次计算的函数,如:cumsum(累积求合),non_negative_derivative(非负求导)等,window(窗口计算函数)等。

用数字化手段保障系统稳定,从这里开始!

心动不停,立刻开始观测之旅!