AWS Builder Center

Builder Center

CloudWatch Transaction Search: del span al SLI sin muestrear a ciegas

En una arquitectura distribuida, la pregunta difícil no es "está caído el servicio", sino "por qué esta transacción concreta de este cliente concreto tardó ocho segundos cuando el promedio es medio segundo". Esa respuesta vive en los spans, las unidades básicas de una traza, y se pierde en el momento en que se muestrea de forma agresiva y el span que importaba nunca se guardó. Amazon CloudWatch Transaction Search ataca justo ese problema.

vtjean

Si has seguido las entregas anteriores, ya conoces el hilo conductor: primero se identifica la señal que de verdad refleja lo que vive el usuario, después se le pone un objetivo medible y, por último, se documenta qué hacer cuando ese objetivo se rompe. Transaction Search entra justo por el principio de ese hilo, porque entrega la materia prima más fina que existe, el span crudo capturado al cien por ciento, sobre la cual se puede construir un indicador de nivel de servicio (SLI) fiel a la experiencia real. Este artículo explica qué es un span, cómo Transaction Search los captura sin dejar huecos, cómo pasar del span al SLI y qué límites tiene. Cierra con limitaciones, recursos y tags.

Qué es un span y por qué importa

Un span es la unidad fundamental de operación dentro de una traza distribuida. Representa una acción o tarea específica en una aplicación o sistema y registra detalles de ese segmento de la transacción: hora de inicio y de fin, duración y metadatos asociados, que pueden incluir atributos de negocio como el identificador de cliente o el número de pedido. Los spans se ordenan en una jerarquía padre-hijo, y esa jerarquía forma la traza completa, que mapea el flujo de la transacción a través de los distintos componentes o servicios.
La consecuencia práctica es que el span es la señal más fina que existe para responder preguntas de rendimiento y de impacto en el usuario. Un promedio de latencia esconde el caso del percentil 99; el span de esa transacción específica lo revela.

Capturar sin huecos: muestreo de cabecera al cien por ciento

El valor central de Transaction Search es que ingiere el cien por ciento de los spans como logs estructurados en Amazon CloudWatch. Esto evita trazas rotas y permite ver trazas grandes, de hasta 10.000 spans, con detalle completo. La técnica que lo hace posible sin disparar el costo es separar dos tasas.
La primera es el muestreo de cabecera (head sampling), que captura las peticiones al inicio de la traza según una tasa o condición fija. Cuando esa tasa se fija en cien por ciento, se captura el inicio de cada traza sin saltos, lo que garantiza visibilidad completa de todas las peticiones entrantes. Si se usa AWS X-Ray o los SDK de AWS Distro for OpenTelemetry (ADOT), la tasa fija se configura en las reglas de muestreo. Si se usa el SDK de OpenTelemetry directamente, se establece la configuración de muestreo en always_on.
La segunda es la tasa de indexación de spans como resúmenes de traza (trace summaries), que se indexan en AWS X-Ray y habilitan la búsqueda y las analíticas de traza de extremo a extremo. Solo hace falta indexar un porcentaje pequeño de spans como resúmenes. Esta separación es la clave del diseño costo-efectivo: se capturan todos los spans como logs para no perder detalle, y se indexa solo una fracción como resúmenes para la búsqueda de trazas.
Los spans enviados a X-Ray quedan en un grupo de logs llamado aws/spans. Como viven ahí, se pueden usar las capacidades de CloudWatch Logs sobre ellos: filtros de métrica para extraer métricas personalizadas, filtros de suscripción para reenviar datos y enmascaramiento de datos para proteger información de identificación personal. Las trazas de X-Ray se convierten al formato de convención semántica, con identificadores de traza W3C, antes de almacenarse.

Buscar el span que importa

Transaction Search ofrece un editor visual para buscar y analizar todos los spans ingeridos por atributos. Esa es la diferencia con mirar métricas agregadas: se puede filtrar por un atributo de negocio, como el nombre del cliente o el número de pedido, y encontrar la transacción exacta en el contexto del problema. Se pueden correlacionar transacciones con eventos de negocio, como un pago fallido, y bajar hasta las interacciones entre componentes para establecer la causa raíz.
Además del editor visual, los spans se pueden analizar con consultas escritas, porque viven como logs estructurados. Ese análisis se hace en Log Analytics, la experiencia de consola unificada de Amazon CloudWatch Logs que reúne en un solo lugar la consulta con el lenguaje de CloudWatch Logs Insights, la transmisión en tiempo real con Live Tail y la identificación de principales contribuidores con CloudWatch Contributor Insights. Conviene tener clara la distinción: Log Analytics es la superficie donde trabajas, y CloudWatch Logs Insights es el lenguaje con el que escribes la consulta. Por ejemplo, para ver las cinco consultas de base de datos más lentas por percentil 99 de duración:
1
2
3
4
STATS pct(durationNano, 99) as p99 by attributes.db.statement
| SORT p99 ASC
| LIMIT 5
| DISPLAY p99, attributes.db.statement
O para identificar los cinco servicios que más errores del lado del servidor están arrojando, filtrando por código de estado HTTP mayor o igual a 500:
1
2
3
4
5
FILTER attributes.http.response.status_code >= 500
| STATS count(*) as conteo by attributes.aws.local.service as service
| SORT conteo ASC
| LIMIT 5
| DISPLAY conteo, service
Cuando se habilita Application Signals para todos los spans enviados a CloudWatch, se accede además a tableros de aplicación, métricas y topología, es decir, una vista centrada en la aplicación que ayuda a monitorear y triar el estado de salud. Ese puente entre el span crudo y la vista de APM es lo que conecta este tema con el terreno de SLI de la serie.

Del span al SLI: fijar el objetivo

Capturar todo no sirve de nada si no se traduce en un objetivo medible. Aquí es donde el span se vuelve SLI. Como los spans viven en el grupo de logs aws/spans, se pueden usar filtros de métrica de CloudWatch Logs para extraer una métrica personalizada a partir de los atributos del span: por ejemplo, contar transacciones cuya duración supera un umbral, o aislar las que terminan en error para una operación crítica.
Con esa métrica personalizada ya se puede fijar un objetivo con la misma disciplina de SLO que la serie aplica en otras entregas. Se define el indicador, por ejemplo la proporción de transacciones de una operación clave que se completan por debajo de cierta latencia, y se le fija un objetivo. La ventaja de partir de spans capturados al cien por ciento es que el SLI no queda sesgado por un muestreo que descartó justo los casos malos.
Un flujo repetible queda así:
  1. Habilitar Transaction Search y fijar el muestreo de cabecera en cien por ciento para capturar todos los spans. Recordar que, tras habilitarlo, los spans pueden tardar unos minutos en estar disponibles.
  2. Ajustar la tasa de indexación de resúmenes de traza a un porcentaje pequeño, suficiente para la búsqueda de extremo a extremo sin costo innecesario.
  3. Identificar la operación crítica y el atributo de span que define éxito o fracaso desde la óptica del usuario.
  4. Extraer una métrica personalizada con un filtro de métrica sobre el grupo de logs aws/spans que capture ese criterio.
  5. Definir el SLI y su objetivo sobre esa métrica, y documentar la acción de runbook cuando el objetivo se incumple.

Limitaciones

  • La captura al cien por ciento se logra con el muestreo de cabecera en cien por ciento, no por defecto. Si las reglas de muestreo de X-Ray o la configuración del SDK no están en cien por ciento, se vuelve a perder detalle sin que nadie lo note.
  • Capturar todos los spans como logs estructurados tiene implicaciones de volumen y de costo. El diseño costo-efectivo depende de separar bien la captura completa de logs de la indexación parcial de resúmenes de traza; conviene revisar la página de precios de Amazon CloudWatch antes de habilitarlo a gran escala.
  • La visualización de una traza admite hasta 10.000 spans. Transacciones extremadamente grandes podrían acercarse a ese límite.
  • Tras habilitar Transaction Search, los spans pueden tardar alrededor de diez minutos en estar disponibles para búsqueda y análisis. No es una herramienta de respuesta instantánea en el primer arranque.
  • El acceso a tableros de aplicación, métricas y topología requiere habilitar Application Signals para todos los spans enviados a CloudWatch. Sin ese paso, se tiene la búsqueda de spans pero no la vista de APM completa.

Cierre

Transaction Search resuelve el viejo dilema del muestreo: no hay que elegir entre pagar por guardarlo todo a ciegas o ahorrar y perder justo el span que explicaba el incidente. Se capturan todos los spans como logs y se indexa solo una fracción como resúmenes. Con esa base, el paso al SLI es directo: un filtro de métrica sobre el grupo aws/spans convierte el atributo de negocio en una señal, y la señal en un objetivo. Del span crudo al indicador que refleja la experiencia real del usuario, sin muestrear a ciegas.

Recursos

# amazon-cloudwatch# spanish# monitoring-observability# observability# sre
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