---
title: "k6 y observabilidad: métricas, tags y dashboards que aceleran el triage"
description: "Observabilidad en k6: métricas HTTP, tags, groups y alineación con APM—referencia Grafana k6 más correlation IDs para triage más rápido."
publishDate: "2026-10-22"
draft: false
keyword: "k6 observabilidad"
intent: "MOFU"
cta: "Usa Performate para convertir este playbook en escenarios k6 ejecutables, umbrales y reportes compartibles sin perder días en glue code."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "observabilidad"]
translationOf: k6-observability-metrics-tags
---

La prueba de carga terminó en verde, pero on-call igual tardó cuarenta minutos adivinando qué ruta regresó. La brecha suele ser alineación de observabilidad: k6 emitió `http_req_duration` agregado mientras los dashboards de Grafana parten por `service`, `route` y `tenant`—y nadie acordó el mismo vocabulario de tags antes de la corrida.

La observabilidad en k6 no trata de exportar más números. Trata de **etiquetar requests de forma consistente** para que métricas del cliente, umbrales y traces de APM cuenten una sola historia durante el triage. En esta guía verás qué métricas built-in importan, cómo diseñar tags de baja cardinalidad y cómo conectar la salida de k6 con dashboards que on-call ya usa.

## Por qué los tags cambian la velocidad de triage—no solo la estética del reporte

Bajo carga, los fallos se agrupan por familia de ruta, dependencia o feature flag—no por «la API se sintió lenta». Sin tags, un umbral único en `http_req_duration` oculta que checkout está bien mientras search dispara:

- **Métricas HTTP built-in**—`http_req_duration`, `http_req_failed`, `http_reqs`—agregan cada request sin tag ([referencia de métricas](https://k6.io/docs/using-k6/metrics/)).
- **Trends y Rates custom** capturan pasos de negocio—añadir al carrito, autorizar pago—pero solo ayudan si van taggeados por fase del journey.
- **Groups** (`group()`) estructuran flujos multipaso en summaries sin reemplazar tags a nivel request.
- **TSDBs downstream** castigan labels de alta cardinalidad—IDs de usuario, tokens de sesión aleatorios y tags por VU explotan almacenamiento y lentifican queries.

Piensa en los tags como la leyenda de un mapa. Un heatmap bonito sin etiquetas manda a los ingenieros a vagar.

### Cuando umbrales verdes igual pierden el incidente

Los checks prueban corrección; los umbrales prueban SLOs. Ninguno reemplaza **latencia segmentada** cuando una ruta arrastra el riesgo en cola. Combina métricas taggeadas con correlation IDs propagados ([tracing distribuido con k6](/es/blog/correlation-ids-tracing-distribuido-k6)) para que iteraciones de k6 aparezcan en el mismo backend de traces que producción.

Alinea claves de tag con [tipos de escenario](/es/blog/tipos-escenarios-k6-explicados) cuando distintos executors ejercitan mezclas de rutas distintas—si no, los filtros del dashboard mienten sobre qué forma de tráfico causó el pico.

## Implementación práctica con k6: tags, groups y umbrales segmentados

Define un **esquema de tags pequeño y estable** antes de escribir escenarios. Aplica las mismas claves en defaults de escenario, overrides por request y selectores de umbrales.

**Script de ejemplo (ilustrativo—no es una prueba lista para producción).** Rutas, tokens y números de SLO ficticios—adapta al naming de tu APM.

**Qué demuestra este ejemplo:**

- **Claves de tag consistentes:** `route`, `dependency` y `env` en cada request para que Grafana y summaries de k6 usen el mismo vocabulario.
- **Defaults a nivel escenario:** tags en el escenario se propagan a métricas salvo override por request.
- **Umbrales por ruta:** `http_req_duration{route:search}` vs `{route:checkout}` detecta regresiones localizadas.
- **Trend custom con tags:** Trend `checkout_duration` taggeado por `step` para análisis de embudo sin explotar cardinalidad.

```javascript
import http from 'k6/http';
import { check, group, sleep } from 'k6';
import { Trend } from 'k6/metrics';

const checkoutStep = new Trend('checkout_step_duration', true);

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const HEADERS = {
  'Content-Type': 'application/json',
  Authorization: `Bearer ${__ENV.TOKEN}`,
  'X-Correlation-Id': () => `k6-${__VU}-${__ITER}`,
};

export const options = {
  scenarios: {
    mixed_routes: {
      executor: 'constant-arrival-rate',
      rate: 20,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 15,
      maxVUs: 60,
      tags: { env: __ENV.ENV_NAME || 'staging', suite: 'observability-demo' },
      exec: 'mixedJourney',
    },
  },
  thresholds: {
    'http_req_duration{route:search}': ['p(95)<400', 'p(99)<700'],
    'http_req_duration{route:checkout}': ['p(95)<900', 'p(99)<1400'],
    'http_req_failed{route:checkout}': ['rate<0.005'],
    checkout_step_duration: ['p(95)<1200'],
  },
};

export function mixedJourney() {
  group('browse', () => {
    const res = http.get(`${BASE}/search?q=widget`, {
      headers: HEADERS,
      tags: { route: 'search', dependency: 'catalog' },
    });
    check(res, { 'search 2xx': (r) => r.status >= 200 && r.status < 300 });
    sleep(0.5);
  });

  group('checkout', () => {
    const start = Date.now();
    const res = http.post(`${BASE}/checkout`, JSON.stringify({ sku: 'SKU-1', qty: 1 }), {
      headers: HEADERS,
      tags: { route: 'checkout', dependency: 'payments' },
    });
    checkoutStep.add(Date.now() - start, { step: 'submit' });
    check(res, { 'checkout 2xx': (r) => r.status >= 200 && r.status < 300 });
    sleep(0.3);
  });
}
```

**Patrones que funcionan**

- **Enum fijo de tags:** documenta valores permitidos para `route`, `dependency`, `feature` en un README del equipo—nunca taggees URLs crudas con query strings.
- **Headers de correlación:** pasa `X-Correlation-Id` o headers de trace context para enlazar spans del servidor con iteraciones k6.
- **Export a Grafana:** usa `--out experimental-prometheus-rw` o salida Cloud cuando ops ya dashboarddea SLIs HTTP ([ideas de test desde observabilidad](/es/blog/observabilidad-a-ideas-pruebas-k6)).
- **Umbrales en métricas taggeadas:** frena releases en rutas que importan al producto, no en promedios globales.

**Anti-patrones a evitar**

- Taggear cada user ID o SKU—la cardinalidad mata TSDBs y el rendimiento del summary de k6.
- Claves de tag distintas por autor de script—`endpoint` vs `route` vs `path` rompe dashboards cross-team.
- Correr pruebas grandes sin compartir links de dashboard con on-call antes ([staging vs producción](/es/blog/staging-vs-produccion-pruebas-carga)).

**Tip pro (comando de ejemplo):** expone tendencias de percentiles por tag en el summary de terminal durante debug local.

```bash
k6 run observability-tags.js --summary-trend-stats="p(95),p(99)"
```

**Qué demuestra este comando:** k6 imprime tendencias de métricas taggeadas en el summary final para validar selectores de umbrales antes de empujar a CI.

## Marco de decisión: qué tags y métricas priorizar

| Situación | Acción recomendada |
|:---|:---|
| API monolito, pocas rutas | Tag por `route` + `method`; umbral por ruta crítica |
| Microservicios detrás de un gateway | Tag `route` en el edge; suma `dependency` al llamar downstream desde el script |
| SaaS multi-tenant | Tag `tenant_tier` (free/pro)—nunca tenant IDs crudos en labels |
| Rollout con feature flags | Tag `flag:on/off` alineado a [métricas canary](/es/blog/releases-canary-metricas-pruebas-carga) |
| Solo smoke en CI | Tags mínimos: `env`, `git_sha`, `route`; pospone Trends custom hasta estabilizar |

**Usa tags por ruta si** on-call filtra APM por path HTTP u operation name.

**Usa tags de dependencia si** tu script llama varios backends y un stall de terceros no debería pasar desapercibido.

**Usa tags env + git_sha si** comparas regresiones entre builds en [pruebas de carga en CI/CD](/es/blog/pruebas-de-carga-en-ci-cd).

## Observabilidad, documentación y siguientes pasos

Las pruebas taggeadas solo sirven si los dashboards existen antes del incidente:

- [ ] Publica un doc de vocabulario de tags—claves permitidas, valores y campos de alta cardinalidad prohibidos.
- [ ] Verifica que correlation IDs aparecen en APM en un smoke de 1 minuto antes de escalar tráfico.
- [ ] Crea filas en Grafana (o equivalente) filtradas por los mismos tags de los umbrales k6.
- [ ] Alerta por divergencia de `p(99){route:critical}` vs baseline, no solo `http_req_failed` global.
- [ ] Archiva metadata de corrida—set de tags, git SHA, JSON de escenario—para comparar regresiones.

## Cómo Performate simplifica flujos de observabilidad k6

Los scripts crudos derivan cuando cada autor inventa nombres de tag. Abajo hay un **ejemplo concreto de flujo** para el journey mixto search/checkout—adapta nombres de ruta a tu catálogo.

**Ejemplo: tags consistentes de import a reporte**

1. **Importa una colección Postman** con requests de search y checkout en carpetas separadas. *Problema resuelto:* nombres de operación se convierten en candidatos estables de tag en lugar de strings escritos a mano en cada script.
2. **Define tags de escenario en el editor visual:** `env:staging`, `suite:checkout-regression` en el escenario; `route:search` y `route:checkout` en requests individuales. *Problema resuelto:* vocabulario de tags coincide con lo que exportas a k6—sin drift al editar.
3. **Define umbrales por ruta** en el panel de umbrales—p. ej. search `p(95)<400`, checkout `p(95)<900`. *Problema resuelto:* gates de SLO localizados sin leer docs de sintaxis de umbrales por cada ruta.
4. **Corre el escenario y abre el reporte integrado** filtrado por `route`. *Problema resuelto:* QA y SRE revisan el mismo gráfico de latencia segmentada, no tres CSV exportados.
5. **Exporta el script k6 generado** con tags y umbrales embebidos para smoke gates en CI. *Problema resuelto:* iteración local y pipeline comparten un esquema de tags.
6. **Comparte el link del reporte** con on-call antes de una corrida programada grande. *Problema resuelto:* nadie descubre un pico de saturación nuevo sin contexto.

Ese flujo conecta con el `cta` de este post: escenarios ejecutables, umbrales y reportes compartibles sin días de glue code.

## Cierre

La observabilidad en pruebas de carga es primero un **problema de vocabulario**. Acuerda tags de baja cardinalidad, parte umbrales por ruta y propaga correlation IDs para que resultados de k6 caigan en los mismos dashboards que producción.

Corre un smoke taggeado de cinco minutos contra staging esta semana—y confirma que on-call puede filtrar las mismas etiquetas `route` en APM antes de tu próxima prueba a escala completa.

[Try Performate free](https://performate.app) | [Book a demo](/demo) | [k6 tags best practices](https://k6.io/docs/using-k6/tags-and-groups/)