Hoekom logs steeds seer in 2026 Logs is die “waarheid”, maar hulle is ook die : least ergonomic data format ever invented 
 
 
 
 Skala: GB / TB per dag is normaal. menslike oogballe is nie. Format drift: Apache, Nginx, JVM, container runtime, app logs, verskaffer SDK logs ... elkeen bring sy eie skema (of gebrek aan skema). Verborge koppeling: die werklike wortel oorsaak leef dikwels in saamkomende boodskappe (timeouts + pool uitputting + CPU spikes), nie 'n enkele sleutelwoord nie. LLMs verander die vergelyking omdat jy die bedoeling in eenvoudige Engels kan beskryf - – sonder om 'n hele parser vooruit te skryf. then force structure on output Maar die sleutelwoord is . Kragte 'N Goeie uitnodiging is nie 'Analyseer hierdie logboeke nie. 'N Goeie uitnodiging is 'n kontrak. Die geestelike model: prompts as kontrakte, nie vrae nie Dink aan jou prompt soos 'n API spec: 
 
 
 
 
 Inputs: Wat jy verskaf (log snippet, tydsbestek, skema wenke). Opdragte: Wat die model moet bereken (filter, uittreksel, tel, cluster). Uitvoer skema: Wat die resultaat moet lyk (tabel / JSON, deterministiese velde). Beperkings: Wat om te ignoreer, hoe om kant gevalle te hanteer, benaming reëls. As jy dit nie spesifiseer nie, sal die model jou gelukkig 'n roman gee. Deel I — Log analise oproepe wat nie hallusinateer nie Die 5-blok prompt sjabloon (battle-testeer) Gebruik dit as jou standaard skeleton: 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.
 'N Kleine stap met 'n groot impak: As 'n mens dit later sal lees, groot - mense kan JSON lees. make the output machine-checkable Skenario A — Incident sortering: trek ERROR/FATAL uit, normaliser, verdraai Hier is 'n prompt wat optree soos 'n on-call spanmaat: 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.
 Hoekom dit werk 
 
 
 
 Jy vra nie vir "analise."Jy vra vir uittreksel + normalisering. Jy voorkom kreatiwiteit deur nul te vereis vir ontbrekende velde. Jy vereis getalle, wat aggregasie in plaas van verhaalverhaal dwing. Skenario B — Produkanalise: bereken funnels uit gedragslogte Vir gedrag logs, jy omgee oor en Geen spore nie. Verskeie gebruikers Konversie van matte 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)
 Skenario C — Trendanalise: spot spikes, hypothesize oorsake (versigtig) Trendvermanings misluk wanneer jy die model laat "verduidelik" voordat dit "meet". Maak die meet eerstens verpligtend: 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.
 Dit hou 'miskien 'n uitrol gebeur' van 'n sprookjesverhaal. Deel II – Sleutelwoorde clustering wat eintlik nuttig is Sleutelwoord clustering is waar teams tyd verspil omdat almal oor taksonomie argumenteer. Definieer die taksonome. Die klustering 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.
 Voorbeeld: Cluster by fault type (ops-vriendelik) Input list (opsetlik messy): 
 
 
 
 
 
 
 
 
 
 DB Conn tydperk MySQL: Verbinding geweier Redis handshake misluk java.lang.OutOfMemoryFout Die 502 Bad Gateway Thread pool uitgeput NullPointerUitsondering by OrderHandler Cache timeout / kaart CPU gebruik 99% Onmiddellike output moet lyk soos: [
  {
    "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"
  }
]
 Let op wat ontbreek: “AI vibes.” . who does what next Die onsexiese waarheid: jy benodig nog voorbehandeling LLMs is nie 'n vervanging vir: 
 
 
 
 
 
 Tydsverspreiding Filter Ekstraktiewe veld die sampling die verdubbeling Join / korrelasie oor die signale Hulle is 'n vervanging vir skryf logika elke keer as die formaat verander. Gewoonte Die winnende werkstroom is: 
 
 Tool doen die sny. LLM doen die betekenis maak. Tool does the slicing. LLM does the sense-making. Geavanceerde werkstroom 1 — Elastic (ELK) + prompts: verminder TB → 200 lyn → helderheid Die pragmatiese spel: 
 
 
 
 
 Use your log platform to filter:
 
 
 
 
 
 service=checkout level >= ERROR @timestamp: 19:10–19:20 Exporteer die klein subset (50-300 rye). Voer na die sortering prompt (JSON uitvoer). Voer geëxtraheerde error_type strings na die clustering prompt. As jou span aanvaar in Elastic tooling, selfs beter: EŞQL maak dit makliker om "voor-joins" te doen (bv, gebruikerslaag of streek byvoeg) voordat jy die data aan 'n LLM oordra. ES|QL Geavanceerde werkstroom 2 — OpenTelemetry logs: betaal een keer, analiseer oral As jy die logging standaarde kan beïnvloed, doen dit: 
 
 
 gebruik konsekwente eienskappe (service.name, deployment.environment, http.route, db.system, ens.) hou boodskappe menslik leesbaar, maar maak seker dat sleutelfakte ook gestruktureerde velde is Omdat LLM oproepe dramaties eenvoudiger word wanneer velde konsekwent is: 
 
 “Extract error.message and db.statement” beats “Gooi wat hierdie blob beteken.” As jou logboeke nie gestruktureer is nie, moet jou oproep 'n parser word. En parsers is waar vreugde sterf. Geavanceerde werkstroom 3 — Python voorverwerking + prompt clustering (met 'n draai) Wanneer jou logboeke vrye vorm is, doen 'n Om die basiese dinge te kry. Die minimum Hier is 'n effens aangepaste voorbeeld wat ruwe lyne omskep in JSON wat jy in 'n LLM-opdrag kan plak. (Dit is doelbewus klein - want die doel is om nie 'n raamwerk te bou nie.) 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))
 Nou kan jou LLM prompt wees : skoonmaak 
 
 
 
 die uitkoms vlak in {FATAL, ERROR} Normalisering van msg na error_type Cluster per diens of fout tipe Algemene spoedfoute (en die regstellings) 1) “Analyzeer hierdie logs” (aka: asseblief ramble) : vraag ekstraksie take + streng output skema. Fix 2) Ontbrekende konteks venster As jy nie 'n tydsraam / stelsel konteks gee nie, kan die model nie "normale lawaai" van "incident" skei nie. Voeg toe . Fix Stelsel + venster + doel 3) Clustering dimension is vague “Groepeer dit volgens relevansie” is hoe jy 14 clusters met die naam “Misc” kry. Definieer 'n dimensie en hou clusters tot 3-7. Fix 4) Geen edge-case beleid nie Verdeling deur nul, leë inputs, duidelike sleutelwoorde ... die model sal raai. Spesifiseer die beleid: die , “nuwe cluster skep”, ens. Fix null N/A 5) Role prompting as 'n crutch 'N "senior SRE" persoon maak nie outputs korrek nie. • Behandel rol net as toon; korreksie kom van . Fix Taak + Skema + Beperkings 'N Herbruikbare "Prompt Pack" wat jy in jou span wiki kan drop 1) Triage prompt (FATAL / FATAL → JSON) 
 
 Gebruik vir gebeurtenisverhale en handoffs. 2) Metrics prompt (gebeurtenisse → funnels) 
 
 Gebruik vir produk / ops dashboards van samplede logboeke. 3) Trend prompt (tydreeks → spikes + hipoteses + opvolg) 
 
 Gebruik vir “wat verander?” sessies. 4) Clustering prompt (sleutelwoorde → 3-7 incident buckets) 
 
 Gebruik vir die bou van 'n lewende fout taksonomie. Sluit: wat “goeie” lyk soos As jy dit reg doen, verander jou oproepstroom: 
 
 
 Vorige: “grep + intuïsie + Slack argeologie” Na: “filter → prompt → gestruktureerde samestelling → eienaar → volgende query” Geen magie nie, nie onafhanklike agente nie, net 'n gedisciplineerde kontrak tussen jou en die model. En dit is genoeg om logs weer soos data te laat voel.

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

Hierdie oudio word in die oorspronklike taal van die storie vervaardig!

Prompt-Driven Log Analysis en sleutelwoord clustering

About Author

KOMMENTAAR

HANG TAGS

HIERDIE ARTIKEL IS AANGEBIED IN

Related Stories

The #bitcoin Writing Contest by Rootstock and HackerNoon: Round 2 Results 🎉

Meet the Writer: HackerNoon Contributor Daniil Sitdikov, Software Engineer

"What If ... I didn't Do It?"

Thrilled to be Recognized as Startup of the Year in New York City

The #bitcoin Writing Contest by Rootstock and HackerNoon: Round 2 Results 🎉

Meet the Writer: HackerNoon Contributor Daniil Sitdikov, Software Engineer

"What If ... I didn't Do It?"

Thrilled to be Recognized as Startup of the Year in New York City

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps