00:00
接下来我们看一个链路延迟的一个测量,也就是说其实对我们一个流式应用来讲。我们肯定要关注他的一个延迟到底能达到多少,对吧?从我的SOURCE1直到think,走完流程大概需要多少,最简单直白,你自己做一个打印。但是这个不一定准确。那这个呢,其实弗link给我们提供了这么一个功能啊。那而且呢,这也是一个非常重要的一个指标处理延迟,那这个指标呢,需要咱们去开启的,它提弗link提供了一个开箱即用的延迟标记机制,来测量咱们一个电路延迟,主要有这么一个参数。监测的一个间隔,那么这个间隔呢?默认是零,表示禁用。那么一般这个间隔咱们也不能设的太短,太短的话不太好。毕竟还是多做一点事,可能会影响一点点性能。
01:03
那一般建议呢,就设为30秒。另外呢,就是一个监控的力度问题。它有三个力度,第一个叫single,这个是每个算子单独统计延迟,什么意思呢?比如说我有三个算子。AABC这个级别测的就是A算子从进入A到出去A。中间这个延迟,延迟是多少。那对于B来讲,它测的就是进入B到出去B啊,这个延迟多少,也就是说它。统计的是一个扇子内部的延迟,那其实咱们更关注的是什么,整个电路从A进来一直到B出来这一段的一个延迟,那这个默认就是一个默认值operator,所以咱们一般也不去修改,那甚至呢。还可以去计算子任务级别的萨task,它可以计算每个下游算子。
02:01
啊与自己之间的一个延迟,对吧,比如说B有多个变形度,它每一个都算,每一个都算,每个都算。那像这个力度级别呢。就有这么一个参数啊。保证级别默认operator,咱们一般也不去改啊,不去改,那这个是这么一个机制啊,使用起来特别简单,但是有一些东西要需要跟大家讲的,就是第一个咱们这个所谓的标记,他不会参与到数据流的。计算逻辑,也就是说咱们定义的那些,呃,算子函数的一些计算逻辑,那些代码,它不会去走的,它是什么呢。跟沃特玛有点像。啊,也不也跟沃特玛不像的啊,比如说AB。呃,这个标记是一个特殊的数据啊,比如说这个标记进入A了。进,他一旦被A接到,他会立马发送给B。
03:02
他并不会去执行里面咱们定义的方法,那B接到这个标记,它就会立马传给C。对吧,那有的人就有疑问,那这有什么意义,那那那我这个测试没什么意义了,也不是。你想想,如果B这里产生了反压。那这个特殊标记是不是就进不去啊,他是不是也得跟那些数据一样在那排队对吧?他能传给B的前提是什么?B能收啊,他能收的前提是不是没有,不会造成反利啊,是吧?所以它也是有意义的。如果你都没反应啊,其实测的就是从头走到尾,不执行计算逻辑,它是一个什么状态。所以基本我们认为呢,它是基本准确的啊,我们也主要是用它来衡量而已,并不是啊说要百分百。另外要注意的一个细节就是它用的是一个处理时间。它是直接获取系统的时间的。system用这个方法。
04:05
那由于咱们执行式分布式的可能,呃,每个算子的每个实力可能运行在不同的服务器上面,对吧,这是有可能的,那基于此呢,所以你这个要保证你这个时间时区是同步的啊这是一个小细节,那同步的话,你可以用NTP这种工具来做,一般应该都是同步的。这是最基本的,另外一个就是咱们提到了这个间隔不适合太小。对吧,那比如说设置成30秒是比较合适的啊。另外要注意点就是window。你像window的话,呃,他一进来它就出去了,那窗口的这个窗口时间这个区间,它就不会去等了。那么也就是说基本准确,大部分呢,咱们也是用通过这个机制来衡量的,那怎么使用呢?很简单,那咱们还是用一个UIDDEMO对吧,用UVDEMO吧,啊UID就UID吧,指定的无所谓啊,那其他的都没变,只不过加了一个参数。
05:11
把它设成30秒。好,那我们来执行一下。等它部署上来。那这个指标的兼,呃,看这个指标还比较麻烦,比较麻烦一点。咱们前面是不是也讲到了一个状态访问的一个延迟,对吧,那咱们可以随便点一个啊,比如说这个reduce。啊,还在啊,等他一会儿好了,Running呢,我们之前。看这个,呃,设置那个状态访问是不是也有一个延迟的监测,那我们在这里是能直接看到的,对吧,当然现在没开,但是如果当前这个使用的话,在这里是看不到的。
06:02
这里没有那个指标,这个指标。是需要咱们跟那个指标系统,也就是说比如说你用普罗米修斯加格尔法纳,那么你在普罗米修斯或者格尔法纳上面是能查到的,但是web UI没有啊,Web UI没有。那我这边是已经配置过了。大家看我其实已经在弗link这里配置的什么跟普罗米修斯啊,里面的G特位啊,普罗米修斯的那个网关模块进行了一个集成。那接下来我要做的是什么?我要启动我的普罗米修斯跟格拉法,这个我是封装了一个脚本。我启动一下。在监控页面我们可以看到,那至于这个监控怎么集成呢?大家可以参考我之前写的那个文档啊,Flink监控就普罗米修斯加格尔法呢这种方案的。
07:03
啊,那些我之前写过,应该呃也能找到现在啊。那格尔法呢,默认的页面应该是我应该是装在哈豆一啊3000。啊,对。那在这里呢,有一个flink监控,这是我之前。之前做的一些监控啊,像这个监控可以干嘛呢,简单瞅一眼呗。比如说服务器的情况,一些负载其实是能看到的,这个在咱们那个,我之前写的那个文档都有介绍。嗯。也可以套用一些模板,这些数据现在还没上报上来,稍等一会儿就有了。好了,咱不关心这个,我拿一个少一点的吧,不改它。那个指标名字还比较长,来我加一个新的一个监控仪表板。
08:03
在这指标里面有flink对吧?哎,我直接搜就行了,他的名字是有一个什么lateness。Latency。啊,就是这个。你看这个指标名这么长,对吧,什么task manager。呃,什么source ID对吧,就第一个source算子的IDID,呃,具体每个算子的ID,还有具体每个算子的子任务编号啊。是这样子的,那来,我先回去让大家看一眼。大家可以看到这里。是不是一大坨呀?它是每个扇子都测量的。它并不是指测量从头到尾,也就是说,呃,你有。这么长。比如说你有三个算子ABC。那A是SC是sin,那么从A到B这一段它会测,A到C也会测,也就是说它是从源头一直到每个算子中间都会有监测,那我们全链路的延迟是不是只要看最长的这个就行了。
09:15
对吧,直接看S算子的一个延迟就可以了,从源头到S。也就是说咱们其实取一个什么最大值就可以了。另外大家看他这里这种展示是不是看着乱七八糟的。对吧,你看这么多个呀。而且它显示的格式还这么不好看,对吧,那如果熟悉这个的应该就知道,比如说我。改成operator ID,因为它这里不就有operator ID吗?我们看一看。拼接上。拼接上这个吧,把这个编号也打出来,让大家瞅一眼。嗯。
10:01
大家看一下这个UID你看得懂吗?怎么好像跟我们想的不一样了,咱们不是已经点UID,然后传了个名字了吗?对不对?这些名字不应该是我们认识的吗?怎么变成了这玩意儿啊?那么大家注意,这边的算子ID跟UID是确实是有关系,但它是什么呢?将咱们的UID做了一个哈希。用的是mma哈希,那所以呢,你现在就比较麻烦的是,你直接看这指标,你根本不知道谁是谁。啊,乱七八糟,另外一个大家可以看到这后面这个小编号,这个是什么子任务的索引子任务编号,也就是说并行度是五,是不是应该有01234啊对吧。很不雅观,那么这个有没有好的解决方案呢?那么给大家聊一聊这么一个故事。官方暂时不打算解决。给大家看一下这个一是。
11:04
你看关于nay matchs应该包含算子名称,这样对我们用户比较友好,那最终他的回复是什么?我们不会在这一点上花时间,可能在未来啊,但在二零年回复的,到现在为止,我们看一下它的状态,这个已经是cross状态了,已经关闭了,然后它的解决是什么呢?不处理。翻译成中文给大家看一下吧。对吧。暂时不会做,也许在将来啊,不会啊。这个了解一下,那既然如此呢,咱们咋办呢。有两种解决方案。对吧,你要么所有的那个唾液啊。是你自己规范一下,这是think算子对吧,这UID你统一名字,所有的作业名字都一模一样,然后呢,你拿着这个名字呢去呃,自己算了一下他的哈希值,他是用的某某哈希三一百二十八位的算法。
12:13
那这样它的哈希值是不是就固定了?哈希值固定了之后,你就可以在这里过滤一下啊,过滤一下取出你要的那个固定的哈希值就可以了,但这样还不太方便,还有一种折中的方案,我们知道S的。从S到S的延迟是不是应该是最长的?那既然是最长,那好了。那咱们也不要区分哪个子任务,咱们直接干嘛取一个最大值。那这边名字就没意义,咱们随便起呗。啊,反正就是说最大延迟。好了,现在是不是有了,看起来是不是清爽多了呀?对吧,啊。那我们来看看这个延迟达到了多大啊?延迟居然令人发指的达到了2.8秒。
13:04
对吧,因为我们知道它里面是什么单位啊。调的是这个方法吧。是不是取的是一个毫秒对吧,所以呢,它的单位是一个毫秒。那这个就是2800,两千八就是两秒,那可以知道我当前任务最大延迟达到了两秒。关于这个指标,它同样跟那个状态延迟,访问延迟一样,它也有什么最大值,最小值,中间还有什么P75 P95 P99 P999也都有啊,但是一般来讲,以目前的使用,咱们就用这个方便一点。直接取个最大值就行了呗,心中有数。这个是关于这个电路监测啊,咱们怎么来做啊,给出一个一个方案。
14:02
像我之前截的这个,其实最大值你看才都一秒一秒左右啊,一秒不到,现在就慢一点。
我来说两句