Hver AWS-tjeneste logger behandlingen til filer organisert under CloudWatch-logggrupper. Logggruppene er vanligvis oppkalt etter selve tjenesten for enklere identifikasjon. Tjenestens systemmeldinger eller felles tilstandsinformasjon skrives inn i disse loggfilene som standard.
Du kan imidlertid legge til tilpasset loggmeldingsinformasjon på toppen av standardmeldingene. Hvis slike logger opprettes på en fornuftig måte, kan de tjene til å lage nyttige CloudWatch-dashbord.
Med beregninger og strukturert informasjon som gir ekstra detaljer om jobbbehandling. Ikke bare kan de inneholde standard widgets med systemlignende informasjon om tjenesten. Du kan utvide dette med ditt eget innhold, samlet i din egendefinerte widget eller beregning.
Innholdsfortegnelse
Spør loggfilene
Kilde: aws.amazon.com
AWS CloudWatch Log Insights lar deg søke og analysere loggdata fra AWS-ressursene dine i sanntid. Du kan se på det som en databasevisning. Du definerer søket på dashbordet, og dashbordet vil velge det når du besøker det eller ved det angitte tidsvinduet tidligere, slik du definerer det i dashbordvisningen.
Den bruker et spørringsspråk kalt CloudWatch Logs Insights for å søke og analysere loggdata. Spørringsspråket er basert på en undergruppe av SQL-språket. Den lar deg søke og filtrere loggdata. Du kan søke etter spesifikke logghendelser, tilpasset loggtekst eller nøkkelord, og filtrere loggdata basert på spesifikke felt. Og viktigst av alt, samle loggdata i én eller flere loggfiler for å generere oppsummerte beregninger og visualiseringer.
Når du kjører en spørring, søker CloudWatch Log Insights gjennom loggdataene i logggruppen. Deretter returnerer den tekstene fra filene som samsvarer med søkekriteriene dine.
Eksempel på loggfilspørring
La oss ta en titt på noen grunnleggende spørsmål for å forstå konseptet.
Hver tjeneste logger som standard noen viktige tjenestefeil. Selv om du ikke oppretter en dedikert tilpasset logg for slike feilhendelser. Med et enkelt spørsmål kan du telle antall feil i applikasjonsloggene dine i løpet av den siste timen:
fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(1h)
Eller her er hvordan du overvåker den gjennomsnittlige responstiden til API-en din den siste dagen:
fields @timestamp, @message | filter @message like /API response time/ | stats avg(response_time) by bin(1d)
Siden CPU-bruken som standard er informasjon som er logget av tjenesten i CloudWatch, kan du også samle denne typen beregninger:
fields @timestamp, @message | filter @message like /CPUUtilization/ | stats avg(value) by bin(1h)
Disse spørringene kan tilpasses for å passe til din spesifikke brukssituasjon og kan brukes til å lage tilpassede beregninger og visualiseringer i CloudWatch Dashboards. Måten du gjør det på er å plassere widgeten på dashbordet og plassere koden inne i widgeten for å definere hva du skal velge.
Her er noen av widgetene som kan brukes i CloudWatch Dashboards og fylles med innhold fra Log Insights:
- Tekstwidgeter – Vis tekstbasert informasjon, for eksempel utdata fra en CloudWatch Insights-spørring.
- Loggspørringswidgeter – Vis resultatene av en CloudWatch Insights-loggspørring, for eksempel antall feil i applikasjonsloggene dine.
Hvordan lage nyttig logginformasjon for Dashboard
Kilde: aws.amazon.com
For å effektivt bruke CloudWatch Insights-spørringer i CloudWatch Dashboards, er det greit å følge noen beste fremgangsmåter når du oppretter CloudWatch-logger for hver av tjenestene du bruker i systemet ditt. Her er noen tips:
#1. Bruk strukturert logging
Du skal holde deg til et loggingsformat som bruker et forhåndsdefinert skjema for å logge data i et strukturert format. Dette gjør det enklere å søke og filtrere loggdata ved hjelp av CloudWatch Insights-spørringer.
Dette betyr i utgangspunktet å standardisere loggene dine på tvers av forskjellige tjenester i arkitekturplattformen din. Å ha det definert i utviklingsstandarder hjelper enormt.
For eksempel kan du definere at hvert problem relatert til en bestemt databasetabell vil bli logget med startmelding som: «[TABLE_NAME] Advarsel / Feil:
Eller du kan skille fulldatajobber fra deltadatajobber med prefikser som «[FULL/DELTA]” for kun å velge meldinger relatert til de konkrete dataprosessene.
Du kan definere at når du behandler data fra et spesifikt kildesystem, vil navnet på systemet være et prefiks for hver relatert loggoppføring. Det er mye lettere etterpå å filtrere slike meldinger fra loggfilene og bygge beregninger over dem.
Kilde: aws.amazon.com
#2. Bruk konsistente loggformater
Bruk konsistente loggformater på tvers av alle AWS-ressursene dine for å gjøre det enklere å søke og filtrere loggdata ved hjelp av CloudWatch Insights-spørringer.
Dette er ganske relatert til det forrige punktet, men faktum er at jo mer standardisert loggformatet er, desto lettere er det å bruke loggdataene. Utviklere kan da stole på det formatet og bruke det til og med intuitivt.
Det grusomme faktum er at de fleste prosjektene ikke bryr seg med noen standarder rundt logging. Dessuten oppretter mange prosjekter ikke engang noen tilpassede logger i det hele tatt. Det er sjokkerende, men også så vanlig på samme tid.
Jeg kan ikke engang fortelle hvor mange ganger jeg lurte på hvordan folk kan bo her uten noen tilnærming til feilhåndtering. Og hvis noen gjorde en innsats for å gjøre en slags feilhåndtering som unntak, gjorde de det feil.
Så et konsistent loggformat er en sterk ressurs. Det er ikke mange som har dem.
#3. Inkluder relevante metadata
Inkluder metadata i loggdataene dine, for eksempel tidsstempler, ressurs-IDer og feilkoder, for å gjøre det enklere å søke og filtrere loggdata ved hjelp av CloudWatch Insights-spørringer.
#4. Aktiver loggrotasjon
Aktiver loggrotasjon for å forhindre at loggdataene dine blir for store og for å gjøre det enklere å søke og filtrere loggdata ved hjelp av CloudWatch Insights-spørringer.
Å ikke ha noen loggdata er én ting, men å ha for mange av dem uten struktur er like desperat. Hvis du ikke kan bruke dataene dine, er det som å ikke ha data i det hele tatt.
#5. Bruk CloudWatch Logs Agents
Hvis du ikke kan hjelpe deg selv og bare nekter å bygge ditt tilpassede loggsystem, så bruk i det minste CloudWatch Logs-agenter. De sender automatisk loggdata fra AWS-ressursene dine til CloudWatch-logger. Dette gjør det enklere å søke og filtrere loggdata ved hjelp av CloudWatch Insights-spørringer.
Eksempler på mer komplekse innsikter
CloudWatch Insights-spørring kan være mer komplisert enn bare to linjers uttalelse.
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
Denne spørringen gjør følgende:
Denne spørringen identifiserer de vanligste feilene i applikasjonen din og sporer gjennomsnittlig responstid for hver kombinasjon av HTTP-metode, bane og statuskode. Du kan bruke resultatene til å lage egendefinerte beregninger og visualiseringer i CloudWatch Dashboards for å overvåke ytelsen til nettapplikasjonen din og feilsøke problemer.
Et annet eksempel på å spørre etter Amazon S3-tjenestemeldinger:
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
- Spørringen velger logghendelser som inneholder strengen «REST.API.REQUEST».
- Deretter analyserer loggmeldingen for å trekke ut HTTP-metoden, banen, statuskoden og responstiden.
- Den beregner gjennomsnittlig responstid og antall logghendelser for hver kombinasjon av HTTP-metode, bane og statuskode og sorterer resultatene etter antall i synkende rekkefølge.
- Begrenser produksjonen til de 20 beste resultatene.
Du kan bruke utdataene fra denne spørringen til å lage en linjegraf i et CloudWatch Dashboard som viser gjennomsnittlig responstid for hver kombinasjon av HTTP-metode, bane og statuskode over tid.
Bygge dashbordet
For å fylle ut beregningene og visualiseringene i CloudWatch Dashboards fra utdataene fra CloudWatch Insights loggforespørsler, kan du navigere til CloudWatch-konsollen og følge Dashboard-veiviseren for å bygge opp innholdet ditt.
Etter det er dette hvordan koden til et CloudWatch Dashboard ser ut og inneholder beregninger fylt 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"
}
}
]
}
Dette CloudWatch-dashbordet inneholder to widgets:
Det er en fil i JSON-format med en definisjon av dashbordet og beregninger inni. Den inneholder (som en egenskap) også selve innsiktsspørringen.
Du kan ta koden og distribuere den til den AWS-kontoen du trenger. Forutsatt at tjenestene og loggmeldingene er konsistente over alle dine AWS-kontoer og stadier, vil dashbordet fungere på alle kontoene uten behov for å endre kildekoden til dashbordet.
Siste ord
Å bygge opp en solid loggstruktur var alltid en god investering i fremtiden for systemets pålitelighet. Nå kan det tjene et enda større formål. Du kan ha nyttige dashbord med beregninger og visualiseringer bare som en bieffekt av det.
Med en nødvendighet som bare må gjøres én gang, med bare litt ekstra arbeid, kan utviklingsteamet, testteamet og produksjonsbrukerne alle dra nytte av den samme løsningen.
Deretter kan du sjekke ut de beste AWS-overvåkingsverktøyene.