Hvorfor logs stadig gør ondt i 2026 Logs er “sandheden”, men de er også : least ergonomic data format ever invented 
 
 
 
 Skala: GB / TB per dag er normalt. menneskelige øjenbolde er ikke. Format drift: Apache, Nginx, JVM, container runtime, app logs, leverandør SDK logs ... hver bringer sin egen ordning (eller mangel på ordning). Hidden coupling: Den virkelige rodårsag lever ofte i sammenhængende beskeder (timeouts + pool udmattelse + CPU spikes), ikke et enkelt søgeord. LLM'er ændrer ligningen, fordi du kan beskrive hensigt på almindelig engelsk - – Uden at skrive en hel parser opad. then force structure on output Nøgleordet er . Styrken En god prompt er ikke “Analyse disse logs.” Den mentale model: opfordringer som kontrakter, ikke spørgsmål Tænk på din prompt som en API spec: 
 
 
 
 
 Indtastninger: Hvad du giver (logsnit, tidsramme, skema hints). Opgaver: Hvad modellen skal beregne (filter, uddrag, tælle, klynge). Udgangsskema: Hvordan resultatet skal se ud (tabeller / JSON, deterministiske felter). Begrænsninger: Hvad man skal ignorere, hvordan man håndterer kant tilfælde, navngivning regler. Hvis du ikke angiver disse, vil modellen med glæde give dig en roman. Del I - Log analyse opfordringer, der ikke hallucinere Den 5-block prompt skabelon (kamptestet) Brug dette som dit standardskeleton: 1) Role: You are a {domain role} specializing in {log type} analysis.
2) Context: System + timeframe + what "good" looks like.
3) Data: Paste logs or provide a schema + sample lines.
4) Tasks: Bullet list of explicit operations to perform.
5) Output: Strict schema (table or JSON). Include edge-case rules.
 Et lille skridt med stor indflydelse: Hvis et menneske vil læse det senere, stor - mennesker kan læse JSON. make the output machine-checkable Scenario A — Incident sortering: uddrag ERROR/FATAL, normalisere, afdække Her er en prompt, der opfører sig som en on-call teammedlem: Role:
You are a senior SRE. You extract incident-relevant signals from mixed application logs.
​
Context:
- System: Checkout Service (Java) + Redis cache + MySQL
- Goal: Identify actionable error patterns for a post-incident summary
- Time window: 2026-02-16 19:10–19:20 UTC
​
Data:
{PASTE LOGS HERE}
​
Tasks:
1) Filter only ERROR and FATAL entries.
2) For each entry, extract:
   - ts, level, service/component (if present), exception/error type, resource (host/ip/url), raw message
3) Normalize error types:
   - e.g., "Conn refused", "Connection refused" -> "Connection refused"
   - Stack traces: keep only top frame + exception class
4) Deduplicate identical errors; count occurrences.
5) Produce top-3 error types by frequency.
​
Output (strict JSON):
{
  "window": "...",
  "total_errors": 0,
  "top_errors": [
    {
      "error_type": "",
      "count": 0,
      "example": {
        "ts": "",
        "level": "",
        "resource": "",
        "message": ""
      }
    }
  ],
  "all_errors": [
    {
      "ts": "",
      "level": "",
      "error_type": "",
      "resource": "",
      "message": ""
    }
  ]
}
​
Constraints:
- Never invent fields. If missing, use null.
- Keep error_type <= 40 chars.
 Hvorfor dette virker 
 
 
 
 Du beder ikke om "analyse", du beder om ekstraktion + normalisering. Du forhindrer kreativitet ved at kræve nul for manglende felter. Du kræver tæller, som tvinger aggregering i stedet for historiefortælling. Scenario B — Produktanalyse: beregning af funnels fra adfærdsloggere For adfærdsmæssige logs, du bekymre dig om og Ikke at lægge spor. Forskellige brugere Konvertering af matematik Role:
You are a product analyst. You compute funnel metrics from event logs.
​
Data:
Each line is one event:
YYYY-MM-DD HH:MM:SS | user_id=... | event=... | item_id=... | device=...
​
Tasks:
1) For item_id=SKU-9411, count each event type.
2) Compute unique users per event (dedupe by user_id).
3) Compute:
   - view->add_to_cart
   - add_to_cart->purchase
4) If denominator is 0, return "N/A" and explain.
​
Output:
- Table: event, events_count, unique_users
- Then: formulas + results (2 decimals)
 Scenario C – Trendanalyse: Spot spikes, hypothesize årsager (med omhu) Trend opfordringer fejler, når du lader modellen "forklare" før den "måler". Gør måling obligatorisk først: Tasks:
1) Identify peak windows (>= P95) and trough windows (==0).
2) Describe the trend using only the provided numbers.
3) Provide 3 hypotheses, each tied to at least one data point.
4) List 5 follow-up queries you'd run in your log tool to validate.
 Dette holder "måske en implementering skete" fra at blive en eventyr. Del II – Keyword clustering, der faktisk er nyttigt Nøgleordsklustering er, hvor teams spiser tid, fordi alle diskuterer taxonomi. Således defineres taxonomien. Den kluster template (6 blokke) 1) Role: You are an NLP engineer for operational logs.
2) Input: List of keywords/errors (raw strings).
3) Dimension: Cluster by {fault type | subsystem | user journey stage | time correlation}.
4) Rules:
   - Each keyword belongs to exactly one cluster.
   - Provide a short cluster name + description.
   - If ambiguous, choose best fit and add rationale.
5) Output: JSON array of clusters.
6) Constraints: 3–7 clusters total, names <= 20 chars.
 Eksempel: kluster efter fejltype (ops-friendly) Indtastningsliste (med vilje messy): 
 
 
 
 
 
 
 
 
 
 DB Conn tidsløsning MySQL: Forbindelse nægtet Redis handshake mislykkedes java.lang.OutOfMemoryFejl Næste 502 Bad Gateway Thread pool udtømt NullPointerException på OrderHandler Cache timeout / kort CPU brug 99% Hurtig udgang skal se ud som: [
  {
    "cluster": "Resource Connect",
    "keywords": ["DB conn timeout", "MySQL: Connection refused", "Redis handshake failed", "Cache timeout /cart"],
    "notes": "Downstream connectivity and timeouts (DB/cache/network). Owner: SRE"
  },
  {
    "cluster": "Code Exceptions",
    "keywords": ["NullPointerException at OrderHandler", "java.lang.OutOfMemoryError"],
    "notes": "Application-level exceptions. Owner: Dev"
  },
  {
    "cluster": "Gateway/Infra",
    "keywords": ["502 Bad Gateway", "CPU usage 99%", "Thread pool exhausted"],
    "notes": "Edge/proxy errors and capacity saturation. Owner: SRE/Platform"
  }
]
 Bemærk, hvad der mangler: “AI vibrerer.” . who does what next Den unsexy sandhed: du har stadig brug for præprocessing LLMs er ikke en erstatning for: 
 
 
 
 
 
 Tidsfiltrering Udvinding af felt Sampling afduplikation Join/korrelation på tværs af signaler Det er en erstatning for at skrive Logik hver gang formatet ændres. Vaner Den vindende arbejdsproces er: 
 
 Værktøj gør skæringen. LLM gør meningsskabende. Tool does the slicing. LLM does the sense-making. Avanceret arbejdsproces 1 – Elastic (ELK) + prompts: reducere TB → 200 linjer → klarhed Et pragmatisk spil: 
 
 
 
 
 Use your log platform to filter:
 
 
 
 
 
 service=checkout level >= ERROR @timestamp: 19:10–19:20 Eksport den lille undergruppe (50-300 linjer). Føde til sorteringsprøven (JSON output). Feed udvundne error_type strenge til klusteropfordringen. Hvis dit team vedtager I Elastic tooling er det endnu bedre: EŞQL gør det nemmere at foretage "pre-joins" (f.eks. vedhæfte brugerniveau eller region) før du overfører dataene til en LLM. ES|QL Avanceret arbejdsproces 2 — OpenTelemetry logs: Betal én gang, analyser overalt Hvis du kan påvirke logging standarder, skal du gøre følgende: 
 
 
 vedtage konsekvente attributter (service.name, deployment.environment, http.route, db.system osv.) holde beskeder menneskeligt læsbare, men sørg for, at nøglefakta også er strukturerede felter Fordi LLM opfordrer til at blive dramatisk enklere, når felter er konsekvente: 
 
 "Udtræk error.message og db.statement" slår "gæt, hvad denne blob betyder." Hvis dine logs ikke er struktureret, skal din prompt blive en parser. Og parsers er, hvor glæde går til døden. Avanceret arbejdsproces 3 — Python forbehandling + prompt clustering (med en twist) Når dine logfiler er friform, gør en For at få det grundlæggende. Minimum af Her er et lidt tweaked eksempel, der konverterer rå linjer til JSON, som du kan indsætte i en LLM-opfordring. (Det er bevidst lille - fordi målet er at Det er ikke muligt at opbygge en ramme.) reduce chaos import re
import json
​
RAW = [
    "2026-02-16 19:12:05 ERROR checkout Thread-17 DB connection timeout url=jdbc:mysql://10.0.4.12:3306/payments",
    "2026-02-16 19:12:19 WARN  checkout Thread-03 heap at 87% host=app-2",
    "2026-02-16 19:13:02 ERROR cache    Thread-22 Redis handshake failed host=10.0.2.9:6379",
    "2026-02-16 19:13:45 FATAL checkout Thread-17 java.lang.OutOfMemoryError at OrderService.placeOrder(OrderService.java:214)"
]
​
PATTERN = re.compile(
    r"(?P<ts>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\s+"
    r"(?P<level>DEBUG|INFO|WARN|ERROR|FATAL)\s+"
    r"(?P<service>\w+)\s+"
    r"(?P<thread>Thread-\d+)\s+"
    r"(?P<msg>.*)"
)
​
def parse_line(line: str):
    m = PATTERN.match(line)
    if not m:
        return {"ts": None, "level": None, "service": None, "thread": None, "msg": line}
​
    d = m.groupdict()
    # lightweight resource hints (optional)
    d["resource"] = None
    if "host=" in d["msg"]:
        d["resource"] = d["msg"].split("host=", 1)[1].split()[0]
    if "url=" in d["msg"]:
        d["resource"] = d["msg"].split("url=", 1)[1].split()[0]
    return d
​
structured = [parse_line(x) for x in RAW]
print(json.dumps(structured, indent=2))
 Nu kan din LLM prompt være : rene 
 
 
 
 udtræk niveau i {ERROR, FATAL} Normaliser msg til error_type Cluster efter service eller fejltype Fælles hurtig fejl (og de rettelser) 1) “Analyze these logs” (aka: venligst ramble) : efterspørgsel udvinding opgaver + streng output ordning. Fix 2) Manglende kontekstvindue Hvis du ikke angiver en tidsramme/systemkontekst, kan modellen ikke adskille "normalt støj" fra "incident". Tilføj . Fix System + vindue + mål 3) Clustering dimension er vage "Gruppe disse efter relevans" er, hvordan du får 14 klynger kaldet "Misc." : definere en dimension og holde klynger til 3–7. Fix 4) Ingen edge-case politik Deling ved nul, tomme input, tvetydige søgeord ... modellen vil gætte. Specifikation af politikker: , der , ”oprette nye klynger” osv. Fix null N/A 5) Role prompting som en crutch En “senior SRE” person gør ikke outputs korrekte. : behandle rolle som tone alene; korrekthed kommer fra . Fix opgaver + ordning + begrænsninger En genanvendelig "prompt pack" du kan droppe i dit team wiki 1) Triage prompt (ERROR/FATAL → JSON) 
 
 Brug til hændelsessammenfatninger og handoffs. 2) Metrics prompt (begivenheder → funnels) 
 
 Brug til produkt/ops dashboards fra samplede logs. 3) Trend prompt (tidsserie → spikes + hypoteser + opfølgninger) 
 
 Bruges til “hvad ændrede sig?” sessioner. 4) Clustering prompt (nøgleord → 3-7 hændelsesbuckets) 
 
 Bruges til at opbygge en levende fejl taxonomi. Afslutning: hvad “godt” ser ud Hvis du gør dette rigtigt, ændres din on-call-flow: 
 
 
 Før: “grep + intuition + Slack arkæologi” Efter: “filter → prompt → struktureret opsummering → ejer → næste forespørgsel” Ikke magisk. Ikke selvstændige agenter. Kun en disciplineret kontrakt mellem dig og modellen. Og det er nok til at få logs til at føle sig som data igen.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Denne lyd er produceret på historiens originalsprog!

Prompt-Driven Log Analysis og Keyword Clustering

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet IONOS: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Bosch: HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Meet IONOS: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Bosch: HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps