Чому логі все ще болять в 2026 році «Логи» є «правдою», але вони також є : least ergonomic data format ever invented 
 
 
 
 Шкала: ГБ / ТБ на день є нормальним. Формат дрейфу: Apache, Nginx, JVM, час запуску контейнерів, щоденники додатків, щоденники SDK постачальника ... кожен приносить свою власну схему (або відсутність схеми). Приховане сполучення: справжня коренова причина часто живе в спільних повідомленнях (часові викиди + виснаження басейну + піки процесора), а не в одному ключовому слові. LLM змінює рівняння, тому що ви можете описати намір простою англійською мовою - — без написання цілого парсера вперед. then force structure on output Але ключове слово є . Сила Хороший запрос не означає «аналізувати ці журнали». Ментальна модель: прохання як контракти, а не питання Подумайте про свій промпт як про специфіку API: 
 
 
 
 
 Входи: те, що ви надаєте (знімки журналу, часові рамки, натяки на схему). Завдання: Що повинна обчислити модель (фільтр, витяг, підрахунок, кластер). Вихідна схема: як повинен виглядати результат (таблиці / JSON, детерміністичні поля). Обмеження: що ігнорувати, як впоратися з крайовими випадками, іменування правил. Якщо ви не вкажете їх, модель із задоволенням дасть вам роман. Частина I — Заклики до аналізу журналу, які не галюцинують Шаблон 5-блокового пробного шаблону (тестується в бою) Використовуйте це як свій стандартний скелет: 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.
 Маленький крок з великим впливом: Якщо людина буде читати його пізніше, великий - люди можуть читати JSON. make the output machine-checkable Сценарій А — сортування інцидентів: витяг ERROR/FATAL, нормалізувати, дедупе Ось прохання, яке поводиться як співрозмовник на виклик: 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.
 Чому це працює 
 
 
 
 Ви не просите про «аналіз», ви просите про вилучення + нормалізацію. Ви перешкоджаєте творчості, вимагаючи нуль для відсутніх полів. Ви вимагаєте рахунків, які змушують агрегацію замість розповіді. Сценарій B — Аналітика продуктів: обчислення каналів з журналів поведінки Що стосується поведінки журналів, то вам цікаво та Не залишайте слідів. Різні користувачі Математичне перетворення 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)
 Сценарій C — аналіз тенденцій: спот-спіки, гіпотезування причин (обережно) Запрошення на тенденцію не спрацьовує, коли ви дозволяєте моделі «пояснювати» перед тим, як вона «вимірює». Спочатку необхідно зробити вимірювання обов'язковим: 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.
 Це тримає "можливо, що розгортання сталося" від того, щоб стати казкою. Частина II — кластери ключових слів, які насправді корисні Класифікація ключових слів - це те, де команди витрачають час, тому що всі сперечаються про таксономію. Таким чином визначається таксономія. Розташування шаблону (6 блоків) 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.
 Приклад: кластер за типом помилки (ops-friendly) Вхідний список (навмисно непомітний): 
 
 
 
 
 
 
 
 
 
 DB Conn Час виходу MySQL: Відмова від підключення Рукоподібний ремінь провалився java.lang.OutOfMemoryПомилка 502 «Bad Gateway» Thread Pool вичерпаний NullPointerException у OrderHandler Створення Timeout /Cart Використання CPU 99% Швидкий вихід повинен виглядати так: [
  {
    "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"
  }
]
 Зверніть увагу на те, що бракує: «AI вібрації». . who does what next Несексуальна правда: вам все ще потрібна попередня обробка LLM не є заміною для: 
 
 
 
 
 
 Час фільтрації Поле видобутку зразки Дедуплікація Співвідношення / кореляція між сигналами Вони є заміною для написання Кожен раз, коли змінюється форма. звичаї Переможним робочим процесом є: 
 
 Інструмент робить розріз. LLM робить сенс. Tool does the slicing. LLM does the sense-making. Розширений робочий процес 1 — Еластичний (ELK) + заклики: зменшити ТБ → 200 рядків → чіткість Про практичну гру: 
 
 
 
 
 Use your log platform to filter:
 
 
 
 
 
 service=checkout level >= ERROR @timestamp: 19:10–19:20 Виведіть невеликий підсумок (50–300 рядків). Використання вихідного запису JSON (JSON output). Витягнуті error_type струни надходять до промови кластерування. Якщо ваша команда приймає У Elastic tooling, ще краще: EŞQL полегшує «передприєднання» (наприклад, додавання рівня користувача або регіону), перш ніж передати дані LLM. ES|QL Розширений робочий процес 2 — журнали OpenTelemetry: платіть один раз, аналізуйте всюди Якщо ви можете вплинути на стандарти журналу, зробіть це: 
 
 
 приймати послідовні атрибути (service.name, deployment.environment, http.route, db.system тощо) зберігати повідомлення для людського читання, але переконайтеся, що ключові факти також є структурованими полями Тому що запрошення LLM стають значно простішими, коли поля є послідовними: 
 
 «Extract error.message and db.statement» перемагає «угадай, що означає цей blob». Якщо ваші журнали не структуровані, ваш запропонувач повинен стати аналітиком. Парсери – це ті місця, де вмирає радість. Розширений робочий процес 3 — Python preprocessing + prompt clustering (з поворотом) Коли ваші записи є вільною формою, зробіть Знайдіть, щоб отримати основи Мінімальна Ось трохи налагоджений приклад, який перетворює сирі рядки в JSON, який ви можете вставити в запрошення LLM. (Це навмисно невелике, тому що мета полягає в тому, щоб не створювати рамки) 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))
 Тепер ваш LLM пробний може бути : Чистий 
 
 
 
 Рівень вилучення в {Error, FATAL} Нормалізація msg в error_type Кластер за службою або типом помилки Поширені швидкі помилки (і виправлення) 1) “Analyze these logs” (так званий: будь ласка, руйнуйте) : завдання видобутку попиту + строга схема виходу. Fix 2) Відсутнє вікно контексту Якщо ви не надаєте контекст часової рамки/системи, модель не може розділити «нормальний шум» від «інциденту». • Додаток . Fix Система + вікно + мета 3) Розмір кластеру є вагомим «Групіть їх за актуальністю» - так ви отримуєте 14 кластерів під назвою «Misc». : визначити вимір і тримати кластери до 3-7. Fix 4) Ніяка політична криза Розділ на нуль, порожні входи, неоднозначні ключові слова... модель здогадується. Ознайомтеся з політикою: , «Створення нового кластера» і т.д. Fix null N/A 5) Роль пробуджує як крок Особистість «Senior SRE» не робить вихід правильним. • розглядати роль тільки як тон; коректність походить від . Fix Задачі + схема + обмеження Повторний «промпт-пакет», який ви можете випустити на вашу групу wiki Помилка сортування (Error / FATAL → JSON) 
 
 Використовуйте для резюме інцидентів та рукостискань. Metrics prompt (події → фуннелі) 
 
 Використовуйте для панелей продуктів / операцій з пробних журналів. Тренд-промпт (Time series → spikes + hypotheses + follow-ups) 
 
 Використовуйте для сеансів «Що змінилося?» 4) Класифікація проб (ключові слова → 3–7 букетів інцидентів) 
 
 Використовується для створення таксономії живих помилок. Закриття: як виглядає «хороше» Якщо ви зробите це правильно, ваш потік дзвінків змінюється: 
 
 
 «Grep + Intuition + Slack Archaeology» Після: «фільтр → прохання → структуроване резюме → власник → наступне запит» Не магія. Не автономні агенти. Просто дисциплінований контракт між вами і моделлю. І цього достатньо, щоб записи знову відчували себе як дані.

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

Це аудіо створено мовою оригіналу історії!

Prompt-Driven Log Analysis & Keyword Clustering (Аналіз журналів та кластер ключових слів)

About Author

КОМЕНТАРІ

ПОВІСИТИ БИРКИ

ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps