AWS Builder Center

Builder Center

CloudWatch Query Studio con PromQL: una consulta, una alarma, un tablero

Quien viene de operar Prometheus llega a Amazon CloudWatch con un reflejo ya formado: escribir PromQL para preguntarle a las métricas qué está pasando. Hasta hace poco ese reflejo no tenía dónde aterrizar dentro de la consola de CloudWatch. Con Amazon CloudWatch Query Studio, disponible de forma general desde el 15 de junio de 2026, ese lenguaje ya es ciudadano de primera clase, y con él llega una forma limpia de recorrer el hilo de esta serie de principio a fin en una sola pantalla.

vtjean

Lo llamativo de Query Studio para esta serie es que deja recorrer el camino de siempre sin salir de una sola pantalla. Ese camino no ha cambiado desde la primera entrega: nombrar con precisión la métrica que importa, ponerle un umbral que sirva de objetivo y tener a mano el paso operativo que sigue cuando el umbral se cruza. Con Query Studio, la consulta elige la métrica, la alarma fija el objetivo y el widget en el tablero mantiene el runbook a la vista. Este artículo explica qué es Query Studio, cómo escribir la consulta que importa, cómo pasar de consulta a alarma y a tablero, y dónde están los límites. Cierra con limitaciones, recursos y tags.

Qué es Query Studio

Query Studio es un entorno de consulta interactivo dentro de la consola de Amazon CloudWatch donde puedes escribir, ejecutar y visualizar consultas contra tus métricas. Se abre desde la consola de Metrics o desde el modo de edición de un dashboard. Soporta dos lenguajes: PromQL y Metrics Insights, el dialecto SQL de CloudWatch. Consulta tanto las métricas ingeridas vía OpenTelemetry Line Protocol (OTLP) como las métricas vended de AWS, es decir, las que los servicios de AWS emiten por defecto.
Lo que lo hace útil para un equipo que opera en varias cuentas y regiones es que trae selectores de cuenta y de región por consulta. Eso permite correlacionar latencia y tasa de error de toda una flota desde un solo espacio de trabajo, sin brincar entre consolas. Se construye la consulta de dos maneras: el modo Builder, que ofrece una experiencia guiada para explorar nombres de métricas, etiquetas y funciones de agregación, y el modo Editor, para quien prefiere escribir la sintaxis directamente. Se puede alternar entre ambos.
Para visualizar hay varios tipos de gráfico: línea, barra, dispersión, mapa de calor, histograma, pastel, indicador y widgets numéricos, con opción de doble eje y ajustes por serie. Además, Query Studio se integra con los tableros de CloudWatch, admite importaciones desde Grafana y ofrece atajos de teclado para ejecutar consultas.
Un apunte de contexto sobre madurez: Query Studio pasó por versión preliminar el 3 de abril de 2026 y alcanzó disponibilidad general el 15 de junio de 2026. No hay una fecha límite de migración pendiente; la versión general es la que se usa hoy.

PromQL, para quien nunca lo ha tocado

PromQL (Prometheus Query Language) es un lenguaje funcional de consulta que permite seleccionar, agregar y transformar series temporales en tiempo real. Nació en Prometheus y se volvió un estándar de facto para métricas, así que buena parte de la comunidad de SRE ya lo lee con fluidez. CloudWatch lo soporta para consultar métricas ingeridas vía OTLP y las métricas vended enriquecidas de AWS. CloudWatch usa PromQL basado en la especificación de Prometheus 3.0, lo que incluye nombres de métrica y de etiqueta en UTF-8.
La forma más básica de una consulta selecciona una métrica por nombre. En el editor de Query Studio se escribe con el nombre de la métrica entre llaves y comillas:
1
{"http.server.active_requests"}
Para acotar a un servicio concreto se agrega un filtro de etiqueta. Esto devuelve un vector instantáneo, es decir, una muestra por serie con la misma marca de tiempo:
1
{"http.server.active_requests", "@resource.service.name"="myservice"}
Los filtros de etiqueta admiten coincidencia exacta con el signo igual, negación con signo de admiración y igual, coincidencia por expresión regular con igual y virgulilla, y negación de expresión regular con admiración y virgulilla. En las métricas ingeridas por OTLP, las etiquetas se derivan de los atributos de recurso, el alcance de instrumentación, los atributos de punto de dato y los metadatos propios de AWS.
Para ver el comportamiento en el tiempo se agrega un selector de duración entre corchetes, lo que crea un vector de rango. Combinado con una función sobre rango se obtiene, por ejemplo, el promedio de los últimos cinco minutos:
1
avg_over_time({"http.server.active_requests", "@resource.service.name"="myservice"}[5m])
Y para colapsar varias series en una sola cifra por servicio se usan operadores de agregación como sum, avg, min, max, count o topk:
1
sum by (service) ({"http.server.request.errors"})
Los nombres de métrica de estos ejemplos son ilustrativos; los de tu entorno dependen de cómo instrumentaste la aplicación. La gracia para esta serie es que PromQL obliga a nombrar con precisión la señal que importa, en lugar de conformarse con un promedio genérico. Elegir la métrica correcta y su agregación correcta es, literalmente, el primer paso del hilo.

La señal correcta: de la métrica cruda a la pregunta operativa

El error más común al monitorear es graficar lo que es fácil de graficar. Query Studio con PromQL invita a lo contrario: escribir la consulta que responde una pregunta operativa. En vez de mirar el uso de CPU porque está a la mano, se consulta la tasa de peticiones activas, la latencia por percentil o la razón de errores del servicio que de verdad afecta al usuario.
El modo Builder ayuda aquí. Al explorar nombres de métricas, etiquetas y funciones de agregación de forma guiada, reduce el riesgo de agregar mal, por ejemplo promediar percentiles, que es una de las trampas clásicas que esta serie ya ha señalado. Cuando la consulta expresa la señal correcta, el resto del ciclo se vuelve mecánico.

Fijar el objetivo: de la consulta a la alarma

Una consulta que nadie vigila es un gráfico bonito, no un objetivo. Query Studio permite crear una alarma de CloudWatch directamente desde una consulta PromQL, con una condición importante: la consulta debe devolver una sola serie temporal. Esto es coherente con la disciplina de SLO de la serie. Una alarma vigila una señal, no diez a la vez.
El flujo es directo. Tras ejecutar una consulta PromQL que devuelve una única serie, se elige Create alarm desde el menú de acciones y se configuran el umbral, los periodos de evaluación y las acciones de notificación. Una consulta que colapsa a una sola serie sirve para esto; por ejemplo, la tasa de error agregada de un servicio:
1
sum({"http.server.request.errors", "@resource.service.name"="checkout"})
El umbral es donde se materializa el objetivo: por ejemplo, esa cifra no debe superar cierto valor durante N periodos consecutivos. Definir ese umbral es fijar el presupuesto, y hacerlo sobre una serie única evita el ruido de alarmas que se disparan por señales mezcladas.

El runbook vivo: llevar la consulta al tablero

El tercer paso del hilo es tener un runbook, y aquí el runbook se vuelve un artefacto vivo. Cualquier visualización de Query Studio se puede agregar a un tablero de CloudWatch. Tras ejecutar la consulta y ver el resultado, se elige Add to dashboard para guardar la visualización como widget. Ese widget sigue ejecutando la consulta PromQL al intervalo de refresco del tablero, así que el tablero se mantiene al día sin intervención.
El valor operativo es que el tablero deja de ser una foto estática y pasa a ser la vista que el equipo de guardia consulta primero. Si la consulta expresa la señal correcta y la alarma fija el objetivo, el widget en el tablero es el lugar donde se confirma el estado y se arranca el runbook. La correlación entre cuentas y regiones que ofrece Query Studio hace que ese tablero sirva para una flota completa, no para una sola cuenta.
Un flujo repetible para cada señal nueva queda así:
  1. Escribir la consulta en modo Builder para elegir la métrica y su agregación correctas. Validar en modo Editor que la sintaxis dice lo que se quiere decir.
  2. Ejecutar y confirmar que la serie devuelta es la que corresponde a la pregunta operativa. Ajustar el rango de tiempo para ver el comportamiento normal antes de fijar umbrales.
  3. Si la consulta devuelve una sola serie, crear la alarma con umbral y periodos de evaluación que reflejen el objetivo acordado.
  4. Agregar la visualización al tablero del equipo para que quede como widget con refresco automático.
  5. Documentar junto al tablero qué acción sigue cuando la alarma se dispara, de modo que la señal, el objetivo y el runbook vivan en el mismo lugar.

Limitaciones

  • La creación de alarma desde Query Studio exige que la consulta devuelva una sola serie temporal. Para vigilar varias series hay que separar consultas o usar otro mecanismo, lo cual es sano para el diseño de alarmas pero conviene tenerlo presente.
  • PromQL en CloudWatch aplica a métricas ingeridas vía OTLP y a métricas vended enriquecidas de AWS. No es un reemplazo universal de todo lo que se consultaba antes; conviene confirmar que la métrica de interés está disponible por esa vía.
  • La disponibilidad regional tiene excepciones. En el momento del anuncio de disponibilidad general, Query Studio estaba en todas las regiones comerciales salvo Medio Oriente (Emiratos Árabes Unidos), Medio Oriente (Baréin) e Israel (Tel Aviv). Conviene verificar la tabla de regiones para el caso propio.
  • Query Studio explora y visualiza métricas. Para logs y trazas se siguen usando las experiencias correspondientes de CloudWatch, así que no sustituye por completo el resto del flujo de observabilidad.
  • El widget en el tablero ejecuta la consulta al intervalo de refresco del tablero. Un intervalo muy agresivo sobre muchas consultas tiene implicaciones que conviene considerar al diseñar el tablero.

Conclusion

Query Studio no cambia la disciplina, la hace fluida. La misma idea de siempre, elegir la señal correcta, fijar el objetivo, tener el runbook, cabe ahora en una sola pantalla: una consulta PromQL que nombra la señal, una alarma que fija el objetivo sobre una serie única, y un widget en un tablero que mantiene el runbook a la vista. Para quien ya piensa en PromQL, el reflejo por fin tiene dónde aterrizar dentro de CloudWatch.

Recursos

# amazon-cloudwatch# sre# monitoring# monitoring-observability# open-telemetry
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article