Una aplicación que se ejecuta en un grupo de Auto Scaling procesa elementos de una cola SQS con workers de larga ejecución. El equipo necesita ser alertado cuando la cola crece más allá del tamaño esperado. Los logs de la aplicación se envían a una herramienta de terceros y el equipo ya utiliza un tema de SNS para las alertas. ¿Qué enfoque de monitoreo es el más eficiente operativamente?

La opción correcta es crear una alarma de CloudWatch utilizando la métrica ApproximateNumberOfMessagesVisible. Esta métrica representa el número de mensajes disponibles para ser procesados en la cola SQS, lo que indica directamente la carga de trabajo pendiente. Si esta métrica excede un umbral, significa que los workers no están procesando los mensajes lo suficientemente rápido o que la tasa de ingesta es demasiado alta, y se necesita una alerta. CloudWatch puede monitorear directamente esta métrica de SQS, lo que la convierte en la solución más eficiente operativamente, ya que no requiere recursos adicionales como funciones Lambda para recopilar la métrica. Las opciones incorrectas son: ApproximateNumberOfMessagesDelayed mide los mensajes que no están disponibles para el consumo porque están retrasados, lo cual no refleja la carga de trabajo activa que los workers deben procesar. Usar una función Lambda para publicar una métrica personalizada o para enviar directamente una notificación a SNS introduce una complejidad operativa innecesaria, ya que CloudWatch puede monitorear directamente las métricas de SQS.