eBPF 프로브가 놓치는 짧은 수명 프로세스

Q: procfs 폴링은 왜 구조적으로 취약한가?

procfs 폴링이 취약한 이유는 감시 주기와 프로세스 수명 사이의 경합 때문이다. 수집기가 /proc을 주기적으로 스캔하는 동안, 그 주기보다 짧게 생성되고 종료되는 프로세스는 스캔과 스캔 사이에서 태어나고 죽는다. 2025년 FOSDEM 발표 초록은 이 구조 때문에 procfs 기반 접근이 짧은 수명 프로세스의 타임라인을 불완전하게 만든다고 설명한다.FOSDEM 2025 이 문제는 폴링 주기를 짧게 잡는다고 해결되지 않는다. 스캔 주기를 좁히면 CPU·I/O 오버헤드가 늘어나고, 그래도 이론적으로는 여전히 그 주기보다 빠른 프로세스가 존재할 수 있다. 실무적 한계는 명확하다 — 감시 주기보다 빨리 끝나는 작업은 폴링으로는 원천적으로 잡을 수 없다. 배치 잡의 헬퍼 스크립트, 쉘 내장 명령 호출, 짧은 컨테이너 초기화 훅처럼 밀리초 단위로 뜨고 지는 프로세스가 이 사각지대의 전형적인 대상이다.

Q: eBPF 훅은 어떻게 짧은 프로세스를 잡아내는가?

eBPF는 커널이 프로세스를 생성·종료하는 그 순간의 훅(fork, exec, exit)에 직접 프로그램을 붙여 이벤트를 즉시 기록하기 때문에 폴링 주기라는 개념 자체가 사라진다. 사용자 공간이 나중에 조회하는 게 아니라, 커널이 이벤트가 발생하는 시점에 직접 데이터를 내보낸다. 2025년 FOSDEM 자료가 제시한 PoC에서 이 방식은 near 100%에 가까운 신뢰도를 기록했다.FOSDEM 2025 다만 이 수치는 재현 조건이 제한적으로만 공개돼 있다. PoC 수준 검증이며, 어떤 커널 버전·부하 수준에서 측정했는지는 원 자료에 세부 명시가 없다. 실무에서 이 수치를 그대로 SLA처럼 쓰기보다는, "폴링 대비 구조적으로 우월하다"는 방향성의 근거로 보는 편이 안전하다. 절대치보다 procfs 83% 대비 eBPF near 100%라는 상대적 격차가 이 소재의 핵심 신호다.

eBPF 프로브는 왜 짧은 수명 프로세스를 놓치는가?

결론부터 말하면, eBPF는 procfs 폴링보다 짧은 수명 프로세스를 훨씬 안정적으로 잡아내지만 완전하지는 않다. 커널 훅에서 직접 이벤트를 뜨는 방식이라 폴링 주기 사이의 사각지대는 사라지지만, 출력 경로인 버퍼가 가득 차면 이벤트가 조용히 드롭된다. 즉 "누락의 원인"이 폴링 주기 문제에서 버퍼·attach 신뢰성 문제로 옮겨갈 뿐이다.

이 글은 관측성 파이프라인 중에서도 프로세스 생명주기 이벤트(fork/exec/exit) 수집 구간만 다룬다. 메트릭 집계나 트레이스 샘플링 전략은 범위 밖이다.

핵심 정리

procfs 기반 폴링은 짧은 수명 프로세스에서 약 83%의 신뢰도를 보였고, eBPF 기반 fork/exec/exit 훅은 동일 조건 PoC에서 near 100%에 가까운 신뢰도를 보였다.FOSDEM 2025
eBPF도 완전하지 않다 — per-CPU perf event array와 BPF ring buffer는 가득 차면 이벤트를 조용히 버리며, 재구성된 타임라인은 실제 행동의 lower bound일 뿐이다.
OpenTelemetry eBPF Instrumentation 같은 실제 제품도 "short-lived process log enrichment" 버그를 별도로 수정할 만큼, 짧은 수명 프로세스에서 메타데이터 연결이 끊기는 문제가 실운영에서 반복된다.
판단 기준은 탐지율 하나가 아니라 탐지율·drop rate·attach 성공률·로그 보강 성공률을 함께 봐야 한다.
카디널리티 비용을 늘려서라도 커버리지를 높일지, 손실을 감수하고 비용을 낮출지는 워크로드의 프로세스 수명 분포에 달려 있다.

procfs 폴링은 왜 구조적으로 취약한가?

procfs 폴링이 취약한 이유는 감시 주기와 프로세스 수명 사이의 경합 때문이다. 수집기가 /proc을 주기적으로 스캔하는 동안, 그 주기보다 짧게 생성되고 종료되는 프로세스는 스캔과 스캔 사이에서 태어나고 죽는다. 2025년 FOSDEM 발표 초록은 이 구조 때문에 procfs 기반 접근이 짧은 수명 프로세스의 타임라인을 불완전하게 만든다고 설명한다.FOSDEM 2025

이 문제는 폴링 주기를 짧게 잡는다고 해결되지 않는다. 스캔 주기를 좁히면 CPU·I/O 오버헤드가 늘어나고, 그래도 이론적으로는 여전히 그 주기보다 빠른 프로세스가 존재할 수 있다. 실무적 한계는 명확하다 — 감시 주기보다 빨리 끝나는 작업은 폴링으로는 원천적으로 잡을 수 없다. 배치 잡의 헬퍼 스크립트, 쉘 내장 명령 호출, 짧은 컨테이너 초기화 훅처럼 밀리초 단위로 뜨고 지는 프로세스가 이 사각지대의 전형적인 대상이다.

eBPF 훅은 어떻게 짧은 프로세스를 잡아내는가?

eBPF는 커널이 프로세스를 생성·종료하는 그 순간의 훅(fork, exec, exit)에 직접 프로그램을 붙여 이벤트를 즉시 기록하기 때문에 폴링 주기라는 개념 자체가 사라진다. 사용자 공간이 나중에 조회하는 게 아니라, 커널이 이벤트가 발생하는 시점에 직접 데이터를 내보낸다. 2025년 FOSDEM 자료가 제시한 PoC에서 이 방식은 near 100%에 가까운 신뢰도를 기록했다.FOSDEM 2025

다만 이 수치는 재현 조건이 제한적으로만 공개돼 있다. PoC 수준 검증이며, 어떤 커널 버전·부하 수준에서 측정했는지는 원 자료에 세부 명시가 없다. 실무에서 이 수치를 그대로 SLA처럼 쓰기보다는, "폴링 대비 구조적으로 우월하다"는 방향성의 근거로 보는 편이 안전하다. 절대치보다 procfs 83% 대비 eBPF near 100%라는 상대적 격차가 이 소재의 핵심 신호다.

커널 버퍼는 왜 이벤트를 조용히 버리는가?

eBPF가 커널 내부에서 이벤트를 잡아도, 그 이벤트를 사용자 공간으로 내보내는 출력 경로 자체에 병목이 있다. eBPF/커널 제한을 정리한 2026년 자료는 이벤트 전달이 ordered이지만 complete하지 않다고 규정한다. per-CPU perf event array와 shared BPF ring buffer는 버퍼가 가득 차면 이벤트를 조용히 drop할 수 있으며, 이 드롭은 알림 없이 발생한다.

같은 자료는 이렇게 재구성된 타임라인이 실제 행동의 lower bound일 뿐이라고 못 박는다. 짧은 수명 프로세스 문제를 해결했다고 해서 고부하 상황에서의 드롭 문제까지 해결된 것은 아니다. 오히려 짧은 수명 프로세스가 많다는 것 자체가 이벤트 발생률을 높이는 조건이라, 버퍼 포화와 짧은 수명 프로세스 누락이 같은 시점에 겹칠 가능성이 있다. 이 지점에서 eBPF의 우위는 "폴링보다 낫다"는 상대적 우위이지 "누락이 없다"는 절대적 보장이 아니다.

로그·트레이스 보강은 어디서 끊기는가?

메타데이터 연결이 끊기는 지점은 이벤트 수집 자체가 아니라 그 뒤의 보강(enrichment) 단계다. 2026년 OpenTelemetry eBPF Instrumentation 릴리스 노트는 short-lived process log enrichment 관련 버그 수정을 신뢰성 항목으로 포함했다. 같은 릴리스의 수정 목록에는 trace parenting, wrapped Go TLS connections, OTLP attribute handling도 함께 있는데, 이는 짧은 수명 프로세스에서 로그·트레이스에 프로세스 메타데이터(이름, 부모 PID, 컨테이너 라벨 등)를 붙이는 작업이 그 자체로 실패할 수 있다는 뜻이다.OpenTelemetry eBPF Instrumentation

프로세스가 exit 이벤트를 발생시키는 시점과, 그 프로세스가 만든 로그 라인·스팬이 파이프라인에서 처리되는 시점 사이에 순서가 어긋나면, 보강 단계가 이미 사라진 프로세스의 메타데이터를 찾지 못해 빈 필드로 남긴다. attach 실패나 context propagation 문제도 같은 계열의 원인이다. 즉 "무계측 수집이라 자동으로 완전하다"는 가정은 성립하지 않으며, 제품 수준에서도 이 문제를 별도 버그로 계속 다루고 있다.

카디널리티 비용과 커버리지, 무엇을 맞바꾸는가?

트레이드오프는 명확하다 — 짧은 수명 프로세스까지 빠짐없이 잡으려 할수록 이벤트 수와 라벨 조합이 늘어나 카디널리티 비용이 커지고, 비용을 아끼려 샘플링·집계 주기를 늘리면 커버리지가 다시 줄어든다. eBPF로 fork/exec/exit을 모두 잡으면 폴링보다 이벤트 총량 자체가 늘어난다. 프로세스 하나마다 최소 두세 개의 이벤트(시작, 필요시 exec, 종료)가 발생하고, 여기에 프로세스명·인자·컨테이너 라벨 같은 속성이 붙으면 시계열/로그 저장소의 카디널리티가 함께 증가한다.

반대로 이벤트를 다운샘플링하거나 짧은 수명 프로세스를 필터링해 저장 비용을 낮추면, procfs가 이미 놓치던 사각지대에 더해 eBPF 경로에서도 의도적 손실이 생긴다. 결국 선택은 "완전한 프로세스 타임라인"과 "감당 가능한 저장·질의 비용" 사이에서 이뤄진다. 짧은 수명 프로세스 비중이 높은 워크로드(배치 스케줄러, 서버리스 콜드스타트, CI 러너)일수록 이 트레이드오프가 더 날카롭게 드러난다.

언제 이 방식을 쓰고, 언제 쓰지 않아야 하나?

짧은 수명 프로세스가 드물고 대부분의 프로세스가 초 단위 이상 실행되는 환경이라면 procfs 폴링만으로도 충분하다. 반대로 배치 잡, 서버리스 콜드스타트, CI 파이프라인처럼 밀리초~초 단위 프로세스가 반복적으로 뜨고 지는 환경에서는 eBPF 기반 fork/exec/exit 훅이 procfs보다 구조적으로 유리하다.

다만 eBPF를 도입한 뒤에도 탐지율만 보고 끝내면 안 된다. drop rate, attach 성공률, 로그/트레이스 보강 성공률을 함께 모니터링해야 실제 커버리지를 알 수 있다. 고부하 구간에서 ring buffer가 포화되는지, 릴리스 업데이트에서 enrichment 관련 버그 수정이 있었는지도 함께 추적 대상이다. eBPF 전환이 "짧은 수명 프로세스 누락"이라는 문제를 procfs 주기 문제에서 버퍼·보강 신뢰성 문제로 옮겨놓았을 뿐이라는 전제를 유지하는 편이 안전하다.

자주 묻는 질문

eBPF로 전환하면 procfs 기반 모니터링을 완전히 걷어내도 되는가?

아니다. eBPF 이벤트 경로에도 버퍼 포화로 인한 드롭이 존재하므로, procfs나 다른 보조 신호를 완전히 제거하기보다는 drop rate와 attach 성공률을 함께 관측하는 이중 검증 체계를 유지하는 편이 안전하다. 특히 고부하 구간에서는 두 경로의 결과를 교차 확인할 필요가 있다.

짧은 수명 프로세스 이벤트를 다 저장하면 카디널리티가 얼마나 늘어나는가?

정확한 증가율은 워크로드별 프로세스 발생 빈도와 부착된 라벨 수에 달려 있어 일률적으로 말하기 어렵다. 다만 fork/exec/exit을 모두 개별 이벤트로 저장하면 프로세스 하나당 최소 두세 배의 레코드가 생기므로, 라벨 카디널리티를 줄이거나 종료 이벤트만 집계하는 식의 절충이 필요하다.

drop된 eBPF 이벤트는 재전송이 되는가?

공개된 자료 기준으로는 per-CPU perf event array와 BPF ring buffer가 가득 차면 이벤트를 조용히 버리며, 별도의 재전송 메커니즘은 언급돼 있지 않다. 이 때문에 재구성된 타임라인은 실제 행동의 하한선(lower bound)으로만 취급해야 한다.

OpenTelemetry eBPF Instrumentation의 로그 보강 버그는 어떤 상황에서 문제가 되는가?

짧은 수명 프로세스가 만든 로그나 스팬에 프로세스 메타데이터를 뒤늦게 붙이는 시점에, 해당 프로세스가 이미 종료돼 정보를 찾지 못하는 경우다. 이런 사례가 릴리스 노트에 별도 수정 항목으로 오른다는 것 자체가, 실운영에서 이 문제가 드물지 않게 발생함을 보여준다.

더 알아보기

관측성 파이프라인 설계: 메트릭·로그·트레이스 수집의 실제 — 이 주제의 종합 가이드