Esta sección cubre el aspecto importante de la gestión de métricas en k6. Cómo y qué tipo de métricas recopila k6 automáticamente (built-in metrics) y qué métricas personalizadas puede hacer que k6 recopile.
Métricas integradas
Las métricas built-in son las que puede ver la salida a stdout cuando ejecuta la prueba k6 más simple posible:
Todas las http_req_... que están después de ellas son métricas built-in que se escriben en stdout al final de una prueba.
Las siguientes métricas built-in serán siempre recopiladas por k6:
Nombre de métrica | Tipo | Descripción |
---|---|---|
vus | Gauge | Número actual de usuarios virtuales activos |
vus_max | Gauge | Número máximo posible de usuarios virtuales (los recursos de VU están preasignados para garantizar que el rendimiento no se vea afectado al escalar el nivel de carga) |
iterations | Counter | El número total de veces que las VU de la prueba han ejecutado el script JS (la función "default"). |
iteration_duration | Trend | El tiempo que tardó en completar una iteración completa de la función predeterminada / principal. |
dropped_iterations | Counter | Introducido en k6 v0.27.0, el número de iteraciones que no se pudieron iniciar debido a la falta de VU (para los ejecutores de tasa de llegada) o falta de tiempo (debido a maxDuration expirado en los ejecutores basados en iteraciones). |
data_received | Counter | La cantidad de datos recibidos. Lea este ejemplo para rastrear los datos de una URL individual. |
data_sent | Counter | La cantidad de datos enviados. Lea este ejemplo para rastrear los datos de una URL individual. |
checks | Rate | La tasa de controles exitosos. |
Métricas integradas específicas de HTTP
Las métricas built-in solo se generarán cuando / si se realizan solicitudes HTTP:
Nombre de métrica | Tipo | Descripción |
---|---|---|
http_reqs | Counter | Cuántas solicitudes HTTP ha generado k6, en total. |
http_req_blocked | Trend | Tiempo pasado bloqueado (esperando una ranura de conexión TCP libre) antes de iniciar la solicitud. float |
http_req_connecting | Trend | Tiempo empleado en establecer una conexión TCP con el host remoto. float |
http_req_tls_handshaking | Trend | Tiempo dedicado a la sesión de protocolo de enlace TLS con el host remoto |
http_req_sending | Trend | Tiempo empleado en enviar datos al host remoto. float |
http_req_waiting | Trend | Tiempo dedicado a la espera de respuesta del host remoto (a.k.a. “time to first byte”, o “TTFB”). float |
http_req_receiving | Trend | Tiempo empleado en recibir datos de respuesta del host remoto. float |
http_req_duration | Trend | Tiempo total de la solicitud. Es igual a http_req_sending + http_req_waiting + http_req_receiving (es decir, cuánto tiempo tardó el servidor remoto en procesar la solicitud y responder, sin el DNS inicial lookup/connection times). float |
http_req_failed (≥ v0.31) | Rate | La tasa de solicitudes fallidas según setResponseCallback. |
Accediendo a los tiempos HTTP desde un script
Si desea acceder a la información de tiempo de una solicitud HTTP individual en el k6, el objeto Response.timings proporciona el tiempo dedicado a las diversas fases en ms:
- blocked: equals to http_req_blocked.
- connecting: equals to http_req_connecting.
- tls_handshaking: equals to http_req_tls_handshaking.
- sending: equals to http_req_sending.
- waiting: equals to http_req_waiting.
- receiving: equals to http_req_receiving.
- duration: equals to http_req_duration.
A continuación se muestra la salida esperada (parcial):
Métricas personalizadas
También puede crear sus propias métricas, que se informan al final de una prueba de carga, al igual que los tiempos HTTP:
El código anterior creará una métrica de tendencia denominada "tiempo_de_espera" y se hará referencia en el código mediante el nombre de variable myTrend.
Las métricas personalizadas se informarán al final de una prueba. Así es como se vería la salida:
Tipos de métricas
Todas las métricas (tanto las incorporadas como las personalizadas) tienen un tipo. Los cuatro tipos de métricas diferentes en k6 son:
Nombre de métrica | Descripción |
---|---|
Counter | Métrica que suma valores agregados de manera acumulativa. |
Gauge | Métrica que almacena los valores mínimo, máximo y último que se le agregan. |
Rate | Métrica que rastrea el porcentaje de valores agregados que no son cero. |
Trend | Métrica que calcula estadísticas sobre los valores agregados (mínimo, máximo, promedio y percentiles). |
Opcionalmente, todos los valores agregados a una métrica personalizada pueden ser tagged, lo que puede ser útil al analizar los resultados de la prueba.
Contador (métrica acumulativa)
El código anterior generará la siguiente salida:
El valor de my_counter será 3 (si lo ejecuta una sola iteración, es decir, sin especificar --iterations o --duration).
Tenga en cuenta que actualmente no hay forma de acceder al valor de ninguna métrica personalizada desde JavaScript. Tenga en cuenta también que los contadores que tienen valor cero (0) al final de una prueba son un caso especial: NO se imprimirán en el resumen de salida estándar.
Gauge (mantener solo el último valor)
El código anterior generará la siguiente salida:
El valor de my_gauge será 2 al final de la prueba. Al igual que con la métrica Contador anterior, un indicador con valor cero (0) NO se imprimirá en el resumen de salida estándar al final de la prueba.
Trend (recopilar estadísticas de tendencias (mínimo / máximo / promedio / percentiles) para una serie de valores)
El código anterior hará que k6 imprima una salida como esta:
Una métrica de tendencia es un contenedor que contiene un conjunto de valores de muestra y al que podemos pedir que genere estadísticas (mínimo, máximo, promedio, mediana o percentiles) sobre esas muestras. De forma predeterminada, k6 imprimirá promedio, mínimo, máximo, mediano, percentil 90 y percentil 95.
Rate (realiza un seguimiento del porcentaje de valores en una serie que no son cero)
El código anterior hará que k6 imprima una salida como esta:
El valor de "my_rate" al final de la prueba será del 50%, lo que indica que la mitad de los valores agregados a la métrica eran distintos de cero.
Notas
- las métricas personalizadas solo se recopilan de los subprocesos de VU al final de una iteración de VU, lo que significa que en el caso de los scripts de ejecución prolongada, es posible que no vea ninguna métrica personalizada hasta un tiempo después de la prueba.