Pruebas de carga de Azure con complementos personalizados para Event Hubs e IoT Hub

2025-06-10

Ideas de solución

En este artículo se describe una idea de solución. El arquitecto de la nube puede usar esta guía para ayudar a visualizar los componentes principales de una implementación típica de esta arquitectura. Use este artículo como punto de partida para diseñar una solución bien diseñada que se adapte a los requisitos específicos de la carga de trabajo.

Esta solución proporciona instrucciones sobre cómo usar Azure Load Testing, un servicio que le permite ejecutar scripts de Apache JMeter y complementos personalizados para simular comportamientos de usuarios y dispositivos. Esta solución también explica cómo diseñar indicadores clave de rendimiento (KPI) y desarrollar un panel para supervisar y analizar los resultados de la prueba de carga en una aplicación de ejemplo con Azure Functions y Azure Event Hubs. En este ejemplo se usa Event Hubs, pero puede aplicar el mismo enfoque a Azure IoT Hub cambiando el cliente de Event Hubs al cliente de IoT Hub. En este artículo se da por supuesto que tiene cierta familiaridad con JMeter, sus complementos, sus complementos personalizados, así como con Functions y Event Hubs.

IoT Hub contiene más componentes principales que Event Hubs, incluidas las particiones. Por lo tanto, el enfoque de pruebas de carga descrito en este artículo también se aplica a IoT Hub con cambios mínimos.

Arquitectura

Para realizar pruebas de carga, necesita un plan de prueba, que es un conjunto de instrucciones que indica a JMeter lo que debe hacer durante la prueba. El plan de prueba puede incluir varios escenarios de prueba, y cada escenario puede tener configuraciones y configuraciones diferentes. Por ejemplo, puede tener un escenario que simula un solo usuario que accede a una aplicación web y otro escenario que simula que varios usuarios acceden simultáneamente a la misma aplicación.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

El siguiente flujo de datos corresponde al diagrama anterior:

Un dispositivo simulado envía datos a un centro de eventos a través de un agente de Load Testing. Cualquier comportamiento del dispositivo se puede simular mediante complementos personalizados de JMeter. El agente de Load Testing envía datos al centro de eventos después de ejecutar el complemento personalizado para cualquier tipo de dispositivo simulado.
El centro de eventos desencadena una aplicación de funciones de Azure que procesa los datos y la envía a otros servicios de bajada, como Azure SQL Database y Azure Digital Twins.
Azure Monitor supervisa la aplicación de funciones y Event Hubs.
Load Testing recopila los datos de Azure Monitor y los muestra en un panel.

Componentes

En este ejemplo se usan los siguientes componentes:

Pruebas de carga: use Pruebas de carga para ejecutar scripts de Apache JMeter y complementos personalizados para simular comportamientos de usuario y dispositivo. Load Testing proporciona una interfaz basada en web para administrar y ejecutar pruebas de carga y un conjunto de API para automatizar el proceso. Load Testing es un servicio totalmente administrado, lo que significa que no es necesario administrar servidores o infraestructuras. En esta arquitectura, Load Testing carga los scripts de JMeter y los complementos personalizados, y es el entorno de computación donde se ejecutan esos scripts.
Event Hubs: Event Hubs es un servicio de procesamiento de eventos basado en la nube que puede usar para recopilar, procesar y analizar eventos y transmitir datos de varios orígenes en tiempo real. Event Hubs admite varios protocolos, incluidos el Protocolo avanzado de Encolado de Mensajes (AMQP), HTTPS, el protocolo Kafka, el Protocolo de transporte de telemetría de mensajería (MQTT) y AMQP sobre WebSocket. Esta arquitectura se basa en eventos, por lo que Load Testing rellena los eventos para cargar la carga de trabajo.
IoT Hub: IoT Hub es un servicio administrado hospedado en la nube que actúa como centro de mensajes central para la comunicación entre una aplicación de IoT y sus dispositivos conectados. Puede conectar millones de dispositivos y sus soluciones de back-end con confianza y de forma segura. Casi cualquier dispositivo se puede conectar a un centro de IoT. Puede adaptar esta arquitectura para usar IoT Hub cambiando el cliente de Event Hubs al cliente de IoT Hub.
Azure Functions: Functions es un servicio de proceso sin servidor que puede usar para ejecutar código sin necesidad de administrar servidores o infraestructuras. Es compatible con varios lenguajes de programación, como C#, F#, Java, JavaScript, PowerShell, Python y TypeScript. Esta arquitectura usa Functions como nivel de proceso principal. Los datos de eventos en Event Hubs desencadenan y amplían horizontalmente las aplicaciones de funciones.
GUI de JMeter: JMeter GUI es una herramienta de prueba de carga de código abierto que se usa principalmente para probar el rendimiento de las aplicaciones web. Sin embargo, también puede usarlo para probar otros tipos de aplicaciones, como servicios web SOAP y REST, servidores FTP y bases de datos.
Azure Monitor: Azure Monitor ofrece funcionalidades de supervisión y alerta para los recursos de Azure. Úselo para supervisar el rendimiento y el estado de las aplicaciones y la infraestructura subyacente. En esta arquitectura, Azure Monitor supervisa el estado de los componentes de la infraestructura de Azure durante la prueba de carga.

Detalles del escenario

Puede usar Load Testing para aplicar un script de Apache JMeter existente y ejecutar una prueba de carga a escala en la nube en cualquier recurso de Azure.

JMeter permite a los evaluadores crear y ejecutar pruebas de carga, pruebas de esfuerzo y pruebas funcionales. Simula que varios usuarios acceden simultáneamente a una aplicación web para que los evaluadores puedan identificar posibles cuellos de botella de rendimiento u otros problemas que puedan surgir bajo cargas pesadas. Puede usar JMeter para medir varias métricas de rendimiento, como el tiempo de respuesta, el rendimiento y la tasa de errores.

JMeter usa una interfaz basada en GUI para permitir a los usuarios crear planes de prueba, que pueden incluir varios escenarios de prueba que tienen configuraciones y configuraciones diferentes. Los evaluadores también pueden personalizar JMeter mediante complementos o escribiendo código personalizado. Los complementos pueden ayudar a los usuarios a trabajar con servicios que usan protocolos que no son HTTP, como AMQP y WebSocket.

JMeter proporciona una amplia gama de características y funciones para las pruebas de carga, pero es posible que la funcionalidad integrada no cubra casos de uso o requisitos específicos. Al desarrollar complementos personalizados, los evaluadores pueden agregar nuevas funcionalidades o personalizar las características existentes para adaptarse mejor a sus necesidades.

Por ejemplo, puede desarrollar un complemento personalizado para simular un tipo específico de comportamiento de usuario o para generar datos de prueba más realistas. También puede desarrollar complementos personalizados para integrar JMeter con otras herramientas o sistemas, como herramientas de registro e informes o canalizaciones de integración continua e implementación continua (CI/CD). Los complementos personalizados pueden ayudar a optimizar el proceso de prueba y facilitar la incorporación de pruebas de carga en el flujo de trabajo general de desarrollo de software. Permiten a los evaluadores adaptar JMeter a sus necesidades específicas y mejorar la precisión y eficacia de sus esfuerzos de pruebas de carga.

En este ejemplo, un dispositivo notifica la temperatura y la humedad durante un período de tiempo específico. En el ejemplo se simula este comportamiento mediante un complemento JMeter personalizado. La implementación actual del complemento personalizado genera datos aleatorios mediante una plantilla proporcionada. Sin embargo, el complemento puede contener cualquier comportamiento complejo posible para cualquier dispositivo. En este ejemplo, el dispositivo envía los datos a un centro de eventos en Azure. El centro de eventos desencadena una aplicación de funciones de Azure que procesa los datos y la envía a otros servicios de bajada, como SQL Database. Azure Functions es el servicio que prueba la arquitectura. El plan de prueba está diseñado para simular el comportamiento del dispositivo y enviar datos al centro de eventos.

Posibles casos de uso

El uso de Pruebas de carga con complementos personalizados puede resultar útil en varios escenarios, como:

Probar el rendimiento de una aplicación que usa protocolos que no son HTTP, como AMQP y WebSocket.
Probar el rendimiento de una aplicación que usa un protocolo personalizado.
Probar el rendimiento de una aplicación que usa un SDK que no es de Microsoft.
Simular un tipo específico de comportamiento de usuario o dispositivo.
Generación de datos de prueba más realistas.

Complementos personalizados

En JMeter, los complementos personalizados son componentes de software que puede agregar para expandir su funcionalidad predeterminada. Los complementos personalizados agregan nuevas características, funciones o integraciones a JMeter. Puede desarrollar complementos personalizados mediante el lenguaje de programación Java y el kit de desarrollo de complementos de JMeter (PDK). El PDK proporciona un conjunto de herramientas y API que le ayudan a crear nuevos complementos, incluidos elementos de GUI, agentes de escucha y muestreadores.

Para implementar un sampler personalizado para Event Hubs en JMeter, siga las instrucciones de Complementos JMeter de pruebas de carga. Después de implementar el sampler personalizado, puede usarlo en el plan de prueba de JMeter en Pruebas de carga igual que cualquier otro sampler.

Puede implementar un plan de prueba mediante un grupo de subprocesos que controla el número de subprocesos, como usuarios virtuales y dispositivos, para ejecutar un escenario específico. Cada grupo de subprocesos puede tener una configuración diferente para el número de subprocesos, el período de inicialización, el recuento de bucles y la duración. Los grupos de subprocesos se pueden ejecutar secuencial o en paralelo, según la configuración del plan de prueba y los requisitos de la aplicación. Puede agregar el muestreador a un grupo de subprocesos, definir sus parámetros y configurarlo según sea necesario. Los muestreadores personalizados pueden ser herramientas eficaces en JMeter que permiten simular escenarios complejos y solicitudes que los samplers integrados no admiten.

Creación de un script de Apache JMeter con un complemento personalizado

En esta sección, creará un script de prueba de JMeter de ejemplo para cargar una aplicación con Event Hubs.

Para crear un script de prueba de JMeter de ejemplo:

Cree un archivo LoadTest.jmx en un editor de texto y pegue el siguiente fragmento de código en el archivo. Este script simula una prueba de carga de 36 máquinas virtuales que envían eventos simultáneamente a un centro de eventos. Tarda 10 minutos en completarse.

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
            <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
            <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
            <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
                <boolProp name="LoopController.continue_forever">false</boolProp>
                <intProp name="LoopController.loops">-1</intProp>
            </elementProp>
            <stringProp name="ThreadGroup.num_threads">36</stringProp>
            <stringProp name="ThreadGroup.ramp_time">20</stringProp>
            <boolProp name="ThreadGroup.scheduler">true</boolProp>
            <stringProp name="ThreadGroup.duration">600</stringProp>
            <stringProp name="ThreadGroup.delay"></stringProp>
            <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
             <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" estclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
                <!-- Azure Event Hub connection configuration using Managed Identity (see repository for instructions) -->
                <boolProp name="useManagedIdentity">true</boolProp>
                <stringProp name="eventHubNamespace">telemetry-ehn.servicebus.windows.net</stringProp>
                <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
                <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
            </com.microsoft.eventhubplugin.EventHubPlugin>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

La implementación de com.microsoft.eventhubplugin.EventHubPluginGui y com.microsoft.eventhubplugin.EventHubPlugin está disponible en Azure samples.

En el archivo, establezca los valores de conexión de Event Hubs mediante la identidad administrada asignada de los ejecutores de pruebas. Esa identidad debe tener acceso de escritura a la instancia de Event Hubs.
En el archivo, establezca como valor del nodo eventHubName el nombre del centro de eventos, como por ejemplo telemetry-data-changed-eh.
Establezca el valor del liquidTemplateFileName nodo en el archivo que contiene el mensaje que se envía al centro de eventos. Por ejemplo, cree un archivo denominado StreamingDataTemplate.liquid como:
```
{
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}
```
En este ejemplo, la carga del mensaje del centro de eventos es un objeto JSON que tiene tres propiedades, MachineId, Temperaturey Humidity. MachineId es un identificador generado aleatoriamente que tiene 27 caracteres y son TemperatureHumidity enteros aleatorios que son menores de 100. Este archivo sigue una sintaxis de plantilla Liquid. La plantilla liquid es un lenguaje de plantillas popular que se usa en varios marcos de desarrollo web. Las plantillas Liquid permiten a los desarrolladores crear contenido dinámico que se pueda actualizar y modificar fácilmente. Permiten insertar variables, condiciones, bucles y otros elementos dinámicos en los mensajes del centro de eventos. La sintaxis es sencilla y hay un montón de recursos en línea disponibles para ayudarle a comenzar. Las plantillas liquid proporcionan una manera eficaz y flexible de crear mensajes dinámicos y personalizables.
Guarde y cierre el archivo.

Importante

No incluya ningún dato personal en el nombre del muestreador en el script de JMeter. Los nombres del sampler aparecen en el panel de resultados de pruebas de carga. Hay disponible un ejemplo de una plantilla líquida junto con el archivo de script JMeter para descargar en ejemplos de Azure.

Actualización del complemento personalizado de Event Hubs a IoT Hub

El complemento personalizado usa Event Hubs como recurso de destino principal. La siguiente configuración es la configuración del cliente del SDK para Event Hubs:

EventHubProducerClient producer = null;
EventHubClientBuilder producerBuilder = new EventHubClientBuilder();

producerBuilder.credential(getEventHubNamespace(), getEventHubName(), new DefaultAzureCredentialBuilder().build());
producer = producerBuilder.buildProducerClient();

EventDataBatch batch = producer.createBatch(new CreateBatchOptions());
batch.tryAdd(new EventData(msg));
producer.send(batch);

En el ejemplo siguiente se muestra cómo puede reutilizar la misma solución, agregar las dependencias de IoT y cambiar el cliente del SDK para usar IoT Hub:

IotHubServiceClientProtocol protocol = IotHubServiceClientProtocol.AMQPS;
ServiceClient client = new ServiceClient(getIoTHostName(), new DefaultAzureCredentialBuilder().build(), protocol);
client.open();

Message message = new Message(msg);
client.send(getDeviceName(), message);

client.close();

Ejecución de la prueba de carga mediante el nuevo complemento

Cuando Load Testing inicia la prueba de carga, primero implementa el script JMeter junto con todos los demás archivos en instancias del motor de prueba. Antes de ejecutar la prueba, vaya a la pestaña parámetro para definir y establecer los parámetros necesarios. Para más información, consulte Personalización de una prueba de carga con complementos de Apache JMeter y Pruebas de carga.

Configuración de pruebas de rendimiento para el entorno

Para las pruebas de rendimiento, es importante que el entorno de prueba sea similar al entorno de producción. En este ejemplo se usa el siguiente entorno para las pruebas de rendimiento para comprender mejor la capacidad y el rendimiento del sistema.

Servicio	Configuración
Event Hubs	Premium con una unidad de procesamiento
Funciones de Azure	Linux con plan Premium (EP1): 210 ACU, 3,5 GB de memoria y 1 vCPU equivalente Standard_D1_v2
Región	Este de EE. UU.

Elegir el nivel de servicio adecuado para cualquier servicio de Azure, incluidos Event Hubs y Azure Functions, es un proceso complejo y depende de muchos factores. Para más información, consulte Precios de Event Hubs y Precios de Functions.

Diseñar KPI para pruebas de rendimiento

Para poder diseñar KPI para pruebas de rendimiento, debe definir los requisitos empresariales y la arquitectura del sistema. Los requisitos empresariales le indican qué KPI, como el tiempo de respuesta, el rendimiento o la tasa de errores, que desea medir. La arquitectura del sistema le indica cómo probar el rendimiento de cada componente, como servidores web, bases de datos o API. También le ayuda a elegir la mejor estrategia de pruebas de rendimiento, como pruebas de carga, pruebas de esfuerzo o pruebas de resistencia.

Este ejemplo tiene los siguientes requisitos empresariales:

El sistema puede controlar 1000 solicitudes por segundo.
La confiabilidad del sistema es superior a 0,99.
El sistema puede controlar 1000 dispositivos simultáneos que informan de su información de datos personales.
Puede especificar la capacidad máxima del sistema en términos del número de dispositivos que puede admitir. Por ejemplo, el sistema puede admitir 1000 dispositivos simultáneos con tres veces la capacidad actual.

Para medir si el sistema cumple estos requisitos, puede usar los siguientes KPI para las pruebas de rendimiento:

KPI	Descripción
RPS	Solicitudes por segundo para un centro de eventos
CARGA	Número de cargas o solicitudes enviadas al centro de eventos durante las pruebas de rendimiento
IR	Número de invocaciones de función o tasa de ingesta
RT	Tiempo promedio de ejecución de Azure Functions
AMU	Uso medio de memoria para Azure Functions
SR	Tasa de éxito de todas las invocaciones de la aplicación de funciones
ARS	Promedio de tiempo de respuesta del servicio de bajada para servicios como SQL Server o un microservicio
Distrito Federal	Recuento de errores de dependencia, incluidos los errores internos de la aplicación de funciones
MRPS	Número máximo de RPS sin trabajo pendiente en el centro de eventos (capacidad del sistema)

Medición de KPI

Para medir los KPI, debe disponer de una estrategia de pruebas de rendimiento. La estrategia define el enfoque de pruebas de rendimiento para cada componente. En este ejemplo se usa la siguiente estrategia de pruebas de rendimiento.

Event Hubs: El enfoque de pruebas de rendimiento del centro de eventos es enviar muchos mensajes al centro de eventos y, a continuación, medir el RPS y LOAD. RPS es el número de mensajes que se envían al centro de eventos por segundo. LOAD es el número total de mensajes que se envían al centro de eventos durante las pruebas de rendimiento. Las pruebas de carga pueden medir RPS y LOAD.
Azure Functions: El enfoque de pruebas de rendimiento para Functions es medir las métricas siguientes.
- IR
- RT
- AMU
- SR
- ARS
- Distrito Federal

Azure Monitor puede medir AMU, ARS y DF, pero no IR, RT o SR. Para medir kpi mediante Azure Monitor, habilite Application Insights para Azure Functions. Para obtener más información, consulte Habilitación de la integración de Application Insights.

Después de habilitar Azure Monitor, puede usar las siguientes consultas para medir los KPI:

IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Ejemplo de panel de Azure Monitor

En la imagen siguiente se muestra un ejemplo del panel de Azure Monitor. Muestra los KPI de Azure Functions en función de las consultas anteriores.

Conclusión

En este artículo, ha aprendido a diseñar indicadores clave de rendimiento y a desarrollar un panel para Pruebas de Carga. También ha aprendido a usar complementos personalizados en JMeter para realizar pruebas de carga en Azure Functions integradas con Event Hubs. Puede usar el mismo método para realizar pruebas de carga en otros servicios de Azure. También puede configurar una canalización de CI/CD para los scripts de prueba de carga mediante Azure DevOps.

Para obtener más información, consulte Pruebas de carga.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

Mahdi Setayesh | Ingeniero principal de software
Oscar Fimbres | Ingeniero sénior de software

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.