揭密首个朝向IaaS的查寻語言:ZStack Query Language(

2021-02-22 03:38 jianzhan

揭密首个朝向IaaS的查寻語言:ZStack Query Language(ZQL)


短视頻,自新闻媒体,达人种草1站服务

以便简化UI工作中并为运维管理人员出示1种更为灵便的資源查寻方法,ZStack在2.6版本号中推出了首个朝向IaaS的查寻語言 ZStack Query Language,简称ZQL。

情况

IaaS管理方法着大量的数据信息管理中心資源,怎样对这些資源开展灵便迅速的查寻是运维管理人员遭遇的1个困难。在过去的IaaS手机软件中,常常只对单独資源的一些字段出示比较有限的API查寻适用,比如能够根据虚似机的IP字段查寻,这不够够也不灵便。运维管理人员在做繁杂查寻时常常得绕开IaaS手机软件立即查寻其后端开发数据信息库,这既规定运维管理人员要掌握IaaS資源的內部关联,又带来了数据信息库误实际操作的风险性。

从ZStack宣布公布的第1个版本号ZStack0.6刚开始,大家就致力在API层面出示跟数据信息库级別的查寻作用,ZStack的每一个資源都包括1个Query API,可以根据資源的本身字段和資源的关系資源字段开展查寻。比如

QueryVmInstance name~=web-vm state=Running

这里查寻全部姓名包括web-vm标识符串,正在运作中的VM。又比如

QueryVmInstance vmNics.eip.vip.ip='22.22.22.22'

EIP是虚似机的关系資源,这里查寻网卡关联了EIP为22.22.22.22的虚似机。

Query API作用强劲:

客户能够根据count主要参数回到考虑查寻标准資源数量,相近SQL的count();

根据fields主要参数特定要回到的字段,相近SQL的uuid,name from;

根据sortBy、sortDirection主要参数特定排列的字段和方位,相近SQL的order by;

根据start、limit主要参数完成分页查询查寻,相近SQL的limit和offset。

Query API除应用便捷外,界定也很简易。程序流程员在ZStack中提升了1种新資源后,只必须在编码中界定以下class:

@AutoQuery(replyClass = APIQueryVmInstanceReply.class, inventoryClass = VmInstanceInventory.class)

public class APIQueryVmInstanceMsg extends APIQueryMessage {

}

不必须写任何完成,对应資源就具备了Query API。

ZStack內部包括1个Query Service负责解决全部資源的Query API,将她们汉语翻译成相应的SQL句子,在查寻标准中包括关系資源标准时会转化成对应的Join子句。

根据Query API, ZStack0.6版本号就包括了超出400万个单项查寻标准,组成查寻标准数为400万的阶乘。巨大的便捷了运维管理和繁杂UI的设计方案。但Query API依然包括1些缺点:

查寻标准之间只能是AND逻辑性,没法实行OR逻辑性,标准之间也没法加括号完成繁杂逻辑性组成

不适用相近SQL中的sub query子句

单独API只能查寻1种資源,查寻多种多样資源时必须启用好几个API

不适用跟监管系统软件的查寻語言整合

伴随着ZStack UI的情景愈来愈丰富多彩,Query API的限定使得UI端工作中愈来愈多,许多情景必须数次启用Query API开展数据信息组成。比如在监管Top 5网页页面(用于检验系统软件中CPU、运行内存、硬盘、互联网等資源应用率最高5个資源的网页页面),必须先选用Query API将虚似机、物理学机等資源信息内容查寻回家,再启用监管系统软件ZWatch的API查寻对应的监管数据信息。

Query API在将来的ZStack版本号中会1直保存并维护保养,其后端开发完成早已从原先的Query Service更换成ZQL。

ZStack Query Language

应用过知名issue管理方法系统软件JIRA的开发设计者都了解JIRA在开展高級检索的情况下出示1种查寻語言JQL (JIRA Query Language),可以应用1类型似SQL的DSL(Domain Specific Language)对JIRA中ticket的各个字段开展高效率的查寻。ZQL跟JQL相近,也是1类型似SQL的DSL,先看来1个事例:

query vminstance where name='webvm' or vmnics.ip='192.168.0.10' or (vmnics.eip = '172.20.100.100' (cpuNum = 8 or clusterUuid in ('fe13b725c80e45709f0414c266a80239','73ca1ca7603d454f8fa7f3bb57097f80')))

在这个简易事例中,能够看到许多熟习的SQL元素,比如and/or标准、括号、 =/in实际操作符等。ZQL能够看做SQL的1个非空子集外加ZStack依据本身要求开展的提高的查寻語言。它的基础构造以下:

QUERY queryTarget (WHERE condition+)? restrictBy? returnWith? groupBy? orderBy? limit? offset? filterBy? namedAs?

query重要词

1条ZQL句子一般以query重要字开始,queryTarget表明要查寻的資源或資源字段的结合。前面的事例中vminstance意味着虚似机,比如host意味着物理学机、zone意味着地区,全部可被查寻的資源都有自身的名字。假如不期待回到資源的全部字段,只期待得到資源的1个或好几个字段,完成相近SQL的uuid,name from ...的作用,能够在資源名后特定字段名,好几个字段名用逗号防护,比如:

query vminstance.uuid,name,cpuNum

该查寻回到全部虚似机的UUID、名字和CPU数量。

除query重要字,查寻也能以count和sum重要字开始,前者回到考虑查寻标准資源的总数,后者能够对資源的某个字段开展求饶。比如:

vminstance where cpuNum 8

回到系统软件中CPU数量超出8核的虚似机的总数。

sum vminstance.memorySize by name where cpuNum 8 

用虚似机姓名对CPU核数超出8个的虚似机开展排序,对它们的memorySize字段开展求饶。假如系统软件中有两个10CPU8G的虚似机都名为webvm,则求饶后回到webvm虚似机总运行内存应用数为16G。汉语翻译成SQL则为:

sum(memorySize) from vminstance where cpuNum 8 group by name

WHERE从句

ZQL的WHERE从句跟SQL的WHERE从句相近,适用and/or逻辑性实际操作符、括号组成,标准的较为符适用=,!=, , =, , =, like, not like, is null, is not null, in, not in,查寻标准名为資源的字段名。跟SQL不1样的地区在于,ZQL的查寻标准能够是关系資源的字段,比如:

query vminstance where 

vmNics.eip.vip.ip='22.22.22.22'

留意where从句前不用写相近SQL的from xx从句,由于query vminstance早已限制了被查寻的資源

这里vip跟eip关系,eip跟vmnic关系,vmnic又跟vminstance关系,则大家能够特定vip的IP做为查寻标准。这更是ZQL的强劲的地方,针对好几个关系資源的查寻,不用启用数次API在运用端组成数据信息,也不用像SQL1样写繁杂的join从句,只必须像程序编写1样根据点号(.)引入另外一个資源便可, ZQL的汉语翻译器会全自动将跨資源引入汉语翻译成对应的SQL join从句。

WHERE从句能够包括子查寻,相近于SQL的sub query作用,比如:

query vminstance where vmNics.l3NetworkUuid in (query l3work.uuid 

where ipRangesworkCidr='10.1.0.0/24')

这里找出全部CIRD为10.1.0.0/24的3层互联网上运作的虚似机。

上面这个事例还可以用更简易的方式完成:query vminstance where vmNics.l3work.ipRangesworkCidr='10.1.0.0/24',这里只是以便演试子查寻作用

GROUP BY、ORDER BY、LIMIT、OFFSET 子句

跟SQL1样,ZQL适用GROUP BY、ORDER BY、LIMIT、OFFSET重要字,以完成排序、排列、分页查询等作用。

GROUP BY:

根据虚似机的地区UUID和群集UUID排序,统计分析各地区中各群集中虚似机的数量。

vminstance group by zoneUuid,clusterUuid

ORDER BY:

查寻全部虚似机,应用cpuNum字段降序排列。

1.query vminstance order by cpuNum desc

LIMIT、OFFSET:

应用limit和offset完成分页查询:

query vminstance limit 100 offset 10

多資源查寻

针对好几个資源的查寻,能够根据好几条query查寻句子完成,句子之间应用分号隔开,比如:

query vminstance where name = 'my-vm';

query host where cpuNum

query zone;

则1次启用便可回到3种資源的查寻結果。因为回到的結果是1个map的JSON构造,以便便捷得到对应句子的查寻結果,可使用named as重要字对查寻句子取名,比如:

query vminstance where name = 'my-vm' named as 'vm';

query host where cpuNum 10 named as 'host';

query zone named as 'zone';

则在回到的JSON map中,能够根据vm、host、zone做为key得到对应句子的查寻結果。

合拼监管查寻 (return with从句)

在ZStack中应用了两种数据信息库:关联数据信息库储放元数据信息,时钟频率数据信息库储放监管数据信息。因为不一样数据信息库查寻方法不1样,在ZQL以前,客户要查寻1个資源的监管数据信息,必须先根据Query API得到该資源的元数据信息,再根据ZWatch的查寻API得到其监管数据信息。比如要查寻1个名为webvm虚似机的CPU应用率监管数据信息,要实行以下API:

QueryVmInstance fields=uuid name=webvm

GetMetricData namespace=ZStack/VM metricName=CPUUsedUtilization labels=VMUuid=QueryVmInstance回到的UUID offsetAheadOfCurrentTime=60

ZQL根据return with子句处理这个难题。return with是1种软件体制,它容许子系统软件 根据软件将本身的查寻标准引入ZQL中,ZQL会先实行关联数据信息库查寻,将考虑标准資源的原数据信息查寻出来后,再将資源的主键(primary key)做为键入标准启用完成return with子句的软件,最终将软件的查寻結果1并回到给ZQL的启用者。

上述查寻虚似机监管数据信息的要求能够根据1条ZQL句子完成:

query vminstance.hostUuid,uuid where name = 'webvm' return with (zwatch{resultName='webvm-cpu',metricName='CPUAllUsedUtilization',offsetAheadOfCurrentTime=60})

回到:

{

"results": [

{

"inventories": [

{

"hostUuid": "f8271f58468b4281a212a43e530b5535",

"uuid": "d24341ac84fc055ae71820ac"

}

],

"returnWith": {

"webvm-cpu": [

{

"labels": {

"VMUuid": "d24341ac84fc055ae71820ac"

},

"time": 02,

"value": 0.8

},

{

"labels": {

"VMUuid": "d24341ac84fc055ae71820ac"

},

"time": 62,

"value": 0.8

}

]

}

}

],

"suess": true

}

这里大家用1条ZQL句子中即回到了大家感兴趣爱好的元数据信息字段:uuid和hostUuid,也回到了该虚似机的监管数据信息。仔细的读者早已留意到大家在ZWatch查寻字段中特定了主要参数resultName='webvm-cpu',而且在回到的JSON map中监管数据信息的key也是webvm-cpu。跟named as重要字1样,这是以便实行好几条ZWatch查寻子句时便捷查找回到結果提前准备的。 ZStack UI应用十分繁杂的ZQL查寻句子,比如在TOP 5网页页面,1条ZQL查寻包括多达13个ZWatch查寻:

ZQLQuery zql="query vmInstance.uuid,name where zoneUuid='89e148fb667c404dbc5309a2e956fa28' hypervisorType='KVM' type='UserVm' state='Running' return with (zwatch{resultName='CPUAllUsedUtilization',metricName='CPUAllUsedUtilization',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='MemoryUsedInPercent',metricName='MemoryUsedInPercent',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='MemoryFreeInPercent',metricName='MemoryFreeInPercent',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllReadOps',metricName='DiskAllReadOps',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllWriteOps',metricName='DiskAllWriteOps',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllReadBytes',metricName='DiskAllReadBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='DiskAllWriteBytes',metricName='DiskAllWriteBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid\")',functions='top(num=5)'},zwatch{resultName='NetworkOutBytes',metricName='NetworkOutBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkInBytes',metricName='NetworkInBytes',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkOutPackets',metricName='NetworkOutPackets',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkInPackets',metricName='NetworkInPackets',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkOutErrors',metricName='NetworkOutErrors',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'},zwatch{resultName='NetworkInErrors',metricName='NetworkInErrors',offsetAheadOfCurrentTime=60,period=6,functions='average(groupBy=\"VMUuid,NetworkDeviceLetter\")',functions='top(num=5)'})"

上例是在ZStack CLI中实行时的事例,应用\对引号转义

当資源非常多时,时钟频率数据信息库查寻特性将会变成好几条ZWatch查寻的特性短板,故return with会根据高并发的方法实行软件,默认设置高并发度为10。比如上述事例中的13条ZWatch查寻会在10个进程中高并发实行。客户能够根据全局性配备zql.returnWith.concurrency变更高并发度,比如

UpdateGlobalConfig category=query name=zql.returnWith.concurrency value=15

限定查寻 (restrict by从句)

ZStack的公司管理方法控制模块包括1个作用,能够对管理方法关联某个地区,使得该管理方法员只能管理方法该地区内的資源,这就规定大家的ZQL对该管理方法员的查寻恳求只回到与其关联小小中的資源。

针对虚似机这样的資源,其元数据信息自身就带zoneUuid字段用于标志所属地区。但针对eip这样的資源,其元数据信息并没有任何字段表明地区特性,地区特性是由其所属的3层互联网或关联的虚似机明确的。比如要查寻某个地区内的eip,可使用:

# 根据与虚似机的关联关联查寻

query eip where vmNic.vmInstance.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'

# 根据所属3层互联网明确

query eip where vip.l3Network.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'

不管那种方法,都必须启用者掌握了解eip跟zone之间的关系关联,这对API的应用者提出了十分刻薄的规定。ZQL根据restrict by从句处理这个难题。跟return with从句相近,restrict by也是个软件架构,它容许其它服务根据软件讲解restrict by从句中特定的标准,向转化成的SQL中引入附加标准。比如上面的eip事例根据restrict by从句能够写成:

query eip restrict by (zone.uuid='52fdad0a2c0d4131a6c0fc6c1b7141a6')

这里启用者不用了解eip跟zone之间的逻辑性关联,restrict by的相对路径软件会全自动测算二者的逻辑性关联,并转化成对应的SQL join从句。这里eip既能够根据所属3层互联网,还可以根据关联的虚似机明确和地区的关联,软件会全自动测算相对路径权重,应用权重最高的相对路径转化成SQL句子。

针对eip这个事例,软件会选择根据3层互联网的关联转化成SQL句子。由于eip将会沒有跟虚似机关联,但其1定处在某个3层互联网,故3层互联网这条相对路径的权重更高。

restrict by适用好几个标准,根据逗号隔开,好几个标准之间是AND关联。

除给ZQL启用者应用外,restrict by软件在ZStack內部也被其它服务普遍应用。比如账户系统软件会根据软件在一般账户启用ZQL的情况下引入跟账户关系的SQL句子,使得一般账户只能查寻到属于该账户的資源;又比如SNS服务会根据软件引入句子让ZQL只能查寻到非系统软件种类的接受端。

将来

ZQL为ZStack出示了1类型似SQL的IaaS查寻語言,而且可以根据return with软件架构跟其它非关联数据信息库系统软件开展查寻整合。在将来的版本号中大家还会再次丰富多彩其作用,现阶段有两个方位:

filter by从句

尽管return with的ZWatch软件能让大家在查寻資源元数据信息的另外查寻其监管数据信息,但还不可以将监管数据信息做为元数据信息的查寻标准,比如没法根据1条ZQL完成查寻某个群集中全部CPU应用率超出90%的虚似机。这在将来版本号中会根据filter by从句完成,比如:

query vminstance where clusterUuid = '33e26bd547d149fbb1904369aca824' filter by (zwatch{metricName='CPUAllUsedUtilization', offsetAheadOfCurrentTime=60, threshold 90})

一样,filter by从句会完成成相近return with的软件架构,用于整合非关联数据信息库的查寻标准。

智能化CLI

ZQL有很多的从句,每一个ZStack又有很多的可查寻字段,现阶段ZStack CLI能够对Query API的可查寻字段开展补全,但ZQL还临时没法补全。将来版本号中,大家会对CLI开展在提高,使其对全部查寻标准能够开展提醒和补全。

欢迎大伙儿在ZStack官方网站免费下载网页页面

zstack.io/product_downloads/

开展完全免费的免费下载安裝和试用。