관측성 · 원격 측정

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)

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

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 같은 오픈소스와 상용 솔루션이 있습니다.

sFlow vs IPFIX — 언제 무엇을 쓰나

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

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는 시간 분포를 보여 줍니다.

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

스크립트 파일로 재사용

같은 시나리오를 .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

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