The IotTelemtrySimulator.Automation .NET Standard 2.1 library allows you to run the IoT Telemetry Simulator as part of a pipeline or any other automation framework.
It authenticates with Azure either using managed identities or a service principal, sets up the Azure resource group, container group(s) and container instance(s) needed, pulls the IotTelemetrySimulator Docker container from an Azure container registry, configures and runs the simulator, waits for it to finish, pulls and outputs it's log files and then tears down the Container instances and groups and the resource group.
This way, automated load tests can be run as part of a CD/CI pipeline or any automation framework that allows executing arbitrary code.
IotTelemetrySimulator.Automation : The .NET Standard 2.1 automation library.
- appsettings.json : Configuration file.
IotTelemetrySimulator.Automation.Console : A .NET Core 3.1 console app that illustrates how to use the automation component.
If you chose Service Principal authentication, you need to create an Active Directory application with the rights to create and remove resources in the desired Azure subscription. To achieve this, create a new application in Azure Active Directory and then navigate to "Subscriptions → [Subscription Id] → Access Control (IAM) → Role Assignments" and then add the newly created AAD Application with "Contributor" role.
If you chose Managed Identity authentication, the application will run with the permissions of the currently logged in user or the Azure DevOps pipeline's permissions. Make sure that you are logged in to the proper Azure account using the AZ command line interface tool.
To use Service Principal authentication, in the configuration, put AuthenticationMethod = 'Service Principal' and provide the first four following settings: AadClientId, AadClientSecret, AzureSubscriptionname and AadTenantId.
To use Managed identity authentication, in the configuration, put AuthenticationMehtod = 'Managed Identity' and provide the following two settings: AadTenantId and AzureSubscriptionId.
To have the Azure Container Instance pull the image from an Azure Container Registry, set the ContainerImage setting to the full image name including the registry: acrname.azurecr.io/azureiot-telemetrysimulator:latest and provide the settings for AcrServer, AcrUsername and AcrPassword.
To use the image published to the Microsoft Container Registry, set the ContainerImage to the full image name including the registry again: mcr.microsoft.com/oss/azure-samples/azureiot-telemetrysimulator:latest but leave the settings for AcrServer, AcrUsername and AcrPassword empty.
The configuration for the automation component is kept in appsettings.json or for local development purposes in appsettings.Development.json. It contains the following fields:
| Parameter | Description |
|---|---|
| AuthenticationMethod | Service Principal or Managed Identity |
| AadClientId | Azure Active Directory app registration Application (Client) Id Only used with Service Principal authentication method |
| AadClientSecret | Azure Active Directory app registration Client Secret Only used with Service Principal authentication method |
| AzureSubscriptionName | Azure Subscription Name Only used with Service Principal authentication method |
| AadTenantId | Azure Active Directory Tenant Id (Get by navigating to "Azure → Active Directory → Manage → Properties → Directory ID") Used with Service Principal and Managed Identity authentication methods |
| AzureSubscriptionId | Azure Subscription Id Only used with Managed Identity authentication method |
| AzureRegion | Azure Region as formatted in the Fluent SDK Core.Region Class' Fields All resources will be created in this region. |
| ResourceGroupName | The name of the Azure Resource Group created by to host the Container Groups |
| ContainerGroupName | The name prefix under which the Azure Container Groups will be created |
| ContainerImage | The full path to the docker image to be pulled by the Azure Container Instances. For example: acrname.azurecr.io/azureiot-telemetrysimulator:latestto use an Azure Container Registry or mcr.microsoft.com/oss/azure-samples/azureiot-telemetrysimulator:latestto use a public container registry / DockerHub |
| AcrServer | The name of the Azure Container Registry. I.e. `acrname.azurecr.io Leave blank to use a public container registry |
| AcrUsername | The name of user with which to access the Azure Container Registry Leave blank to use a public container registry |
| AcrPassword | The above user's Azure Container Registry password Leave blank to use a public container registry |
| IotHubConnectionString | Iot Hub connection string. "Device" our "Iot Hub owner" scopes are good. Example: HostName=your-iothub-name.azure-devices.net;SharedAccessKeyName=device;SharedAccessKey=your-iothub-keyOnly provide if messages are to be sent to IoT Hub. |
| EventHubConnectionString | Event Hub connection string. SAS Policy "Send" is required. For EventHub no device registration is required. Example: Endpoint=sb://your-eventhub-namespace.servicebus.windows.net/;SharedAccessKeyName=send;SharedAccessKey=your-send-sas-primary-key;EntityPath=your-eventhub-nameOnly provide if messages are to be sent to Event Hub. |
| PayloadDistribution | Allows the generation of payloads based on a distribution. Example: "fixSize(10, 12) template(25, default) fix(65, aaaaBBBBBCCC)"generates 10% a fix payload of 10 bytes, 25% a template generated payload and 65% of the time a fix payload from values aaaaBBBBBCCC |
| Template1 | Telemetry payload template 1 see telemetry template |
| Template2 | Telemetry payload template 2 see telemetry template |
| Variables | Telemetry variables see telemetry template |
| DevicePrefix | Device identifier prefix (default = "sim Make sure these devices exist in your target IoT hub |
| Header | Telemetry header template |
| DeviceCount | Nubmer of simulated devices (default = 1) |
| MessageCount | Number of messages to send per device (default = 10). Set to zero if you wish to send messages until cancelled |
| Interval | Interval between each message in milliseconds (default = 1000) |
| ContainerCount | Number of Azure Container Instances to be created See sizing |
| CpuCores | Number of CPU Cores to allocate per Azure Container Instance See sizing |
| MemoryGb | Gb of memory to allocate per Azure Container Instance See sizing |
To find out the valid values for CPU cores and Gb of memory to allocate for the Azure Container Instances, please consult the Resource availability for Azure Container Instances in Azure regions guide. The automation component uses Linux based containers.
It is usually not needed to use more than 1 CPU and 1.5 Gb of memory as the limitation of the container is the networking throughput, not the memory or CPU load.
The number of devices you plan to run your load test with is divided by the number of ConainerCount and each container will simulate this number of devices.
10'000 devices, 2 ContainerCount: 2 Azure Container Instances running with 5000 devices each.
Note that we have had the best results with up to 2500 messages per second sent from one container with a message payload size of about 500 bytes.