Cómo utilizar AWS Logs Insights para consultar las métricas del panel de control a partir de los registros de los servicios de AWS

Cada servicio de AWS registra su procesamiento en archivos organizados en grupos de logs de CloudWatch. Los grupos de logs suelen llevar el nombre del propio servicio para facilitar su identificación. Los mensajes del sistema del servicio o la información de estado común se escriben en esos archivos de registro por defecto.

Sin embargo, puede añadir información de mensajes de registro personalizados además de los predeterminados. Si estos registros se crean de forma inteligente, pueden servir para crear útiles cuadros de mando de CloudWatch.

Con métricas e información estructurada que ofrece detalles adicionales sobre el procesamiento de los trabajos. No sólo pueden contener widgets estándar con información similar a la del sistema sobre el servicio. Puede ampliarlo con su propio contenido, agregado en su widget o métrica personalizada.

Consultar los archivos de registro

AWS CloudWatch Log Insights le permite buscar y analizar datos de registro de sus recursos de AWS en tiempo real. Puede verlo como una vista de base de datos. Usted define la consulta en el panel de control, y éste la seleccionará cuando lo visite o en la ventana de tiempo especificada en el pasado, según lo defina dentro de la vista del panel de control.

Utiliza un lenguaje de consulta llamado CloudWatch Logs Insights para buscar y analizar los datos de registro. El lenguaje de consulta se basa en un subconjunto del lenguaje SQL. Le permite buscar y filtrar datos de registro. Puede buscar eventos de registro específicos, texto de registro personalizado o palabras clave, y filtrar los datos de registro basándose en campos específicos. Y lo que es más importante, agregar datos de registro dentro de uno o más archivos de registro para generar métricas y visualizaciones resumidas.

Cuando ejecuta una consulta, CloudWatch Log Insights busca entre los datos de registro del grupo de registros. A continuación, devuelve los textos resultantes de los archivos que coinciden con sus criterios de consulta.

Ejemplo de consulta de archivos de registro

Echemos un vistazo a algunas consultas básicas para entender el concepto.

Cada servicio, por defecto, registra algunos errores de servicio cruciales. Incluso si no crea un registro personalizado dedicado para tales eventos de error. Entonces, con una simple consulta, puede contar el número de errores en los registros de su aplicación durante la última hora:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)

O aquí tiene cómo monitorizar el tiempo medio de respuesta de su API durante el último día:

fields @timestamp, @message
| filter @message like /Tiempo de respuesta de la API/
| stats avg(tiempo_respuesta) by bin(1d)

Dado que, por defecto, la utilización de la CPU es información registrada por el servicio en CloudWatch, también puede recopilar este tipo de métrica:

fields @timestamp, @message
| filter @message like /CPUUtilization/
| stats avg(valor) by bin(1h)

Estas consultas pueden personalizarse para adaptarse a su caso de uso específico y pueden utilizarse para crear métricas y visualizaciones personalizadas en los cuadros de mando de CloudWatch. La forma de hacerlo es colocar el widget en el cuadro de mandos y colocar el código dentro del widget para definir qué seleccionar.

Estos son algunos de los widgets que pueden utilizarse en los Cuadros de mando de CloudWatch y rellenarse con contenido de Log Insights:

• Widgets detexto – Muestran información basada en texto, como la salida de una consulta de CloudWatch Insights.

• Widgetsde consulta de registro: muestran los resultados de una consulta de registro de CloudWatch Insights, como el número de errores en los registros de su aplicación.

Cómo crear información de registro útil para el panel de control

Para utilizar eficazmente las consultas de CloudWatch Insights en los cuadros de mando de CloudWatch, es bueno seguir algunas buenas prácticas a la hora de crear registros de CloudWatch para cada uno de los servicios que utilice en su sistema. He aquí algunos consejos:

#1. Utilice un registro estructurado

Deberá ceñirse a un formato de registro que utilice un esquema predefinido para registrar los datos en un formato estructurado. Esto facilita la búsqueda y el filtrado de los datos de registro mediante las consultas de CloudWatch Insights.

Esto significa básicamente estandarizar sus registros en los diferentes servicios de su plataforma de arquitectura. Tenerlo definido en estándares de desarrollo ayuda enormemente.

Por ejemplo, puede definir que cada problema relacionado con una tabla específica de la base de datos se registre con un mensaje inicial como «[NOMBRE_TABLA] Advertencia / Error: «.

O puede separar los trabajos de datos completos de los trabajos de datos delta mediante prefijos como «[FULL/DELTA]» para seleccionar sólo los mensajes relacionados con los procesos de datos concretos.

Puede definir que al procesar datos de un sistema fuente concreto, el nombre del sistema sea un prefijo de cada entrada de registro relacionada. Después será mucho más fácil filtrar esos mensajes de los archivos de registro y construir métricas sobre ellos.

#2. Utilice formatos de registro coherentes

Utilice formatos de registro coherentes en todos sus recursos de AWS para facilitar la búsqueda y el filtrado de datos de registro mediante consultas de CloudWatch Insights.

Esto está bastante relacionado con el punto anterior, pero el hecho es que cuanto más estandarizado esté el formato de registro, más fácil será utilizar los datos de registro. Así, los desarrolladores pueden confiar en ese formato y utilizarlo incluso de forma intuitiva.

El hecho cruel es que la mayoría de los proyectos no se preocupan por ningún estándar en torno al registro. Es más, muchos proyectos ni siquiera crean registros personalizados. Es chocante, pero también tan común al mismo tiempo.

Ni siquiera puedo decir cuántas veces me he preguntado cómo se puede vivir aquí sin ningún enfoque de gestión de errores. Y si alguien se esforzaba por hacer algún tipo de gestión de errores como excepción, lo hacía mal.

Por lo tanto, un formato de registro coherente es una gran ventaja. No muchos los tienen.

#3. Incluya metadatos relevantes

Incluya metadatos en sus datos de registro, como marcas de tiempo, ID de recursos y códigos de error, para facilitar la búsqueda y el filtrado de los datos de registro mediante las consultas de CloudWatch Insights.

#4. Habilite la rotación de registros

Active la rotación de registros para evitar que sus datos de registro se vuelvan demasiado grandes y para facilitar la búsqueda y el filtrado de datos de registro mediante consultas de CloudWatch Insights.

No tener datos de registro es una cosa, pero tener demasiados sin estructura es igualmente desesperante. Si no puede utilizar sus datos, es como no tener ningún dato.

#5. Utilice los agentes de registros de CloudWatch

Si no puede evitarlo y se niega a crear su sistema de registro personalizado, utilice al menos los agentes CloudWatch Logs. Estos envían automáticamente los datos de registro de sus recursos de AWS a CloudWatch Logs. Esto facilita la búsqueda y el filtrado de los datos de registro mediante consultas de CloudWatch Insights.

Ejemplos de consultas Insights más complejas

Las consultas de CloudWatch Insights pueden ser más complicadas que una simple sentencia de dos líneas.

campos @timestamp, @message
| filtrar @mensaje como /ERROR/
| filter @message not like /404/
| parse @mensaje /.*\[(?<timestamp>[^\]] )\].*\"(?<method>[^\s] )\s (?<path>[^\s] ).*\" (?<status>\d ) (?<response_time>\d )/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20

Esta consulta hace lo siguiente

1. Selecciona los eventos de registro que contienen la cadena «ERROR» pero no «404».
2. Analiza el mensaje de registro para extraer la marca de tiempo, el método HTTP, la ruta, el código de estado y el tiempo de respuesta.
3. Calcula el tiempo medio de respuesta y el recuento de eventos de registro para cada combinación de método HTTP, ruta, código de estado y hora.
4. Ordena los resultados por conteo en orden descendente.
5. Limita la salida a los 20 primeros resultados.

Esta consulta identifica los errores más comunes en su aplicación y rastrea el tiempo medio de respuesta para cada combinación de método HTTP, ruta y código de estado. Puede utilizar los resultados para crear métricas y visualizaciones personalizadas en los paneles de CloudWatch para monitorizar el rendimiento de su aplicación web y solucionar problemas.

Otro ejemplo de consulta de los mensajes del servicio Amazon S3:

fields @timestamp, @message
| filtre @mensaje como /REST\.API\.REQUEST/
| parse @mensaje /.*\"(?<método>[^\s] )\s (?<ruta>[^\s] ).*\" (?<estado>\d ) (?<tiempo_respuesta>\d )/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20

• La consulta selecciona los eventos de registro que contienen la cadena «REST.API.REQUEST».
• A continuación, analiza el mensaje de registro para extraer el método HTTP, la ruta, el código de estado y el tiempo de respuesta.
• Calcula el tiempo de respuesta medio y el recuento de eventos de registro para cada combinación de método HTTP, ruta y código de estado y ordena los resultados por recuento en orden descendente.
• Limita la salida a los 20 primeros resultados.

Puede utilizar la salida de esta consulta para crear un gráfico de líneas en un panel de CloudWatch que muestre el tiempo medio de respuesta para cada combinación de método HTTP, ruta y código de estado a lo largo del tiempo.

Creación del panel de control

Para rellenar las métricas y visualizaciones en los cuadros de mando de CloudWatch a partir de la salida de las consultas de registro de CloudWatch Insights, puede navegar a la consola de CloudWatch y seguir el asistente de cuadros de mando para construir su contenido.

Después de eso, así es como se ve el código de un CloudWatch Dashboard que contiene métricas rellenadas por datos de consultas de CloudWatch Insights:

{
    "widgets": [
        {
            "tipo": "métrica",
            "x": 0,
            "y": 0,
            "anchura": 12,
            "altura": 6,
            "propiedades": {
                "métricas": [
                    [
                        "AWS/EC2",
                        "CPUUtilization",
                        "InstanceId",
                        "i-0123456789abcdef0",
                        {
                            "label": "Utilización de CPU",
                            "stat": "Promedio",
                            "periodo": 300
                        }
                    ]
                ],
                "vista": "timeSeries",
                "stacked": falso
                "region": "us-east-1",
                "title": "Utilización de la CPU de EC2"
            }
        },
        {
            "type": "log",
            "x": 0,
            "y": 6,
            "ancho": 12,
            "altura": 6,
            "propiedades": {
                "consulta": "fields @timestamp, @message
| filter @mensaje like /ERROR/
| stats count() by bin(1h)
",
                "region": "us-east-1",
                "title": "Errores de aplicación"
            }
        }
    ]
}

Este CloudWatch Dashboard contiene dos widgets:

1. Un widget de métricas que muestra la utilización media de la CPU de una instancia EC2 a lo largo del tiempo. CloudWatch Insights Query rellena el widget. Selecciona los datos de utilización de la CPU para una instancia EC2 específica y los agrega a intervalos de 5 minutos.
2. Un widget de registro que muestra el número de errores de aplicación a lo largo del tiempo. Selecciona los eventos de registro que contienen la cadena «ERROR» y los agrega por horas.

Es un archivo en formato JSON con una definición del cuadro de mandos y métricas en su interior. También contiene (como propiedad) la propia consulta insight.

Puede tomar el código e implementarlo en cualquier cuenta de AWS que necesite. Suponiendo que los servicios y los mensajes de registro sean coherentes en todas sus cuentas y etapas de AWS, el tablero funcionará en todas las cuentas sin necesidad de cambiar el código fuente del tablero.

Palabras finales

Construir una sólida estructura de registro siempre fue una buena inversión para el futuro de la fiabilidad del sistema. Ahora puede servir a un propósito aún mayor. Puede tener cuadros de mando útiles con métricas y visualizaciones sólo como efecto secundario de ello.

Al tener que hacerse una sola vez, con sólo un poco de trabajo adicional, el equipo de desarrollo, el equipo de pruebas y los usuarios de producción pueden beneficiarse de la misma solución.

A continuación, consulte las mejores herramientas de monitorización de AWS.