Iperf3로 슬라이스별 UE 트래픽과 FlexRIC KPM 모니터링 구현하기

Slice별 트래픽 주입하기

---

현재 총 3개의 Slice에 각각 3개의 UE를 붙여놓은 상황.

이제 실제로 각 UE (총 9명의 UE)에 eMBB·URLLC·mMTC 슬라이스별 트래픽을 지속적으로 발생시키도록 구성한다.

트래픽은 실제 애플리케이션 사용 패턴에서 추출한 CSV 데이터를 기반으로 iperf3를 통해 재생한다.

 

 

 

현재 테스트베드 구성

---

클러스터는 4개의 노드로 구성했다.

노드	역할	IP
master-node	Kubernetes control-plane	192.168.56.50
oai-ran	OAI gNB, FlexRIC, UE 9대	192.168.56.30
free5gc-cp	AMF, SMF 등 Free5GC Control Plane	192.168.56.51
free5gc-up	UPF, iperf3 server	192.168.56.52

UE Pod
  └─ oaitun_ue1
       ↓
OAI gNB
       ↓ N3 / GTP-U
Free5GC UPF
       ↓
iperf3 server

 

Control Plane은 free5gc-cp 노드에, User Plane은 free5gc-up 노드에 분리했다.

RAN 관련 워크로드는 oai-ran 노드에서 실행한다.

 

 

트러블슈팅 1: UE는 9개인데 터널은 하나뿐이었다

---

겉으로는 정상처럼 보이긴 했음.

 

처음에는 UE1부터 UE9까지 모두 다음과 같이 hostNetwork: true로 실행했다.

spec:
  hostNetwork: true

 

각 UE 로그에서는 다음 절차가 모두 정상으로 보였다.

• Registration Accept
• PDU Session Establishment Accept
• UE IP 할당
• gNB 연결 성공

따라서 처음에는 9개의 UE가 모두 정상 연결된 것으로 판단했다.

하지만 실제 터널 인터페이스를 확인하니, 가장 최근에 접속한 UE 하나만 oaitun_ue1을 보유하고 있었다.

 

 

원인: 모든 UE가 같은 네트워크 네임스페이스를 공유했다

 

OAI nr-uesoftmodem은 UE 번호와 관계없이 터널 인터페이스 이름을 기본적으로 다음과 같이 생성한다.

oaitun_ue1

 

UE1은 oaitun_ue1, UE2는 oaitun_ue2처럼 자동으로 분리되지 않는다.

여기에 hostNetwork: true를 사용하면 모든 UE Pod가 oai-ran 노드의 호스트 네트워크 네임스페이스를 공유한다.

결국 9개의 UE 프로세스가 하나의 이름을 가진 인터페이스를 동시에 생성하려는 구조가 된다.

UE1 ─┐
UE2 ─┤
UE3 ─┤
...  ├─> 동일한 host network namespace
UE9 ─┘        └─ oaitun_ue1 하나

 

새로운 UE가 접속하면서 oaitun_ue1을 다시 만들면 기존 UE가 사용하던 터널이 사라지거나 덮어써진다.

즉, 로그상으로는 9개 UE가 모두 등록되지만 실제 User Plane 터널은 마지막 UE 하나만 유지되는 상태였다.

 

 

 

해결: UE마다 독립된 Pod 네트워크 네임스페이스 사용

---

UE Pod에서 hostNetwork를 제거했다.

spec:
  hostNetwork: false

 

Kubernetes와 Calico는 각 Pod에 독립적인 네트워크 네임스페이스를 제공한다.

이제 각 UE Pod 안에는 동일한 이름의 oaitun_ue1이 존재해도 서로 충돌하지 않는다.

UE1 Pod netns
  └─ oaitun_ue1

UE2 Pod netns
  └─ oaitun_ue1

UE3 Pod netns
  └─ oaitun_ue1

 

인터페이스 이름은 같지만 네트워크 네임스페이스가 다르기 때문에 완전히 독립적인 인터페이스다.

 

 

RF Simulator 연결 주소 변경

---

기존에는 UE와 gNB가 동일한 host network를 사용했기 때문에 UE에서 RF Simulator 주소를 다음처럼 지정할 수 있었다.

127.0.0.1

 

하지만 UE Pod가 독립 네트워크 네임스페이스로 분리되면 127.0.0.1은 UE Pod 자신을 의미한다.

따라서 다음 옵션을 gNB가 실행되는 노드 IP로 변경했다.

--rfsimulator.serveraddr 192.168.56.30

 

gNB의 RF Simulator가 이미 다음 주소에서 리슨하고 있었기 때문에 가능한 구성이다.

0.0.0.0:4043

 

UE Pod에서 192.168.56.30:4043으로 접근하면 gNB RF Simulator와 연결할 수 있다.

 

 

최종 UE 주소 구성

---

9개의 UE가 동시에 연결된 상태에서 각 UE의 PDU Session 주소는 다음과 같이 할당됐다.

UE	슬라이스	PDU 주소
UE1	eMBB	10.60.0.1
UE2	eMBB	10.60.0.2
UE3	eMBB	10.60.0.3
UE4	URLLC	10.61.0.1
UE5	URLLC	10.61.0.2
UE6	URLLC	10.61.0.3
UE7	mMTC	10.62.0.1
UE8	mMTC	10.62.0.2
UE9	mMTC	10.62.0.3

 

서로 다른 슬라이스의 UE1과 UE9에서 동시에 ping을 실행한 결과 두 UE 모두 패킷 손실 0%를 기록했다.

이 단계에서 실제 User Plane 기준으로 9개의 UE가 동시에 동작한다는 것을 확인했다.

 

 

슬라이스별 UE 구성

---

각 UE의 NSSAI와 트래픽 데이터셋을 다음과 같이 매핑했다.

UE	슬라이스	NSSAI	데이터셋	UL 포트	DL 포트
UE1	eMBB	sst:1 / sd:000001	Amazon Prime	5201	5301
UE2	eMBB	sst:1 / sd:000001	GeForce Now	5202	5302
UE3	eMBB	sst:1 / sd:000001	YouTube Live	5203	5303
UE4	URLLC	sst:2 / sd:000002	Battleground	5204	5304
UE5	URLLC	sst:2 / sd:000002	Teamfight Tactics	5205	5305
UE6	URLLC	sst:2 / sd:000002	Zoom	5206	5306
UE7	mMTC	sst:3 / sd:000003	Roblox #1	5207	5307
UE8	mMTC	sst:3 / sd:000003	Roblox #2	5208	5308
UE9	mMTC	sst:3 / sd:000003	Zepeto	5209	5309

 

각 데이터셋은 ETRI에서 수집한 5G Production Dataset을 가공하여 사용하였다.

데이터셋 : https://www.kaggle.com/datasets/kimdaegyeom/5g-traffic-datasets

5G Traffic Datasets

 

 

각 UE는 UL과 DL에 서로 다른 포트를 사용한다.

총 포트 수는 다음과 같다.

UE 9대 × UL/DL 2개 = 18개 포트

 

UL은 UE에서 서버 방향으로 전송한다.

UE → UPF → iperf3 server

 

DL은 서버가 UE 방향으로 전송하도록 구성한다.

iperf3 server → UPF → UE

 

 

 

 

iperf3 트래픽 주입 방식

---

슬라이스별 트래픽을 발생시키기 위해 세 가지 방식을 순서대로 사용했다.

방식	실행 위치	csv 한 행 처리 시간	결과
수동 실행	kubectl exec	해당 없음	단발 검증용
중앙 오케스트레이션	master-node	약 2~4초	느리고 API 서버 부하 발생
Pod 사이드카	UE Pod 내부	약 1초	최종 채택

 

첫 번째 방식: 수동 kubectl exec

---

초기 검증에서는 다음과 같이 직접 iperf3를 실행했다.

kubectl exec -n oai-ran oai-nr-ue1 -- \
  iperf3 -c <SERVER_IP> \
  -B 10.60.0.4 \
  -p 5201 \
  -u \
  -b 20M \
  -t 5

 

이 방식은 특정 UE의 데이터 경로가 정상인지 확인하기에는 충분하다.

하지만 9개 UE가 매초 다른 UL/DL 속도를 재생해야 하는 운영 구조에는 적합하지 않다.

 

 

두 번째 방식: master-node 오케스트레이션

---

다음으로 master-node에서 CSV를 읽고, UE별로 매초 kubectl exec를 호출하는 스크립트를 작성했다.

개념적으로는 다음과 같은 구조다.

while read -r timestamp ul dl; do
  kubectl exec ue1 -- iperf3 ...
  kubectl exec ue2 -- iperf3 ...
  kubectl exec ue3 -- iperf3 ...
done

 

문제는 kubectl exec가 단순한 로컬 프로세스 실행이 아니라는 점이다.

호출할 때마다 다음 과정이 필요하다.

1. Kubernetes API 서버 인증
2. 대상 Pod 및 컨테이너 조회
3. SPDY 또는 WebSocket 기반 exec 스트림 생성
4. 컨테이너 런타임에 명령 전달
5. stdout·stderr 스트림 회수
6. 연결 종료

실제 iperf3를 돌려보니까 호출 하나에 약 2~4초가 걸렸다.

UE 9대에 대해 UL과 DL 명령을 매초 실행하면 이론적으로 매초 18회의 exec 호출이 필요하다.

9 UE × 2 directions = 18 exec calls/sec

 

하지만 호출 하나가 이미 수 초가 걸리기 때문에 CSV의 1초 단위 타임라인을 따라갈 수 없었다.

5행짜리 스모크 테스트도 몇 분이 걸렸고, API 서버 부하도 증가했다.

 

 

세 번째 방식: UE Pod 내부의 traffic-gen 사이드카

---

최종적으로 트래픽 생성기를 각 UE Pod 안에 사이드카로 넣었다.

Kubernetes에서 같은 Pod에 속한 컨테이너는 다음 리소스를 공유할 수 있다.

• 네트워크 네임스페이스
• Pod IP
• loopback 인터페이스
• 라우팅 테이블
• Pod 내부 가상 인터페이스

따라서 nr-ue 컨테이너와 traffic-gen 컨테이너는 동일한 oaitun_ue1을 볼 수 있다.

UE Pod
├─ nr-ue
│   └─ nr-uesoftmodem
│       └─ oaitun_ue1 생성
│
└─ traffic-gen
    └─ iperf3 실행
        └─ 동일한 oaitun_ue1 사용

 

OAI UE 이미지에 이미 bash, iperf3, ip가 포함되어 있도록 하면,

별도의 traffic generator 이미지를 빌드할 필요 없이 동일 이미지를 사이드카에 재사용할 수 있다.

 

 

 

ConfigMap의 역할

---

각 UE는 서로 다른 CSV 트래픽 데이터를 사용한다.

예를 들어 UE1은 Amazon Prime 패턴, UE2는 GeForce Now 패턴을 재생한다.

이 CSV 파일을 컨테이너 이미지에 직접 넣는 방법도 있지만, 그러면 CSV를 변경할 때마다 이미지를 다시 빌드해야 한다.

 

Kubernetes의 ConfigMap은 설정 파일이나 비밀이 아닌 일반 데이터를 Kubernetes 오브젝트로 저장하고,
이를 Pod에 파일 또는 환경변수 형태로 주입하기 위한 리소스다.

이번 구성에서는 UE별 CSV 파일을 ConfigMap으로 저장했다.

ue1-traffic-csv
ue2-traffic-csv
...
ue9-traffic-csv

 

예를 들어 다음과 같이 ConfigMap을 생성할 수 있다.

kubectl create configmap ue1-traffic-csv \
  -n oai-ran \
  --from-file=traffic.csv=ue1.csv

 

생성된 ConfigMap은 개념적으로 다음과 같은 데이터를 가진다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ue1-traffic-csv
  namespace: oai-ran
data:
  traffic.csv: |
    timestamp,ul_mbps,dl_mbps
    0,12.5,32.1
    1,10.4,35.7
    2,14.8,28.6

 

Pod에서는 ConfigMap을 volume으로 선언한다.

volumes:
  - name: traffic-csv
    configMap:
      name: ue1-traffic-csv

 

그리고 traffic generator 컨테이너에 파일로 마운트한다.

volumeMounts:
  - name: traffic-csv
    mountPath: /traffic
    readOnly: true

 

최종적으로 컨테이너 내부에서는 다음 경로로 CSV를 읽을 수 있다.

/traffic/traffic.csv

 

ConfigMap을 사용함으로써 얻는 장점은 다음과 같다.

• CSV 변경 시 컨테이너 이미지 재빌드 불필요
• UE별 데이터셋을 Kubernetes 리소스로 관리 가능
• Git으로 YAML 또는 원본 CSV 버전 관리 가능
• Pod와 데이터셋의 매핑이 명확함
• 배포 자동화가 쉬움

ConfigMap은 대규모 바이너리 데이터 저장용은 아니지만, 수천 행 수준의 텍스트 CSV를 Pod에 주입하는 용도로는 적합하다.

 

 

traffic-gen 사이드카 동작 방식

---

traffic generator는 다음 순서로 시작한다.

 

UE 터널 생성 대기

 

traffic-gen은 nr-ue보다 먼저 시작할 수 있다.

따라서 oaitun_ue1이 생길 때까지 대기한다.

until ip link show oaitun_ue1 >/dev/null 2>&1; do
  echo "waiting for oaitun_ue1..."
  sleep 2
done

 

 

 

PDU 주소 확인

 

터널이 생기면 해당 인터페이스의 IPv4 주소를 가져온다.

UE_IP=$(
  ip -4 addr show oaitun_ue1 |
  awk '/inet / {print $2}' |
  cut -d/ -f1
)

 

예를 들어 UE1이라면 다음 값이 나온다.

10.60.0.1

 

 

 

iperf3 서버 주소로 /32 경로 추가

 

트래픽이 반드시 oaitun_ue1을 통과하도록 iperf3 서버 주소에 대해 host route를 추가한다.

ip route replace ${IPERF_SERVER_IP}/32 dev oaitun_ue1

 

여기서 /32는 특정 서버 IP 하나만 터널로 보내겠다는 의미다.

예를 들어:

ip route replace 10.96.120.10/32 dev oaitun_ue1

 

기본 경로 전체를 바꾸지 않기 때문에 Kubernetes 내부 통신과 DNS 통신에는 영향을 최소화할 수 있다.

 

 

 

CSV 무한 반복

 

traffic generator는 /traffic/traffic.csv를 한 줄씩 읽는다.

while true; do
  tail -n +2 /traffic/traffic.csv |
  while IFS=',' read -r timestamp ul_mbps dl_mbps; do
    run_ul "$ul_mbps"
    run_dl "$dl_mbps"
    sleep 1
  done
done

 

CSV 끝에 도달하면 다시 첫 번째 행부터 반복한다.

따라서 Pod가 실행되는 동안 트래픽도 계속 발생한다.

 

 

UL과 DL iperf3 실행

---

UL 트래픽

 

UL은 UE가 클라이언트가 되어 서버로 송신한다.

iperf3 \
  -c "${IPERF_SERVER_IP}" \
  -p "${UL_PORT}" \
  -B "${UE_IP}" \
  -u \
  -b "${UL_MBPS}M" \
  -t 1 \
  --connect-timeout 1000

 

주요 옵션은 다음과 같다.

옵션	의미
-c	iperf3 서버 주소
-p	UE별 UL 포트
-B	PDU Session 주소에 bind
-u	UDP 사용
-b	목표 대역폭
-t 1	1초 동안 전송

 

-B 옵션이 중요하다.

-B 10.60.0.4

 

이 옵션으로 iperf3 소켓을 UE의 PDU 주소에 bind하여 패킷이 OAI 터널 경로를 사용하도록 한다.

 

 

DL 트래픽

 

DL은 iperf3 reverse mode를 사용할 수 있다.

iperf3 \
  -c "${IPERF_SERVER_IP}" \
  -p "${DL_PORT}" \
  -B "${UE_IP}" \
  -u \
  -b "${DL_MBPS}M" \
  -t 1 \
  -R \
  --connect-timeout 1000

 

-R 옵션을 사용하면 클라이언트와 서버의 데이터 송신 방향이 반대로 바뀐다.

일반 모드:
UE client → server

Reverse 모드:
server → UE client

 

따라서 UE에서 명령을 시작하더라도 실제 데이터는 서버에서 UE 방향으로 전달된다.

 

 

iperf3 서버 구성

---

처음에는 단일 Pod로 서버를 실행했지만, 재시작 시 Pod IP가 변경되는 문제가 있었다.

최종적으로 다음 구조로 변경했다.

• Deployment
• ClusterIP Service
• UL/DL 18개 포트 상시 리슨

iperf3-server Deployment
       ↓
iperf3-server Service
       ↓
고정된 ClusterIP

 

Pod가 재시작되어도 Service 주소는 유지되므로 UE 측 /32 라우트의 목적지 주소가 바뀌지 않는다.

 

 

서버의 다중 포트 리스닝

 

iperf3 서버 프로세스 하나는 일반적으로 하나의 포트에서 대기한다.

따라서 18개 포트를 사용하려면 포트마다 서버 프로세스를 실행해야 한다.

for port in $(seq 5201 5209) $(seq 5301 5309); do
  iperf3 -s -p "$port" &
done

wait

 

서버 로그에서는 다음과 같이 UE별 세션이 독립적으로 생성된다.

Server listening on 5301
Accepted connection from 20.96.53.173
local 20.96.53.169 port 5301 connected to 20.96.53.173

 

 

 

 

FlexRIC Pod의 최종 구조

---

oai-flexric Pod에는 두 개의 컨테이너가 존재한다.

oai-flexric Pod
├─ nearrt-ric
│   └─ FlexRIC nearRT-RIC
│
└─ xapp-kpm-moni
    └─ KPM monitor xApp

 

두 컨테이너는 같은 Pod에 있으므로 동일한 네트워크 네임스페이스를 공유한다.

기존 FlexRIC 구성이 host network를 사용하고 있다면 E42 연결에 별도의 Kubernetes Service가 필요하지 않다.

xApp은 RIC의 로컬 또는 지정된 E42 주소로 직접 연결할 수 있다.

 

 

xapp_kpm_moni의 동작 특성

---

xapp_kpm_moni는 영구 데몬으로 설계된 프로세스라기보다 일정 시간 KPM을 구독하고 종료하는 예제 또는 테스트 성격의 xApp이다. 실행이 끝나면 다음과 같은 로그를 남긴다.

[xApp]: E42 RIC_SUBSCRIPTION_DELETE_REQUEST tx
[xApp]: E42 SUBSCRIPTION DELETE RESPONSE rx
[xApp]: Successfully stopped
Test xApp run SUCCESSFULLY

 

따라서 컨테이너의 메인 프로세스로 한 번만 실행하면 컨테이너도 함께 종료된다.

이를 상시 수집기로 사용하기 위해 반복 실행 구조를 적용했다.

while true; do
  xapp_kpm_moni
  sleep 30
done

 

이 구조에서는 다음 순서가 반복된다.

1. E42 연결
2. xApp 등록
3. E2 Node 확인
4. KPM subscription
5. KPM indication 수신
6. subscription 해제
7. xApp 종료
8. 30초 대기
9. 재실행

완전한 연속 subscription은 아니지만, 별도의 xApp 코드를 수정하지 않고도 장시간 KPM을 반복 수집할 수 있다.

 

 

실제 트래픽과 KPM 측정 결과

---

60 Mbps 수준의 UDP UL 트래픽을 발생시키는 동안 xapp_kpm_moni에서 다음 값이 관찰됐다.

DRB.UEThpUl = 52,373 ~ 63,009 [kbps]

RRU.PrbTotUl = 44 ~ 53 [PRBs]

DRB.PdcpSduVolumeUL = 52,108 ~ 62,666 [kb]

 

각 지표는 다음 의미를 가진다.

 

 

DRB.UEThpUl

 

UE의 DRB 기준 UL 처리량이다.

약 52~63 Mbps

 

60 Mbps로 설정한 iperf3 UL 트래픽과 유사한 범위가 측정됐다.

 

 

 

RRU.PrbTotUl

UL에서 사용된 Physical Resource Block 수다.

44~53 PRBs

 

트래픽 부하가 증가하면 일반적으로 스케줄러가 더 많은 UL PRB를 할당한다.

 

 

 

DRB.PdcpSduVolumeUL

 

PDCP 계층에서 처리된 UL SDU 데이터 볼륨이다.

약 52,000~62,000 kb

 

iperf3 트래픽이 실제 RAN 프로토콜 스택을 통과하고 있음을 확인할 수 있는 지표다.

 

 

 

 

트래픽 생성기와 KPM 모니터링은 독립적으로 동작한다.

---

이번 구현에서 중요한 점은 트래픽 생성과 모니터링이 서로 독립적으로 동작한다는 것이다.

traffic-gen sidecar
  └─ iperf3로 60 Mbps UL 생성

FlexRIC xApp
  └─ gNB에서 약 52~63 Mbps UL KPM 관찰

 

traffic generator는 UE Pod 안에서 실행되며 FlexRIC을 직접 참조하지 않는다.

xApp은 nearRT-RIC을 통해 gNB의 KPM만 구독하며 traffic generator를 직접 알지 못한다.

두 시스템이 독립적으로 거의 같은 처리량을 관찰했다는 것은 다음 데이터 경로가 실제로 동작한다는 의미다.

CSV
 → iperf3
 → UE PDU interface
 → OAI protocol stack
 → gNB scheduler
 → GTP-U
 → UPF
 → iperf3 server

 

동시에 다음 모니터링 경로도 정상이다.

gNB
 → E2SM-KPM
 → nearRT-RIC
 → E42
 → xapp_kpm_moni

 

 

 

 

최종 Kubernetes 구성

---

UE Pod

---

각 UE Pod에는 최소 두 개의 컨테이너가 있다.

spec:
  containers:
    - name: nr-ue
      image: oai-nr-ue:latest

    - name: traffic-gen
      image: oai-nr-ue:latest

 

 

traffic generator는 ConfigMap으로부터 CSV를 받는다.

volumes:
  - name: traffic-csv
    configMap:
      name: ue1-traffic-csv

volumeMounts:
  - name: traffic-csv
    mountPath: /traffic

 

이런 방식으로 총 9개의 UE로 Traffic을 흘려보낸다.

 

 

 

 

iperf3 서버

---

Deployment
├─ 5201~5209 UL server
└─ 5301~5309 DL server

Service
└─ 고정 ClusterIP

 

 

 

 

FlexRIC Pod

---

oai-flexric
├─ nearrt-ric
└─ xapp-kpm-moni

 

xApp은 다음 정책으로 실행된다.

초기 대기: 60초
종료 후 재시도: 30초

 

 

 

 

운영상 주의할 점

---

hostNetwork 사용 시 인터페이스 이름 충돌

 

동일 노드에서 여러 UE가 같은 터널 인터페이스 이름을 생성하면 hostNetwork를 사용하면 안 된다.

OAI UE가 향후 UE별 인터페이스 이름을 설정할 수 있도록 개선되지 않는 한, Pod별 네트워크 네임스페이스 분리가 필요하다.

 

 

Pod 안에서 추가한 라우트의 영향 범위

 

Pod가 일반적인 Calico 네트워크를 사용하면 라우트 변경은 해당 Pod 네임스페이스에만 적용된다.

반대로 hostNetwork: true인 Pod에서 라우트를 추가하면 노드 전체 라우팅 테이블을 변경한다.

이전 구성에서는 UE Pod에서 서버 Pod IP에 /32 경로를 추가하면서 호스트 라우팅을 오염시킨 적이 있었다.

server Pod IP → oaitun_ue1

 

서버 Pod가 같은 노드에 있으면 Calico의 실제 Pod 경로와 충돌할 수 있다.

따라서 UE를 일반 Pod 네트워크로 분리한 현재 구조가 라우팅 안전성 측면에서도 더 적절하다.

 

 

ConfigMap 크기

 

ConfigMap은 대형 데이터 저장소가 아니다.

Kubernetes 오브젝트 크기 제한 때문에 CSV가 매우 크다면 다음 대안을 고려해야 한다.

• PersistentVolume
• Object Storage
• HTTP 기반 데이터 다운로드
• 전용 traffic generator 이미지
• Git sidecar
• init container에서 원본 파일 다운로드

현재처럼 3600행 정도의 텍스트 데이터 9개는 구성에 따라 ConfigMap으로 관리할 수 있지만, 파일 크기는 반드시 확인해야 한다.

 

 

xApp 재시작 방식의 한계

 

현재 방식은 xapp_kpm_moni를 수정하지 않고 반복 실행하는 우회다.

따라서 실행 종료와 다음 실행 사이에 30초의 수집 공백이 생길 수 있다.

상시 모니터링을 위해서는 장기적으로 다음 중 하나가 필요하다.

• xapp_kpm_moni가 종료되지 않도록 소스 수정
• 별도의 persistent KPM xApp 구현
• KPM indication을 Prometheus exporter로 전달
• OpenTelemetry Collector로 변환
• 로그 기반 파싱 파이프라인 구축