En el anterior post conté cómo podemos tener logs en el lambda de nuestra skill, ya sea con mensajes que nosotros decidamos sacar o por errores que ocurren en la ejecución. Un ejemplo de lo primero serían los interceptores que creamos para sacar las requests y response. Y sobre los errores vimos como las excepciones también aparecen en CloudWatch.
Usando esos mensajes vamos a poder crear alarmas con las herramientas de AWS y así generar notificaciones, a nuestro correo por ejemplo, si están ocurriendo errores o cualquier cosa que se nos ocurra metricar.
Creando métricas sobre los mensajes de logs
Como base para las alarmas vamos a tener métricas de eventos que ocurren en nuestro lambda. Estas métricas se crean a nivel de grupo de logs y normalmente para los skills tendremos un grupo por lambda.
Desde la consola inicial de CloudWatch podemos acceder a todos los grupos de logs para nuestro usuario.
El botón para crear métricas no está habilitado de primeras sino que tendremos que seleccionar un grupo de logs y así podremos habilitarlo.
Tenemos dos pasos que cubrir:
- Definir el filtro que se usará para detectar el evento que nos interese. Esto se hace creando un patrón que coincida con el mensaje que sea. Por ejemplo, en la imagen, podemos ver un filtro que tengo yo creado para detectar eventos que sean de
Unhandled exceptiony deriven en un error de la skill. Podemos probar nuestro patrón copiando mensajes que saquemos de logs y ver si encuentra resultados. Podemos verlo en la imagen también.
- Una vez tenemos el patrón pasamos a asignarle una métrica. En este segundo paso simplemente le damos nombre al filtro anterior, elegimos un namespace para la métrica (yo creé uno para las métricas de los logs) y, por último, asignamos un nombre a la propia métrica.
Cada métrica que creemos la vamos a tener accesible desde la primera pantalla que hemos visto, donde aparecen todos los grupos de logs. Hay una columna que se llama "Filters" y de ahí vamos a la siguiente imagen:
Aquí podeis ver tres filtros que tengo yo creados (empezando por arriba):
- Uno para respuestas inválidas del lambda hacía Alexa. Las respuestas de texto están anotadas con un lenguaje de marcado (SSML) y si está mal formado vamos a tener una respuesta indicándolo en nuestro interceptor de la response.
- Uno para un mensaje que estoy metiendo yo en el lambda. La skill de Estrenos de Cine pide la info a una API y el modelo de respuesta para cada estrenos lleva un campo de
original_language. Yo uso ese campo para marcar cómo Alexa tiene que decir el título de la película si no está localizado al español. Puede pasar que me lleguen idiomas que, o Alexa no conoce o bien yo aún no lo he añadido a mis opciones de marcado. Creado un log para esto me entero y puedo actuar como corresponda. - Y, el último, es el filtro que acabamos de crear para enterarnos de excepciones que no sabe manejar el lambda.
De los tres que tengo yo, al menos el relacionado con SSML y el tema de las excepciones me parecen básicos para cualquier skill.
Creando alarmas sobre las métricas
Una vez tenemos los filtros anteriores es muy fácil crear una alarma. Si nos fijamos en la última captura, AWS ya nos está ofreciendo un link para crear una alarma a partir de ese filtro.
La creación de una alarma tiene varias fases:
- Primero tenemos que especificar la métrica y las condiciones para que esa alarma "salte". Para esto tenemos que poner el nombre de la métrica (se rellena automática si venimos del link del listado de filtros), la operación (suma, media, máxima, etc) y el periodo. No hay que complicarse mucho la vida aquí, nos vale con la suma en periodos de 5 minutos.
- Para las condiciones, al igual que antes, tampoco nos compliquemos mucho. Con poner que las condiciones de la alarma son que el valor del
thresholdsea mayor o igual a 1 ya lo tenemos. Esto se puede interpretar como que queremos que la alarma salte cuando nuestro filtro detecte un caso y se cumpla.
- El siguiente paso consiste en configurar las acciones que se llevarán a cabo cuando se active la alarma. En nuestro caso queremos que, en el estado de alarma, se envíe un correo. Para eso vamos a usar el SNS de AWS. Si es la primera vez que pasamos por aquí tenemos que crear un topic. Yo creé uno con mi dirección de correo personal y es el que uso en todas las alarmas.
- Como siguiente paso tendremos que ponerle nombre a la alarma y una descripción. Ten en cuenta que lo que pongamos ahí será parte del mail que recibiremos. Es recomendable poner info para saber, al menos, cuál es la alarma saltando si tenemos varias. Dentro del propio mail ya tendremos un enlace al dashboard de CloudWatch.
- En el último paso tendremos un resumen de todo el proceso y procederemos a confirmar la creación de la alarma.
Una vez tengamos la alarma creada podremos acceder a ella desde la sección de "Alarms" de la consola de CloudWatch.
Ahí podremos ver el listado de alarmas creadas, su estado actual, condiciones, etc. Igualmente desde aquí podemos crear alarmas siguiendo un proceso similar al anterior sólo que como primer paso hay que seleccionar la métrica sobre la que estará funcionando la alarma.
Una vez ocurra alguno de los escenarios que hemos preparado recibiremos un correo desde el cual podremos acceder a la consola de logs. Este correo nos informa de la alarma y la métrica asociada junto con el valor que ha tomado y en el momento en el que ha ocurrido el evento.
En estos dos últimos posts os he contado cómo tener un sistema de monitoring y alarmas básico y simple para nuestras skills. Así no estaremos ciegos ante situaciones de error o comportamiento inesperado. De todas formas recordad mirar de vez en cuando los logs porque pueden aparecer situaciones que aún no tengamos controladas y podrían implicar alarmas nuevas.
Top comments (0)