Varje AWS-tjänst loggar sin bearbetning till filer organiserade under CloudWatch-logggrupper. Logggrupperna är vanligtvis döpta efter själva tjänsten för enklare identifiering. Tjänstens systemmeddelanden eller allmän statusinformation skrivs in i dessa loggfiler som standard.
Du kan dock lägga till anpassad loggmeddelandeinformation utöver standardinformationen. Om sådana loggar skapas på ett klokt sätt, kan de tjäna till att skapa användbara CloudWatch-instrumentpaneler.
Med mått och strukturerad information som ger extra detaljer om jobbhantering. De kan inte bara innehålla standardwidgets med systemliknande information om tjänsten. Du kan utöka detta med ditt eget innehåll, samlat i din anpassade widget eller statistik.
Innehållsförteckning
Fråga loggfilerna
Källa: aws.amazon.com
AWS CloudWatch Log Insights låter dig söka och analysera loggdata från dina AWS-resurser i realtid. Du kan se det som en databasvy. Du definierar frågan på instrumentpanelen, och instrumentpanelen kommer att välja den när du besöker den eller vid det angivna tidsfönstret tidigare, som du definierar det i instrumentpanelsvyn.
Den använder ett frågespråk som heter CloudWatch Logs Insights för att söka och analysera loggdata. Frågespråket är baserat på en delmängd av SQL-språket. Det låter dig söka och filtrera loggdata. Du kan söka efter specifika logghändelser, anpassad loggtext eller nyckelord och filtrera loggdata baserat på specifika fält. Och viktigast av allt, samla loggdata i en eller flera loggfiler för att generera sammanfattade mätvärden och visualiseringar.
När du kör en fråga söker CloudWatch Log Insights igenom loggdata i logggruppen. Sedan returnerar den texterna från filerna som matchar dina sökkriterier.
Exempel på loggfilsfråga
Låt oss ta en titt på några grundläggande frågor för att förstå konceptet.
Varje tjänst loggar som standard några avgörande tjänstefel. Även om du inte skapar en dedikerad anpassad logg för sådana felhändelser. Sedan 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)
Eller så här övervakar du den genomsnittliga svarstiden för ditt API under den senaste dagen:
fields @timestamp, @message | filter @message like /API response time/ | stats avg(response_time) by bin(1d)
Eftersom CPU-användningen som standard är information som loggas av tjänsten i CloudWatch, kan du också samla in den här typen av mätvärde:
fields @timestamp, @message | filter @message like /CPUUtilization/ | stats avg(value) by bin(1h)
Dessa frågor kan anpassas för att passa ditt specifika användningsfall och kan användas för att skapa anpassade mätvärden och visualiseringar i CloudWatch Dashboards. Hur man gör det är att placera widgeten på instrumentpanelen och placera koden inuti widgeten för att definiera vad som ska väljas.
Här är några av widgetarna som kan användas i CloudWatch Dashboards och fyllas med innehåll från Log Insights:
- Textwidgetar – Visa textbaserad information, till exempel resultatet av en CloudWatch Insights-fråga.
- Loggfrågewidgetar – Visa resultaten av en CloudWatch Insights-loggfråga, till exempel antalet fel i dina programloggar.
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 bästa praxis när du skapar CloudWatch-loggar för var och en av de tjänster du använder i ditt system. Här är några tips:
#1. Använd strukturerad loggning
Du ska hålla dig till ett loggningsformat som använder ett fördefinierat schema för att logga data i ett strukturerat format. Detta gör det enklare att söka och filtrera loggdata med hjälp av CloudWatch Insights-frågor.
Detta innebär i princip att standardisera dina loggar över olika tjänster i din arkitekturplattform. Att ha det definierat i utvecklingsstandarder hjälper enormt.
Till exempel kan du definiera att varje problem relaterat till en specifik databastabell kommer att loggas med ett startmeddelande som: ”[TABLE_NAME] Varning / Fel:
Eller så kan du separera fullständiga datajobb från deltadatajobb med prefix som ”[FULL/DELTA]” för att endast välja meddelanden relaterade till de konkreta dataprocesserna.
Du kan definiera att när du bearbetar data från ett specifikt källsystem kommer namnet på systemet att vara ett prefix för varje relaterad loggpost. Det är mycket lättare efteråt att filtrera sådana meddelanden från loggfilerna och bygga mätvärden över dem.
Källa: aws.amazon.com
#2. Använd konsekventa loggformat
Använd konsekventa loggformat över alla dina AWS-resurser för att göra det enklare att söka och filtrera loggdata med CloudWatch Insights-frågor.
Detta är ganska relaterat till föregående punkt, men faktum är ju mer standardiserat loggformatet är, desto lättare är det att använda loggdata. Utvecklare kan sedan lita på det formatet och använda det till och med intuitivt.
Det grymma faktum är att de flesta av projekten inte stör sig på några standarder kring loggning. Dessutom skapar många projekt inte ens några anpassade loggar alls. Det är chockerande men också så vanligt på samma gång.
Jag kan inte ens säga hur många gånger jag kom på mig själv att undra hur människor kan bo här utan något felhanteringssätt. Och om någon ansträngde sig för att göra någon form av felhantering som ett undantag, så gjorde de det fel.
Så ett konsekvent loggformat är en stark tillgång. Det är inte många som har dem.
#3. Inkludera relevant metadata
Inkludera metadata i din loggdata, såsom tidsstämplar, resurs-ID och felkoder, för att göra det enklare att söka och filtrera loggdata med CloudWatch Insights-frågor.
#4. Aktivera loggrotation
Aktivera loggrotation för att förhindra att din loggdata blir för stor och för att göra det enklare att söka och filtrera loggdata med CloudWatch Insights-frågor.
Att inte ha några loggdata är en sak, men att ha för många av dem utan struktur är likaså desperat. 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 inte kan hjälpa dig själv och bara vägrar att bygga ditt anpassade loggsystem, använd åtminstone CloudWatch Logs-agenter. De skickar automatiskt loggdata från dina AWS-resurser till CloudWatch-loggar. Detta gör det enklare att söka och filtrera loggdata med hjälp av CloudWatch Insights-frågor.
Mer komplexa insikter frågeexempel
CloudWatch Insights-förfrågan kan vara mer komplicerad än bara två 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:
Den här frågan 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 resultaten 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 problem.
Ett annat exempel på att fråga efter 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
- Frågan väljer logghändelser som innehåller strängen ”REST.API.REQUEST”.
- Analyserar sedan 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.
- Begränsar resultatet till de 20 bästa resultaten.
Du kan använda utdata från den här frågan 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.
Bygga instrumentpanelen
För att fylla i mätvärden och visualiseringar i CloudWatch Dashboards från utdata från CloudWatch Insights loggfrågor kan du navigera till CloudWatch-konsolen och följa Dashboard-guiden för att bygga upp ditt innehåll.
Efter det är det så här koden för en CloudWatch Dashboard ser ut och innehåller mätvärden fyllda av 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å widgets:
Det är en fil i JSON-format med en definition av instrumentpanelen och mätvärden inuti. Den innehåller (som en egenskap) även själva insiktsfrågan.
Du kan ta koden och distribuera den till vilket AWS-konto du än behöver. Förutsatt att tjänsterna och loggmeddelandena är konsekventa över alla dina AWS-konton och steg, kommer instrumentpanelen att fungera på alla konton utan att behöva ändra källkoden för instrumentpanelen.
Slutord
Att bygga upp en solid loggningsstruktur var alltid en bra investering i framtiden för systemets tillförlitlighet. Nu kan det tjäna ett ännu större syfte. Du kan ha användbara instrumentpaneler med mätvärden och visualiseringar bara som en bieffekt av det.
Utvecklingsteamet, testteamet och produktionsanvändarna kan dra nytta av samma lösning eftersom det bara måste göras en gång, med bara lite extra arbete.
Kolla sedan in de bästa AWS-övervakningsverktygen.