【Azure 事件中心】EPH (EventProcessorHost) 消费端观察到多次Shutdown,LeaseLost的error信息,这是什么情况呢?

简介: 【Azure 事件中心】EPH (EventProcessorHost) 消费端观察到多次Shutdown,LeaseLost的error信息,这是什么情况呢?

问题详情

使用EPH获取Event Hub数据时,多次出现连接shutdown和LeaseLost的error  ,截取某一次的error log如:

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '29', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '26', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '1', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '22', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '8', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '9', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '7', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '31', Reason: 'LeaseLost'.

Time:2021-03-10 08:43:48.4650|NE:VSDN|Machine:RD0003FF01A8BE|Lv:INFO|ActivityId:|Msg:CdmEventProcessor Shutting Down. Partition '17', Reason: 'LeaseLost'

....

 

如何解释EPH的Shutting Down呢?为什么出现LeaseLost(租约丢失)情况呢?

 

问题解释

在Azure SDK Microsoft.Azure.EventHubs.Processor 的解释中列举出LeaseLost是The lease was lost or transitioned to a new processor instance,表示当前租约丢失,或者转移到一个新的Processor实例上。

 

这是因为Event Hub可以设置多个分区,同时也可以通过多个消费端来消费分区中的数据,但是多少个客户端是最好的呢?根据【Azure 事件中心的 .NET 编程指南】中对EPH(Event Processor Host)的介绍,客户端主机将尝试使用“贪婪”算法获取事件中心内每个分区上的租约,如果当前只有一个消费端连接Event Hub,则当前消费端会把所有分区的租约都获取过去。当有2个或者多个消费端时,它们会自动在多个消费端中进行负载均衡,最终达到动态平衡

  • 只有一个消费端时(Azure Worker Role 1),8个分区都与它建立租约。
  • 当有第二个消费端时(Azure Worker Role 2), EPH就自动动态平衡分区数,最终表现为各自处理4个分区数据。
  • 而原来与Worker Role 1相连的5,6,7,8分区就会出现shutdown,原因时leaselost的日志记录。

 

所以,我们观察到的Shutdown LeaseLost日志消息就是因为EPH在自动进行多个实例间分区数的动态平衡而产生的。这是完全正常的现象。

 

EPH出现LeaseLost的详细分解

可见原文地址:https://stackoverflow.com/questions/41496754/what-is-causing-azure-event-hubs-receiverdisconnectedexception-leaselostexceptio/41867611#41867611

TLDR: This behavior is absolutely normal.

Why can't Lease Management be smooth & exception-free: To give more control on the situation to developer.

The really long story - all-the-way from Basics EventProcessorhost (hereby EPH - is very similar to what __consumer_offset topic does for Kafka Consumers - partition ownership & checkpoint store) is written by Microsoft Azure EventHubs team themselves - to translate all of the EventHubs partition receiver Gu into a simple onReceive(Events) callback.

... ...

译文内容为:

TLDR: This behavior is absolutely normal. 这是正常的行为

为什么不能让Event Hub分区租约的管理不出现异常呢?这是为了更好地让开发者来控制租约到期(Lease Lost)的情况。

 

这需要从EventProcessorHost(简称 EPH)从创建之时说起, EPH是由Microsoft Azure EventHubs团队开发,用来把所有的EventHubs partition receiver事件转换为一个简单的回调事件 onReceive。这样的目的是为了解决在读取高吞吐量分区数据流的情况下的2个主要的,众所周知的问题

1)容错接收管道 (Fault tolerant receive pipe-line) - 如果运行PartitionReceiver的Host 宕机后恢复正常,则它需要从其宕机的地方继续进行处理。 为了记住上一次成功处理的EventData,EPH使用提供给EPH构造函数的Blob来存储检查点(Checkpoints -调用context.CheckpointAsync()时)。 所以,当Host进程终止时(例如:突然重新启动或遇到硬件故障,再也无法恢复),任何EPH实例都可以执行此任务并从该Checkpoint恢复。

2)在EPH实例之间动态分配分区 (Balance/distribute partitions across EPH instances) 假设有10个分区和2个EPH实例处理来自这10个分区的事件 - 需要一种在实例之间划分分区的方法(PartitionManager组件)。 使用Azure存储-Blob LeaseManagement功能来实现这一点。 从2.2.10版本开始 --- 简化为EPH假定所有分区均被加载。

 

基于以上的情况,我们来看一看EPH发生了什么,首先, 在上面的10个事件中心分区和2个EPH实例的示例中,处理其中的事件顺序如下:

一:假设第一个EPH实例(EPH1)最初是单独启动的,它为所有10个分区创建了接收器,并且开始处理事件。在启动过程中 ---  EPH1将通过获取代表这10个事件中心分区的租约(存储Blob上)来宣布拥有所有这10个分区(EPH在存储帐户中内部创建-从StorageConnectionString中获取Blob)。但是该租约旨在指定时间内有效,有效期过后,EPH1会失去对分区的所有权

二:通过更新Blob上的租约,EPH1会连续续订这10个分区的租约。 续订频率以及其他有用的调整可以使用PartitionManagerOptions修改

三:启动第二个EPH实例(EPH2), 并且使用与EPH1相同的StorageConnectionString。开始时,EPH2有0个分区要处理,为了要在EPH实例之间实现分区的动态平衡,EPH2将下载租约列表(包含分区ID与拥有者的映射关系)。并会平均的截取5个分区的租约。在整个过程中,EPH2会根据所获取的分区信息得到最新的检查点(checkpoint),创建PartitionReceiver并继续接收消息

四:最后,EPH1将失去对这5个分区的所有权,并将根据其分区的实时状态而遇到不同的错误。

  • 如果EPH1正在调用PartitionReceiver.Receive时,而且EPH2在同一分区创建PartitionReceive, EPH1就会遇见ReceiverDisconnectedException。并且调用EventProcessor.Close方法,Close Reason为LeaseLost
  • 如果EPH1处于checkpointingrenewing 租约的状态,而EPH2窃取了租约,则产生EventProcessorOptions.ExceptionReceived异常,eventHandler带有leaselostException的信号(409 conflict error)-最终也会调用IEventProcess.Close (LeaseLost)

 

为什么不能让Event Hub分区租约的管理不出现异常呢?(Why can't Lease Management be smooth & exception-free)

为了使消费端简单和无错误,EPH可以吞下与租约相关的异常,而不通过用户代码的方式通知。 但是,我们意识到,抛出LeaseLostException可能使客户能够在IEventProcessor.ProcessEvents()回调中找到问题的根源 --- 可能是频繁进行分区移动造成

  • 当消费端实例(EPH)发生轻微的网络抖动, 使得EPH无法续订租约而重启。如果这个实例的网络一直处于抖动情况,EPH将来来回回获取Partitions信息,同时不断的尝试从其他EPH中窃取租约。这将导致消费端无法处理正常的Event Hub事件。当发生这样的情况时,可以在日志中可见ReceiverDisconnectedException异常,这一点可以非常好的帮助开发者定位问题。
  • 或是在ProcessEvents的逻辑代码中出现无法处理的异常,并导致整个进程被破坏,分区也会在多个EPH实例之间来回移动。
  • 也有可能是在EPH中使用的储存账户上有执行write/delete操作,与EPH实例执行的操作冲突等。
  • 也有可能是Azure的数据中心发生大范围的宕机事件(不希望这样的情况发生),分区也会在多个EPH实例之间来回移动。

 

在大多数情况下,对于Event Hub SDK而言,要检测以上这些异常是非常棘手的。 所以SDK团队将控制权委托给开发者,开发者通过抛出的异常来定位问题。

 

 

参考资料

CloseReason Enum:https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.eventhubs.processor.closereason?view=azure-dotnet#fields

What is causing Azure Event Hubs ReceiverDisconnectedException/LeaseLostException? https://stackoverflow.com/questions/41496754/what-is-causing-azure-event-hubs-receiverdisconnectedexception-leaselostexceptio

Event Hub事件使用者https://docs.azure.cn/zh-cn/event-hubs/event-hubs-programming-guide#event-consumers

相关文章
|
4月前
|
Java 网络安全 开发工具
【Azure 事件中心】Event Hub 无法连接,出现 Did not observe any item or terminal signal within 60000ms in 'flatMapMany' 的错误消息
【Azure 事件中心】Event Hub 无法连接,出现 Did not observe any item or terminal signal within 60000ms in 'flatMapMany' 的错误消息
144 1
|
4月前
|
存储
【Azure 事件中心】Event Hubs中存在非常多的错误数据,是否能提前删除这些数据呢?
【Azure 事件中心】Event Hubs中存在非常多的错误数据,是否能提前删除这些数据呢?
|
4月前
|
消息中间件 存储 Kafka
【Azure 事件中心】Flink消费Event Hub中事件, 使用Azure默认示例代码,始终获取新产生的事件,如何消费旧事件呢?
【Azure 事件中心】Flink消费Event Hub中事件, 使用Azure默认示例代码,始终获取新产生的事件,如何消费旧事件呢?
|
4月前
|
Java 开发工具
【事件中心 Azure Event Hub】关于EventHub中出现Error时候的一些问题(偶发错误,EventHub后台升级,用户端错误,Retry机制的重要性)
【事件中心 Azure Event Hub】关于EventHub中出现Error时候的一些问题(偶发错误,EventHub后台升级,用户端错误,Retry机制的重要性)
|
4月前
|
存储 Java 开发工具
【Azure 事件中心】Event Hubs如何获取其中存放的历史消息
【Azure 事件中心】Event Hubs如何获取其中存放的历史消息
|
4月前
|
监控 Java 开发工具
【事件中心 Azure Event Hub】Event Hub Java SDK的消费端出现不消费某一个分区中数据的情况,出现IdleTimerExpired错误消息记录
【事件中心 Azure Event Hub】Event Hub Java SDK的消费端出现不消费某一个分区中数据的情况,出现IdleTimerExpired错误消息记录
|
4月前
|
存储 开发工具 C#
【Azure 事件中心】从Azure Event Hub中消费数据,如何查看当前消费客户端消费数据的Offset和SequenceNumber呢(消息偏移量和序列号)?
【Azure 事件中心】从Azure Event Hub中消费数据,如何查看当前消费客户端消费数据的Offset和SequenceNumber呢(消息偏移量和序列号)?
|
4月前
|
分布式计算 Java Spark
【事件中心 Azure Event Hub】使用Logstash消费EventHub中的event时遇见的几种异常(TimeoutException, ReceiverDisconnectedException)
【事件中心 Azure Event Hub】使用Logstash消费EventHub中的event时遇见的几种异常(TimeoutException, ReceiverDisconnectedException)
|
4月前
|
SQL 存储 数据库连接
【Azure Stream Analystics】流分析服务执行遇见警告错误消息,导致上游数据堆积,下游无任何输出
【Azure Stream Analystics】流分析服务执行遇见警告错误消息,导致上游数据堆积,下游无任何输出
【Azure Stream Analystics】流分析服务执行遇见警告错误消息,导致上游数据堆积,下游无任何输出
|
4月前
|
运维
【Azure Event Hub】自定义告警(Alert Rule)用来提示Event Hub的消息incoming(生产)与outgoing(消费)的异常情况
【Azure Event Hub】自定义告警(Alert Rule)用来提示Event Hub的消息incoming(生产)与outgoing(消费)的异常情况