관측성 · 원격 측정

VPP의 관측성 전반: perfmon CPU 성능 카운터, sFlow 샘플링, IPFIX 플로우 익스포트, Stats Segment → Prometheus → Grafana, 이벤트 로그 G2 뷰어, Packet Generator, nsim, Buffer Metadata Tracker까지 정리합니다.

이 문서의 범위: VPP의 관측성(Observability) 전반입니다. 내장 성능 측정(perfmon), 샘플링(sFlow), IPFIX 플로우 익스포트, Stats Segment → Prometheus → Grafana 파이프라인, 이벤트 로그 시각화(G2), 내장 트래픽 생성(Packet Generator)까지를 다룹니다. 장애 디버깅의 반응적 측면은 디버깅 · 성능 측정을, 일상 운영은 운영 · 플랫폼 · 확장을 참고하시기 바랍니다.

perfmon — CPU 성능 카운터 측정

VPP의 perfmon 플러그인은 리눅스 perf_events 인터페이스를 감싸 VPP 노드 단위로 하드웨어 성능 카운터를 수집합니다. cache miss, branch miss, stall cycle, instructions retired 같은 CPU 내부 지표를 그래프 노드별로 볼 수 있어, 성능 문제의 원인이 메모리 대역폭인지 분기 예측 실패인지 바로 좁힐 수 있습니다.

vpp# show perfmon bundle
vpp# perfmon start bundle cache-hierarchy type node
# 트래픽을 흘린 뒤 측정 중지
vpp# perfmon stop
vpp# show perfmon statistics

대표적인 번들:

cache-hierarchy — L1/L2/L3 캐시 hit/miss
branch-mispred — 분기 예측 실패율
memory-bandwidth — 메모리 컨트롤러 읽기/쓰기
inst-and-clock — IPC(instructions per cycle), stall 비율
topdown-lvl1/2 — Intel Top-Down 분석 (frontend bound · backend bound · retiring · bad speculation)

perfmon 번들 선택 가이드

어떤 번들을 먼저 써야 할지 증상 기반으로 정리합니다.

증상	권장 번들
처리량이 예상보다 낮음	`inst-and-clock` (IPC 확인)
L3 캐시 미스 급증 의심	`cache-hierarchy`
분기 예측 실패 의심	`branch-mispred`
메모리 대역폭 한계 의심	`memory-bandwidth`
CPU 병목 위치 파악	`topdown-lvl1` 먼저, 좁혀지면 `topdown-lvl2`

Top-Down 해석: Intel Top-Down은 모든 CPU 사이클을 네 범주로 분류합니다. Retiring이 60%+면 건강한 상태, Frontend bound가 높으면 I-cache / branch 문제, Backend bound가 높으면 메모리 대역폭 · cache miss 문제, Bad speculation이 높으면 분기 오류입니다. 튜닝 방향이 명확해집니다.

perfmon 25.x → 26.x 변경사항

VPP 26.x 계열에서 perfmon 플러그인은 최신 마이크로아키텍처 지원을 강화했습니다.

신규 CPU 모델 지원: 최신 Intel/AMD 마이크로아키텍처(Sapphire Rapids, Zen 4 이후 세대 등 newer Intel/AMD microarchitectures)에 대한 PMU 이벤트 정의가 추가됐습니다. 이전 버전에서 일부 이벤트가 unsupported로 표시되던 플랫폼에서도 번들이 정상 동작할 수 있습니다.
show perfmon active bundles 출력 변경: 26.x에서는 현재 활성화된 번들 목록과 각 번들의 이벤트 상태가 더 명확하게 표시됩니다. topdown-lvl3 번들이 활성화되어 있는지 확인하려면 아래 명령을 사용하세요.
```
vpp# show perfmon active bundles
# 출력 예시 — topdown-lvl3가 목록에 포함되면 정상 활성화됨
vpp# perfmon start bundle topdown-lvl3 type node
```
Cache miss 해석 vs IPC 결합 분석: cache-hierarchy 번들의 L3 miss 비율이 높을 때, inst-and-clock 번들의 IPC 수치를 함께 보면 병목 원인을 좁힐 수 있습니다. IPC가 낮고 L3 miss가 높으면 메모리 대기(memory-bound), IPC가 낮지만 miss는 적으면 분기 예측 실패 또는 프론트엔드 병목을 의심합니다.
```
# 순서대로 측정: 먼저 cache miss, 다음 IPC
vpp# perfmon start bundle cache-hierarchy type node
vpp# perfmon stop
vpp# show perfmon statistics
vpp# perfmon start bundle inst-and-clock type node
vpp# perfmon stop
vpp# show perfmon statistics
```

perf_event_paranoid 설정: perfmon은 리눅스 perf_event API 기반으로 동작합니다. 비루트(non-root) 환경이나 컨테이너에서 EACCES 오류가 발생하면 /proc/sys/kernel/perf_event_paranoid 값을 확인하세요. 기본값 2는 일반 사용자의 커널 이벤트 수집을 제한합니다. VPP가 루트로 실행 중이라면 문제 없지만, 그렇지 않은 경우 echo 1 > /proc/sys/kernel/perf_event_paranoid 로 완화하거나 CAP_PERFMON capability를 부여하세요 (Linux 5.8+).

sFlow — 샘플링 기반 흐름 모니터링

sFlow(RFC 3176)는 N개 패킷마다 1개를 랜덤 샘플링해 외부 수집기에 보내는 경량 모니터링 프로토콜입니다. 모든 플로우를 추적하는 NetFlow와 달리 오버헤드가 샘플링 비율에 비례하므로 100G/400G 라인레이트에서도 활용 가능합니다. VPP는 sflow 플러그인으로 제공합니다.

vpp# sflow enable <interface> sampling-rate 1024
vpp# sflow sampling-rate 1024
vpp# sflow polling-interval 10
vpp# sflow agent address 192.0.2.100
vpp# sflow collector address 192.0.2.50 port 6343
vpp# show sflow

sampling-rate 1024는 1024 패킷마다 1건 샘플링을 의미합니다. 수집기에는 sflowtool, ntopng, Akvorado 같은 오픈소스와 상용 솔루션이 있습니다.

🆕 VPP 25.10 — sFlow 방향 제어 및 드롭 모니터링:

방향 제어: sflow direction rx|tx|both — 인터페이스별로 수신·송신·양방향 샘플링 방향을 지정할 수 있습니다. 25.10 이전에는 방향 구분 없이 단일 경로만 가능했습니다. API: sflow_direction_get / sflow_direction_set (CLI 구문은 소스 코드 기준)
드롭 모니터링: sflow drop-monitoring enable/disable — error-drop 노드에서 폐기된 패킷도 sFlow 레코드에 포함하는 feature-arc 연동이 추가됐습니다. API: sflow_drop_monitoring_get / sflow_drop_monitoring_set (CLI 구문은 소스 코드 기준)

sFlow vs IPFIX — 언제 무엇을 쓰나

	sFlow	IPFIX / NetFlow
모델	확률적 샘플링	결정론적 플로우 집계
오버헤드	일정 (샘플링 비율에 비례)	플로우 수에 비례 — DDoS 시 폭발
해상도	통계적 — 소수 플로우 놓칠 수 있음	모든 플로우 보존
주 용도	용량 계획 · DDoS 탐지 · 대시보드	감사 · 청구 · 포렌식
VPP 플러그인	`sflow`	`flowprobe` + `ipfix`

sFlow 컬렉터 연동 및 필터 설정

실제 환경에서 sFlow 컬렉터를 연동하는 전형적인 설정 절차와 운영 팁을 정리합니다.

Collector IP 및 샘플링 파라미터 설정: 수집기 주소·포트를 지정하면서 샘플링 비율, 헤더 복사 바이트, 폴링 주기를 함께 설정합니다.

# sampling-rate 1000, 헤더 128바이트 복사, 30초 카운터 폴링
vpp# set sflow sampling-rate 1000 header-bytes 128 polling-interval 30
vpp# sflow collector address 192.0.2.50 port 6343
vpp# sflow agent address 192.0.2.100
vpp# sflow enable <interface> sampling-rate 1000

sFlow → ntopng / Akvorado 연동: sFlow 컬렉터가 수신하는 표준 포트는 6343/UDP입니다. ntopng는 -i sflow://0.0.0.0:6343 옵션으로 직접 수신하며, Akvorado는 sflow 입력 소스 블록에서 listen: "0.0.0.0:6343"으로 설정합니다. sflow agent address는 수집기가 어느 장비에서 온 데이터인지 구분하는 기준 IP가 되므로, 라우팅 가능한 루프백 또는 관리 IP로 지정하는 것이 권장됩니다.
패킷 샘플링 비율과 CPU 영향 추정: sampling-rate N은 평균 N패킷마다 1건을 CPU 소프트웨어 경로로 처리함을 의미합니다. 1/1000 샘플링(rate 1000)은 라인레이트 트래픽 기준 약 0.1% 수준의 추가 오버헤드로 추정됩니다. 트래픽이 많거나 패킷 크기가 작을수록(pps가 높을수록) 절대적인 샘플 수가 늘어 오버헤드가 증가하므로, 10G 이상 라인레이트 환경에서는 rate 4096~8192 범위부터 시작해 show runtime으로 sflow 노드의 벡터 사용량을 확인하면서 조정하세요.
통계 확인: 샘플 전송 건수, 드롭, 폴링 카운터를 아래 명령으로 확인합니다.
```
vpp# show sflow
```

헤더 복사 바이트(header-bytes) 선택: 기본값(128바이트)은 IPv4/IPv6 + TCP/UDP 헤더를 포함하기에 충분합니다. L7 애플리케이션 식별이 필요하면 256~512바이트로 늘릴 수 있지만, 샘플 패킷 크기가 커져 수집기로의 UDP 전송량이 증가합니다. 대역폭이 제한된 관리 네트워크에서는 128바이트를 유지하고 ntopng/Akvorado의 DPI 계층에 의존하는 것이 일반적입니다.

IPFIX probe — 플로우 익스포트

IPFIX(RFC 7011~7015)는 NetFlow v9의 표준화 후속입니다. VPP의 flowprobe 플러그인이 L2/L3/L4 플로우를 추적하고 ipfix 플러그인이 이를 템플릿 포함 데이터레코드로 수집기에 전송합니다.

vpp# flowprobe params record l3 active 60 passive 120
vpp# flowprobe feature add-del <if> l2 l3 l4
vpp# set ipfix exporter collector 192.0.2.50 src 10.0.0.1 template-interval 20 port 4739 path-mtu 1400
vpp# show flowprobe params

플로우 레코드에는 5튜플, 바이트/패킷 카운터, 시작/종료 타임스탬프, TCP 플래그가 포함됩니다. active timeout(60s)은 플로우가 살아 있어도 주기적으로 export하고, passive timeout(120s)은 트래픽이 없는 플로우를 종료하는 기준입니다.

Stats Segment → Prometheus → Grafana

VPP는 모든 카운터를 Stats Segment라는 공유 메모리 트리에 노출합니다. vpp_prometheus_export 바이너리가 이 세그먼트를 스크레이프해 Prometheus exposition format(text/plain)으로 HTTP 노출합니다.

$ vpp_prometheus_export --interface 127.0.0.1 --port 9482     /err/.* /if/.* /mem/.* /nodes/.*/calls     /nodes/.*/clocks /nodes/.*/vectors

# 다른 터미널에서
$ curl http://127.0.0.1:9482/metrics | head

Prometheus scrape 설정

scrape_configs:
  - job_name: vpp
    static_configs:
      - targets: ['vpp-host:9482']
    scrape_interval: 10s
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'vpp_.*'
        action: keep

Grafana 대시보드 주요 패널

Throughput: rate(vpp_if_rx_bytes[1m]) * 8 — 인터페이스별 bps
Packet drop: rate(vpp_err_counter[1m]) + 에러 이름으로 top-K
Vector size: vpp_node_vectors / vpp_node_calls — 노드 효율 지표
CPU per node: rate(vpp_node_clocks[1m]) / rate(vpp_node_vectors[1m]) — 패킷당 사이클
Session count: vpp_session_count — 호스트 스택 연결 수

이벤트 로그 · G2 뷰어

VPP의 이벤트 로거(vlib_elog)는 CPU 사이클 정밀도로 노드 진입·특수 이벤트를 타임스탬프와 함께 기록합니다. 기록된 로그는 G2 그래픽 뷰어로 시각화할 수 있습니다.

vpp# event-logger resize 100000
vpp# event-logger restart
# 트래픽을 흘린 뒤
vpp# event-logger save /tmp/vpp-elog.clib
$ g2 /tmp/vpp-elog.clib

G2는 타임라인 뷰에서 각 워커 스레드의 시간축을 병렬로 보여 줘, 워커 간 불균형·배리어 동기화 지연·프레임 핸드오프 hot spot을 즉시 식별할 수 있습니다. CLI 트레이스가 노드 경로를 보여 준다면, G2는 시간 분포를 보여 줍니다.

🆕 VPP 26.02 — selog 플러그인 (실험적): 공유 메모리 기반 elog

기존 vlib_elog가 VPP 프로세스 내부 링 버퍼에만 기록했다면, selog(SSVM Shared Event Log) 플러그인은 공유 메모리(SSVM) 세그먼트에 이벤트를 기록하여 외부 모니터링 프로세스가 무중단으로 실시간 소비할 수 있습니다. VPP 26.02에 experimental 플러그인으로 추가됐습니다.

selog_get_shm — 공유 메모리 핸들 획득
selog_track_dump — 트랙 목록 덤프
selog_event_type_dump — 이벤트 타입 스키마 덤프
selog_get_string_table — 문자열 인터닝 테이블 조회

소스: src/plugins/selog/. 프로덕션 배포 전에는 안정성을 충분히 검증하시기 바랍니다.

Packet Generator (PG) — 내장 트래픽 생성

VPP에는 외부 트래픽 생성기 없이 테스트·벤치마크·재현 테스트를 할 수 있는 내장 Packet Generator가 있습니다. 스크립트로 임의의 헤더 조합을 정의해 특정 노드로 주입할 수 있어, 엣지 케이스 회귀 테스트에 매우 유용합니다.

vpp# create packet-generator interface pg0
vpp# packet-generator new {
  name flow1
  limit 1000000
  rate 1e6
  node ip4-input
  size 64-64
  data { UDP: 10.0.0.1 -> 10.0.0.2
         UDP: 1234 -> 5678
         incrementing 48 }
}
vpp# packet-generator enable-stream flow1
vpp# show packet-generator
vpp# packet-generator disable-stream flow1

Deprecated (25.10+): pg_create_interface_v2는 VPP 25.10부터 deprecated됩니다. 대신 pg_create_interface_v3를 사용하세요. v3는 체크섬 오프로드(checksum offload) 지원이 추가됐습니다. 자동화 스크립트나 Python 바이너리 API 클라이언트에서 직접 호출한다면 이관 계획을 세워 두시기 바랍니다.

스크립트 파일로 재사용

같은 시나리오를 .pg 파일로 저장해 CI에서 재실행할 수 있습니다. make test가 실행하는 통합 테스트도 내부적으로 PG를 사용합니다.

Network Delay Simulator (nsim)

nsim 플러그인은 송신 경로에 지연 · 대역폭 한계 · 패킷 손실을 삽입해 WAN 환경을 재현합니다. 리눅스 netem의 VPP 버전으로, 혼잡 제어나 TCP 재전송 동작을 검증할 때 유용합니다.

vpp# nsim output-feature enable-disable <if>
vpp# set nsim delay 50.0 ms bandwidth 100.0 mbit packets-per-drop 1000
vpp# show nsim

nsim TCP 처리량 영향 예제

50ms RTT 지연과 0.1% 패킷 손실을 적용했을 때 TCP 처리량이 어떻게 낮아지는지 확인하는 구체적인 예제입니다.

nsim 설정 (50ms 지연 + 0.1% 손실)

# 인터페이스에 nsim output feature 적용
vpp# nsim output-feature enable-disable GigabitEthernet0/8/0
# 50ms 지연, 100Mbps 대역폭, 1000패킷마다 1개 드롭 (≈ 0.1% 손실)
vpp# set nsim delay 50.0 ms bandwidth 100.0 mbit packets-per-drop 1000
vpp# show nsim

iperf3 Before/After 측정

# nsim 적용 전 — 기준 처리량 측정
$ iperf3 -c 10.0.0.2 -t 30
Bandwidth:  94.3 Mbits/sec

# nsim 적용 후 — 50ms RTT, 0.1% loss 조건
$ iperf3 -c 10.0.0.2 -t 30
Bandwidth:   2.1 Mbits/sec

TCP 처리량 이론값: TCP 처리량의 상한은 Window Size / RTT로 결정됩니다. 기본 TCP 수신 윈도우가 16KB(= 131072 bit)이고 RTT가 50ms일 때, 이론적 최대 처리량은 약 131072 / 0.050 ≈ 2.6 Mbps입니다. 패킷 손실이 추가되면 혼잡 제어(CUBIC/BBR)가 윈도우를 더욱 줄여 실제 처리량은 2Mbps 전후로 낮아집니다. 처리량을 회복하려면 -w 4M 옵션으로 윈도우를 키우거나(131072000 / 0.050 ≈ 2 Gbps), 손실을 수용하는 BBR 혼잡 제어를 사용하면 됩니다.

Buffer Metadata Change Tracker

vlib_buffer_t의 메타데이터가 누가 언제 변경했는지를 추적하는 디버그 전용 기능입니다. 릴리스 빌드에서는 비활성이며, 버퍼 손상이나 미상 오염이 의심될 때 디버그 빌드에서 활성화합니다.

vpp# buffer metadata track on
# 문제 재현 후
vpp# show buffer metadata

출력은 각 필드(예: current_data, flags, next_buffer)가 어느 노드에서 덮어써졌는지를 기록합니다.

관측성 스택 선택 가이드

질문	권장 도구
지금 이 순간 VPP가 CPU를 어디에 쓰는가?	`show runtime` + `perfmon topdown-lvl1`
어떤 플로우가 트래픽의 80%를 차지하나?	sFlow → ntopng / Akvorado
감사 · 청구용 전수 플로우 기록	IPFIX → nfacctd · Elasticsearch
SLO 대시보드 (bps, pps, drop rate)	Stats Segment → Prometheus → Grafana
워커 간 불균형이 보이는데 어디서?	이벤트 로거 → G2
특정 엣지 케이스 재현	Packet Generator + `show trace`
WAN 조건에서의 TCP 동작 검증	nsim + iperf3