메트릭·로그 intelligence

학습 목표

메트릭·로그가 AIOps에서 서로 다른 intelligence 역할을 한다는 점을 설명할 수 있다.

log classification으로 노이즈·카테고리·심각도를 구조화할 수 있다.

metric correlation·lag로 연관 지표·선행 신호를 찾을 수 있다.

embedding search로 유사 로그·incident 검색 패턴을 설명할 수 있다.

intelligence 출력이 detect·correlate 단계로 어떻게 넘어가는지 연결할 수 있다.

문제 상황

• Loki 수백만 줄/분 — grep ERROR만으로는 원인·우선순위 없음
• NullPointerException과 connection reset이 같은 severity로 page
• latency alert 때 어느 메트릭부터 볼지 모름 — CPU·DB·queue 수동 비교
• deploy 직후 error log 패턴이 바뀌었는데 템플릿 rule만 — 미탐
• 3개월 전 비슷한 incident가 있었는데 postmortem 검색 실패
• 3편 이상탐지는 숫자 신호 — 로그 문장·유사 사례는 별도 축

3편은 메트릭 이상 점수다. 이번 편은 로그 구조화·지표 연관·의미 검색 — detect 전·옆 intelligence. alert 그룹핑·topology는 5편.

1. 메트릭 vs 로그 intelligence

Observability 신호 종류마다 intelligence가 다르다.

	Metric intelligence	Log intelligence
입력	시계열 숫자	비정형 문장·필드
질문	무엇이 같이 움직이나	무슨 종류·얼마나 심각한가
기법	correlation, lag, baseline (3편)	parse, classify, embed
출력	연관 metric set, lead indicator	category, template, similar case

Metrics:  latency_p99 ──correlates──► db_conn_wait
Logs:     raw line ──classify──► timeout · payment-api · page
          error text ──embed──► past incident #1842 (similar)

• 메트릭 — 양·추세·조합 — 숫자가 주 신호
• 로그 — 맥락·문구·희귀 패턴 — 사람이 읽는 이유
• 둘 다 AIOps 파이프라인 enrich·detect 입력 (2편)
• ELK 검색은 본 편 embedding·분류와 겹치지만 — AIOps는 알림·triage 목적

2. Log classification

로그를 읽기 전에 구조와 라벨을 붙인다.

단계	역할	예
Parse	timestamp, level, service, message 필드	JSON, grok, OTel log model
Template	동적 값 마스킹	order_id=123 → order_id={id}
Classify	category·severity 라벨	timeout, OOM, auth_fail
Route	alert·sample·drop 정책	known noise → sample 1%

# code/log-classification-rules.yaml (발췌)
rules:
  - match: 'level=ERROR AND message=~".*connection reset.*"'
    category: network_reset
    severity: warn
    action: ticket
  - match: 'category=healthcheck AND service=kube-probe'
    category: noise
    severity: info
    action: drop

방법	적합	한계
Rule / regex	알려진 패턴, 감사 필요	새 패턴 수동 추가
Template mining (Drain 등)	대량 비정형 로그	초기 학습·drift
Supervised classifier	라벨된 과거 로그 충분	라벨 비용, drift
LLM zero-shot	소량·탐색	비용·일관성 (6편)

• Parse 먼저 — classification 전 structured field 없으면 정확도 급락
• Severity ≠ log level — ERROR healthcheck는 noise (2편 signal vs noise)
• Cardinality — user_id를 label로 쓰면 시계열 폭발 — template으로 묶기
• 출력 — category, template_id, service — downstream correlate feature (5편)

3. Metric correlation

on-call이 수동으로 여는 대시보드 비교를 자동 후보로 만든다.

개념	의미	운영 활용
Correlation	두 시계열 동시 변화 정도	후보 metric 짝
Lag	A가 먼저, B가 나중	선행 지표
Granger (개요)	과거 A가 B 예측에 도움	인과 힌트 (주의)
Partial corr	공통 요인(트래픽) 제거	spurious 상관 완화

# code/metric_correlation.py (발췌)
import numpy as np

def best_lag_corr(a, b, max_lag=12):
    """Find lag (in steps) where |correlation| is highest."""
    best_lag, best_r = 0, 0.0
    for lag in range(-max_lag, max_lag + 1):
        if lag < 0:
            x, y = a[:lag], b[-lag:]
        elif lag > 0:
            x, y = a[lag:], b[:-lag]
        else:
            x, y = a, b
        r = np.corrcoef(x, y)[0, 1]
        if abs(r) > abs(best_r):
            best_lag, best_r = lag, r
    return best_lag, best_r
# latency_p99 vs db_pool_wait → lag +3m suggests DB queue leads

• 같은 incident — 여러 metric이 동시 튀지만 원인 metric이 먼저
• Deploy 경계 — correlation은 구간 나눠 계산 — 배포 전·후 섞이면 왜곡
• Cardinality — instance별 전부 correlate 하면 조합 폭발 — service·golden set
• 인과 착각 — correlation ≠ causation — topology·trace로 검증 (5편)
• 3편 multivariate anomaly — correlation으로 feature 후보 선정

4. Embedding search (개요)

로그·incident를 벡터로 바꿔 의미가 가까운 과거 사례를 찾는다.

단계	역할
Chunk	log line, stack trace, postmortem 단위
Embed	sentence embedding, log-specific model
Index	vector store (HNSW, ES dense_vector)
Retrieve	k-NN 유사 chunk · incident

Current: "payment timeout after 30s upstream 503"
    → embed → top-3: incident-1842, runbook-payment-timeout, log-template-9f2a

용도	예
Similar incident	“예전에도 이랬나” 빠른 검색
Runbook hint	유사 장애 조치 문서
New pattern	cluster에 안 맞는 outlier log
Duplicate alert	같은 root 문구 반복 탐지

• Embedding ≠ magic — 품질은 chunk·필드·도메인 모델에 달림
• PII — embed 전 마스킹 (Security 시리즈)
• Stale index — deploy·버전 바뀌면 재색인 — 6~7편 RAG와 같은 인프라 재사용 가능
• Hybrid — keyword(BM25) + vector 재순위 — 운영에서 흔함

5. Intelligence에서 파이프라인으로

분류·상관·검색 결과는 alert 하나가 아니라 enrich·detect·correlate 입력.

출력	파이프라인 단계	효과
category=timeout	enrich alert label	routing·runbook 자동
correlated_metrics	detect composite	단일 threshold 대신 조합
similar_incident	respond context	MTTR 단축
template_id spike	correlate group key	동일 패턴 한 incident

# code/intelligence-enrich.yaml (발췌)
enrich:
  on_alert:
    - fetch_correlated_metrics: [latency_p99, db_pool_wait, error_rate]
      window: 15m
    - log_classify_recent:
        service: "{{ alert.labels.service }}"
        lookback: 5m
    - similar_incidents:
        query_from: alert.annotations.summary
        top_k: 3

• Batch vs realtime — correlation은 주기 job, classification은 스트림 near-line
• Feedback — on-call “helpful similar” 클릭 → 검색 재학습·가중치
• 비용 — 전 로그 embed는 비쌈 — ERROR·샘플·alert window만
• 5편 correlation — topology·time window로 그룹 — 이번 편 feature가 재료

6. 실무 체크리스트

#	질문
1	로그가 parse·template 되는가
2	classification severity가 page 정책과 맞는가
3	correlation 대상 metric이 golden set으로 제한됐는가
4	lag·deploy 구간을 분리해 계산하는가
5	embedding index에 PII가 없는가
6	intelligence 출력이 alert에 annotation으로 보이는가

정리

• 메트릭 intelligence — 연관·lag·조합, 로그 — 분류·template·의미 검색
• Log classification — parse → template → label → route, noise 먼저 제거
• Metric correlation — 후보 짝·선행 지표, 인과는 topology로 검증
• Embedding search — 유사 incident·runbook, hybrid retrieval이 실무적
• 출력은 enrich·detect·correlate 입력 — 5편 그룹핑의 재료

다음에 다룰 것

• Incident correlation
• alert grouping, root cause hint, topology context

---

해당 내용은 Google SRE Workbook (Monitoring), Designing Machine Learning Systems, vector search 패턴을 기반으로 합니다.