M3 Event Hub
A high estimated backlog for an Event Hub subscriber can cause delays in processing the events in the receiving application. The cause may be many events to process, a slow processing rate, or a problem with the subscriber. This is perceived as a queue buildup for the subscriber, even though the events are not stored in a physical queue per subscriber.
See the information about Event Hub in the M3 Core User and Administration Library and select .
Time lag is used to detect queue buildups for a subscriber. Time lag is consumer lag measured in time rather than in events.
Estimated backlog answers the question, "How many events behind is this subscriber?"
Time lag answers the question, "How far back in time is this subscriber?"
Time lag is the difference between the production timestamps of the most recent event available to the subscriber and the most recent event the subscriber has processed.
The distinction matters because estimated backlog, which is based on the number of events, does not include the elapsed time. An estimated backlog of 10,000 events for a well-functioning subscriber may be two seconds of processing time; an estimated backlog of 5 events for a subscriber with a problem may mean the overall process has been stuck for an hour. Time lag is what maps onto a business expectation, such as events are processed within 5 minutes, which is why it drives the alerting threshold here rather than the estimated backlog.
- Green: When the time lag is normal
- Red: When there is an increased time lag
You can check the current estimated backlog for the subscriber on the page on the Administration tab by using the drill back link M3 Event Hub Administration UI in the notification.