Erste Einblicke in CloudWatch Logs Insights

Mal unter uns - in der Analyse der Logdateien hat CloudWatch logs bisher nicht gerade geglänzt. Das Feld wurde eher anderen Kandidaten überlassen. Jetzt hat man die Analysefähigkeit aufpoliert. Daher ist es Zeit sich das genauer anzuschauen. _TL;DR : Nicht schlecht gemacht, einen Blick wert! _ Verschiedene Auswertungen von vordefinierten und eigenen Feldern, kombiniert mit einer einfache Visualisierung können schon viele Anwendungsfälle erschlagen.

Testfunktion erzeugt Log Einträge

Ich nehme zum Test eine Lambda Function “pandocs3converter”, die auf einem S3 Bucket Markdown Texte in Docx umwandelt. Dabei werden Logeinträge durch Hochladen von Dateien erzeugt. Für Lambda Funktionen werden durch Inisght standardmäßig die Felder @timestamp,@logStream,@message,@requestId,@duration, ``@billedDuration,@type,@maxMemoryUsed,@memorySize bereitgestellt. Als erstes kann ich mir also mit

fields @timestamp, @type, @message | head 30

eine einfache Auswertung anzeigen lassen. Insight hilft mir bereits bei der Auswahl der Log Group mit Autocompletion:

Eine einfache query

Rechts gibt es ein “commands” Fenster, aus dem ich jetzt “fields” auswähle. Die Felder erste ich durch “@timestamp, @type, @message | head 30 “. Damit bekomme ich die ersten 30 Zeilen.

Erste Zeilen

Die query wird ausgeführt und ich sehe die Ergebnisse. Hier sehen wir auch schon, wie das Feld “@type” gefüllt wird oder auch nicht.  

Grafische Auswertung

Jetzt habe ich auch Möglichkeiten mit verschiedenen Funktionen Visualisierungen darzustellen. Die Informationen über die Ausführungszeit stehen bei Lambda im “REPORT” Satz. Daher kann ich mit

filter @type = "REPORT"
| stats avg(@duration), max(@duration), min(@duration) by bin(1min)

Eine  Auswertung über Mittelwert, Maxima- und Minimalwert der Ausführungsdauer bekommen:

Man sieht in der Grafik schön den ersten Kaltstart der Lambda Funktion.

Auswerten eigener Felder

Die lambda verarbeitet Objekte, die auf einen S3 Bucket hochgeladen werden. Ich will jetzt wissen, welche Objekte verarbeitet wurden. Das könnte ich dann später mit Zählen der Ereignisse (count) usw. erweitern. Dazu kann ich das “parse” Kommando verwenden.

Im Log steht:

2018-11-29T09:08:04.974Z 47c76fee-f3b6-11e8-9d80-937cf190f299 Key: Training/M03-Tools\\\_CROW\\\_STORIES.md

Ich kann mit Logs Insights “parse” diese Information in ein Feld, hier “@Key” umwandeln. Interessant ist, dass man dieses Feld z.B. im Filter gleich weiter verwenden kann. Die komplette Zeile im Log ist in dem Feld @message hinterlegt.

Dort kann ich mit dem Pattern “Key: *” nach dem Feld suchen.

Im Filter filtere ich mit einer Regular Expression Felder heraus, die auch einen Inhalt haben, also “.” - ein Zeichen “*” mehrfach.

parse @message "Key: *" as @Key
| fields @timestamp, @File, @message
| filter @Key like /.*/
| sort @timestamp desc
| head 30

Das Ergebnis mit eigenen Felder.

Man kann also auf Anhieb viel mehr machen als mit den normalen Filterfunktionen von CloudWatch Logs und spart sich so eventuell eine zusätzliche Architektur und ein zusätzliche Applikation, wie z.B. beim Serverless Hero Yan Cui hervorragend beschrieben: 

/centralised-logging-for-aws-lambda-revised-2018.

Und jetzt viel Spaß beim Ausprobieren!

Photo (edited) by Paweł Czerwiński on Unsplash

Similar Posts You Might Enjoy

CloudWatch Alarme über Slack empfangen

Ob CPU-Auslastung einer EC2-Instanzen, Fehler beim Ausführen einer Lambda-Funktion oder verfügbarer Speicherplatz einer RDS-Instanz mit Amazon CloudWatch lassen sich Ressourcen bei AWS überwachen. Dafür werden zwei Komponenten benötigt: Metriken: Eine Metrik ist ein Sammeltopf für Messwerte, die von den AWS Services automatisch befüllt werden. Alarme: Ein Alarm überprüft in regelmäßigen Abständen ob sich die Messwerte einer Metrik noch innerhalb von definierten Grenzen bewegt. Eine Übersicht über alle verfügbaren Metriken findet sich unter Metriken und Dimensionen-Referenz von Amazon CloudWatch. - by Andreas Wittig

Building an AWS Lambda Telemetry API extension for direct logging to Grafana Loki

In hybrid architectures, serverless functions work together with container solutions. Lambda logs have to be translated when you don`t choose CloudWatch Logs. The old way of doing this is through subscription filters using additional Lambda functions for log transformation. With the Lambda Telemetry API there is a more elegant, performant and cost-effective way. I am using Grafana Loki as a working example and show you how to build a working Lambda-Loki Telemetry APi extension. - by Gernot Glawe

Logging Amazon FSx for NetApp ONTAP

Recently, I spent a lot of time using the exciting new member of the FSx family. One detail made working with it a bit unpleasant, though - the lack of log files. This post details how to create a custom integration into CloudWatch Logs and make ONTAP audit logs visible. - by Thomas Heinen