7 Métricas para Monitorizar AWS Lambda

Si yo tuviera que vigilar una función Lambda con lo mínimo, miraría 7 datos: invocaciones, duración, throttles, errores, arranques en frío, memoria y trazas. Con eso puedo controlar coste, latencia, fallos y límites sin perder tiempo en paneles de más.

En corto: si suben las invocaciones, reviso si también sube la duración. Si aparecen Throttles, tengo un problema de capacidad. Si crecen los Errors, miro la tasa de error y no solo el número bruto. Y si hay lentitud sin más carga, reviso Init Duration y MaxMemoryUsed.

Esto es lo que me llevo del artículo:

• Invocaciones: me dicen si el tráfico cambia.

• Duración: miro media, p95 y p99 para ver latencia de verdad.

• Throttles: si no están en 0, algo limita la concurrencia.

• Errores: importa más el % de error que el total.

• Cold starts / Init Duration: ayudan a separar lentitud por arranque.

• Memoria / MaxMemoryUsed: sirven para ajustar coste y evitar timeouts.

• X-Ray: me enseña si el tiempo se va en mi código o fuera.

Idea central: no hace falta medir todo. Yo cruzaría volumen + latencia + errores y dejaría memoria y trazas para encontrar la causa del problema.

Mi lectura rápida sería esta: primero salud, luego rendimiento y después causa raíz. Ese orden evita alarmas por ruido y ayuda a decidir antes qué tocar en producción.

Observabilidad y monitorización de aplicaciones con AWS Lambda | AWS Lambda Fundamentals

Por qué estas 7 métricas importan a los equipos en fase inicial

Estas 7 métricas contestan a cuatro preguntas operativas muy claras: tráfico, rendimiento, fallos y uso de recursos.

No todas las métricas pesan igual. Los errores y las limitaciones de ejecución son críticos y piden acción inmediata. Si aparecen, no conviene esperar.

La duración y las invocaciones funcionan más como señales de tendencia. No siempre apuntan a un problema urgente, pero sí ayudan a ver si algo está cambiando poco a poco. Y ahí es donde muchos equipos se la juegan: no por un gran fallo de golpe, sino por pequeños desvíos que pasan desapercibidos.

El uso de memoria suele importar más cuando el equipo ya ha ganado cierta estabilidad y quiere ajustar costes sin pasarse de recursos. Dicho de otro modo: primero haces que funcione bien; después afinas.

Por eso merece la pena leer estas señales en un solo panel. Verlo todo junto permite detectar cambios rápido y unir puntos que, por separado, dicen bastante menos.

A partir de aquí, cada métrica responde a una decisión concreta.

1. Invocaciones

La primera señal que conviene mirar es el volumen bruto. Esta métrica indica cuántas veces se ejecuta tu función en un periodo concreto. En una startup, las invocaciones te dejan ver si el uso está creciendo, si se mantiene estable o si se está yendo de lo previsto.

Lo más útil es medir las invocaciones por minuto o por hora. Así detectas picos, caídas y cambios de patrón sin dar palos de ciego. Un pico sostenido puede acabar saturando dependencias compartidas, como bases de datos o colas. Si tu Lambda se conecta a una base de datos, conviene limitar y reutilizar las conexiones.

Actúa cuando el volumen crezca de forma sostenida o cuando empiece a meter presión sobre dependencias compartidas. Y si el volumen cambia y, además, cada ejecución tarda más, el siguiente dato que toca mirar es la duración.

2. Duración

Cuando suben las invocaciones, la duración te enseña si la función mantiene el ritmo o empieza a ir más lenta. Esta métrica mide cuánto tarda en ejecutarse tu función.

No te quedes solo con la media. p95 y p99 suelen contar la historia de verdad, porque dejan ver picos de latencia que el promedio tapa con facilidad.

Si la duración empeora, mira primero qué parte del recorrido está metiendo ese retraso. Si el aumento se mantiene en el tiempo, o aparece al mismo tiempo que sube el volumen de invocaciones, conviene revisarlo cuanto antes.

Las causas más comunes suelen ser estas:

• Código de la propia función

• Llamadas a servicios externos

• Cold starts

• Cargas útiles demasiado grandes

X-Ray te ayuda a separar la lógica interna de las dependencias externas para encontrar el cuello de botella. Si p95 o p99 se desvían, investígalo antes de que empiece a notarse en los usuarios. Si el tiempo sigue subiendo, toca pasar a revisar capacidad y fallos.

3. Throttles

Los throttles aparecen cuando Lambda rechaza invocaciones porque la función ha llegado al límite de concurrencia que tiene asignado. Si la causa es la capacidad, el siguiente paso es medir cuánto afecta eso al rendimiento y a los fallos.

En CloudWatch, la métrica Throttles indica cuántas invocaciones se han rechazado. Debería estar en cero.

Conviene actuar cuando los throttles se repiten o suben a medida que crece el tráfico. En ese caso:

• revisa la concurrencia reservada

• ajusta las alertas

• valida el límite con pruebas de estrés

Si además aparecen errores, pasa a la siguiente sección.

4. Errores

Si no hay un límite de capacidad, el paso siguiente es medir los fallos.

La métrica Errors de CloudWatch cuenta las invocaciones fallidas por excepción, timeout o error no controlado. Te ayuda a separar si el problema está en la función o en una dependencia externa. Si esta métrica sube, tómatelo en serio e investígalo cuanto antes.

No mires solo el dato suelto. Fíjate en el volumen total y en cómo cambia con el tiempo. Un pico aislado suele ser algo puntual. En cambio, una subida sostenida ya huele a problema de verdad. Con AWS X-Ray puedes localizar el punto de fallo y comprobar si afecta a la función, a un trigger o a una versión concreta.

Si los errores se concentran en una versión, un alias o un trigger, revisa el despliegue o la configuración de esa parte. A veces el fallo no está en toda la función, sino en una pieza muy concreta.

Actúa cuando los errores se repiten, crecen o aparecen en una función que antes iba bien. Si el código falla y, además, la latencia también sube, revisa los arranques en frío.

5. Arranques en frío e Init Duration

Si la función falla solo a ratos o se vuelve más lenta sin que suba el tráfico, lo primero es mirar los arranques en frío.

Un arranque en frío pasa cuando Lambda crea un nuevo entorno de ejecución. Init Duration mide cuánto tarda esa fase de inicio. Revísalo en CloudWatch y X-Ray para aislar el coste del arranque.

Cuando la latencia sube sin más carga, Init Duration te ayuda a separar el tiempo del arranque del resto de la ejecución. Pon esta métrica en el punto de mira justo después de un despliegue y en funciones con poco tráfico.

Conviene actuar si el pico se repite, si coincide con despliegues o si golpea a funciones que se usan poco. Como primeros pasos:

• Reduce el tamaño del paquete.

• Saca la inicialización de clientes y conexiones fuera del handler.

• Usa Provisioned Concurrency solo si el coste fijo te sale a cuenta. No la actives por defecto.

Si el problema no viene del arranque, toca revisar el consumo de memoria.

6. Uso de memoria y MaxMemoryUsed

Si la latencia sigue alta después de descartar los cold starts, toca mirar la memoria y el tamaño de la función.

MaxMemoryUsed indica el pico de memoria usado en una invocación. Lo ideal es leer este dato junto con la memoria asignada. Así ves enseguida si la función se ha quedado corta o si le has dado más de la cuenta.

Cuando MaxMemoryUsed se acerca de forma sostenida al límite, la función está subdimensionada. También conviene vigilar los picos y las subidas con el paso del tiempo, porque muchas veces avisan de fallos antes de que aparezcan en producción. Un consumo alto aumenta el riesgo de timeouts y puede hacer que la función salga más cara. Si ves ese patrón, el siguiente paso es revisar la configuración y cómo consume memoria la función.

No actúes por una sola invocación aislada. Muévete solo cuando el patrón se repita. Si el consumo se mantiene alto, sube la memoria y mide qué pasa con la duración y el coste. Si se mantiene bajo durante bastante tiempo, bájala para no sobredimensionar la función. Y antes de tocar nada, revisa CloudWatch y X-Ray.

7. Trazas con AWS X-Ray

AWS X-Ray añade contexto cuando las métricas, por sí solas, no te dicen qué está pasando.

Si la duración, los errores o los throttles no dejan claro el origen del problema, X-Ray te ayuda a verlo. Registra cada invocación y enseña dónde se va el tiempo: dentro de la función o en servicios externos.

Lo más útil de X-Ray no es solo mirar una traza suelta. La clave está en el mapa de servicio de CloudWatch ServiceLens. Ahí ves cómo se relaciona tu función con los servicios a los que llama y puedes detectar subsegmentos lentos o repetidos. Y eso, muchas veces, apunta directo al cuello de botella.

Cuándo actuar: revisa las trazas cuando aparezcan subsegmentos lentos de forma repetida, picos de latencia de extremo a extremo o segmentos con estado Fault o Error, aunque en CloudWatch todavía no se vea con claridad.

No traces el 100 % de las invocaciones. Empieza con un muestreo bajo y súbelo solo durante ventanas de diagnóstico. Así podrás leer mejor los picos antes de sacar conclusiones.

Cómo leer los datos sin perder la calma

Después de medir, toca interpretar bien. El fallo más común es mirar cada métrica por su cuenta. Cruza duración, invocaciones y tasa de error antes de mover ficha. Un pico, por sí solo, dice poco. Empieza a importar cuando aparece junto a más tráfico o más fallos.

Para la latencia, fíjate en p95 y p99. Ahí es donde suele verse la degradación de verdad. La media puede dar una falsa sensación de control y tapar picos que sí afectan a los usuarios.

Con los errores pasa algo parecido. El número absoluto puede engañar bastante. Lo que conviene calcular es la tasa de error: errores divididos entre invocaciones.

Cinco errores en 100 invocaciones son un problema serio. Cinco en un millón, no. Son ruido. Si no normalizas por invocaciones, las alertas basadas en valores absolutos acaban lanzando falsos positivos. Y cuando eso pasa una y otra vez, el equipo deja de hacerles caso.

Por eso este criterio encaja mejor en paneles que muestren, a la vez, invocaciones, latencia y tasa de error.

Tablas y ayudas visuales que incluir

Estas vistas convierten las métricas en umbrales de acción.

Después de medir cada métrica, compárala con estos umbrales para ver si toca intervenir o si todo va bien.

Duración por percentiles frente al timeout configurado

Si el p99 se acerca al timeout, el riesgo es alto. No hace falta esperar a que haya fallos: esa señal ya te está diciendo que vas muy justo.

Memoria configurada frente a MaxMemoryUsed

Aquí la lectura es bastante directa. Subir memoria solo merece la pena si la duración baja de forma clara. Si pagas más pero apenas ganas tiempo, el cambio no sale a cuenta.

Tasa de arranques en frío y acciones recomendadas

Juntas, estas tres vistas funcionan como un panel de lectura rápida. De un vistazo, te ayudan a detectar si el problema está en el tiempo de ejecución, en la memoria o en los arranques en frío.

Además, estas vistas alimentan el panel y las alertas dentro del flujo de monitorización.

Un flujo de monitorización sencillo para Lambda en producción

Flujo de Monitorización AWS Lambda: 3 Etapas para Detectar Problemas

Cuando ya entiendes qué te dice cada métrica, el siguiente paso es poner orden. En producción, no conviene mirar todo a la vez. Sale mejor revisar las señales según su prioridad operativa.

Empieza por Invocations y Errors. Estas dos métricas te dan la foto base: cuánto trabajo está entrando y cuántos fallos se están produciendo. Si aquí algo va mal, ya sabes que hay un problema de salud que atender.

Después, pasa a Duration y Throttles. Aquí controlas dos cosas muy concretas: la latencia y la capacidad. Configura una alarma en CloudWatch para que te avise cuando la duración supere tu umbral o cuando Throttles sea mayor que 0. Así no dependes de entrar a revisar paneles todo el rato.

Por último, usa Cold Starts, memoria y trazas para ir a la causa raíz. Este bloque es el que te ayuda a decidir si toca escalar, ajustar la configuración o investigar más a fondo.

Visto así, la monitorización deja de ser una pila de datos sueltos y pasa a ser un proceso de decisión. La tabla resume ese orden de trabajo.

Conclusión

Después de revisar tráfico, rendimiento, capacidad y trazas, la idea es bastante simple: no necesitas decenas de paneles para leer Lambda con criterio y saber cuándo mover ficha.

Cada métrica responde a una decisión distinta. Unas te hablan del tráfico, otras de la latencia, la capacidad, los fallos, el arranque, la memoria o la trazabilidad. La lectura buena casi siempre empieza igual: cruza volumen, latencia y errores. No se trata de medir más. Se trata de responder antes.

Mirarlas con cierta regularidad recorta ruido y ayuda a decidir mejor en producción. Así puedes detectar incidencias antes de que lleguen al usuario y al gasto. Cuando las ves en conjunto, Lambda deja de parecer una caja negra.

FAQs

¿Qué métrica debería vigilar primero?

La primera métrica que debes vigilar son las invocaciones. Es el punto de partida para entender qué está pasando en AWS Lambda, porque te muestra el volumen de uso de tu aplicación.

Además, te da el contexto que necesitas para leer mejor otras métricas, como los errores, el throttling o la duración. Sin ese dato, es fácil mirar números sueltos y sacar la conclusión equivocada. Con él, en cambio, puedes gestionar los recursos con más criterio.

¿Cuándo un throttle es grave?

Un throttle es grave cuando golpea de lleno la experiencia del usuario o corta procesos críticos del negocio.

Pasa a ser prioritario cuando el porcentaje de invocaciones rechazadas se mantiene estable o empieza a subir, sobre todo durante picos de tráfico previstos. En muchos casos, eso apunta a que los límites de concurrencia de AWS Lambda se han quedado cortos para la carga actual.

¿Cómo sé si necesito más memoria?

Monitoriza el uso de memoria de tu función AWS Lambda y compáralo con el límite que has configurado. Si el consumo se acerca de forma constante al máximo asignado, suele ser una señal clara: algo va justo. Y cuando una función va justa de memoria, no solo puede rendir peor; también puede acabar fallando por falta de recursos.

También merece la pena revisar los logs de ejecución. Una memoria insuficiente puede hacer que el procesamiento se vuelva más lento y que la duración de las invocaciones suba. A veces el problema no salta a la vista hasta que miras esos tiempos y ves que, poco a poco, se disparan.

Publicaciones de blog relacionadas

• Checklist para Implementar Monitoreo en la Nube en Startups

• Serverless y Reducción de Costos en Startups

• Cómo Implementar Monitoreo de Seguridad en SaaS

• ¿Cuándo elegir serverless para tu proyecto?