Varje tjänst inom AWS registrerar sin aktivitet i loggfiler, vilka organiseras under CloudWatch loggrupper. Dessa grupper ges vanligen namn som relaterar till tjänsten, vilket gör dem lätta att identifiera. Som standard skrivs systemmeddelanden och allmän statusinformation från tjänsten in i dessa loggfiler.
Det är möjligt att lägga till anpassad information i loggmeddelandena utöver det som registreras som standard. Om dessa anpassade loggar skapas på ett genomtänkt sätt, kan de användas för att skapa informativa instrumentpaneler i CloudWatch.
Genom att använda mätvärden och strukturerad information kan du få djupare insikt i jobbhanteringen. Instrumentpanelerna behöver inte begränsas till standardwidgets med systeminformation, utan kan utökas med eget innehåll, vilket samlas i anpassade widgets eller statistik.
Sökning i loggfilerna
Källa: aws.amazon.com
AWS CloudWatch Log Insights möjliggör sökning och analys av loggdata från dina AWS-resurser i realtid. Tänk på det som en databasvy där du definierar en sökfråga på instrumentpanelen. Denna fråga kommer att exekveras varje gång du besöker instrumentpanelen, eller inom ett specifikt tidsintervall som du har definierat i instrumentpanelens inställningar.
För att söka och analysera loggdata används ett frågespråk som kallas CloudWatch Logs Insights. Detta språk är baserat på en delmängd av SQL. Med det kan du söka och filtrera loggdata, efter specifika logghändelser, anpassad loggtext, eller nyckelord. Du kan också filtrera loggdata baserat på specifika fält och, vilket är viktigast, samla loggdata från en eller flera loggfiler för att generera summerade mätvärden och visualiseringar.
När en fråga körs söker CloudWatch Log Insights igenom loggdata i den angivna loggruppen. Därefter returneras de delar av loggfilerna som uppfyller dina sökkriterier.
Exempel på loggfilsfråga
Låt oss granska några grundläggande frågor för att illustrera konceptet.
Som standard loggar varje tjänst kritiska servicefel. Även om du inte skapar en särskild anpassad logg för dessa felhändelser, kan du med en enkel fråga räkna antalet fel i dina applikationsloggar under den senaste timmen:
fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(1h)
Ett annat exempel är övervakning av den genomsnittliga svarstiden för ditt API under det senaste dygnet:
fields @timestamp, @message | filter @message like /API response time/ | stats avg(response_time) by bin(1d)
Eftersom CPU-användning är standardinformation som loggas av tjänsten i CloudWatch, kan du även samla in detta mätvärde:
fields @timestamp, @message | filter @message like /CPUUtilization/ | stats avg(value) by bin(1h)
Dessa frågor kan anpassas efter dina specifika behov och användas för att skapa egna mätvärden och visualiseringar i CloudWatch Dashboards. Du lägger till en widget på instrumentpanelen och placerar koden i den för att definiera vad som ska väljas.
Här är några av de widgetar som kan användas i CloudWatch Dashboards och fyllas med innehåll från Log Insights:
- Textwidgets – Visar textbaserad information, till exempel resultatet av en CloudWatch Insights-fråga.
- Loggfrågewidgets – Visar resultaten av en CloudWatch Insights-loggfråga, som antalet fel i dina applikationsloggar.
Hur man skapar användbar logginformation för instrumentpanelen
Källa: aws.amazon.com
För att effektivt använda CloudWatch Insights-frågor i CloudWatch Dashboards, är det bra att följa några riktlinjer när du skapar loggar för de tjänster du använder. Här följer några tips:
#1. Använd strukturerad loggning
Det är viktigt att använda ett loggningsformat som följer ett fördefinierat schema för att logga data på ett strukturerat sätt. Det gör det enklare att söka och filtrera loggdata med hjälp av CloudWatch Insights-frågor.
Detta innebär i grunden att standardisera loggarna över de olika tjänsterna i din arkitekturplattform. Att ha detta definierat i utvecklingsstandarder är en stor fördel.
Du kan till exempel bestämma att varje problem som rör en specifik databastabell ska loggas med ett inledande meddelande som: ”[TABLE_NAME] Varning / Fel: <meddelande>”.
Du kan även separera loggar för fullständiga datajobb från deltadatajobb med prefix som ”[FULL/DELTA]” för att selektivt välja meddelanden som är relevanta för dessa dataprocesser.
Ytterligare ett exempel är att inkludera namnet på det källsystem som används i loggmeddelandet när data bearbetas från det. Det gör det mycket enklare att filtrera relevanta meddelanden från loggfilerna och skapa mätvärden baserat på dem.
#2. Använd konsekventa loggformat
Använd konsekventa loggformat över alla dina AWS-resurser, det förenklar sökning och filtrering av loggdata med CloudWatch Insights-frågor.
Detta är nära relaterat till föregående punkt, men det är ett faktum att ju mer standardiserat loggformatet är, desto enklare blir det att använda loggdatan. Utvecklare kan förlita sig på formatet och använda det intuitivt.
Det är uppseendeväckande att de flesta projekt inte har några standarder kring loggning. Dessutom är det många projekt som inte ens skapar egna anpassade loggar. Det är både chockerande och väldigt vanligt.
Jag har ofta undrat hur det är möjligt att arbeta utan ett sätt att hantera fel. Och om någon har försökt göra någon form av felhantering som ett undantag, har det inte utförts korrekt.
Ett konsekvent loggformat är en stark tillgång, vilket många saknar.
#3. Inkludera relevant metadata
Lägg till metadata i din loggdata, som tidsstämplar, resurs-ID och felkoder, för att underlätta sökning och filtrering av loggdata med CloudWatch Insights-frågor.
#4. Aktivera loggrotation
Aktivera loggrotation för att förhindra att loggdatan blir för omfattande och för att underlätta sökning och filtrering med CloudWatch Insights-frågor.
Att inte ha någon loggdata är ett problem, men att ha för mycket data utan struktur är lika besvärligt. Om du inte kan använda din data, är det som att inte ha någon data alls.
#5. Använd CloudWatch Logs Agents
Om du av någon anledning inte kan implementera ett eget loggsystem, använd åtminstone CloudWatch Logs-agenter. De skickar automatiskt loggdata från dina AWS-resurser till CloudWatch Logs. Det gör det enklare att söka och filtrera loggdata med hjälp av CloudWatch Insights-frågor.
Mer komplexa exempel på frågor
CloudWatch Insights-frågor kan vara mer avancerade än bara några få rader.
fields @timestamp, @message | filter @message like /ERROR/ | filter @message not like /404/ | parse @message /.*[(?<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
Den här frågan gör följande:
- Väljer logghändelser som innehåller strängen ”ERROR” men inte ”404”.
- Analyserar loggmeddelandet för att extrahera tidsstämpeln, HTTP-metoden, sökvägen, statuskoden och svarstiden.
- Beräknar den genomsnittliga svarstiden och antalet logghändelser för varje kombination av HTTP-metod, sökväg, statuskod och timme.
- Sorterar resultaten efter antal i fallande ordning.
- Begränsar resultatet till de 20 mest frekventa träffarna.
Denna fråga identifierar de vanligaste felen i din applikation och spårar den genomsnittliga svarstiden för varje kombination av HTTP-metod, sökväg och statuskod. Du kan använda resultatet för att skapa anpassade mätvärden och visualiseringar i CloudWatch Dashboards för att övervaka prestandan för din webbapplikation och felsöka eventuella problem.
Ett annat exempel, denna gång med fokus på Amazon S3-tjänstmeddelanden:
fields @timestamp, @message | filter @message like /REST.API.REQUEST/ | parse @message /.*"(?<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
- Denna fråga väljer logghändelser som innehåller strängen ”REST.API.REQUEST”.
- Sedan analyseras loggmeddelandet för att extrahera HTTP-metoden, sökvägen, statuskoden och svarstiden.
- Den beräknar den genomsnittliga svarstiden och antalet logghändelser för varje kombination av HTTP-metod, sökväg och statuskod och sorterar resultaten efter antal i fallande ordning.
- Resultatet begränsas till de 20 mest förekommande träffarna.
Utdatan från den här frågan kan användas för att skapa ett linjediagram i en CloudWatch Dashboard, som visar den genomsnittliga svarstiden för varje kombination av HTTP-metod, sökväg och statuskod över tid.
Skapa instrumentpanelen
För att lägga in mätvärden och visualiseringar i CloudWatch Dashboards från CloudWatch Insights-loggfrågor, navigerar du till CloudWatch-konsolen och följer guiden för att skapa din instrumentpanel.
Här är ett exempel på kod som visar hur en CloudWatch Dashboard kan se ut med mätvärden från CloudWatch Insights Query-data:
{
"widgets": [
{
"type": "metric",
"x": 0,
"y": 0,
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/EC2",
"CPUUtilization",
"InstanceId",
"i-0123456789abcdef0",
{
"label": "CPU Utilization",
"stat": "Average",
"period": 300
}
]
],
"view": "timeSeries",
"stacked": false,
"region": "us-east-1",
"title": "EC2 CPU Utilization"
}
},
{
"type": "log",
"x": 0,
"y": 6,
"width": 12,
"height": 6,
"properties": {
"query": "fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
",
"region": "us-east-1",
"title": "Application Errors"
}
}
]
}
Denna CloudWatch Dashboard innehåller två widgetar:
- En metrisk widget som visar den genomsnittliga CPU-användningen för en EC2-instans över tid. CloudWatch Insights Query används för att fylla widgeten. Den väljer CPU-användningsdata för en specifik EC2-instans och aggregerar den i 5-minutersintervall.
- En loggwidget som visar antalet applikationsfel över tid. Den väljer logghändelser som innehåller strängen ”ERROR” och aggregerar dem per timme.
Detta är en JSON-formaterad fil som definierar instrumentpanelen och innehåller mätvärden. Den inkluderar även (som en egenskap) själva insiktsfrågan.
Du kan använda koden och distribuera den till valfritt AWS-konto. Förutsatt att tjänsterna och loggmeddelandena är enhetliga över alla dina AWS-konton och steg, kommer instrumentpanelen att fungera på samtliga konton utan att behöva ändra källkoden för instrumentpanelen.
Slutord
Att skapa en stabil loggningsstruktur är en värdefull investering i systemets framtida tillförlitlighet, vilket nu kan tjäna ett ännu större syfte. Du kan ha praktiska instrumentpaneler med mätvärden och visualiseringar som en direkt följd av loggningen.
Utvecklingsteam, testteam och produktionsanvändare kan alla dra nytta av samma lösning, eftersom den endast behöver implementeras en gång, med en mindre extra ansträngning.
Kolla även in de bästa AWS-övervakningsverktygen.