Logovervågning i realtid og streaming-alarmer
Følg og filtrér live-logstreams for at udløse alarmer, så snart fejlsmønstre opstår.
Logovervågning i realtid og streaming-alarmer er en gratis Intensiv DevOps-uddannelse-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Intensiv DevOps-uddannelse, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Intensiv DevOps-uddannelse-kurset indeholder 4 lektioner i alt.
Hvorfor logovervågning i realtid er vigtig
I produktionssystemer vokser logfiler kontinuerligt. Hvis du venter med at undersøge loggene, til nogen rapporterer et problem, har nedetiden allerede kostet dig dyrt. Logovervågning i realtid lader dig følge hændelser, så snart de skrives, og gør det muligt at reagere med det samme på fejl, sikkerhedshændelser og forringet ydeevne.
- Webservere skriver én linje pr. forespørgsel — fejl vises med det samme
- Applikationsdæmoner logger stakspor, så snart en undtagelse opstår
- Godkendelsessystemer registrerer mislykkede loginforsøg i realtid
Det grundlæggende Unix-værktøj til dette er tail -f, kombineret med filtrerings- og alarmværktøjer, der omdanner rå logstrømme til signaler, du kan handle på.
tail -f: Følg en aktiv log
tail -f (følg) holder filen åben og udskriver nye linjer, efterhånden som de tilføjes. Det er det enkleste og mest universelt tilgængelige værktøj til logovervågning i realtid.
Almindelige anvendelsesmønstre:
tail -f /var/log/syslog— følg systemloggentail -n 50 -f app.log— vis de seneste 50 linjer, og følg derefter filentail -f /var/log/nginx/access.log— følg nginx-forespørgsler live
Tryk på Ctrl+C for at stoppe. Processen forbliver aktiv, indtil du annullerer 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: Overlev logrotation
Mange systemer roterer logfiler ved midnat eller når de når en størrelsesgrænse. Når det sker, omdøbes den oprindelige fil (f.eks. app.log.1), og en ny app.log oprettes. Med tail -f fortsætter du ubemærket med at læse den gamle omdøbte fil og går glip af alt nyt output.
tail -F (stort F) løser dette ved at holde øje med filnavnet i stedet for fildeskriptoren. Når filen forsvinder og dukker op igen, åbner tail -F den automatisk igen og fortsætter med at følge den.
- Foretræk altid
tail -Ffrem fortail -fi produktionsscripts - Virker med logrotate, newsyslog og Docker-logdrivere, der 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.logFiltrering af strømmen med grep
Det er overvældende at følge en travl log råt — en aktiv webserver kan skrive hundredvis af linjer i sekundet. Send outputtet fra tail -F gennem grep for kun at udskille de mønstre, du er interesseret i.
Vigtige flag til grep på en strøm:
--line-buffered— tøm bufferen for hver matchende linje med det samme i stedet for at gemme linjer i en buffer; påkrævet i pipelines, ellers bliver output forsinket eller går tabt-i— match uden forskel på store og små bogstaver-E— udvidet regulært udtryk til alternation (error|warn|crit)-v— vend matchningen om (udeluk 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'Tilføj tidsstempler og kontekst med awk
Loglinjer mangler nogle gange kontekst, der kan hjælpe med den indledende fejlanalyse. Du kan berige strømmen i realtid med awk — ved at tilføje et lokalt tidsstempel, udtrække felter eller omformatere outputtet, så det bliver lettere at læse.
awk kører også i strømtilstand (med linjebuffer), når outputtet sendes gennem en pipe, så det er sikkert at bruge i aktive pipelines uden ekstra flag.
# 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'Send alarmer med Slack-webhooks
Filtrering er kun halvdelen af arbejdet — når du har registreret et fejlmønster, skal du underrette nogen. En indgående Slack-webhook lader dig sende en POST-meddelelse til en kanal med ét curl-kald, uden at du behøver et Slack-SDK eller andre legitimationsoplysninger end webhook-URL'en.
Mønsteret er: filtrer strømmen, og send en HTTP POST for hver matchende linje.
#!/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"
doneBegræns alarmfrekvensen for at undgå støj
En logstorm kan generere tusindvis af fejllinjer i minuttet. Hvis du sender én Slack-meddelelse pr. linje, oversvømmer du kanalen og skaber alarmtræthed. Du har brug for frekvensbegrænsning — udløs alarmen, og undertryk derefter yderligere meddelelser i en afkølingsperiode.
Det opnås med en simpel tidsstempelfil: registrer, hvornår den seneste alarm blev sendt, og spring udsendelsen over, hvis afkølingsperioden ikke er udløbet.
#!/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
doneTæl fejludbrud med et glidende vindue
Nogle gange er en enkelt fejllinje ikke betydningsfuld — men 20 fejl på 30 sekunder er et alvorligt problem. En tæller med et glidende vindue lader dig udløse alarmer, kun når en tærskel for fejlfrekvens overskrides, så du reducerer falske positiver.
Teknikken gemmer hver matchende hændelses tidsstempel i epoketid i en midlertidig fil og tæller derefter, hvor mange der falder inden for vinduet, før det afgøres, om der skal sendes en alarm.
#!/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
donejournalctl -f: Følg systemd-journaler
På moderne Linux-systemer (RHEL, Ubuntu 20.04+, Debian 10+) skriver tjenester til systemd-journalen i stedet for almindelige tekstfiler. journalctl -f er journalens pendant til tail -F.
Nyttige flag:
-u myapp.service— følg kun en bestemt enhed-p err— filtrer efter prioritet (emerg, alert, crit, err, warning, notice, info, debug)--since '5 min ago'— start fra et relativt tidspunkt-o json— output struktureret JSON til maskinfortolkning
# 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 farvekodet overvågning fra flere kilder
Når du har brug for at overvåge flere logkilder samtidigt, opdeler multitail terminalen i ruder — hver rude følger en anden fil eller kommando — med mulighed for farvekodning efter mønster.
Hvis multitail ikke er installeret, er et let alternativ, der kun bruger Bash, at sætte kildenavnet foran hver strøm og samle dem 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
)Byg en selvstændig alarmdæmon
En alarmdæmon i produktionskvalitet, der samler alt fra denne lektion, bør:
- Følge logfilen robust med
tail -F - Filtrere efter kritiske mønstre med bufferet
grep - Begrænse alarmfrekvensen for at undgå alarmtræthed
- Logge sin egen aktivitet, så du kan kontrollere, hvad der blev sendt
- Køre som en baggrundsproces, der administreres af systemd eller en supervisor
Scriptet nedenfor er en minimal, men komplet dæmon, som du kan placere 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
doneTest din viden: Strømmende logpipelines
Test din forståelse af logovervågning i realtid og strømmende alarmer.
En Bash-pipeline følger en logfil og sender en Slack-alarm for hver matchende linje. Under en logstorm skrives der 3.000 fejllinjer på 10 sekunder. Hvilken enkelt ændring forhindrer bedst scriptet i at oversvømme Slack-kanalen med 3.000 meddelelser?
Opsummering af lektionen: Logovervågning i realtid og strømmende alarmer
I denne lektion har du opbygget en komplet pipeline til observerbarhed af logge i realtid helt fra bunden:
- tail -F følger en logfil efter navn og overlever logrotation — foretræk den altid frem for
tail -fi produktion - grep --line-buffered filtrerer den aktive strøm uden at tilføje latenstid; tilføj altid dette flag i grep-kommandoer, der indgår i en pipe
- awk with fflush() beriger hver linje med tidsstempler eller udtrukne felter på en måde, der er sikker ved strømbehandling
- Slack-webhooks via curl leverer alarmer med én HTTP POST — intet SDK er nødvendigt
- Afkølingsfiler forhindrer alarmtræthed under logstorme ved at håndhæve et minimumsinterval mellem meddelelser
- Tællere med glidende vindue registrerer fejludbrud (frekvensbaserede alarmer) i stedet for at reagere på hver enkelt linje
- journalctl -f er systemds oprindelige pendant til tail -F med indbygget prioritetsfiltrering og JSON-output
- Et selvstændigt alarmdæmonscript kombinerer alle disse mønstre og kan administreres af systemd for pålidelig drift i produktion
Disse grundelementer kan sammensættes til fundamentet for enhver brugerdefineret pipeline til observerbarhed — uden behov for en agent fra en tredjepart.
Lær Intensiv DevOps-uddannelse med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 142
- Lektioner
- 568
Ofte stillede spørgsmål
Er lektionen “Logovervågning i realtid og streaming-alarmer” gratis?
Ja — alle 3 lektioner i læringssporet Intensiv DevOps-uddannelse, inklusive “Logovervågning i realtid og streaming-alarmer”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Intensiv DevOps-uddannelse-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Logovervågning i realtid og streaming-alarmer”?
Følg og filtrér live-logstreams for at udløse alarmer, så snart fejlsmønstre opstår. Du øver dig i Intensiv DevOps-uddannelse med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Intensiv DevOps-uddannelse?
Der kræves ingen tidligere erfaring. Intensiv DevOps-uddannelse på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.
Hvor lang tid tager lektionen “Logovervågning i realtid og streaming-alarmer”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Intensiv DevOps-uddannelse-lektion?
Ja. Alle Intensiv DevOps-uddannelse-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Parsing af web- og applikationslogs i stor skala
- Logovervågning i realtid og streaming-alarmer
- Forespørgsler til journald med journalctl i scripts
- Beregning af metrikker og histogrammer fra logstreams