Cómo filtrar Logs en CloudWatch para generar una alerta.
En algunas ocasiones cuando tenemos alguna aplicación y esta presenta alguna falla, es posible que necesitemos detectarlo y quisiéramos poder enviar una alerta al equipo de soporte o desarrollo para que puedan tomar una acción de esto.
El caso de uso también puede cubrir que disparemos una alarma cuando detectemos que no existe tráfico proveniente entre un servicio de terceros que nos consume una aplicación nuestra y cuando no detecte tráfico en un intervalo de 1 minuto, entonces avisemos al area de operaciones de T.I…. en este último caso nos enfocaremos.
Prerrequisitos:
- Tener habilitado VPC Flogs en la VPC actual donde filtramos el patrón que queremos identificar en los Logs
- Tener previamente creado un Topic SNS
- Definir cuál es el host origen , host destino.
Host Origen → (Mi instancia EC2 en AWS ) Ip privada → 10.10.150.208
Host Destino → (Servidor On premise ó Servidor de nuestro cliente que consume nuestro servicio alojado en el host origen).
10.150.2.33
Puerto → podemos monitorear algún puerto específico pero en nuestro caso todos.
- Tener un tráfico ya existente que cumpla el patrón que vamos a monitorear.
Configuración
Una vez tengamos todos los Prerrequisitos y la información necesaria procedemos a configurar en en el servicio de Cloud Watch.
Cloud Watch → Log Groups → Log Groups que tienes creado donde estas capturando el VPC Flows, en mi caso se llama “VPCLOG_PROD”
Una vez hemos dado click en VPCLOG_PROD vamos a Metric Filter → Create metric filter
Definimos el patrón que haga match con nuestro caso uso , escogemos la ENI de nuestra instancia EC2 Origen donde corre nuestra aplicación y le damos “Test Pattern”, esto entregará unos resultados de ejemplo que se filtrarán del Flow Logs de la VPC.
Script del patrón
[version, account, eni=”eni-02c4b09ed2e32XXXX", source=10.10.150.208, destination=10.150.2.33, srcport, destport, protocol, packets, bytes, windowstart, windowend, action, flowlogstatus]
Continuamos con darle un nombre al filtro y los diferentes campos que se solicitan y le damos next.
Nos hace un Review para finalizar el el patrón del filtro creado y nos permite realizar algún cambio si fuera necesario.
Hemos culminado la creación de la métrica con el filtro creado basado en nuestro patrón de búsqueda en los Flow Logs.
Creación alarma
Crearemos una alarma que nos indique que si en 1 minuto no recibimos ningún tipo de tráfico desde nuestro host origen, envié un email y un SMS al equipo de Help Desk.
Lo anterior es de gran utilidad para notificar si una aplicación esta presentando problemas , no hay consumo del servicio y hasta dado el caso realizar otro nivel de automatizaciones para recuperar la disponibilidad.
Cloud Watch → Alarm → Create Alarm
Escogemos en select metric la métrica Custom llamada “blogfilter” que hemos creado anteriormente.
Navegamos sobre la métrica hasta encontrar el nombre “trafficbetweenEc2Onpremise” la cual es el nombre de la métrica creada y la seleccionamos.
Recomiendo antes de dar Select Metric, pasar a la pestaña Graph options y cambiar por número
Especificamos las condiciones de la alarma como Statistics → Sum y Period 1 Minute.
Con esto nos aseguramos de contar cada minuto todas las transacciones que vienen desde el servidor On Premise hacia nuestro Servidor Web en EC2 .
Cuando durante 1 minuto existan menos de 2 registros en el filtro del Log con el patrón definido, entonces dispare la alarma.
Escogemos el Topic SNS que tengamos creado en nuestro caso se llama pruebaBlog y este contiene nuestro correo electrónico y celular para envío de SMS.
Identificamos nuestra alarma con un nombre en nuestro caso “TrafficBetween Ec2ToOnpremise” y damos Next
Un Preview donde se mostrará un Preview y resumen de toda la configuración y podremos ajustar o cambiar alguna opción si fuera el caso.
Hemos finalizado y ahora nuestra alarma estará monitoreando nuestro filtro dentro del Flow Log y esperando que suceda la regla.
Vemos cómo sucede nuestra alarma una vez hemos tenido indisponibilidad del servicio o no llega ninguna transacción de nuestro cliente a las 3:55 AM UTC-5.
De igual forma nuestra notificación ha disparado un SMS al operador de sistemas.
Conclusiones
Realmente es muy poderoso monitorear los FlowLogs y poder automatizar muchas acciones dentro de su infraestructura Cloud, incluso monitoreando tráfico desde su Red On Premise si tiene una VPN Site to Site contra AWS o si tiene un VPC Peering con otro proveedor y le envía tráfico.
Puede ajustar el Script y las reglas como quiera considerar su caso de uso para monitorear por ejemplo errores en un servidor apache , la llegada de transacciones a procesar de su servidor Web, la caída de trafico de Red desde el On Premise, etc.
