PricingLoginStart free
DevOps-bootcamp · Lektion

Följ loggar i realtid och skapa strömmande aviseringar

Följ och filtrera live-loggströmmar för att utlösa aviseringar så snart felmönster uppstår.

Lektion 2 av 413 steg

Följ loggar i realtid och skapa strömmande aviseringar är en gratis lektion i DevOps-bootcamp på CoddyKit. Detta är lektion 2 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för DevOps-bootcamp, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i DevOps-bootcamp innehåller totalt 4 lektioner.

Varför övervakning av loggar i realtid är viktigt

I produktionssystem växer loggfiler kontinuerligt. Om Ni väntar tills ett problem rapporteras innan Ni granskar loggarna har driftstoppet redan kostat Er. Övervakning av loggar i realtid låter Er se händelser utvecklas i samma ögonblick som de skrivs, vilket möjliggör omedelbara åtgärder vid fel, säkerhetshändelser och försämrad prestanda.

  • Webbservrar skriver en rad per begäran — fel visas omedelbart
  • Applikationsdemoner loggar stack traces i samma ögonblick som ett undantag uppstår
  • Autentiseringssystem registrerar misslyckade inloggningsförsök i realtid

Det grundläggande Unix-verktyget för detta är tail -f, i kombination med filtrerings- och notifieringsverktyg som omvandlar råa loggströmmar till användbara signaler.

tail -f: Följ en logg i realtid

tail -f (följ) håller filen öppen och skriver ut nya rader när de läggs till. Det är det enklaste och mest allmänt tillgängliga verktyget för loggövervakning i realtid.

Vanliga användningsmönster:

  • tail -f /var/log/syslog — följ systemloggen
  • tail -n 50 -f app.log — visa de senaste 50 raderna och följ sedan filen
  • tail -f /var/log/nginx/access.log — följ Nginx-begäranden i realtid

Tryck på Ctrl+C för att stoppa. Processen fortsätter att vara aktiv tills Ni avbryter den eller terminalen stängs.

#!/usr/bin/env bash
# Simulate a live log and follow it
LOGFILE='/tmp/demo_app.log'

# Write a header
echo '[INFO] Application started' >> "$LOGFILE"

# In a real scenario you would run:
# tail -f "$LOGFILE"
# Below we demonstrate tail showing the last 3 lines then exit
tail -n 3 "$LOGFILE"

tail -F: Klara av loggrotation

Många system roterar loggfiler vid midnatt eller när de når en storleksgräns. När det händer byter den ursprungliga filen namn (till exempel app.log.1) och en ny app.log skapas. Med tail -f fortsätter Ni i tysthet att läsa den gamla filen med det nya namnet och missar all ny output.

tail -F (versalt F) löser detta genom att bevaka filnamnet, inte filbeskrivningen. När filen försvinner och dyker upp igen öppnar tail -F automatiskt filen på nytt och fortsätter att följa den.

  • Föredra alltid tail -F framför tail -f i produktionsskript
  • Fungerar med logrotate, newsyslog och Docker-loggdrivrutiner som roterar filer
# Follow nginx access log, surviving log rotation
tail -F /var/log/nginx/access.log

# Follow multiple files simultaneously
tail -F /var/log/nginx/access.log /var/log/nginx/error.log

Filtrera strömmen med grep

Att följa en aktiv logg utan filtrering blir snabbt överväldigande — en aktiv webbserver kan skriva hundratals rader per sekund. Skicka utdata från tail -F vidare till grep för att isolera endast de mönster Ni är intresserade av.

Viktiga flaggor för grep i strömmande läge:

  • --line-buffered — töm bufferten efter varje matchad rad i stället för att buffra; krävs i pipelines, annars fördröjs eller går utdata förlorad
  • -i — matchning som inte skiljer på stora och små bokstäver
  • -E — utökade reguljära uttryck för alternativ (error|warn|crit)
  • -v — invertera matchningen (uteslut rader)
# Show only ERROR and WARN lines from a live application log
tail -F /var/log/myapp/app.log | grep --line-buffered -Ei 'error|warn|critical'

# Follow nginx and exclude health-check requests
tail -F /var/log/nginx/access.log | grep --line-buffered -v '/health'

Lägg till tidsstämplar och kontext med awk

Loggrader saknar ibland kontext som underlättar felsökningen. Ni kan berika strömmen i realtid med awk — lägga till en lokal tidsstämpel, extrahera fält eller formatera om utdata så att den blir lättare att läsa.

awk körs också i strömmande läge (radbuffrat) när det används i en pipe, vilket gör det säkert att använda i aktiva pipelines utan extra flaggor.

# Prepend a reception timestamp to every ERROR line
tail -F /var/log/myapp/app.log | \
  grep --line-buffered -i 'error' | \
  awk '{ print strftime("[%Y-%m-%d %H:%M:%S]"), $0; fflush() }'

# Extract HTTP status code (field 9) and URL (field 7) from nginx combined log
tail -F /var/log/nginx/access.log | \
  awk '{ print $9, $7; fflush() }' | \
  grep --line-buffered '^5'

Skicka notifieringar med Slack-webhooks

Filtrering är bara halva arbetet — när Ni upptäcker ett felmönster behöver Ni meddela någon. Med en inkommande Slack-webhook kan Ni skicka ett POST-meddelande till en kanal med ett enda anrop till curl, utan Slack SDK eller andra autentiseringsuppgifter än webhook-URL:en.

Mönstret är: filtrera strömmen och skicka en HTTP POST för varje matchande rad.

#!/usr/bin/env bash
# Real-time alert: send every ERROR line to a Slack channel
LOGFILE='/var/log/myapp/app.log'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  payload=$(printf '{"text":"*[ERROR ALERT]*\n%s"}' "$line")
  curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
    -d "$payload" "$WEBHOOK_URL"
done

Begränsa notifieringsfrekvensen för att undvika brus

En loggstorm kan generera tusentals felrader per minut. Om Ni skickar ett Slack-meddelande per rad översvämmas kanalen och notifieringströtthet uppstår. Ni behöver frekvensbegränsning — utlös notifieringen och undertryck sedan ytterligare notifieringar under en nedkylningsperiod.

Detta åstadkoms med en enkel tidsstämpelfil: registrera när den senaste notifieringen skickades och avstå från att utlösa en ny om nedkylningsperioden inte har löpt ut.

#!/usr/bin/env bash
# Alert on ERROR lines but no more than once every 60 seconds
LOGFILE='/var/log/myapp/app.log'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'
COOLDOWN=60
LAST_ALERT_FILE='/tmp/last_alert_ts'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  now=$(date +%s)
  last=0
  [ -f "$LAST_ALERT_FILE" ] && last=$(cat "$LAST_ALERT_FILE")

  if (( now - last >= COOLDOWN )); then
    echo "$now" > "$LAST_ALERT_FILE"
    payload=$(printf '{"text":"*[ERROR ALERT]*\n%s"}' "$line")
    curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
      -d "$payload" "$WEBHOOK_URL"
    echo "[$(date)] Alert sent: $line"
  else
    echo "[$(date)] Suppressed (cooldown): $line"
  fi
done

Räkna felutbrott med ett glidande fönster

Ibland är en enskild felrad inte betydelsefull — men 20 fel på 30 sekunder är ett allvarligt problem. En räknare med glidande fönster låter Er utlösa notifieringar endast när en tröskel för felfrekvensen överskrids, vilket minskar antalet falska positiva.

Tekniken lagrar varje matchande händelses epoch-tidsstämpel i en temporär fil och räknar sedan hur många som faller inom fönstret innan den avgör om en notifiering ska skickas.

#!/usr/bin/env bash
# Alert when more than 10 errors occur within any 60-second window
LOGFILE='/var/log/myapp/app.log'
WINDOW=60
THRESHOLD=10
TS_FILE='/tmp/error_timestamps'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  now=$(date +%s)
  echo "$now" >> "$TS_FILE"

  # Keep only timestamps within the window
  cutoff=$(( now - WINDOW ))
  tmp=$(mktemp)
  awk -v c="$cutoff" '$1 > c' "$TS_FILE" > "$tmp" && mv "$tmp" "$TS_FILE"

  count=$(wc -l < "$TS_FILE")
  if (( count > THRESHOLD )); then
    msg="*[BURST ALERT]* ${count} errors in ${WINDOW}s — last: ${line}"
    curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
      -d "{\"text\":\"$msg\"}" "$WEBHOOK_URL"
    # Clear to avoid re-alerting until next burst
    > "$TS_FILE"
  fi
done

journalctl -f: Följ systemd-journaler

I moderna Linux-system (RHEL, Ubuntu 20.04+, Debian 10+) skriver tjänster till systemd-journalen i stället för till vanliga textfiler. journalctl -f är journalens motsvarighet till tail -F.

Användbara flaggor:

  • -u myapp.service — följ endast en specifik enhet
  • -p err — filtrera efter prioritet (emerg, alert, crit, err, warning, notice, info, debug)
  • --since '5 min ago' — börja från en relativ tidpunkt
  • -o json — skriv ut strukturerad JSON för maskinell tolkning
# Follow only error-and-above entries for nginx
journalctl -f -u nginx.service -p err

# Stream journal as JSON and extract MESSAGE field with jq
journalctl -f -u myapp.service -o json | \
  jq --unbuffered -r 'select(.PRIORITY <= "3") | .MESSAGE'

multitail och färgkodad övervakning av flera källor

När Ni behöver övervaka flera loggkällor samtidigt delar multitail upp terminalen i paneler — varje panel följer en annan fil eller ett annat kommando — med valfri färgkodning efter mönster.

Om multitail inte är installerat är ett lättviktigt alternativ i ren Bash att förse varje ström med källans namn och slå ihop dem till en enda vy.

# multitail: watch nginx access + error + app log in split panes
# (requires: apt install multitail  or  brew install multitail)
multitail /var/log/nginx/access.log /var/log/nginx/error.log /var/log/myapp/app.log

# Pure-Bash alternative — merge three streams with labeled prefixes
(
  tail -F /var/log/nginx/access.log | sed --unbuffered 's/^/[nginx-access] /' &
  tail -F /var/log/nginx/error.log  | sed --unbuffered 's/^/[nginx-error]  /' &
  tail -F /var/log/myapp/app.log    | sed --unbuffered 's/^/[myapp]        /' &
  wait
)

Bygg en fristående notifieringsdemon

En notifieringsdemon av produktionskvalitet bör samla allt från den här lektionen och:

  • följa loggfilen robust med tail -F
  • filtrera efter kritiska mönster med buffrad grep
  • begränsa notifieringsfrekvensen för att undvika notifieringströtthet
  • logga sin egen aktivitet så att Ni kan granska vad som skickades
  • köras som en bakgrundsprocess som hanteras av systemd eller en supervisor

Skriptet nedan är en minimalt men komplett demon som Ni kan placera i /usr/local/bin/ och hantera med systemd.

#!/usr/bin/env bash
# log_alert_daemon.sh — tail a log and fire Slack alerts with cooldown
set -euo pipefail

LOGFILE=${1:-'/var/log/myapp/app.log'}
PATTERN=${2:-'error|critical|fatal'}
WEBHOOK_URL=${SLACK_WEBHOOK_URL:?'Set SLACK_WEBHOOK_URL env var'}
COOLDOWN=${ALERT_COOLDOWN:-120}
DAEMON_LOG='/var/log/log_alert_daemon.log'
LAST_SENT_FILE='/tmp/log_alert_last_sent'

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$DAEMON_LOG"; }

log "Starting alert daemon: watching $LOGFILE for pattern: $PATTERN"

tail -F "$LOGFILE" | grep --line-buffered -Ei "$PATTERN" | while IFS= read -r line; do
  now=$(date +%s)
  last=0
  [ -f "$LAST_SENT_FILE" ] && last=$(cat "$LAST_SENT_FILE")

  if (( now - last >= COOLDOWN )); then
    echo "$now" > "$LAST_SENT_FILE"
    msg=$(printf '{"text":"*[ALERT]* %s\n%s"}' "$(hostname)" "$line")
    if curl -s -o /dev/null -w '%{http_code}' -X POST \
         -H 'Content-Type: application/json' -d "$msg" "$WEBHOOK_URL" | grep -q '^200$'; then
      log "Alert sent: $line"
    else
      log "Alert FAILED to send: $line"
    fi
  else
    log "Suppressed (cooldown ${COOLDOWN}s): $line"
  fi
done

Kunskapskontroll: Strömmande loggpipelines

Testa Er förståelse av loggövervakning i realtid och strömmande notifieringar.

En Bash-pipeline följer en loggfil och skickar en Slack-notifiering för varje matchande rad. Under en loggstorm skrivs 3 000 felrader på 10 sekunder. Vilken enskild ändring förhindrar bäst att skriptet översvämmar Slack-kanalen med 3 000 meddelanden?

Besvara frågan i den interaktiva lektionen

Lektionssammanfattning: Loggövervakning i realtid och strömmande notifieringar

I den här lektionen har Ni byggt en komplett pipeline för loggobservabilitet i realtid från grunden:

  • tail -F följer en loggfil via filnamnet och klarar loggrotation — föredra alltid detta framför tail -f i produktion
  • grep --line-buffered filtrerar den aktiva strömmen utan att införa fördröjning; lägg alltid till denna flagga i grep-kommandon som används i en pipe
  • awk med fflush() berikar varje rad med tidsstämplar eller extraherade fält på ett sätt som är säkert i strömmande läge
  • Slack-webhooks via curl levererar notifieringar med en enda HTTP POST — ingen SDK krävs
  • Nedkylningsfiler förhindrar notifieringströtthet under loggstormar genom att upprätthålla ett minimiintervall mellan notifieringar
  • Räknare med glidande fönster upptäcker felutbrott (frekvensbaserad notifiering) i stället för att reagera på varje enskild rad
  • journalctl -f är systemd:s inbyggda motsvarighet till tail -F, med inbyggd prioritetsfiltrering och JSON-utdata
  • Ett fristående notifieringsdemon-skript kombinerar alla dessa mönster och kan hanteras av systemd för tillförlitlighet i produktion

Dessa grundkomponenter kan kombineras till grunden för valfri anpassad pipeline för observabilitet — ingen tredjepartsagent krävs.

Gratis att börja

Lär dig DevOps-bootcamp med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
142
Lektioner
568
Börja lära dig gratisVisa hela kursen

Vanliga frågor

Är lektionen ”Följ loggar i realtid och skapa strömmande aviseringar” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen DevOps-bootcamp, inklusive ”Följ loggar i realtid och skapa strömmande aviseringar”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i DevOps-bootcamp innehåller totalt 4 lektioner.

Vad lär jag mig i ”Följ loggar i realtid och skapa strömmande aviseringar”?

Följ och filtrera live-loggströmmar för att utlösa aviseringar så snart felmönster uppstår. Ni övar på DevOps-bootcamp med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig DevOps-bootcamp?

Du behöver inga förkunskaper. Utbildningen i DevOps-bootcamp på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Följ loggar i realtid och skapa strömmande aviseringar”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här DevOps-bootcamp-lektionen?

Ja. Varje DevOps-bootcamp-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Analysera webb- och applikationsloggar i stor skala
  2. Följ loggar i realtid och skapa strömmande aviseringar
  3. Fråga journald med journalctl i skript
  4. Beräkna mätvärden och histogram från loggströmmar
← Tillbaka till DevOps-bootcamp