Consultas sobre ALB Access Logs con Amazon Athena

partenon

Objetivo

Examinar el tráfico de un ALB endpoint, utilizando la función Access Logs y realizar consultas SQL con la herramienta Amazon Athena sobre dichos logs.

Intro

Un ALB o Aplication Load Balancer es uno de los 3 tipos de load balancers que ofrece aws como parte de su servicio ELB (Elastic Load Balancer), es un balanceador de carga de layer 7, que posee cierta “inteligencia” a la hora de redirigir el tráfico hacia nuestras aplicaciones, por lo general es muy usado en ambientes web así como también en ambientes de microservicios y containers. Existen 4 formas de monitorear un ELB:

  • Cloudwatch Metrics
  • Access Logs
  • Request Tracing (solo disponible para ALB)
  • CloudTrail Logs

Nosotros vamos a utilizar Access Logs, que básicamente va a registrar los accesos a nuestro load balancer, junto con otras métricas como por ejemplo cantidad de accesos, dirección IP origen, verbo http usado, path de requests etc.

Algo que resaltar sobre Access Logs en ELB es que los logs van a ser guardados en un Bucket S3, lo cual nos ofrece una ventaja adicional, ya que al guardarse en un bucket, estos logs se podrían analizar días o incluso semanas después de ocurrido algún evento en el cual las instancias o contenedores destino de esas requests hayan desaparecido, esto resulta sumamente útil por ejemplo en un esquema de Autoscaling Groups.

Pero…. para qué vamos a usar Athena?

Imaginense a nuestro ALB en un entorno productivo, con miles de requests por día/minuto/segundo lo que fuere, si quisiéramos analizar algún caso en particular, buscar los logs de nuestro ALB en un bucket con miles de objetos resulta muy difícil o directamente imposible. En este escenario es donde nos viene muy bien un servicio que aws sacó a la luz en su reInvent del 2016, llamado Athena, que básicamente es un servicio serverless que nos permite realizar consultas SQL sobre un bucket S3 (GENIAL), gracias a este super-poder de Athena podemos hacer querys SQL puntuales sobre un océano de logs sin mayores problemas.

Activamos el Logging en nuestro ALB endpoint

Vamos a nuestra consola EC2 en la sección ELB y seleccionamos nuestro ALB, luego vamos a Actions -> Edit attributes y activamos los Access logs, indicando el bucket destino y de no existir dicho bucket, tambien nos ofrece la opción de crearlo.

enableAccesslogs

IMPORTANTE: Para activar correctamente Access logs, el servicio ELB debe tener permisos para crear objetos en S3, por lo tanto debemos crear una Bucket Policy en el bucket destino permitiendo a ELB el acceso para peticiones de tipo PutObject, para mas detalles sobre esta conf pueden ir al siguiente enlace.

Probemos Access Logs

Vamos a estresar nuestro ALB con una herramienta muy copada llamada Apache Benchmarking, les dejo la doc oficial en este enlace, vamos a utilizar el siguiente comando ab:

$ ab -k -c 20 -n 50 http://url-alb-aws/path

ab

Inmediatamente si miramos nuestro bucket, veremos reflejado los logs de ALB generados por nuestra herramienta de apache.

s3-logs

Creamos la BD en Athena

Ahora que ya verificamos el correcto funcionamiento de nuestro access logs, vamos a ir a la consola de Athena y en primer lugar, creamos nuestra BD, corriendo la siguiente query:

CREATE DATABASE alb_logs_test

Una vez que tenemos la BD creada, vamos a crear una tabla con la siguiente query SQL:

CREATE EXTERNAL TABLE IF NOT EXISTS alb_logs (
        type string,
        time string,
        elb string,
        client_ip string,
        client_port int,
        target_ip string,
        target_port int,
        request_processing_time double,
        target_processing_time double,
        response_processing_time double,
        elb_status_code string,
        target_status_code string,
        received_bytes bigint,
        sent_bytes bigint,
        request_verb string,
        request_url string,
        request_proto string,
        user_agent string,
        ssl_cipher string,
        ssl_protocol string,
        target_group_arn string,
        trace_id string,
        domain_name string,
        chosen_cert_arn string,
        matched_rule_priority string,
        request_creation_time string,
        actions_executed string,
        redirect_url string,
        lambda_error_reason string,
        new_field string
        )
        ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
        WITH SERDEPROPERTIES (
        'serialization.format' = '1',
        'input.regex' =
    '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) ([^ ]*) (- |[^ ]*)\" \"([^\"]*)\" ([A-Z0-9-]+) ([A-Za-z0-9.-]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^\"]*)\" ([-.0-9]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\"($| \"[^ ]*\")(.*)')
        LOCATION 's3://your-alb-logs-directory/AWSLogs/<ACCOUNT-ID>/elasticloadbalancing/<REGION>/';

No olvides reemplazar los 3 valores (tu bucket s3, id de cuenta y region), esta query crea una tabla que contiene todos los campos presentes en los Access logs de ALB, y los mapea a todos usando como fuente de ORIGEN el bucket S3 que usamos de destino de nuestros Access Logs de ALB, el esquema sería el siguiente:

esquema

NOTA: La integración con Quicksight es bastante usada en este tipo de esquema, por eso la incluí en el gráfico, pero no es materia de estudio de este post, básicamente tenemos la posibilidad de integrar athena con quicksight para crear dashboards dinámicos, reportes, alarmas por mail basadas en datos etc..

Tabla creada:

tabla

Athena en Acción

Ahora que tenemos mapeados nuestros logs de ALB en nuestra tabla Athena, podemos jugar con las consultas SQL que queramos, no soy un experto en SQL (como verán a continuación) pero solo a modo de ejemplo podemos tirar algunas consultas básicas para ver a Athena en funcionamiento:

Un SELECT ALL para probar:

selectall

Vemos que nos trae toda la info de las requests al ALB (IP origen/destino, puertos, trace_id etc)

Requests de un Verbo específico agrupadas por IP origen:

get

Acá estamos consultando la cantidad y la ip origen de las requests, agrupando el resultado por Verbo HTTP e IP origen, en este caso solo veremos una IP ya que todas las requests fueron hechas por nuestro ab.

Imaginen todo lo que podría hacer con Athena alguien que de verdad conozca de SQL xD.

Casos de Uso

Realizar consultas SQL sobre uno o más set de datos es realmente una herramienta poderosa para cualquier negocio/empresa, por mencionar algunos casos de uso:

  • Análisis de logs,
  • Analisis de Trafico
  • Análisis financiero realizando querys sobre reportes de gastos.
  • Integración con clusters ELK
  • Integración con EMR
  • Integración con QuickSight para el armado de dashboards interactivos.
  • Soporte a herramientas de BI

Fuentes

Invitame un CaféInvitame un Café