Kibana Streams란?
Kibana 9.2(GA 시점)부터 내장된 데이터 스트림 통합 관리 UI입니다. 기존 인제스트 파이프라인 · ILM · 인덱스 템플릿을 각각 설정해야 했던 작업을 단일 화면에서 처리하는 기능을 제공합니다.
한 줄 요약Streams = 인덱스 템플릿 + 컴포넌트 템플릿 + 인제스트 파이프라인을 대신 만들어 주고 관리해 주는 UI
•
Datastream에 대해 각 탭에서 편집 시 AI 기반 Grok 패턴 자동 생성 및 라우팅 규칙 제안
•
Retention · Partitioning · Processing · Schema · Data Quality · Advanced 6개 탭으로 구성
•
Wired 모드: 모든 로그를 logs 루트로 수집 후 child stream으로 분기
•
Classic 모드: 기존 data stream을 그대로 온보딩
Wired vs Classic 모드의 차이는?
수집 엔드포인트 | logs 고정 (OTel 포맷 자동 변환) | 기존 logs-*-* 등 자유 지정 |
적합 대상 | 신규 파이프라인 설계 | 기존 data stream 온보딩 |
계층 상속 | 부모 → 자식 자동 전파 | 미지원 |
Partitioning | 조건 기반 child 분기 + AI 제안 | 미지원 |
AI 기능 | Grok 생성 + 라우팅 제안 | Grok 생성만 |
인덱스 템플릿 | 신규 자동 생성 (managed) | 기존 템플릿 그대로 유지 |
기존 파이프라인 충돌 위험 | logs-*-* priority 충돌 가능 | 리스크 없음 |
Streams 탭 별 기능 소개
Kibana > Streams 메뉴의 6개 탭의 역할과 주요 기능을 정리합니다.
1) Retention
데이터 보존 기간(Data Stream Lifecycle)을 설정합니다. 변경 즉시 기존 backing index 전체에 전파됩니다.
부모 상속 | child stream은 부모 retention 상속. 개별 override 가능 |
즉시 전파 | 변경 즉시 신규·기존 backing index 전체에 적용 (ILM rollover 대기 불필요) |
데이터 크기 인사이트 | 스트림 용량·일별 인제스트량 시각화 |
보존 기간 설정 | 슬라이더 또는 직접 입력으로 일/주/월 단위 설정 |
Failure Store retention | 인제스트 실패 문서 별도 보존 기간 설정 |
•
ILM과의 차이
기존 ILM은 hot → warm → delete 단계별 정책을 정의하고 rollover 이후 적용됩니다. Streams Retention은 단순 보존 기간만 설정하며 _data_stream/_settings API를 통해 즉시 반영됩니다. 세밀한 티어 이동 정책이 필요하면 기존 ILM 정책을 병행 사용하세요.
2) Partitioning
‘Wired 모드 전용’ 기능이며, 루트 스트림(logs)으로 들어온 데이터를 조건에 따라 child stream으로 분기합니다. 내부적으로 @stream.processing 파이프라인의 reroute 프로세서를 자동 관리합니다.
조건 직접 입력 | 필드 값 기반 라우팅 조건 설정 (eq / contains / startsWith 등) |
AI — Get suggestions | 유입 데이터 필드 분포 분석 후 적절한 분기 조건 자동 제안 |
Child stream 자동 생성 | 규칙 저장 시 logs.s-core 같은 child data stream 자동 생성 |
설정 상속 | 부모 스트림의 Processing · Schema · Retention 설정이 자식에 자동 전파 |
Partitioning vs 기존 Reroute Processor
기존에는 인제스트 파이프라인에 reroute 프로세서를 수동 작성했습니다. Partitioning 탭은 이를 UI로 추상화하며, 생성된 조건은 내부적으로 @stream.processing 파이프라인에 자동 반영됩니다.
Kibana 9.2(GA 시점)부터 내장된 데이터 스트림 통합 관리 UI입니다. 기존 인제스트 파이프라인 · ILM · 인덱스 템플릿을 각각 설정해야 했던 작업을 단일 화면에서 처리하는 기능을 제공합니다.
한 줄 요약Streams = 인덱스 템플릿 + 컴포넌트 템플릿 + 인제스트 파이프라인을 대신 만들어 주고 관리해 주는 UI•
Datastream에 대해 각 탭에서 편집 시 AI 기반 Grok 패턴 자동 생성 및 라우팅 규칙 제안
•
Retention · Partitioning · Processing · Schema · Data Quality · Advanced 6개 탭으로 구성
•
Wired 모드: 모든 로그를 logs 루트로 수집 후 child stream으로 분기
•
Classic 모드: 기존 data stream을 그대로 온보딩
Wired vs Classic 모드의 차이는?
구분 | Wired | Classic |
수집 엔드포인트 | logs 고정 (OTel 포맷 자동 변환) | 기존 logs-*-* 등 자유 지정 |
적합 대상 | 신규 파이프라인 설계 | 기존 data stream 온보딩 |
계층 상속 | 부모 → 자식 자동 전파 | 미지원 |
Partitioning | 조건 기반 child 분기 + AI 제안 | 미지원 |
AI 기능 | Grok 생성 + 라우팅 제안 | Grok 생성만 |
인덱스 템플릿 | 신규 자동 생성 (managed) | 기존 템플릿 그대로 유지 |
기존 파이프라인 충돌 위험 | logs-- priority 충돌 가능 | 리스크 없음 |
Streams 탭 별 기능 소개
Kibana > Streams 메뉴의 6개 탭의 역할과 주요 기능을 정리합니다.
1) Retention
데이터 보존 기간(Data Stream Lifecycle)을 설정합니다. 변경 즉시 기존 backing index 전체에 전파됩니다.
기능 | 설명 |
보존 기간 설정 | 슬라이더 또는 직접 입력으로 일/주/월 단위 설정 |
부모 상속 | child stream은 부모 retention 상속. 개별 override 가능 |
즉시 전파 | 변경 즉시 신규·기존 backing index 전체에 적용 (ILM rollover 대기 불필요) |
Failure Store retention | 인제스트 실패 문서 별도 보존 기간 설정 |
데이터 크기 인사이트 | 스트림 용량·일별 인제스트량 시각화 |
ILM과의 차이
기존 ILM은 hot → warm → delete 단계별 정책을 정의하고 rollover 이후 적용됩니다. Streams Retention은 단순 보존 기간만 설정하며 _data_stream/_settings API를 통해 즉시 반영됩니다. 세밀한 티어 이동 정책이 필요하면 ILM을 병행 사용하세요.2) Partitioning
Wired 모드 전용 기능이며, 루트 스트림(logs)으로 들어온 데이터를 조건에 따라 child stream으로 분기합니다. 내부적으로 @stream.processing 파이프라인의 reroute 프로세서를 자동 관리합니다.
기능 | 설명 |
조건 직접 입력 | 필드 값 기반 라우팅 조건 설정 (eq / contains / startsWith 등) |
AI — Get suggestions | 유입 데이터 필드 분포 분석 후 적절한 분기 조건 자동 제안 |
Child stream 자동 생성 | 규칙 저장 시 logs.s-core 같은 child data stream 자동 생성 |
설정 상속 | 부모 스트림의 Processing · Schema · Retention 설정이 자식에 자동 전파 |
Partitioning vs 기존 Reroute Processor
기존에는 인제스트 파이프라인에 reroute 프로세서를 수동 작성했습니다. Partitioning 탭은 이를 UI로 추상화하며, 생성된 조건은 내부적으로 @stream.processing 파이프라인에 자동 반영됩니다.•
Suggest Partitions 사용 시, LLM으로 로그를 처리하여 datastream을 분기 처리할 수 있는 패턴을 제안
3) Processing
인입 문서에서 필드를 파싱·추출하는 ingest 단계를 관리하고, 내부적으로는 @stream.processing 파이프라인을 자동 생성·갱신합니다.
기능 | 설명 |
Grok / Dissect / Date 등 프로세서 추가 | 비정형 로그에서 구조화 필드 추출. UI에서 직접 패턴 작성 가능 |
AI - Generate Pattern | 유입 문서 100건 샘플링 후 LLM이 Grok 패턴 자동 제안. 수락 전 시뮬레이션(diff 뷰) 제공 |
저장 전 시뮬레이션 | 파이프라인 변경 없이 100건 미리보기 — 파싱 성공률·매핑 충돌 사전 감지 |
4) Schema
스트림의 필드 매핑을 관리합니다. 내부적으로 component template(managed)을 자동 생성·갱신합니다.
기능 | 설명 |
필드 타입 선언 | keyword / text / long / date 등 필드 타입 UI에서 직접 선언 |
상속 필드 확인 | 부모 스트림에서 내려온 inherited_fields 목록 표시 |
Processing 연동 | Grok으로 추출된 신규 필드를 Schema에서 바로 타입 지정 가능 |
스키마 변경은 다음 rollover부터 적용
Schema 탭에서 필드 타입 변경 → managed component template 업데이트 → 기존 backing index에는 소급 적용되지 않습니다. 다음 rollover 이후 생성되는 backing index부터 적용됩니다. 기존 필드 타입 변경이 필요하면 reindex를 고려하세요.5) Data Quality
인제스트 과정에서 발생한 파싱 실패(failed) 및 필드 무시(degraded) 문서의 현황을 모니터링합니다. 내부적으로 ES|QL 쿼리 3개를 실행해 집계한 결과를 시각화합니다.
항목 | 설명 |
Degraded 문서 | _ignored 필드가 있는 문서. 매핑 불일치, ignore_above 초과 등으로 일부 필드가 인덱싱에서 제외된 경우. 문서 자체는 저장되나 해당 필드 값은 누락됨 |
Failed 문서 | 매핑 충돌·파이프라인 오류로 인제스트 자체가 거부된 문서. Failure Store 활성화 시 ::failures 인덱스에 보관되어 재처리 가능 |
품질 등급 자동 산정 | Good: degraded/failed 모두 0% / Degraded: 어느 하나라도 0% 초과 ~ 3% 이하 / Poor: 어느 하나라도 3% 초과 |
시계열 차트 | 시간대별 degraded/failed 문서 추이 — 문제 발생 시점 파악 |
이슈 테이블 | 원인 필드·영향 문서 수·해결 방법 안내. “현재 미해결 이슈만” 필터 지원 |
알림 규칙 생성 | Degraded 문서 비율이 임계값 초과 시 Alert 발송 규칙 연동 |
Data Quality는 ML Anomaly Detection을 대체하는가?결론: 아니오. 목적이 완전히 다릅니다.구분 | Streams Data Quality | ML Anomaly Detection |
목적 | 인제스트 파이프라인 오류 탐지 | 비즈니스/운영 데이터의 이상 패턴 탐지 |
감지 대상 | 매핑 충돌, 파이프라인 실패, 필드 무시 | 시계열 데이터의 통계적 이상값 (급증/급감 등) |
ML 사용 여부 | ES | QL 기반 단순 집계 |
설정 필요성 | 설정 불필요, 자동 활성화 | Job 생성·bucket span·학습 기간 설정 필요 |
라이선스 | 기본 포함 | Platinum 이상 |
질문 유형 | “왜 데이터가 제대로 안 들어왔나?” | “지금 비정상적인 패턴이 있나?” |
→ Data Quality는 데이터 파이프라인 헬스 체크, ML Anomaly Detection은 비즈니스 이상 탐지입니다. 두 기능은 상호 보완적으로 사용합니다.
6) Advanced
Streams가 내부적으로 생성한 인덱스 설정을 직접 조정합니다.
기능 | 설명 |
Index 설정 조정 | shard 수, replica 수, refresh interval 등 직접 변경 |
managed 컴포넌트 ES API 직접 수정 금지
모든 내용은 Streams가 소유합니다. ES API (PUT _index_template/..., PUT _ingest/pipeline/...) 로 직접 수정하면 Streams 동기화가 깨집니다. 항상 Streams UI / API를 통해서만 수정 필요.ES 내부 구조 — Streams가 실제로 무엇을 만드는가
1) 기존 수동 방식 vs Kibana Streams
기존 방식 (수동) | Kibana Streams (자동 관리) |
① ILM Policy — hot → warm → delete 단계별 직접 설정 | Retention 탭 — 보존 기간 설정 → /_data_stream/_settings 즉시 전파 |
② Index Template — PUT _index_template/logs-myapp | 스트림 자체 생성 → managed index template 자동 생성 |
③ Component Template (매핑) — PUT _component_template/logs-myapp@mappings | Schema 탭 → managed component template 자동 생성 |
④ Ingest Pipeline + Grok — PUT _ingest/pipeline/logs-myapp-pipeline | Processing 탭 + AI Generate Pattern → @stream.processing pipeline 자동 생성 |
⑤ Reroute Processor (분기) — 파이프라인에 reroute 프로세서 수동 작성 | Partitioning 탭 + AI suggestions → child stream 자동 생성, 라우팅 조건 pipeline에 자동 반영 |
⑥ Pipeline Simulate — POST _ingest/pipeline/my-pipeline/_simulate | Processing 탭 저장 전 자동 시뮬레이션 → diff 뷰로 필드 변화 확인, 매핑 충돌 사전 감지 |
2) 문서 인제스트 플로우 (Wired 기준)
Filebeat (index: "logs")
│
▼
logs 루트 스트림 수신
│
├─ @stream.processing 파이프라인 실행
│ ├─ Grok 파싱 (Processing 탭에서 설정)
│ └─ Reroute 조건 평가 (Partitioning 탭에서 설정)
│
├─ service.name = "api-gateway" → logs.api-gateway (child stream)
├─ service.name = "batch-worker" → logs.batch-worker (child stream)
├─ service.name = "admin-portal" → logs.admin-portal (child stream)
└─ 조건 미해당 → logs 루트 backing index
Plain Text
복사
3) Classic vs Wired: ES 레벨 영향 범위
항목 | Classic 모드 | Wired 모드 |
기존 Index Template | 그대로 유지 | 신규 생성 (managed) |
기존 ILM 정책 | 그대로 유지 | Streams Retention으로 관리 |
Component Template | 그대로 유지 | 신규 생성 (managed) |
@stream.processing Pipeline | Processing 설정 시 생성 | Processing 설정 시 생성 |
기존 템플릿 충돌 위험 | 없음 | logs-- priority 충돌 가능 |
Partitioning / 계층 상속 | 미지원 | 지원 |
추천 용도 | 기존 클러스터 온보딩, 리스크 최소 | 신규 파이프라인·분기 설계 |
S-Core 시나리오 실습 — 앱 로그 수집부터 분기까지 (Wired 모드)
시나리오 전제조건•
Elastic Stack 9.3 (self-managed)
•
Filebeat 9.3.1
•
Kibana → Streams Settings → Enable wired streams ON
•
샘플 로그: /var/log/s-core/app.log (스프링부트 앱 발생 로그)
컨테이너 | 포트 | SERVICE_NAME | ENVIRONMENT |
s-core-api-gateway | 8080 | api-gateway | production |
s-core-batch-worker | 8081 | batch-worker | production |
s-core-admin-portal | 8082 | admin-portal | development |
Kibana > Streams > Settings의 Wired Streams 활성화 필요
Step 1 — 수집 대상 로그 포맷 확인
샘플 로그에는 3가지 서비스 패턴이 혼재합니다. AI Grok이 학습할 샘플을 먼저 확인합니다.
# app.log 샘플 (패턴별)
# api-gateway
2025-03-04T06:01:58.000Z INFO [api-gateway] [production] GET /api/v1/users 200 244ms
2025-03-04T06:04:00.000Z ERROR [api-gateway] [production] PUT /api/v1/auth 500 121ms - Internal Server Error
# batch-worker
2025-03-04T06:02:50.000Z INFO [batch-worker] [production] Job 'daily-report' completed in 1816ms. records=74273
2025-03-04T06:15:22.000Z ERROR [batch-worker] [production] Job 'data-sync' failed. DB connection timeout after 5000ms. retries=3
# admin-portal
2025-03-04T06:06:44.000Z INFO [admin-portal] [development] Login attempt success. user=operator ip=10.0.0.1
2025-03-04T06:11:24.000Z WARN [admin-portal] [development] Login attempt failed. user=unknown ip=10.0.0.5
Plain Text
복사
공통 포맷:
<timestamp> <level> [<service.name>] [<environment>] <message>
Plain Text
복사
Step 2 — Filebeat 구성
/etc/filebeat/filebeat.yml 전체 설정:
filebeat.inputs:
-type: filestream # 9.x: type: log 제거됨, filestream 필수
id: s-core-app-log # 고유 ID 필수
enabled:true
paths:
- /var/log/s-core/app.log
parsers:
-multiline: # multiline은 parsers: 하위에 위치 (type: log와 다름)
type: pattern
pattern:'^[0-9]{4}-[0-9]{2}-[0-9]{2}'
negate:true
match: after
output.elasticsearch:
hosts:["https://<ES_HOST>:9200"]
username:"elastic"
password:"<PASSWORD>"
ssl:
enabled:true
verification_mode:"none" # 운영 환경에서는 CA 인증서 경로로 교체
index:"logs" # Wired 스트림은 반드시 "logs" 고정
# Streams가 템플릿·lifecycle을 직접 관리하므로 반드시 false
setup.template.enabled:false
setup.ilm.enabled:false
logging.level: info
YAML
복사
index: "logs" 고정 — 왜 logs.s-core를 직접 지정하면 안 되나?
Wired 스트림은 OTel 포맷 기반으로 모든 데이터를 logs 루트 스트림 하나로만 수집합니다.
logs.s-core를 Filebeat index에 직접 지정하면 OTel 변환이 적용되지 않아 Streams UI에서 조회되지 않습니다.
→ logs.s-core child stream은 데이터 유입 후 Partitioning 탭에서 라우팅 규칙으로 생성합니다. Filebeat 9.x 주요 변경사항 (8.x 대비)항목 | 8.x | 9.x |
Input 타입 | type: log 사용 가능 | type: log 완전 제거 → type: filestream 필수 |
filestream id | 선택 | 필수 |
multiline 위치 | input 레벨 직접 설정 | parsers: 하위로 이동 |
최신 버전 | 8.19.x | 9.3.1 |
Step 3 — 데이터 유입 확인
# 문서 수 확인
GET logs/_count
# Response
{
"count": 290,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
}
}
# 최근 문서 샘플 확인
GET logs/_search
{
"size": 3,
"sort": [{ "@timestamp": "desc" }]
}
Bash
복사
Step 4 — Partitioning 탭: child stream 분기
1.
Partitioning 탭 클릭
2.
Get AI suggestions 클릭
3.
제안 수락 또는 수동으로 조건 추가 (Fork API 사용 예시):
POST kbn:/api/streams/logs/_fork
{
"stream": { "name": "logs.admin-portal" },
"where": {
"field": "service.name",
"contains": "gateway"
},
"status": "enabled"
}
Bash
복사
1.
규칙 저장 → logs.admin-portal child stream 자동 생성 확인
Step 5 — Processing 탭: AI Grok 패턴 자동 생성
1.
Kibana → Streams → logs 선택 → Processing 탭
2.
Generate Pattern 클릭 (최소 50건 이상 유입 후 실행 권장)
3.
AI 제안 패턴 확인 — 예상 추출 결과 확인
4.
시뮬레이션 결과 확인 (diff 뷰) — 파싱 성공률 및 추출 필드 확인
5.
Accept → Save changes 클릭
파싱 후 문서 예시// AS-IS
{
"@timestamp": "2026-03-05T05:01:05.169Z",
"body.text": "2026-03-05T04:00:15.000Z INFO [admin-portal] [development] Login attempt success. user=admin ip=10.0.0.1",
"stream.name": "logs.admin-portal"
}
// TO-BE
{
"@timestamp": "2026-03-05T04:00:15.000Z",
"body.text": "Login attempt success user",
"severity_text": "INFO",
"attributes.log.logger": "admin-portal",
"resource.attributes.deployment.environment.name": "development",
"attributes.user.name": "admin",
"attributes.source.ip": "10.0.0.1",
"stream.name": "logs.admin-portal"
}
JSON
복사
•
적용 전 Diff Preview를 확인하여 변경 사항을 확인 가능
Step 6 — 검증
# child stream 존재 확인
GET _data_stream/logs.admin-portal
# child stream의 문서 수
GET logs.admin-portal/_count
# 필드 파싱 확인
GET logs.admin-portal/_search
Bash
복사
최종 체크리스트•
GET logs/_count → 0보다 큰 숫자•
GET /_data_stream/logs.admin-portal → 404 아님•
logs.admin-portal/_search → 파이프라인 적용 필드 정상 파싱•
Kibana → Streams → logs.admin-portal 목록에 표시•
Data Quality 탭 → degraded 문서 0% (Good)QnA
Wired 모드 사용 시 Data View 생성 및 Discover에서 확인이 가능한지? 그리고 사용하는 기본 템플릿이 있는건가요?해당 데이터스트림의 인덱스 패턴으로 별도 Data View를 만들면됩니다.
logs@stream.layer (파티셔닝, 프로세싱 단계에 따라 자동으로 Component Templates가 생성되고 반영)
Data Quality 에서 실패한 내용을 어떻게 분석? 실패하면 어디 적재되는 내용이나 인덱스가 있는걸까요?네. 8.19부터 도입된 데이터스트림 레벨의 옵션인 ’Failure store’으로 저장된 데이터를 봅니다 (.fs- 패턴으로 저장되는 형태)
아래와 같이 설정 가능하며, 9.2버전 부터 새롭게 생성된 데이터스트림에는 자동으로 적용됩니다. (GitHub Issue #131105)
PUT _data_stream/my-datastream-1/_options
{
"failure_store": {
"enabled": false
}
}
Bash
복사
wired 분기라는게 별개의 데이터스트림으로 reroute processor 동작하는건가요?파티션 기능 사용 시, logs@stream.reroutes 라는 ingest pipeline이 자동 생성되며 별개의 데이터 스트림으로 분기처리 합니다.
[
{
"reroute": {
"destination": "logs.admin-portal",
"if": "try { if (($('body.text', null) !== null && $('body.text', null).toLowerCase().contains(\\"admin-portal\\"))) { return true; } return false; } catch (Exception e) { return false; }"
}
},
{
"reroute": {
"destination": "logs.api-gateway",
"if": "try { if (($('body.text', null) !== null && $('body.text', null).toLowerCase().contains(\\"api-gateway\\"))) { return true; } return false; } catch (Exception e) { return false; }"
}
}
]
JSON
복사
참고 자료
3) Processing
인입 문서에서 필드를 파싱·추출하는 ingest 단계를 관리하고, 내부적으로는 '@stream.processing' 파이프라인을 자동 생성·갱신
Grok / Dissect / Date 등 프로세서 추가 | 비정형 로그에서 구조화 필드 추출. UI에서 직접 패턴 작성 가능 |
AI - Generate Pattern | 유입 문서 100건 샘플링 후 LLM이 Grok 패턴 자동 제안. 수락 전 시뮬레이션(diff 뷰) 제공 |
저장 전 시뮬레이션 | 파이프라인 변경 없이 100건 미리보기 — 파싱 성공률·매핑 충돌 사전 감지 |
4) Schema
스트림의 필드 매핑을 관리합니다. 내부적으로 'component template(managed)'을 자동 생성·갱신합니다.
필드 타입 선언 | keyword / text / long / date 등 필드 타입 UI에서 직접 선언 |
상속 필드 확인 | 부모 스트림에서 내려온 inherited_fields 목록 표시 |
Processing 연동 | Grok으로 추출된 신규 필드를 Schema에서 바로 타입 지정 가능 |
스키마 변경은 다음 rollover부터 적용Schema 탭에서 필드 타입 변경 → managed component template 업데이트 → 기존 backing index에는 소급 적용되지 않습니다. 다음 rollover 이후 생성되는 backing index부터 적용됩니다. 기존 필드 타입 변경이 필요하면 reindex를 고려하세요.
5) Data Quality
인제스트 과정에서 발생한 파싱 실패(failed) 및 필드 무시(degraded) 문서의 현황을 모니터링합니다. 내부적으로 ES|QL 쿼리 3개를 실행해 집계한 결과를 시각화합니다.
Degraded 문서 | _ignored 필드가 있는 문서. 매핑 불일치, ignore_above 초과 등으로 일부 필드가 인덱싱에서 제외된 경우. 문서 자체는 저장되나 해당 필드 값은 누락됨 |
Failed 문서 | 매핑 충돌·파이프라인 오류로 인제스트 자체가 거부된 문서. Failure Store 활성화 시 ::failures 인덱스에 보관되어 재처리 가능 |
품질 등급 자동 산정 | Good: degraded/failed 모두 0%Degraded: 어느 하나라도 0% 초과 ~ 3% 이하Poor: 어느 하나라도 3% 초과 |
시계열 차트 | 시간대별 degraded/failed 문서 추이 — 문제 발생 시점 파악 |
이슈 테이블 | 원인 필드·영향 문서 수·해결 방법 안내. "현재 미해결 이슈만" 필터 지원 |
알림 규칙 생성 | Degraded 문서 비율이 임계값 초과 시 Alert 발송 규칙 연동 |
Data Quality는 ML Anomaly Detection을 대체하는가?결론: 아니오. 목적이 완전히 다릅니다.
목적 | 인제스트 파이프라인 오류 탐지 | 비즈니스/운영 데이터의 이상 패턴 탐지 |
감지 대상 | 매핑 충돌, 파이프라인 실패, 필드 무시 | 시계열 데이터의 통계적 이상값 (급증/급감 등) |
ML 사용 여부 | ES|QL 기반 단순 집계 | 비지도 학습 시계열 모델링 |
설정 필요성 | 설정 불필요, 자동 활성화 | Job 생성·bucket span·학습 기간 설정 필요 |
라이선스 | 기본 포함 | Platinum 이상 |
질문 유형 | "왜 데이터가 제대로 안 들어왔나?" | "지금 비정상적인 패턴이 있나?" |
→ Data Quality는 데이터 파이프라인 헬스 체크, ML Anomaly Detection은 비즈니스 이상 탐지입니다. 두 기능은 상호 보완적으로 사용합니다.
managed 컴포넌트 ES API 직접 수정 금지모든 내용은 Streams가 소유합니다. ES API (PUT _index_template/..., PUT _ingest/pipeline/...) 로 직접 수정하면 Streams 동기화가 깨집니다. 항상 Streams UI / API를 통해서만 수정 필요.
ES 내부 구조 — Streams가 실제로 무엇을 만드는가
1) 기존 수동 방식 vs Kibana Streams
① ILM PolicyPUT _ilm/policy/my-policy# hot → warm → delete 단계별 직접 설정 | Retention 탭 — 보존 기간 설정→ /_data_stream/_settings 즉시 전파 |
② Index TemplatePUT _index_template/logs-myapp | 스트림 자체 생성 → managed index template 자동 생성 |
③ Component Template (매핑)PUT _component_template/logs-myapp@mappings | Schema 탭 → managed component template 자동 생성 |
④ Ingest Pipeline + GrokPUT _ingest/pipeline/logs-myapp-pipeline | Processing 탭 + AI Generate Pattern→ @stream.processing pipeline 자동 생성 |
⑤ Reroute Processor (분기)
파이프라인에 reroute 프로세서 수동 작성 | Partitioning 탭 + AI suggestions→ child stream 자동 생성, 라우팅 조건 pipeline에 자동 반영 |
⑥ Pipeline SimulatePOST _ingest/pipeline/my-pipeline/_simulate | Processing 탭 저장 전 자동 시뮬레이션→ diff 뷰로 필드 변화 확인, 매핑 충돌 사전 감지 |
2) 문서 인제스트 플로우 (Wired 기준)
Filebeat (index: "logs")
│
▼
logs 루트 스트림 수신
│
├─ @stream.processing 파이프라인 실행
│ ├─ Grok 등 파싱 (Processing 탭에서 설정)
│ └─ Reroute 조건 평가 (Partitioning 탭에서 설정)
│
├─ service.name = "api-gateway" → logs.api-gateway (child stream)
├─ service.name = "batch-worker" → logs.batch-worker (child stream)
├─ service.name = "admin-portal" → logs.admin-portal (child stream)
└─ 조건 미해당 → logs 루트 backing index
Markdown
복사
3) Classic vs Wired: ES 레벨 영향 범위
기존 Index Template | 그대로 유지 | 신규 생성 (managed) |
기존 ILM 정책 | 그대로 유지 | Streams Retention으로 관리 |
Component Template | 그대로 유지 | 신규 생성 (managed) |
@stream.processing Pipeline | Processing 설정 시 생성 | Processing 설정 시 생성 |
기존 템플릿 충돌 위험 | 없음 | logs-*-* priority 충돌 가능 |
Partitioning / 계층 상속 | 미지원 | 지원 |
추천 용도 | 기존 클러스터 온보딩, 리스크 최소 | 신규 파이프라인·분기 설계 |
시나리오 실습 — 앱 로그 수집부터 분기까지 (Wired 모드)
시나리오 전제조건
•
Elastic Stack 9.3 (self-managed)
•
Filebeat 9.3.1
•
Kibana → Streams Settings → Enable wired streams ON
•
샘플 로그: /var/log/s-core/app.log (스프링부트 앱 발생 로그)
s-core-api-gateway | 8080 | api-gateway | production |
s-core-batch-worker | 8081 | batch-worker | production |
s-core-admin-portal | 8082 | admin-portal | development |
•
Kibana > Streams > Settings의 Wired Streams 활성화 필요
Step 1 — 수집 대상 로그 포맷 확인
샘플 로그에는 3가지 서비스 패턴이 혼재합니다. AI Grok이 학습할 샘플을 먼저 확인합니다.
app.log 샘플 (패턴별)
# api-gateway
2025-03-04T06:01:58.000Z INFO [api-gateway] [production] GET /api/v1/users 200 244ms
2025-03-04T06:04:00.000Z ERROR [api-gateway] [production] PUT /api/v1/auth 500 121ms - Internal Server Error
# batch-worker
2025-03-04T06:02:50.000Z INFO [batch-worker] [production] Job 'daily-report' completed in 1816ms. records=74273
2025-03-04T06:15:22.000Z ERROR [batch-worker] [production] Job 'data-sync' failed. DB connection timeout after 5000ms. retries=3
# admin-portal
2025-03-04T06:06:44.000Z INFO [admin-portal] [development] Login attempt success. user=operator ip=10.0.0.1
2025-03-04T06:11:24.000Z WARN [admin-portal] [development] Login attempt failed. user=unknown ip=10.0.0.5
JavaScript
복사
공통 포맷:
<timestamp> <level> [<service.name>] [<environment>] <message>
Step 2 — Filebeat 구성
/etc/filebeat/filebeat.yml 전체 설정:
filebeat.yml
filebeat.inputs:
- type: filestream # 9.x: type: log 제거됨, filestream 필수
id: s-core-app-log # 고유 ID 필수
enabled: true
paths:
- /var/log/s-core/app.log
parsers:
- multiline: # multiline은 parsers: 하위에 위치 (type: log와 다름)
type: pattern
pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
negate: true
match: after
output.elasticsearch:
hosts: ["https://<ES_HOST>:9200"]
username: "elastic"
password: "<PASSWORD>"
ssl:
enabled: true
verification_mode: "none" # 운영 환경에서는 CA 인증서 경로로 교체
index: "logs" # Wired 스트림은 반드시 "logs" 고정
# Streams가 템플릿·lifecycle을 직접 관리하므로 반드시 false
setup.template.enabled: false
setup.ilm.enabled: false
logging.level: info
Plain Text
복사
index: "logs" 고정 — 왜 logs.s-core를 직접 지정하면 안 되나?Wired 스트림은 OTel 포맷 기반으로 모든 데이터를 'logs' 루트 스트림 하나로만 수집합니다.
logs.s-core를 Filebeat index에 직접 지정하면 OTel 변환이 적용되지 않아 Streams UI에서 조회되지 않습니다.
→ logs.s-core child stream은 데이터 유입 후 Partitioning 탭에서 라우팅 규칙으로 생성합니다.
Filebeat 9.x 주요 변경사항 (8.x 대비)
Input 타입 | type: log 사용 가능 | type: log 완전 제거 → type: filestream 필수 |
Filestream id | 선택 | 필수 |
multiline 위치 | input 레벨 직접 설정 | parsers: 하위로 이동 |
최신 버전 | 8.19.x | 9.3.1 |
Step 3 — 데이터 유입 확인
Dev Tools — 수집 확인
# 문서 수 확인
GET logs/_count
# Response
{
"count": 290,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
}
}
# 최근 문서 샘플 확인
GET logs/_search
{
"size": 3,
"sort": [{ "@timestamp": "desc" }]
}
Markdown
복사
Step 4 — Partitioning 탭: child stream 분기
1.
Partitioning 탭 클릭
2.
Get AI suggestions 클릭
Step 5 — Processing 탭: AI Grok 패턴 자동 생성
1.
Kibana → Streams → logs 선택 → Processing 탭
2.
Generate Pattern 클릭 (최소 50건 이상 유입 후 실행 권장)
3.
AI 제안 패턴 확인 — 예상 추출 결과:
Step 6 — 검증
Dev Tools — child stream 확인
# child stream 존재 확인
GET _data_stream/logs.admin-portal
# child stream의 문서 수
GET logs.admin-portal/_count
# 필드 파싱 확인
GET logs.admin-portal/_search
Markdown
복사
최종 체크리스트•
GET logs/_count → 0보다 큰 숫자•
GET /_data_stream/logs.admin-portal → 404 아님•
logs.admin-portal/_search → 파이프라인 적용 필드 정상 파싱•
Kibana → Streams → logs.admin-portal 목록에 표시•
Data Quality 탭 → degraded 문서 0% (Good)QnA
Wired 모드 사용 시 Data View 생성 및 Discover에서 확인이 가능한지? 그리고 사용하는 기본 템플릿이 있는건가요?해당 데이터스트림의 인덱스 패턴으로 별도 Data View를 만들면 됩니다.
logs@stream.layer (파티셔닝, 프로세싱 단계에 따라 자동으로 Componernt Templates가 생성되고 반영)
Data Quality 에서 실패한 내용을 어떻게 분석? 실패하면 어디 적재되는 내용이나 인덱스가 있는걸까요?네. 8.19부터 도입된 데이터스트림 레벨의 옵션인 'Failure store'으로 저장된 데이터를 봅니다 (.fs- 패턴으로 저장되는 형태)
아래와 같이 설정 가능하며, 9.2버전 부터 새롭게 생성된 데이터스트림에는 자동으로 적용됩니다. (https://github.com/elastic/elasticsearch/issues/131105)
PUT _data_stream/my-datastream-1/_options
{
"failure_store": {
"enabled": false
}
}
JSON
복사
wired 분기라는게 별개의 데이터스트림으로 reroute processor 동작하는건가요?파티션 기능 사용 시, 'logs@stream.reroutes' 라는 ingest pipeline이 자동 생성되며 별개의 데이터 스트림으로 분기처리 합니다.
[
{
"reroute": {
"destination": "logs.admin-portal",
"if": " try { if (($('body.text', null) !== null && (($('body.text', null) instanceof Number && $('body.text', null).toString().toLowerCase().contains(\"admin-portal\")) || $('body.text', null).toLowerCase().contains(\"admin-portal\")))) { return true; } return false; } catch (Exception e) { return false; } "
}
},
{
"reroute": {
"destination": "logs.api-gateway",
"if": " try { if (($('body.text', null) !== null && (($('body.text', null) instanceof Number && $('body.text', null).toString().toLowerCase().contains(\"api-gateway\")) || $('body.text', null).toLowerCase().contains(\"api-gateway\")))) { return true; } return false; } catch (Exception e) { return false; } "
}
}
]
JavaScript
복사
참고 자료
반윤성 프로
에스코어에서 Elastic Stack 구축 및 기술지원 업무를 수행하고 있습니다.