Mide el rendimiento de ingesta y consultas de Telemetry

Un punto de referencia útil es una medición reproducible con condiciones reveladas, no una sola captura de pantalla rápida. Esta guía proporciona un arnés limitado del lado del cliente para las API públicas de registro y consulta y explica lo que demuestran y lo que no demuestran sus números.

Telemetry no publica una afirmación de rendimiento de este arnés hasta que se conserven juntos el script, el entorno, la forma del evento, el número de filas, el tiempo, el resultado y las limitaciones exactos.

Preguntas a responder antes de correr

Elija una pregunta:

• ¿Cuánto tiempo le toma a este cliente enviar un lote sintético conocido?
• ¿Con qué rapidez puede una consulta leer la ejecución recién enviada con los datos en tiempo real habilitados?
• ¿Cómo cambia el ancho de la carga útil el tiempo de ingesta observado por el cliente?
• ¿Cómo afectan la ventana de tiempo de consulta, las columnas seleccionadas y la cardinalidad de agrupación al tiempo de respuesta?

No mezcle todos estos en un solo número de "velocidad". La medición del reloj de pared de un cliente incluye distancia de red, TLS, programación local y serialización, además del tiempo de servicio.

Seguridad y alcance

El arnés incluido escribe filas sintéticas en telemetry_benchmark_events. Se niega a ejecutarse a menos que:

• TELEMETRY_API_KEY se establece en el momento de la ejecución;
• --confirm-write está presente;
• el recuento de filas solicitado está entre 1 y 10.000.

Utilice un equipo de pruebas dedicado o la clave API. El script no elimina filas. Aplique la política de retención normal de la tabla o elimine los datos de prueba más adelante mediante un proceso de gestión de datos aprobado.

La variable de entorno es opcional para el sitio web y la aplicación. Sólo se requiere cuando una persona ejecuta deliberadamente el script de referencia.

Ejecute el arnés limitado

De este repositorio:

TELEMETRY_API_KEY="YOUR_TEST_KEY" \
  node scripts/benchmark-telemetry-api.mjs \
  --confirm-write \
  --rows 500 \
  --batch-size 100

El resultado es un documento JSON que contiene:

• un run_id opaco;
• Horas de inicio y finalización UTC;
• filas solicitadas y tamaño de lote;
• bytes de carga útil total;
• tiempo de ingesta observado por el cliente;
• filas calculadas por segundo del reloj de pared del cliente;
• tiempo de consulta observado por el cliente;
• el resultado de la consulta para esa ejecución.

Redirija la salida a agent_space/ si desea comparar ejecuciones locales sin confirmar datos de diagnóstico:

node scripts/benchmark-telemetry-api.mjs \
  --confirm-write \
  --rows 500 \
  --batch-size 100 \
  > agent_space/benchmark-500.json

Lo que envía el guión

Cada fila usa una forma determinista:

{
  "run_id": "unique-per-run",
  "sequence": 42,
  "event_name": "benchmark_request_completed",
  "route": "/synthetic/orders",
  "region": "test-west",
  "status_code": 200,
  "latency_ms": 47,
  "payload_size_bytes": 768,
  "success": true
}

Los valores varían según la secuencia utilizando una fórmula determinista. Por lo tanto, la ejecución contiene filas exitosas y fallidas además de valores de latencia limitados, sin datos aleatorios similares a los del cliente.

La consulta de verificación es:

SELECT
  COUNT(*) AS rows_observed,
  SUM(CASE WHEN success THEN 1 ELSE 0 END) AS successful_rows,
  AVG(latency_ms) AS average_synthetic_latency_ms,
  MAX(sequence) AS maximum_sequence
FROM telemetry_benchmark_events
WHERE run_id = 'RUN_ID';

latency_ms es un campo de carga útil sintético. No representa la latencia del servicio Telemetry. Los tiempos de consulta e ingesta medidos por el arnés son campos separados.

Registro de reproducibilidad

Mantenga este contexto con cada resultado:

Para obtener resultados comparativos, alterne candidatos en lugar de realizar todas las pruebas para A y luego todas las pruebas para B. La carga externa puede variar con el tiempo.

Mejora el experimento sin ocultar fallos

Realice un pequeño calentamiento por separado y etiquételo. Luego recopile suficientes repeticiones para informar la mediana más un percentil alto o la distribución completa. Mantenga los tiempos de espera explícitos y cuéntelos como resultados en lugar de eliminarlos.

Cambie una variable a la vez:

1. fijar el número de filas y variar el tamaño del lote;
2. fijar el tamaño del lote y variar el ancho de la carga útil;
3. corregir las condiciones de ingesta y comparar consultas selectivas versus amplias;
4. corrija la consulta y compare un intervalo cálido versus inactivo.

Si se produce un límite de tarifa o una respuesta de muro de pago, registre el estado de HTTP y deténgase. No interprete el tiempo de reintento del cliente como rendimiento de ingesta sin procesar.

Qué puedes reclamar responsablemente

Una declaración defendible es limitada:

Desde un entorno de cliente designado a una hora UTC registrada, esta confirmación envió una cantidad revelada de filas sintéticas en lotes revelados. La distribución del tiempo medido en el muro del cliente se adjuntó a los artefactos de ejecución.

Esto no es una garantía de rendimiento universal, un límite de capacidad del lado del servidor ni una comparación con la competencia. Los resultados de la carga de trabajo de producción requieren esquemas representativos, simultaneidad, retención, patrones de consulta, regiones y un entorno de prueba coordinado.

Utilice Gestión del coste y el volumen de telemetría para medir el volumen de recopilación y Solución de problemas de ingesta de eventos cuando un punto de referencia exponga eventos rechazados o faltantes.