Sample for Lag Metrics for Event Hub

This repo sets up a minimal example (using Bicep) for using Lag Metrics for Event Hub and defining an Azure Monitor alert.

Documentation

Documentation regarding Lag Metrics can be found here.

Deploy the sample

You must create the resource group beforehand, e.g. with:

az group create \
  --name lag-metrics-sample \
  --location EastUS \
  --subscription YOUR_SUBSCRIPTION_NAME_OR_ID

Before deploying Lag Metrics, Microsoft requires that the terms are accepted. Lag Metrics uses the Microsoft-defined standard terms for Managed Applications without any amendments. You can find these terms here. Please review them and then accept them with the following command:

az vm image terms accept \
  --offer lag-metrics \
  --plan standard \
  --publisher huditechughaftungsbeschrnkt1673457598758

The sample can then be deployed with:

az deployment group create \
    --resource-group lag-metrics-sample \
    --subscription YOUR_SUBSCRIPTION_NAME_OR_ID \
    -f main.bicep

You will be prompted for the email address that notifications should be sent to.

Alternatively, you can also run:

./deploy.sh youremail@example.com

This has the advantage that it automatically creates the .env file for the sender and receiver clients (see below).

Send and receive messages

The client folder contain a Javascript client to produce messages to Event Hub in order to trigger the alert. The connection strings are contained in clients/.env which is auto-generated by ./deploy.sh. You can simply run the sender:

cd clients
npm install
node sender.js

You now have to consume some messages. This causes offset/checkpoint information to be written.

node receiver.js

Now the lag can be calculated by Lag Metrics. You can observe the lag metrics being pulished after a few minutes. If the lag is above 100, an alert will be fired and a notification will be sent via email. Expect a delay of a few minutes since the rule is only evaluated at certain intervals by Azure Monitor.

NOTE: If no messages have been consumed at all, no lag will be detected. The reason for this is that if no messages have been consumed, no offset information is available and thus no lag can be calculated.