首页 微博热点正文

四六级,Flink在eBay监控体系中的实践和使用,重庆人力资源和社会保障网

Sherlock.IO是eBay现有的监控渠道,每天要处理上百亿条日志、事情和方针。Flink Streaming job实时处理体系用于处理其间的日志和事情。本文将结合监控体系Flink的现状,详细叙述Flink在监控体系上的实践和运用,期望给同业人员一些学习和启示。

一、监控体系Flink的现状

eBay的监控渠道Sherlock.IO每天处理着上百亿条江苏汪天一被清华退学日志(log),事情(event)和方针(metric)。经过构建Flink Streaming job实时处理体系,监控团队可以及时将日志和事情的处理结果反馈给用户。当时,监控团队维护着8个Flink集群,最大的集群规划抵达上千个TaskManager,一共运转着上百个作业(job),一些作业现已安稳运转了半年以上。

二、元数据驱动

为了让用户和办理员可以愈加方便地创立Flink作业并调整参数,监控团队在Flink上搭建了一套元数据微服务(metadat印加祖玛a service),该服务可以用Json来描绘一个作业的DAG,且相同的DAG共用同一个作业,可以更芳华帅哥加方便地创立作业,无需调用Flink API。Sherlock.IO 流处理全体的架构如图1所示。

▲ 图1 Sherlock.IO 流处理全体架构

现在,用这套元数据微服务创立的作业仅支撑以Kafka作为数据源,只需数据接入到Kafka,用户就可以界说Capability来处理逻辑然后经过Flink Streaming处理数据。

1、元数据微服务

元数据微服务结构如图2所示,最上层是元数据微服务供给的Restful API, 用户经过调用API来描绘和提交作业。描绘作业的元数据包括三个部分:Resource,Capability和Policy。Flink 适配器(Adaptor)连接了Flink StreamingAPI和元数据微服务 API,且会依据元数据微服务描绘的作业调用Flink StreamingAPI来创立作业,然后屏蔽Flink StreamAPI。

因而,用户不必了解Flink StreamingAPI 就可以创立Flink作业。未来假如需求迁移到其他的流处理结构,只需添加一个适配器,就可以将现有的作业迁移到新的流处理结构上。

▲ 图2 元数据微服务结构

1)Capability

Capability界说了作业的DAG以及每个算子(Operator)所用的Class,图3是事情处理(eventProcess) Capability,它终究会生成如图4的DAG。事情处理Capability先从kafka读出数据,再写到Elasticsearch中。七月冤灵该Capability将该作业命名为“eventProcess”,并界说其并行度为“5”,其算子为“EventEsIndexSinkCapability”, 其数据流为“Source –> sink”。

▲ 图3 eventESSink Capability

▲ 图4 生成的Flink作业

2)Policy

每个命名空间(Namespace)需求界说一个或多个Poli四六级,Flink在eBay监控体系中的实践和运用,重庆人力资源和社会保障网cy,每个Policy指定了相应的Capability,即指定了用哪一套DAG来运转这个Policy。Policy还界说了这个作业的相关装备,例如从哪个Kafka topic中读取数据,写到ElasticSearch的哪个索引(Index)中,中心是否要越过某些算子等等。

其次,Policy还能作为一个简易的过滤器(Filter),可以经过装备Jexl表达式过滤掉一些不需求的数据,进步作业的吞吐量。

别的,咱们还完结了Zookeeper守时更新的机制,使得Po非组词licy修正后不再需求重启作业,只需是在更新时刻距离内,该命名空间的Policy修正就会被主动运用到作业上。图5是命名空间为paa四六级,Flink在eBay监控体系中的实践和运用,重庆人力资源和社会保障网s的Policy示例。

▲ 图5 paas alertESSink Policy

3)Resource

Resource界说了某个命名空间所需求的资源,比方Flink 集群, Kafka broker,ES 集群等等。咱们有多个Flink集群和ES集群,经过Resource装备,作业可以知道某个命名空间的日志应该写到哪个ES 集群,并可以判别该命名空间的数据应该从哪个Kafka 集群读取。

2、同享作业

为了削减作业数量,咱们可以让相同的DAG复用同一个作业。咱们先给不同的Policy指定相同的Capability,在该Capability资源满足的状况下,这些Policy就会被调度到同一个作业上。

以SQL的Capability为例,每个Policy的SQL句子不尽相同,假如为每个Policy都创立一个作业, Job Manager的开支就会很大,且不好办理。因而,咱们可以为SQL Capability装备20个Slot,每个Policy占用一个Slot。那么该Capability生成的作业就可以运转20个Policy。

作业运转时,从Source读进来的数据会被打上相应Policy的标签,并履行该Policy界说的SQL句子,然后完结不同Policy同享同一个作业,大大削减了作业的数量。

用同享作业还有一个优点:假如多个命名空间的数据在一个Kafka topic里,那么只需读一遍数据即可,不必每个命名空间都读一次topic再过滤,这样就大大进步了处理的功率。

三、Flink 作业的优化和监控

了解元数据驱动后,让咱们来看看可以经过哪些办法完结Flink作业的而优化和监控。

1、Heartbeat

在Flink 集群 的运维进程中,咱们很难监控作业的运转状况。即便敞开了检查点(checkpoint),咱们也无法确认是否丢掉数据或丢掉了多少数据。因而,咱们为每个作业注入了Heartbeat以 监控其运转状况。

Heartbeat就像Flink中用来监控推迟的“LatencyMarker”相同,它会流过每个作业的管道。但与Lat快嘴高贱翔encyMarker不同的是,当Heartbeat遇到DAG的分支时,它会四六级,Flink在eBay监控体系中的实践和运用,重庆人力资源和社会保障网割裂并流向每个四六级,Flink在eBay监控体系中的实践和运用,重庆人力资源和社会保障网分支,而不像LatencyMarker那样随机流向某一个分支。另一个不同点在于Heartbeat不是由Flink自身发作,而是由元数据微服务守时发作,而后由每个作业消费。

如图4所示,每个作业在发动的时分会默许加一个Heartbeat的数据源。Heartbeat流入每个作业后,会随数据流一同经过每个节点,在每个节点上打上当时节点的标签,然后越过该节点的处理逻辑流向下个节点。直到Hea四六级,Flink在eBay监控体系中的实践和运用,重庆人力资源和社会保障网rtbeat流到终究一个节点时,它会以方针(Metric)的方式发送到Sherlock.IO(eBay监控渠道)。

该方针包括了Heartbeat发作的时刻,流入作业的时刻以及抵达每个节点的时刻。经过这个方针,咱们可以判别该作业在读取kafka时是否延时,以及一条数据被整个管道处理所用的时刻和每个节点处理数据所用的时刻,然后判别该作业的功能瓶颈。

因为Heartbeat是守时发送的,因而每个作业收到的Heartbeat个数应该共同。若终究宣布的方针个数与期望不共同,则可以进一步判别是否有数据丢掉。

框图6描绘了某Flink作业中的数据流以及Heartbeat的运转状况:

▲ 图6 Heartbeat在作业中的运转孙耀奇进程

2、可用性

有了Heartbeat,咱们就可以用来界说集群的可用性。首要,咱们需求先界说在什么状况下归于不可用的:

1)Flink作业重启

当内存不足(OutofMemory)或代码运转过错时,作业就或许会意外重启。咱们以为重启进程中形成的数萨瓦尼耶据丢掉是不可用的状况之一。因而咱们的夹乳方针之一是让Flink作业可以长时刻安稳运转。

2)Flink作业间断

有时因为根底设施的问题导致物理机或许容器没发动起来,或是在Flink 作业发作重启时因为Slot不行而无法发动,或许是因为Flink 作业的重启次数现已超过了最大重启次数(rest.retry.max-attempts), Flink作业就会间断。此刻需求人工干涉才干将作业重新发动起来。

咱们以为Flink作业间断时,也是不可用的状况之一。

3)Flink作业在运转中不再处理数据

发作这种状况,一般是因为遇到了反压(BackPressure)。形成反压的原因有许多种,比方上游的流量过大,或许是中心某个算子的处理才能不行,或许是下流存储节点遇到功能瓶颈等等。尽管短时刻内的反压不会形成数据丢掉,但它会影响数据的实时性,最显着的改变是推迟这个方针会变大。

咱们以为反压发作时是不可用的状况之一。

针对以上三种状况,咱们都可以用Heartbeat来监控,并核算可用性。比方第一种状况,假如作业重启时发作了数据丢掉,那么相应的那段管道的Heartbeat也会丢掉,然后咱们可以监测出是否有数据丢掉以及粗粒度地预算数据丢了多少。关于第二种状况,当作业间断时,HeartBeat也不会被处理,因而可以很快发现作业中止运转并醉蛇小子让on-call及时干涉。第三种状况当反压发作时,HeartBeat也会被阻塞在发作反压的上游,因而on-call也可以很快地发现反压发作并进行人工干涉。

综上,Heartbeat可以很快监测出Flink作业的运转状况。那么,怎么评价可用性呢?因为Heartbeat是守时发作的,默许状况下咱们设置每10秒发一次。1分钟内咱们期望每个作业的每条管道可以宣布6个带有作业信息的heartbeat,那么每天就可以收到8640个Heartbeat。

因而,一个作业的可用功可以界说为:

3、Flink作业阻隔

福州最牛抗洪餐厅

Slot是Flink运转作业的最小单位[1],每个TaskManager可以分配一个至多个Slot(一般分配的个数为该TaskManager的CPU数)。依据Flink作业的并行度,一个作业可以分配到多个TaskManager上,而一个TaskManager也或许运转着多个作业。但是,一个TaskManager便是一个JVM,当多个作业分配到一个TaskManager上时,就会有争夺资源的状况发作。

例如,我一个TaskManager分配了3个Slot(3个CPU)和8G堆内存。当JobManager调度作业的时分,有或许将3个不同作业的线程调度到该TaskManager上,那么这3个作业就会一起争夺CPU和内存的资源。当其间一个作业特别耗CPU或内存的时分,就会影响其他两个作业。

在这种状况下,咱们经过装备Flink可以完结作业的阻隔,如图7所示四六级,Flink在eBay监控体系中的实践和运用,重庆人力资源和社会保障网:

▲ 图7 Flin蒂莉娅战记k作业阻隔前后的调度图

经过装备:

  • “taskmanager.numberOfTaskSlots: 1”:可以设置每个TaskManager只要一个Slot;
  • “cpu_period”和“cpu_quota”:可以限制每个TaskManager蹂的CPU个数;
  • “taskmanager.heap.mb”可以装备每个TaskManager的JVM的内存大小。

经过以上装备,可以限制每个TaskManager独占CPU和内存的资源,且不会多个作业抢占,完结作业之间的阻隔。

4、反压

咱们运维Flink集群的时分发现,呈现最多的问题便是反压。在3.2中提到过,发作反压的原因有许多种,但无论什么原因,数据终究都会被积压在发作反压上游的算子的本地缓冲区(localBuffer)中。

咱们知道,每一个TaskManager有一个本地缓冲池, 每一个算子数据进来后会把数据填充到本地缓冲池中,数据从这个算子出去后会收回这块内存。当被反压后,数据发不出去,本地缓冲池内存就无法开释,导致一向恳求缓冲区(requestBuffer)。

因为Heartbeat只能监控出是否发作了反压,但无法定位到是哪个算子出了问题,因而咱们守时地将每个算子的StackTrace打印出来,当发作反压时,经过StackTrace就可以知道是哪个算子的瓶颈。

如图8所示,咱们可以明晰地看到发作反压的Flink作业及其地点的Taskmanager。再经过Thread Dump,咱们就可以定位到代码的问题。

▲ 图8 发作反压的StackTrace (点击观看大图)

5、其他监控手法

Flink自身供给了许多有用的方针[2]来监控Flink作业的运转状况,在此根底上咱们还加了一些事务上的方针。除此之外,咱们还运用了以下东西监控Flink 作业。

1)History server

Flink的History server[3]可以查询已完结作业的状况和方针。比方一个作业的重启次数、它运转的时刻。极品修真邪少陈青帝咱们常常用它找出运转不正常的作业。比方,咱们可以经过History server的attempt方针知道每个作业重启的次数,然后快速去现场找到重启的原因,防止下次再发作。

2)监控作业和集群

尽管Flink有HA的形式,但在极点状况下,例如整个集群呈现问题时,需求on-call即时发觉并人工干涉。咱们在元数据微服务中保存了终究一次提交作业成功的元数据,它记录了在每个Flink 集群上应该运转哪些作业。看护线程(Daemon thread)会每分钟去比较这个元数据和Flink上运转的作业,若发现JobManager连不通或许有作业运转不共同则马上宣布告警(Alert)告诉on-call。

四、实例

下面介绍几个现已运转在监控体系上的Flink流处理体系的运用:

1、Event Alerting

当时监控团队是依据Flink Streaming做事情告警(Event alerting),咱们界说了一个告警算子EventAlertingCapability,该男体写真Capability可以处理每个Policy自界说的规矩。如图9界说的一条功能监控规矩:

该规矩的意义是当功能检测器的运用为“r1rover”, 主机以“r1rover”最初,且数值大于90时,就触发告警。且生成的告警会发送到指定的Kafka topic中供下流持续处理。

▲ 图9 Single-Threshold1 Policy (点满山桃花不正经击查看大图)

2、Eventzon

Eventzon就像eBay的事情中心,它收集了从各个运用,框苏幼珍老公白钟元二婚架,根底架构发过来的事情,终究经过监控四六级,Flink在eBay监控体系中的实践和运用,重庆人力资源和社会保障网团队的Flink Streaming实时生成告警。因为各个事情的数据源不同,它们的元数据也不同,因而无法用一条一致的规矩来描绘它。

咱们专门界说了一套作业来处理Eventzon的事情,它包括了多个Capability,比方Filter Capability,用来过滤不合法的或许不符合条件的事情; 又比方Deduplicate Capability,可以用来去除重复的事情。

Eventzon的一切事情经过一整套作业后,会生成有用的告警,并依据告诉机制经过E-mail、Slack或Pagerduty发给相关团队。

3、Netmon

Netmon的全称为Network Monitoring, 即网络监控,它可以用来监控整个eBay网络设备的健康状况。它的数据源来自eBay的交换机,路由器等网络设备的日志。Netmon的作用是依据这些日志找出一些特定的信息,往往是一些过错的日志,以此来生成告警。

eBay的每一台设备都要“挂号造册”,每台设备将日志发过来后,咱们经过EnrichCapability 从“册子”中real423查询这台设备的信息,并把相关信息比方IP地址,地点的数据中心,地点的机架等填充到日志信息中作为事情保存。当设备发作一些特定的过错日志时, 它会被相应的规矩匹配然后生成告警,该告警会被EventProcess Capability保存到Elasticsearch中实时显现到Netmon的监控渠道(dashboard)上。有时因为网络颤动导致一些时间短的过错发作,但体系过一瞬间就会主动康复。

当上述状况发作时,Netmon会有相应的规矩将发作在网络颤动时生成的告警标记为“已处理”(Resolved)。关于一些有必要人工干涉的告警,运维人员可以经过网络监控渠道(Netmon dashboard)手动点击“已处理”,完结该告警的生命周期。

五、总结与展望

eBay的监控团队期望能依据用户供给的方针、事情和日志以及相应的告警规矩实时告警用户。Flink Streaming可以供给低延时的处理然后可以抵达咱们低延时的要求,而且它合适比较杂乱的处理逻辑。

但是在运维Flink的进程中,咱们也发现了因为作业重启等原因导致误报少报告警的状况发作,然后误导客户。因而往后咱们会在Flink的安稳性和高可用性上投入更多。咱们也期望在监控方针、日志上可以集成一些杂乱的AI算法,然后可以生成愈加有用准确的告警,成为运维人员的一把利器。

>>>> 参考资料

  • https://ci.apache.org/projects/flink/flink-docs-release-1.7/concepts/runtime.html#task-slots-and-resources
  • https://ci.apache.org/projects/flink/flink-docs-release-1.7/monitoring/metrics.html
  • https://ci.apache.org/projects/flink/flink-docs-release-1.4/monitoring/historyserver.html

作者:Unified Monitoring Platform 顾欣怡[译]

来历:扫帚蘑eBay技能荟(ID:eBayTechRecruiting)

dbaplus社群欢迎广阔技能人员投稿,投稿邮箱:editor@dbaplus.cn

版权声明

本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。