Pourquoi les journaux font encore mal en 2026 Les journaux sont la « vérité », mais ils sont aussi les : least ergonomic data format ever invented 
 
 
 
 L’échelle : GB/TB par jour est normale. les globes oculaires humains ne le sont pas. Drift de format : Apache, Nginx, JVM, runtime de conteneur, journaux d’application, journaux SDK de fournisseur... chacun apporte son propre schéma (ou manque de schéma). Couplage caché : la vraie cause-racine vit souvent dans les messages co-occurrents (temporel + épuisement du pool + pics de CPU), pas un seul mot-clé. LLMs changent l'équation parce que vous pouvez décrire l'intention en anglais simple - - sans écrire un parser entier à l'avance. then force structure on output Le mot clé est . force Un bon prompt n’est pas « analyser ces journaux ». Le modèle mental : les prompts comme des contrats, pas des questions Pensez à votre prompt comme à un spec API: 
 
 
 
 
 Inputs : Ce que vous fournissez (snippet de journal, délai, astuces de schéma). Tâches : Ce que le modèle doit calculer (filtre, extrait, compte, cluster). Schéma de sortie : à quoi doit ressembler le résultat (tables/JSON, champs déterministes). Restrictions: Ce qu'il faut ignorer, comment gérer les cas d'avantage, les règles de dénomination. Si vous ne les spécifiez pas, le modèle vous donnera heureusement un roman. Partie I - Analyse de journaux qui ne hallucinent pas Le modèle de prompt de 5 blocs (testé en bataille) Utilisez ceci comme votre squelette par défaut: 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.
 Un petit mouvement avec un grand impact : (JSON ou tables strictes) Si un humain le lit plus tard, grand – les humains peuvent lire JSON. make the output machine-checkable Scénario A — Triage des incidents : extraire ERROR/FATAL, normaliser, déduire Voici un prompt qui se comporte comme un coéquipier sur appel: 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.
 Pourquoi cela fonctionne 
 
 
 
 Vous ne demandez pas d’« analyse », vous demandez l’extraction + la normalisation. Vous empêchez la créativité en demandant null pour les champs manquants. Vous demandez des comptes, qui forcent l’agrégation au lieu du récit. Scénario B — Analyse de produit: calcul des funnels à partir des journaux de comportement Pour les logiciels de comportement, vous vous souciez de et Pas de traces. Utilisateurs distincts Conversion mathématique 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)
 Scénario C — Analyse des tendances: pics de points, causes hypothétiques (attentionné) Les prompts de tendance échouent lorsque vous laissez le modèle « expliquer » avant de « mesurer ». Faire la mesure obligatoire d'abord: 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.
 Cela empêche "peut-être qu'un déploiement est arrivé" de devenir un conte de fées. Partie II – Clustering de mots clés qui est réellement utile Le cluster de mots clés est un processus dans lequel les équipes perdent du temps parce que tout le monde discute de la taxonomie. Définir la taxonomie. Le modèle de clustering (6 blocs) 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.
 Exemple : cluster par type de défaut (ops-friendly) Liste d’entrée (intentionnellement confuse) : 
 
 
 
 
 
 
 
 
 
 DB Conn Téléchargement MySQL : Connexion refusée Redis Handshake échoué java.lang.OutOfMémoireErreur 502 : Bad Gateway Thread Pool épuisé NullPointerException chez OrderHandler Temps de mise en cache / cartes Utilisation de la CPU 99% La sortie rapide devrait ressembler à : [
  {
    "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"
  }
]
 Notez ce qui manque : « Vibrations d’IA. » Ceci est directement cartographiable . who does what next La vérité non sexy: vous avez toujours besoin de pré-traitement Les LLM ne sont pas un substitut pour: 
 
 
 
 
 
 filtrage du temps Extraction de champs échantillons dédoublement Join / corrélation entre les signaux C’est un substitut à l’écriture logique chaque fois que le format change. coutume Le workflow gagnant est : 
 
 L'outil fait la découpe. LLM fait le sens. Tool does the slicing. LLM does the sense-making. Flux de travail avancé 1 — Elastic (ELK) + prompts: réduire le TB → 200 lignes → clarté Un jeu pragmatique : 
 
 
 
 
 Use your log platform to filter:
 
 
 
 
 
 service=checkout level >= ERROR @timestamp: 19:10–19:20 Exporter le petit sous-ensemble (50 à 300 lignes). Envoyer à la prompt de triage (sortie JSON). Fournit les chaînes d'erreur_type extraites à la prompt de clustering. Si votre équipe adopte En outre, dans Elastic tooling, il est encore mieux : EŞQL facilite les « pré-adhésions » (par exemple, l’ajout d’un niveau d’utilisateur ou d’une région) avant de transmettre les données à un LLM. ES|QL Flux de travail avancé 2 — journaux OpenTelemetry: payer une fois, analyser partout Si vous pouvez influencer les normes de journalisation, faites ceci: 
 
 
 adopter des attributs cohérents (service.name, deployment.environment, http.route, db.system, etc.) Gardez les messages lisibles, mais assurez-vous que les faits clés sont également des champs structurés Parce que les appels LLM deviennent considérablement plus simples lorsque les domaines sont cohérents: 
 
 « Extraire error.message et db.statement » bat « devinez ce que signifie ce blob. » Si vos journaux ne sont pas structurés, votre prompt doit devenir un analyseur. Et les parsers sont là où la joie meurt. Flux de travail avancé 3 — Pré-traitement Python + clustering prompt (avec un twist) Lorsque vos journaux sont de forme libre, faites un Pour obtenir les bases. Le minimum Voici un exemple légèrement ajusté qui convertit les lignes brutes en JSON que vous pouvez coller dans une prompt LLM. (Cela est intentionnellement petit - parce que l'objectif est de Ne pas créer de cadre) 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))
 Maintenant votre prompt LLM peut être : nettoyé 
 
 
 
 niveau d'extraction dans {ERROR, FATAL} normaliser msg en error_type Cluster par service ou type de défaut Les défaillances courantes (et les corrections) 1) « Analyse ces journaux » (aka: s’il vous plaît ramble) : tâches d'extraction de la demande + schéma de sortie strict. Fix 2) Manque de fenêtre contextuelle Si vous ne donnez pas un contexte temporel/système, le modèle ne peut pas séparer le « bruit normal » d’un « incident ». • Ajouter . Fix Système + fenêtre + objectif 3) La dimension du cluster est vague « Groupez-les par pertinence » est la façon dont vous obtenez 14 clusters appelés « Misc ». : définir une dimension et garder les clusters à 3-7. Fix Aucune politique de cas d’avant-garde Division par zéro, entrées vides, mots clés ambigus... le modèle devinera. Spécification des politiques : , à , « créer un nouveau cluster », etc. Fix null N/A 5) Role prompting comme un crutch Une personne «senior SRE» ne rend pas les sorties correctes. : traiter le rôle comme un seul ton; la correction vient de . Fix Tâches + schéma + contraintes Un « prompt pack » réutilisable que vous pouvez laisser tomber dans votre wiki d’équipe 1) Prompt de triage (ERROR/FATAL → JSON) 
 
 Utilisation pour les résumés d'incidents et les handoffs. 2) Métriques prompt (événements → funnels) 
 
 Utilisation pour les tableaux de bord de produits/options à partir de journaux d'échantillons. 3) Prompt de tendance (série de temps → pics + hypothèses + suites) 
 
 Utiliser pour les séances « Qu’est-ce qui a changé ? ». 4) Clustering prompt (mots clés → 3 à 7 buckets d’incidents) 
 
 Utiliser pour construire une taxonomie d'erreur vivante. Clôture : ce que « bon » ressemble Si vous faites cela correctement, votre flux d'appel change : 
 
 
 « Grep + Intuition + Slack Archaeology » Après : « filtre → prompt → résumé structuré → propriétaire → prochaine requête » Pas de magie, pas d'agents autonomes, juste un contrat discipliné entre vous et le modèle. Et cela suffit pour que les journaux se sentent à nouveau comme des données.

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

Cet audio est produit dans la langue originale de l'histoire !

Analyse de journaux prompt-driven & clustering de mots clés

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Télégramme : le pont de Crypto Island vers le continent

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Télégramme : le pont de Crypto Island vers le continent

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps