PricingLoginStart free
DevOps-bootcamp · leksjon

Sanntidsfølging av logger og strømmende varsler

Følg og filtrer aktive loggstrømmer for å utløse varsler idet feilmønstre oppstår.

Leksjon 2 av 413 trinn

Sanntidsfølging av logger og strømmende varsler er en gratis leksjon i DevOps-bootcamp på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i DevOps-bootcamp, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i DevOps-bootcamp inneholder totalt 4 leksjoner.

Hvorfor det er viktig å følge logger i sanntid

I produksjonssystemer vokser loggfiler kontinuerlig. Hvis De venter med å undersøke loggene til noen rapporterer et problem, har nedetiden allerede kostet Dem. Å følge logger i sanntid lar Dem se hendelsene utfolde seg idet de skrives, slik at De kan reagere umiddelbart på feil, sikkerhetshendelser og redusert ytelse.

  • Webservere skriver én linje per forespørsel — feil vises umiddelbart
  • Applikasjonsdemoner logger stack traces idet et unntak oppstår
  • Autentiseringssystemer registrerer mislykkede påloggingsforsøk i sanntid

Det grunnleggende Unix-verktøyet for dette er tail -f, kombinert med filtrerings- og varslingsverktøy som gjør rå loggstrømmer om til handlingsrelevante signaler.

tail -f: Følge en logg i sanntid

tail -f (follow) holder filen åpen og skriver ut nye linjer etter hvert som de legges til. Det er det enkleste og mest tilgjengelige verktøyet for sanntidslogging.

Vanlige bruksmønstre:

  • tail -f /var/log/syslog — følg systemloggen
  • tail -n 50 -f app.log — vis de siste 50 linjene og følg deretter
  • tail -f /var/log/nginx/access.log — følg Nginx-forespørsler i sanntid

Trykk Ctrl+C for å stoppe. Prosessen forblir tilkoblet til De avbryter den eller terminalen lukkes.

#!/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: Overleve loggrotasjon

Mange systemer roterer loggfiler ved midnatt eller når de når en størrelsesgrense. Når det skjer, får den opprinnelige filen et nytt navn (for eksempel app.log.1), og en ny app.log opprettes. Med tail -f fortsetter De å lese den gamle, omdøpte filen uten å merke det, og går glipp av all ny utdata.

tail -F (stor F) løser dette ved å følge filnavnet, ikke fildeskriptoren. Når filen forsvinner og dukker opp igjen, åpner tail -F den automatisk på nytt og fortsetter å følge den.

  • Foretrekk alltid tail -F fremfor tail -f i produksjonsskript
  • Fungerer med logrotate, newsyslog og Docker-loggdrivere som roterer 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

Filtrere strømmen med grep

Det er overveldende å følge en travel logg ufiltrert — en aktiv webserver kan skrive hundrevis av linjer i sekundet. Send utdataene fra tail -F gjennom grep for å isolere bare mønstrene De er interessert i.

Viktige flagg for grep i strømmer:

  • --line-buffered — tøm bufferen etter hver treffende linje i stedet for å mellomlagre den; påkrevd i pipelines, ellers kan utdata bli forsinket eller gå tapt
  • -i — ikke-sensitivt for store og små bokstaver
  • -E — utvidet regex for alternativer (error|warn|crit)
  • -v — inverter treffet (utelat linjer)
# 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'

Legge til tidsstempler og kontekst med awk

Logglinjer mangler noen ganger kontekst som gjør feilsøking enklere. De kan berike strømmen i sanntid ved hjelp av awk — for eksempel ved å legge til et lokalt tidsstempel, hente ut felt eller formatere utdataene slik at de blir enklere å lese.

awk kjører også i strømmemodus (linjebufret) når utdata sendes gjennom en pipe, slik at det kan brukes trygt i aktive pipelines uten ekstra flagg.

# 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'

Sende varsler med Slack-webhooks

Filtrering er bare halve jobben — når De oppdager et feilmønster, må De varsle noen. En innkommende Slack-webhook lar Dem sende en melding til en kanal med ett enkelt curl-kall, uten behov for Slack SDK eller annen legitimasjon enn webhook-URL-en.

Mønsteret er: filtrer strømmen, og send en HTTP POST for hver linje som samsvarer.

#!/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

Begrense varslingsfrekvensen for å unngå støy

En loggstorm kan generere tusenvis av feillinjer i minuttet. Hvis De sender én Slack-melding per linje, vil kanalen bli oversvømt, og De kan bli utmattet av varsler. De trenger frekvensbegrensning — utløse varselet og deretter undertrykke flere varsler i en nedkjølingsperiode.

Dette oppnås med en enkel tidsstempelfil: registrer når det siste varselet ble sendt, og hopp over utsendingen hvis nedkjølingsperioden ikke er utløpt.

#!/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

Telle feilutbrudd med et glidende vindu

Noen ganger er ikke én enkelt feillinje betydningsfull — men 20 feil på 30 sekunder er et alvorlig problem. En teller med glidende vindu lar Dem utløse varsler bare når en terskel for feilfrekvens overskrides, slik at antallet falske positiver reduseres.

Teknikken lagrer epoketidsstempelet for hver treffende hendelse i en midlertidig fil, og teller deretter hvor mange som faller innenfor vinduet før den avgjør om det skal sendes et varsel.

#!/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ølge systemd-journaler

På moderne Linux-systemer (RHEL, Ubuntu 20.04+, Debian 10+) skriver tjenester til systemd-journalen i stedet for til vanlige tekstfiler. journalctl -f er journalens motstykke til tail -F.

Nyttige flagg:

  • -u myapp.service — følg bare en bestemt unit
  • -p err — filtrer etter prioritet (emerg, alert, crit, err, warning, notice, info, debug)
  • --since '5 min ago' — start fra et relativt tidspunkt
  • -o json — skriv ut strukturert JSON for maskinell tolking
# 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 og fargekodet overvåking fra flere kilder

Når De trenger å følge flere loggkilder samtidig, deler multitail terminalen inn i ruter — hver rute følger en annen fil eller kommando — med valgfri fargekoding etter mønster.

Hvis multitail ikke er installert, er et lettvektsalternativ i ren Bash å sette kildenavnet foran hver strøm og slå dem sammen i én visning.

# 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
)

Bygge en selvstendig varslingsdemon

En produksjonsklar varslingsdemon som samler alt fra denne leksjonen, bør:

  • følge loggfilen robust med tail -F
  • filtrere etter kritiske mønstre med bufret grep
  • begrense varslingsfrekvensen for å unngå varslingsutmattelse
  • logge sin egen aktivitet slik at De kan kontrollere hva som ble sendt
  • kjøre som en bakgrunnsprosess administrert av systemd eller en supervisor

Skriptet nedenfor er en minimal, men komplett demon som De kan legge i /usr/local/bin/ og administrere 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

Kunnskapssjekk: Pipelines for loggstrømming

Test forståelsen Deres av sanntidsfølging av logger og strømmende varsler.

En Bash-pipeline følger en loggfil og sender et Slack-varsel for hver linje som samsvarer. Under en loggstorm skrives 3 000 feillinjer på 10 sekunder. Hvilken enkeltendring forhindrer best at skriptet oversvømmer Slack-kanalen med 3 000 meldinger?

Besvar den i den interaktive leksjonen

Oppsummering av leksjonen: Sanntidsfølging av logger og strømmende varsler

I denne leksjonen bygget De en komplett pipeline for loggovervåking i sanntid, fra grunnen av:

  • tail -F følger en loggfil basert på filnavnet og overlever loggrotasjon — foretrekk den alltid fremfor tail -f i produksjon
  • grep --line-buffered filtrerer den aktive strømmen uten å innføre forsinkelse; legg alltid til dette flagget i grep-kommandoer som bruker pipe
  • awk med fflush() beriker hver linje med tidsstempler eller uthentede felt på en måte som er trygg for strømming
  • Slack-webhooks via curl leverer varsler med én enkelt HTTP POST — ingen SDK kreves
  • Nedkjølingsfiler forhindrer varslingsutmattelse under loggstormer ved å håndheve et minsteintervall mellom varsler
  • Tellere med glidende vindu oppdager feilutbrudd (frekvensbaserte varsler) i stedet for å reagere på hver enkelt linje
  • journalctl -f er systemds innebygde motstykke til tail -F, med innebygd prioritetsfiltrering og JSON-utdata
  • Et selvstendig varslingsdemon-skript kombinerer alle disse mønstrene og kan administreres av systemd for pålitelig drift i produksjon

Disse grunnprinsippene kan kombineres og utgjør fundamentet for enhver tilpasset pipeline for observability — ingen tredjepartsagent kreves.

Gratis å komme i gang

Lær deg DevOps-bootcamp med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
142
Leksjoner
568
Start læringen gratisSe hele kurset

Ofte stilte spørsmål

Er leksjonen «Sanntidsfølging av logger og strømmende varsler» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien DevOps-bootcamp, inkludert «Sanntidsfølging av logger og strømmende varsler», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i DevOps-bootcamp inneholder totalt 4 leksjoner.

Hva lærer jeg i «Sanntidsfølging av logger og strømmende varsler»?

Følg og filtrer aktive loggstrømmer for å utløse varsler idet feilmønstre oppstår. Du øver på DevOps-bootcamp med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med DevOps-bootcamp?

Ingen tidligere erfaring er nødvendig. DevOps-bootcamp på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Sanntidsfølging av logger og strømmende varsler»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne DevOps-bootcamp-leksjonen?

Ja. Alle DevOps-bootcamp-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Analyse av nett- og applikasjonslogger i stor skala
  2. Sanntidsfølging av logger og strømmende varsler
  3. Spørring mot journald med journalctl i skript
  4. Beregning av måltall og histogrammer fra loggstrømmer
← Tilbake til DevOps-bootcamp