소개
프로덕션 프로파일링은 항상 용감한 자들의 영역이었습니다. 수년간 SRE들은 불편한 트레이드오프에 직면했습니다: 측정 가능한 지연을 도입하고 프로덕션 워크로드를 불안정하게 만들 위험이 있는 무거운 프로파일링 도구를 연결하거나, 증상만 보여주고 근본 원인은 절대 보여주지 않는 메트릭 대시보드에 의존하며 눈을 감고 운영하는 것이었습니다. 메인스트림 Linux 커널 기술로서 eBPF의 등장은 이 계산을 근본적으로 변화시켰습니다. eBPF를 사용하면 무시할 수 있는 오버헤드로 커널과 사용자 공간의 거의 모든 계층을 계측할 수 있으며, 이전에는 스테이징 환경에서만 사용할 수 있었던 종류의 깊은 관찰 가능성 데이터를 생성할 수 있습니다.
eBPF는 extended Berkeley Packet Filter의 약자로, 네트워크 패킷 필터링 메커니즘으로서의 기원에서 범용 커널 내 가상 머신으로 발전했습니다. eBPF용으로 작성된 프로그램은 실행 전에 커널에 의해 검증되어, 시스템 크래시, 무한 루프 진입, 또는 비인가 메모리 접근이 불가능하도록 보장합니다. 이 안전성 보장이 eBPF를 프로덕션 프로파일링에 고유하게 적합하게 만드는 것입니다. 커널을 재컴파일하거나 서비스를 재시작하지 않고도 커널 함수, tracepoint, 사용자 공간 함수 진입점, 하드웨어 성능 카운터에 프로브를 연결할 수 있습니다.
이 가이드는 SRE 팀이 프로덕션 Linux 시스템에서 성능 문제를 진단하기 위해 매일 사용하는 실용적인 워크플로우를 다룹니다. 표준 eBPF 도구 체인을 사용하여 CPU 프로파일링, 지연 분석, 메모리 누수 탐지, 네트워크 추적, I/O 프로파일링을 살펴보겠습니다. 여기에 표시된 모든 명령어와 스크립트는 커널 5.15 이상을 실행하는 프로덕션 환경에서 사용되었습니다.
eBPF가 프로덕션 프로파일링을 변화시키는 이유
전통적인 프로파일링 도구는 프로덕션에서 비실용적으로 만드는 비용을 부과합니다. 바쁜 서비스에서 strace를 실행하면 100배 이상 느려질 수 있는데, strace가 ptrace를 사용하여 모든 syscall을 가로채고 각 호출마다 추적되는 프로세스와 추적하는 프로세스 사이에서 컨텍스트를 전환하기 때문입니다. 하드웨어 성능 카운터를 사용하고 strace보다 훨씬 가벼운 perf조차도 여전히 샘플 데이터를 디스크에 기록해야 하며 높은 샘플 속도에서는 상당한 I/O 부담을 생성할 수 있습니다.
eBPF는 세 가지 중요한 방식으로 방정식을 변경합니다. 첫째, eBPF 프로그램은 커널 내부에서 실행되어 ptrace 기반 도구의 컨텍스트 스위치 오버헤드를 제거합니다. kprobe나 tracepoint를 연결하면 eBPF 프로그램이 커널 코드 경로와 인라인으로 실행되며, 일반적으로 호출당 수십 나노초만 추가합니다. 둘째, eBPF 프로그램은 map을 사용하여 커널 내에서 데이터를 집계할 수 있어, 모든 이벤트를 사용자 공간으로 복사하지 않고 히스토그램, 카운트, 요약을 계산할 수 있습니다. strace로는 초당 수백만 개의 이벤트를 생성하는 지연 히스토그램이 eBPF로는 간격당 하나의 map 읽기만 생성합니다. 셋째, eBPF 검증기가 안전을 보장합니다: 프로그램이 널 포인터를 역참조하거나, 범위 밖 메모리에 접근하거나, 무한히 루프를 돌 수 없습니다.
실질적인 영향은 극적입니다. biolatency와 같은 도구는 수십만 IOPS를 처리하는 시스템에서 모든 블록 I/O 요청을 추적하면서 1% 미만의 CPU 오버헤드로 지연 히스토그램을 생성할 수 있습니다. 피크 트래픽을 서비스하는 동안 애플리케이션 서버의 핫 함수에 대해 funclatency를 실행할 수 있습니다. 이것은 이전 세대의 추적 도구로는 단순히 불가능했습니다.
eBPF 도구 체인 설정
eBPF 생태계는 세 가지 주요 도구 세트로 통합되었습니다: bcc-tools, bpftrace, libbpf 기반 CO-RE 프로그램. 각각 다른 사용 사례를 위해 제공되며, 잘 갖춰진 SRE 워크스테이션은 세 가지 모두를 사용할 수 있어야 합니다.
Ubuntu 및 Debian 시스템에서 전체 도구 체인을 설치합니다:
sudo apt-get update
sudo apt-get install -y bpfcc-tools bpftrace linux-headers-$(uname -r)
sudo apt-get install -y libbpf-dev bpftool
RHEL 및 Fedora 시스템에서:
sudo dnf install -y bcc-tools bpftrace kernel-devel-$(uname -r)
sudo dnf install -y libbpf-devel bpftool
커널이 최신 bpftrace 기능 및 CO-RE 프로그램에 필요한 BTF를 지원하는지 확인합니다:
ls /sys/kernel/btf/vmlinux
bpftool btf dump file /sys/kernel/btf/vmlinux format raw | head -c 100
BTF를 사용할 수 없는 경우 커널이 CONFIG_DEBUG_INFO_BTF=y로 컴파일되었는지 확인해야 합니다. 2022년 이후의 대부분의 배포판 커널은 BTF 지원을 포함합니다.
bcc-tools 패키지는 가장 일반적인 프로파일링 시나리오를 다루는 수십 개의 즉시 사용 가능한 도구를 제공합니다. 이들은 일반적으로 Debian 기반 시스템에서 -bpfcc 접미사가 있는 실행 파일로 설치되거나 RHEL에서 /usr/share/bcc/tools/ 아래에 직접 설치됩니다. Bpftrace는 사용자 정의 원라이너 및 짧은 스크립트를 작성하기 위한 고수준 스크립팅 언어를 제공합니다. Libbpf와 CO-RE(Compile Once, Run Everywhere) 프로그램은 자체 포함된 바이너리로 배포되는 프로덕션 등급의 이식 가능한 eBPF 도구를 구축하는 데 사용됩니다.
CPU 프로파일링 워크플로우
CPU 프로파일링은 성능 문제를 조사할 때 가장 일반적인 출발점입니다. 목표는 커널 공간이든 사용자 공간이든 어떤 함수가 가장 많은 CPU 시간을 소비하는지 식별하고, 핫스팟을 시각적으로 명확하게 만드는 플레임 그래프를 생성하는 것입니다.
가장 간단한 접근 방식은 bcc의 profile 도구를 사용하여 고정 주파수에서 스택 트레이스를 샘플링하는 것입니다:
sudo profile-bpfcc -F 99 -a --stack-storage-size 16384 30 > /tmp/cpu-stacks.txt
이것은 30초 동안 99 Hz로 모든 CPU를 샘플링합니다. 99 Hz 주파수는 100 Hz에서 자주 실행되는 타이머 기반 활동과의 앨리어싱을 방지합니다. 출력에는 Brendan Gregg의 FlameGraph 도구에 직접 전달할 수 있는 접힌 스택 트레이스가 포함됩니다:
git clone https://github.com/brendangregg/FlameGraph.git
cat /tmp/cpu-stacks.txt | FlameGraph/stackcollapse-bpf.pl | FlameGraph/flamegraph.pl > cpu-flame.svg
더 타겟팅된 프로파일링을 위해 bpftrace를 사용하면 특정 프로세스를 프로파일링하고 CPU별로 필터링할 수 있습니다:
sudo bpftrace -e 'profile:hz:99 /pid == 12345/ { @[ustack(perf), comm] = count(); }' > stacks.bt
실행 시간이 아닌 CPU 스케줄링 동작을 이해해야 할 때 cpudist 도구는 스레드가 디스케줄링되기 전에 CPU에서 실행되는 시간을 보여줍니다:
sudo cpudist-bpfcc -p 12345 10 1
이것은 10초 간격 동안 프로세스 12345의 on-CPU 지속 시간 히스토그램을 출력합니다. 높은 컨텍스트 스위치와 결합된 짧은 on-CPU 시간은 락 경합을 시사합니다. 낮은 처리량과 결합된 긴 on-CPU 시간은 계산 병목 현상을 시사합니다.
NUMA 시스템에서 CPU 마이그레이션 문제를 조사하려면 스케줄러 이벤트를 추적할 수 있습니다:
sudo bpftrace -e 'tracepoint:sched:sched_migrate_task {
printf("pid=%d comm=%s from_cpu=%d to_cpu=%d\n",
args->pid, args->comm, args->orig_cpu, args->dest_cpu);
}'
지연 분석
지연 분석은 eBPF가 진정으로 빛나는 분야입니다. 측정되는 코드 경로를 방해하지 않고 임의의 이벤트 사이의 시간을 측정할 수 있기 때문입니다. bcc-tools 컬렉션에는 전용으로 구축된 여러 지연 도구가 포함되어 있습니다.
블록 I/O 지연은 블록 I/O 요청에서 완료까지의 시간을 추적하는 biolatency로 측정됩니다:
sudo biolatency-bpfcc -D 10 1
-D 플래그는 디스크 장치별로 지연을 분류하여 어떤 드라이브가 느린지 쉽게 식별할 수 있게 합니다. 출력은 마이크로초 단위의 지연 분포를 보여주는 2의 거듭제곱 히스토그램입니다.
실행 대기열 지연은 스레드가 CPU 시간을 얻기 전에 스케줄러 큐에서 대기하는 시간을 측정하며, runqlat으로 측정됩니다:
sudo runqlat-bpfcc -p 12345 10 1
높은 실행 대기열 지연은 프로세스가 CPU를 기다리고 있음을 의미하며, 이는 CPU 포화를 나타냅니다. 정상 운영 중 10밀리초 이상의 지연이 보이면 더 많은 CPU 용량이 필요하거나 CPU를 소비하는 것이 무엇인지 조사해야 합니다.
함수 지연은 특정 커널 또는 사용자 공간 함수의 실행 시간을 측정합니다:
sudo funclatency-bpfcc -p 12345 'c:malloc' 10 1
이것은 프로세스 12345의 libc에서 malloc 호출을 추적하고 지연 히스토그램을 보여줍니다. 바이너리나 공유 라이브러리에 심볼이 있는 모든 함수를 추적할 수 있습니다. 커널 함수의 경우:
sudo funclatency-bpfcc 'vfs_read' 10 1
bpftrace를 사용한 애플리케이션 수준 지연 추적의 경우, 두 프로브 지점 사이의 시간을 측정할 수 있습니다:
sudo bpftrace -e '
uprobe:/usr/bin/myapp:process_request { @start[tid] = nsecs; }
uretprobe:/usr/bin/myapp:process_request /@start[tid]/ {
@latency_us = hist((nsecs - @start[tid]) / 1000);
delete(@start[tid]);
}
END { clear(@start); }
'
메모리 분석
프로덕션의 메모리 문제는 며칠에 걸쳐 OOM kill을 유발하는 점진적 누수에서 성능을 저하시키는 캐시 비효율성에 이르기까지 다양합니다. eBPF는 각 범주에 대해 여러 도구를 제공합니다.
memleak 도구는 메모리 할당 및 해제 호출을 추적하여 누수를 식별하기 위해 미해결 할당을 추적합니다:
sudo memleak-bpfcc -p 12345 --combined-only 30
이것은 프로세스 12345에 연결하고 30초 후에 해제되지 않은 할당의 스택 트레이스를 총 미해결 바이트 순으로 정렬하여 출력합니다. 전문 할당자 디버깅을 활성화하고 재시작하지 않고 장기 실행 서비스에서 누수를 잡는 데 매우 유용합니다.
커널 메모리 할당 추적의 경우:
sudo memleak-bpfcc --combined-only 30
pid 플래그 없이 memleak은 kmalloc과 kfree를 통해 커널 할당을 추적하며, 드라이버나 커널 모듈로 인한 커널 메모리 누수를 식별할 수 있습니다.
캐시 동작은 애플리케이션 성능에 막대한 영향을 미칩니다. cachestat 도구는 페이지 캐시에 대한 초당 통계를 제공합니다:
sudo cachestat-bpfcc 5
출력에는 히트, 미스, 더티 페이지, 읽기/쓰기 비율이 포함됩니다. 높은 미스 비율은 작업 세트가 사용 가능한 메모리를 초과함을 나타내며, 애플리케이션에 더 많은 RAM이 필요한지 또는 더 나은 접근 패턴이 필요한지 고려해야 합니다.
OOM kill은 어떤 프로세스가 종료되고 왜 종료되는지 이해하기 위해 실시간으로 추적할 수 있습니다:
sudo bpftrace -e 'kprobe:oom_kill_process {
printf("OOM kill: pid=%d comm=%s pages=%d\n",
((struct task_struct *)arg1)->pid,
((struct task_struct *)arg1)->comm,
arg0);
}'
더 간단한 접근 방식으로, bcc의 oomkill 도구가 이것을 자동으로 캡처합니다:
sudo oomkill-bpfcc
이것은 OOM killer가 호출될 때마다 트리거된 프로세스와 종료된 프로세스의 세부 정보를 포함하여 한 줄을 출력합니다.
네트워크 추적
네트워크 성능 문제는 애플리케이션, 커널 TCP 스택, 네트워크 인프라 간의 상호 작용을 포함하기 때문에 진단하기가 악명 높게 어렵습니다. eBPF는 각 계층에 대한 정밀한 도구를 제공합니다.
tcplife 도구는 TCP 세션 수명을 추적하여 연결이 설정되고 닫히는 시기와 전송된 바이트를 보여줍니다:
sudo tcplife-bpfcc -D
-D 플래그는 타임스탬프를 포함합니다. 각 줄은 PID, 프로세스 이름, 로컬 및 원격 주소, 포트, 지속 시간, 전송/수신 바이트를 보여줍니다. 이것은 연결 이탈, 예상치 못한 단기 연결, 또는 예상보다 오래 연결을 유지하는 서비스를 식별하는 데 필수적입니다.
TCP 재전송은 네트워크 건강의 중요한 지표입니다:
sudo tcpretrans-bpfcc -l
-l 플래그는 tail loss probe를 포함합니다. 각 재전송 이벤트는 소스 및 대상 주소, 상태, 재전송을 트리거한 커널 함수와 함께 출력됩니다. 특정 대상으로의 재전송 클러스터는 네트워크 경로 문제를 나타냅니다.
TCP 계층에서 드롭된 패킷은 tcpdrop으로 추적할 수 있습니다:
sudo tcpdrop-bpfcc
각 드롭된 패킷은 커널 스택 트레이스와 함께 출력되어 커널이 왜 패킷을 드롭했는지 정확히 알려줍니다. 일반적인 원인에는 소켓 버퍼 오버플로우, 연결 리셋, 메모리 압박이 포함됩니다.
자세한 TCP 연결 상태 분석을 위해 상태 전환을 추적하는 bpftrace 스크립트를 작성할 수 있습니다:
sudo bpftrace -e '
tracepoint:tcp:tcp_set_state {
printf("pid=%d sport=%d dport=%d oldstate=%d newstate=%d\n",
pid, args->sport, args->dport, args->oldstate, args->newstate);
}
'
DNS 해석 지연은 종종 간과되는 애플리케이션 지연의 원인입니다. 리졸버 수준에서 DNS 조회를 추적할 수 있습니다:
sudo bpftrace -e '
uprobe:/lib/x86_64-linux-gnu/libc.so.6:getaddrinfo { @start[tid] = nsecs; }
uretprobe:/lib/x86_64-linux-gnu/libc.so.6:getaddrinfo /@start[tid]/ {
@dns_us = hist((nsecs - @start[tid]) / 1000);
delete(@start[tid]);
}
'
I/O 프로파일링
스토리지 I/O는 프로덕션 지연의 가장 일반적인 원인 중 하나이며, eBPF는 스토리지 스택의 여러 수준에서 I/O를 추적하는 도구를 제공합니다.
biosnoop 도구는 타임스탬프, 지연, 프로세스 귀속과 함께 개별 블록 I/O 작업을 추적합니다:
sudo biosnoop-bpfcc -d sda 10
이것은 10초 동안 sda 장치에 대한 모든 블록 I/O를 추적하며, 각 작업의 PID, 프로세스 이름, 디스크, 작업 유형, 섹터, 바이트, 지연을 보여줍니다. 특정 디스크에서 정확히 무엇이 I/O를 생성하는지 이해해야 할 때 가장 먼저 사용하는 도구입니다.
파일 시스템 수준 추적은 더 높은 수준의 컨텍스트를 제공합니다. ext4slower 도구는 지연 임계값을 초과하는 ext4 작업을 추적합니다:
sudo ext4slower-bpfcc 10
이것은 읽기, 쓰기, 열기, sync를 포함하여 10밀리초보다 느린 모든 ext4 작업을 출력합니다. 블록 수준 추적과 파일 시스템 메타데이터를 상관시킬 필요 없이 느린 파일 시스템 작업을 즉시 식별합니다.
모든 파일 시스템 유형에 걸친 일반 파일 시스템 추적의 경우 fileslower가 같은 목적을 제공합니다:
sudo fileslower-bpfcc 10
쓰기 패턴은 애플리케이션이 스토리지와 어떻게 상호 작용하는지 이해하는 데 중요합니다. filetop의 bpftrace 등가물은 가장 자주 읽고 쓰는 파일을 보여줍니다:
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_write {
@writes[comm, pid] = count();
}
interval:s:5 { print(@writes); clear(@writes); }
'
데이터베이스와 같은 fsync 집약적 워크로드의 경우 sync 작업을 추적하면 예상치 못한 flush 패턴을 발견할 수 있습니다:
sudo bpftrace -e '
kprobe:vfs_fsync_range {
@fsync_latency[comm] = count();
}
kretprobe:vfs_fsync_range {
printf("fsync completed: comm=%s\n", comm);
}
'
사용자 정의 bpftrace 원라이너 구축
eBPF의 진정한 힘은 특정 스택에 맞춤화된 사용자 정의 추적 프로그램을 작성하는 능력에서 옵니다. bpftrace의 스크립팅 언어는 셸 스크립트를 작성할 수 있는 누구에게나 이것을 접근 가능하게 만듭니다.
bpftrace 원라이너의 기본 구조는 프로브 사양 다음에 액션 블록이 오는 것입니다. 프로브는 kprobe(커널 함수), uprobe(사용자 공간 함수), tracepoint(안정적인 커널 이벤트), 소프트웨어 이벤트에 연결할 수 있습니다.
프로세스별 syscall 카운트:
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
프로세스별 읽기 크기 히스토그램:
sudo bpftrace -e 'tracepoint:syscalls:sys_exit_read /args->ret > 0/ {
@read_bytes[comm] = hist(args->ret);
}'
전체 명령줄로 새 프로세스 생성 추적:
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve {
printf("exec: pid=%d ppid=%d %s\n", pid, curtask->real_parent->pid, str(args->filename));
}'
전체 경로로 파일 열기 추적:
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat {
printf("open: pid=%d comm=%s file=%s\n", pid, comm, str(args->filename));
}'
콜 스택별로 집계하여 애플리케이션이 특정 함수에서 보내는 시간 측정:
sudo bpftrace -e '
uprobe:/opt/myapp/bin/server:DatabaseQuery { @start[tid] = nsecs; }
uretprobe:/opt/myapp/bin/server:DatabaseQuery /@start[tid]/ {
@query_ns[ustack(5)] = hist(nsecs - @start[tid]);
delete(@start[tid]);
}
'
고빈도 이벤트의 경우, map을 사용하여 커널 내에서 집계하고 출력 버퍼를 압도하지 않도록 합니다:
sudo bpftrace -e '
tracepoint:syscalls:sys_exit_read /args->ret > 0/ {
@total_bytes[comm] = sum(args->ret);
@total_calls[comm] = count();
}
interval:s:10 {
printf("\n--- Top readers (10s window) ---\n");
print(@total_bytes, 10);
print(@total_calls, 10);
clear(@total_bytes);
clear(@total_calls);
}
'
지속적 프로파일링 통합
bpftrace와 bcc-tools를 사용한 임시 프로파일링은 인시던트 대응에 필수적이지만, 지속적 프로파일링은 항상 켜져 있는 성능 가시성을 제공합니다. 이 분야를 이끄는 두 가지 오픈소스 프로젝트가 있습니다: Parca와 Pyroscope.
Parca는 eBPF를 사용하여 호스트의 모든 프로세스에 걸쳐 최소한의 오버헤드로 스택 트레이스를 지속적으로 샘플링합니다. Parca 에이전트는 Kubernetes에서 DaemonSet으로 또는 bare metal에서 systemd 서비스로 실행됩니다:
sudo parca-agent --remote-store-address=parca-server:7070 \
--node=production-host-01 \
--sampling-ratio=1.0 \
--http-address=:7071
에이전트는 실행 중인 모든 프로세스를 자동으로 검색하고, 디버그 정보와 BTF 데이터에서 심볼을 해석하고, 프로파일링 데이터를 Parca 서버로 스트리밍합니다. 서버는 시계열 쿼리에 최적화된 컬럼 형식으로 프로필을 저장하고 플레임 그래프 탐색, 시간 윈도우 간 프로필 비교, 회귀 식별을 위한 UI를 제공합니다.
Pyroscope는 유사한 접근 방식을 취하지만 CPU 외에도 메모리 할당 프로파일링, 락 경합 프로파일링, Go 애플리케이션용 goroutine 프로파일링 등 추가 프로파일링 모드를 지원합니다:
# pyroscope-agent.yaml
server-address: http://pyroscope-server:4040
log-level: info
targets:
- service-name: api-server
spy-name: ebpfspy
application-name: api-server
- service-name: worker
spy-name: ebpfspy
application-name: worker-pool
두 도구 모두 대시보드 생성 및 알림을 위해 Grafana와 통합됩니다. 일반적인 지속적 프로파일링 설정에는 다음이 포함됩니다:
# Grafana data source configuration for Parca
curl -X POST http://grafana:3000/api/datasources \
-H "Content-Type: application/json" \
-d '{
"name": "Parca",
"type": "parca",
"url": "http://parca-server:7070",
"access": "proxy"
}'
지속적 프로파일링의 진정한 가치는 시간이 지나면서 나타납니다. 성능 회귀가 배포되면 현재 프로필을 배포 전 기준선과 비교하여 어떤 함수가 더 많은 CPU를 소비하는지 즉시 확인할 수 있습니다. 이것은 성능 디버깅을 반응적 조사에서 사전 탐지 시스템으로 변환합니다.
프로덕션에서의 모범 사례와 안전
eBPF의 안전 보장은 아무 생각 없이 어떤 프로덕션 시스템에서든 eBPF 프로그램을 실행할 수 있다는 것을 의미하지 않습니다. 검증기가 커널 크래시를 방지하지만, 잘못 작성된 eBPF 프로그램은 여전히 과도한 CPU를 소비하거나, 압도적인 출력을 생성하거나, 시스템 성능을 방해할 수 있습니다.
항상 bpftrace와 bcc-tools에 시간 제한을 설정하세요. 모든 프로파일링 세션에는 명시적 지속 시간이 있어야 합니다:
# 좋음: 명시적 30초 지속 시간
sudo biolatency-bpfcc 30 1
# 위험: 수동으로 중지할 때까지 실행
sudo biolatency-bpfcc
고빈도 프로브에 주의하세요. 초당 수백만 번 발화하는 함수에 kprobe를 연결하면 eBPF 프로그램 자체가 사소하더라도 측정 가능한 오버헤드가 추가됩니다. 프로덕션에서 프로브를 연결하기 전에 빈도를 추정하세요:
sudo bpftrace -e 'kprobe:vfs_read { @count = count(); } interval:s:1 { print(@count); clear(@count); }'
함수가 초당 수십만 번 이상 발화하면 kprobe 대신 tracepoint를 사용할 수 있는지, 처리되는 이벤트 수를 줄이기 위한 필터를 추가할 수 있는지, 또는 모든 이벤트를 추적하는 대신 샘플링할 수 있는지 고려하세요.
bpftrace의 --dry-run 플래그를 사용하여 실행 전에 스크립트를 검증하세요:
sudo bpftrace --dry-run -e 'kprobe:vfs_read { @[comm] = count(); }'
제한 없는 메모리 증가를 방지하기 위해 map 크기를 제한하세요:
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' --map-max-entries=10000
프로덕션 시스템의 경우, 사전 승인된 eBPF 도구 및 스크립트의 런북을 수립하세요. bcc-tools 컬렉션은 잘 테스트되었으며 프로덕션 사용에 안전합니다. 사용자 정의 bpftrace 스크립트는 팀에서 검토하고 프로덕션 사용 전에 스테이징에서 테스트해야 합니다.
전체 root 접근 대신 적절한 capability를 가진 컨테이너 내에서 eBPF 도구를 실행하는 것을 고려하세요:
docker run --rm -it --privileged \
-v /sys/kernel/debug:/sys/kernel/debug:ro \
-v /sys/kernel/btf:/sys/kernel/btf:ro \
-v /proc:/proc:ro \
quay.io/iovisor/bpftrace:latest \
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
마지막으로, 프로파일링 워크플로우를 문서화하세요. 새벽 3시에 인시던트가 발생하면 처음부터 bpftrace 스크립트를 작성하고 싶지 않을 것입니다. 증상별로 정리된 테스트된 프로파일링 스크립트 저장소를 유지하세요: 높은 CPU, 높은 지연, 메모리 증가, 네트워크 오류, I/O 포화. 각 스크립트에는 무엇을 측정하는지, 예상 오버헤드, 출력 해석 방법을 설명하는 주석이 포함되어야 합니다. eBPF는 프로덕션에서 초능력을 부여하지만, 긴급 상황이 도착하기 전에 사용 연습을 한 경우에만 그렇습니다.