프로덕션 문제를 프로파일하는 전통적인 방법은 어색한 종속성을 가지고 있습니다: 당신은 이미 그것을 의심해야 합니다. 무언가가 느려 보입니다. 프로파일러를 부착합니다. 조건을 재현하려고 시도합니다. 그리고 — 운이 좋고 문제가 여전히 발생한다면 — 데이터를 캡처합니다. 실패 모드는 명백하고 일반적입니다. 사건은 오전 3시에 발생했습니다. 4분 지속되었습니다. 누군가가 봤을 때, 증거가 이미 사라졌습니다. 로깅을 추가하고, 재발을 희망하고, 기다립니다.
eBPF는 항상 켜진 프로파일링을 만들기에 충분히 경제학을 변경했습니다. eBPF 프로그램이 검증된 샌드박스의 커널 내에서 실행되기 때문에, 그들은 시스콜, 스케줄링, 그리고 기계의 모든 프로세스에 걸친 스택 추적을 오버헤드 낮음 — 계속 1% 미만 — 로 관찰할 수 있어서, 그것은 영구적으로 실행되도록 남길 수 있습니다. 이것이 프로파일링을 당신이 시작하는 것에서 당신이 쿼리하는 것으로 전환합니다: 오전 3시 데이터가 이미 존재합니다. 이 가이드는 Parca Agent를 통한 연속 프로파일링을 통해 그 변화를 다루고, 자율 에이전트가 증식함에 따라 나타나는 새로운 응용 프로그램 — 동일한 커널 수준 가시성을 사용하여 AI 에이전트가 실제로 무엇을 했는지 보기, AgentSight과 같은 도구를 통해.
eBPF가 항상 켜진 것을 실행 가능하게 만든 이유
기술적 이유는 이전에 연속 프로파일링이 비실용적이었다는 것입니다. 더 오래된 옵션은 모두 영구적으로 지불하지 않는 세금을 부과했습니다. perf에 기반한 샘플링 프로파일러는 저렴하지만 대상당 설정이 필요하고 자신을 관리해야 하는 데이터를 생산합니다. 계측된 프로파일러는 코드 변경이 필요하고 호출당 오버헤드를 추가합니다. 언어별 에이전트는 한 런타임을 다루고 종종 자신의 성능 비용을 소개합니다. 그 중 어느 것도 영구적으로 모든 프로세스에 모든 노드에서 실행할 것들이 아닙니다.
eBPF의 기여는 프로그램이 커널 공간에서 실행되므로 스택 추적을 수집하기 위해 각 샘플에 대해 사용자 공간 에이전트로 문맥 전환할 필요가 없고, 커널의 검증자가 프로그램을 로드하기 전에 시스템을 충돌시키거나 영원히 루프할 수 없다는 것을 정적으로 증명합니다. 결과는 커널 수준 가시성이며 안전 보증이며 오버헤드는 소음에서입니다. 중요하게, 그것은 또한 제로 계측입니다: 프로파일된 응용 프로그램을 수정, 재컴파일, 또는 재시작할 필요가 없습니다, 이전 시도의 대부분을 죽인 조직적 마찰을 제거합니다.
한 가지 실제 전제조건이 명시할 가치가 있습니다: 이것은 BTF 지원이 있는 합리적으로 현대적 커널과 기호 가용성에 달려 있습니다. 제거된 프로덕션 바이너리는 16진 주소로 가득한 프로파일을 생성하며, 이는 풀 수 있는 문제이지만 결론을 내리기 전에 풀어야 하는 것입니다.
실제로 연속 프로파일링
Parca Agent는 아이디어의 가장 명확한 표현입니다. Kubernetes에 DaemonSet으로 배포 (또는 노드의 프로세스)되면, 그것은 해당 노드의 모든 프로세스에서 스택 추적을 샘플링합니다, 계속, pod, 컨테이너, 네임스페이스 메타데이터로 그들을 레이블하고, 시간 범위 및 레이블로 쿼리할 수 있는 메트릭처럼 저장되는 서버로 그들을 전송합니다.
그 저장 모델은 그것을 흥미롭게 만드는 것이 아닌 유용하게 만드는 것입니다. 프로파일이 레이블이 지정된 시계열이므로, 온디맨드 프로파일링이 대답할 수 없는 질문을 할 수 있습니다. 03:04에서 03:08 사이에 지불 네임스페이스에서 CPU를 소비하는 것은 무엇이었나요? 프로파일이 존재합니다; 당신이 창을 필터합니다. 더욱 귀중한 것은 비교입니다: 배포 전의 프로파일을 배포 후와 차이하고, 회귀가 커진 함수로 나타납니다. "이전" 프로파일을 원할 것으로 예측할 필요가 없습니다 — 연속 수집은 이제 항상 거기 있다는 뜻입니다.
Parca는 혼합 언어 스택을 처리하며, 이것이 소리보다 더 중요합니다. 현대 서비스는 C 라이브러리로 호출하는 Go일 수 있으며, 또는 네이티브 확장을 호출하는 Python이며, 한 계층만 해석하는 프로파일은 오해의 소지가 있는 이야기를 말합니다. 커널 수준 언와인딩은 전체 스택을 봅니다. 심층 일회성 분석을 위해 당신은 여전히 perf 또는 async-profiler에 도달할 것입니다 — 연속 프로파일링은 최대 실행당 세부사항이 아닌 커버리지 및 이력을 위해 최적화합니다 — 하지만 "이 클러스터가 CPU에 무엇을 지출하고 있나요"라는 일상적인 질문은 계속 및 저렴하게 대답됩니다.
새로운 문제: 에이전트가 무엇을 했는가?
두 번째 응용은 더 새로우며, 2026년에는 점점 더 긴급합니다. 팀은 실제 시스템에서 자율 코딩 에이전트 및 도구 접근으로 LLM 에이전트를 실행하고 있습니다. 이러한 에이전트는 파일을 읽고, 명령을 실행하고, 패키지를 설치하고, 네트워크 호출을 만듭니다. 이러한 시스템이 제공하는 관찰성은 응용 프로그램 수준: 프롬프트, 도구 호출, 토큰 수, 스팬. Langfuse와 Arize Phoenix와 같은 도구가 이것을 잘 합니다. 그리고 진정으로 유용합니다.
그러나 응용 프로그램 수준 추적은 구조적 제한을 가지고 있습니다: 에이전트 프레임워크가 보고하기로 선택한 것을 보여줍니다. 도구가 셸 명령을 실행하면, 추적은 명령 문자열을 기록합니다 — 명령이 생성한 17개 프로세스, 그들이 건드린 파일, 또는 그들이 연락한 호스트는 아닙니다. 에이전트가 프롬프트 주입에 의해 손상되고 의도된 범위 밖의 조치를 취하면, 추적은 에이전트가 설명한 행동을 보여주며, 이는 정확히 보안 질문에 대한 잘못된 진실 원본입니다.
AgentSight는 여기 eBPF를 적용합니다: 에이전트의 실제 시스템 동작을 커널 수준에서 관찰합니다 — 프로세스 실행, 파일 접근, 네트워크 연결 — 에이전트에 계측 없이. 에이전트는 이 이벤트를 생략하거나 오류할 수 없습니다. 왜냐하면 보고하는 것이 아니라 커널입니다. 리포지토리에서 작동하는 코딩 에이전트의 경우, 당신은 실제 답변을 얻습니다 "어느 파일을 수정했나요", "무엇을 실행했나요", 그리고 "범위 밖으로 도달했나요".
올바른 자세는 이들이 경쟁자가 아닌 보완 계층입니다. 응용 프로그램 추적은 당신에게 에이전트의 의도 및 추론을 말합니다; 커널 추적은 그것의 효과를 말합니다. 타임스탐프로 그들을 상관관계하면 당신은 둘 다의 절반을 얻습니다: 이것이 에이전트가 시도하려고 했던 것입니다, 그리고 기계에 실제로 발생했던 것입니다. 실제 권한이 있는 것의 경우, 첫 번째 절반만 있는 것이 격차입니다.
보안, 단지 성능이 아니라
그 프레이밍은 더 광범위한 용도를 가리킵니다. 동일한 eBPF 기초는 런타임 보안 도구를 지원합니다 — Tracee, Falco, Tetragon — 의심스러운 커널 수준 동작을 감시하고, Tetragon의 경우, 커널 내에서 정책을 시행할 수 있습니다. 모든 노드에서 프로세스, 파일, 네트워크 이벤트를 수집하면, "관찰성"과 "탐지" 사이의 차이는 주로 어느 질문을 당신이 데이터에 묻는지입니다.
에이전트 워크로드의 경우, 그 수렴이 유용합니다. "이게 왜 느린가", "에이전트가 무엇을 바꿨는가", 그리고 "뭔가 그것의 샌드박스를 벗어났는가"라는 질문이 모두 같은 이벤트 스트림에서 대답됩니다. 실제로, 이것은 시스템 접근으로 에이전트를 배포하는 조직이 커널 수준 가시성을 배포 후 생각이 아닌 배포의 일부로 취급해야 한다는 의미입니다 — 자율 프로세스가 실제로 무엇을 했는지에 대한 감시 가능한 증거를 생산하는 유일한 계층입니다.
정직한 경고는 부피입니다. 커널 수준 추적은 거대한 이벤트 스트림을 생성할 수 있으며, 바쁜 노드의 모든 시스콜을 추적하는 것을 일단이면 저장소를 압도하고 뭔가를 찾을 능력이 있습니다. 소스에서 필터링 — 경로별, 프로세스별, 이벤트 타입별 — 최적화가 아니라 요구사항입니다. 그리고 그것이 대부분의 운영 작업이 이러한 도구에서 산다는 곳입니다.
속임수 없이 프로파일 읽기
연속 프로파일링은 많은 데이터를 생산하고, 그것을 잘못 읽을 신뢰할 수 있는 몇 가지 방법이 있습니다. 행동하기 전에 알아야 합니다.
폭은 샘플이지, 월 시간이 아닙니다. CPU 프로파일은 CPU 시간이 어디로 갔는지 보여줍니다. 당신의 서비스가 느린 이유가 그것이 기다리고 있기 때문이라면 — 데이터베이스에, 잠금에, 네트워크 호출에 — CPU 프로파일은 완전히 건강해 보일 수 있으며, 차단된 스레드는 CPU를 소비하지 않습니다. 이것이 가장 일반적인 오진입니다: 프로파일이 평탄하기 때문에 문제가 없다고 결론지음, 문제가 오프 CPU 시간입니다. 월 시간 또는 오프 CPU 프로파일링이 대신 그 질문에 대답합니다.
집계 핫스팟이 필연적으로 당신의 지연 문제는 아닙니다. 함수가 클러스터 CPU의 30%를 소비하는 것이 완전히 예상된 배경 일입니다 — 직렬화, 압축, 쓰레기 수거. 흥미로운 신호는 보통 변화입니다: 이 함수는 지난주 5%였고 이제 30%입니다. 그것이 비교가 절대 순위보다 더 중요한 이유이며, 왜 연속 수집이 단일 스냅샷을 이깁니다.
기호 품질은 결론을 형성합니다. 누락된 기호는 스택을 도움이 되지 않는 16진 주소로 붕괴시키고, 더 나쁜 것은 그들이 가장 가까운 해석 가능 프레임에 시간을 오귀속시킬 수 있습니다 — 자신감 있고 잘못된 답을 생산합니다. 프로파일이 말도 안 되는 함수를 탓하면, 코드를 의심하기 전에 언와인딩을 의심합니다.
샘플링은 바닥을 가지고 있습니다. 자주 실행하지만 매우 짧게 실행하는 함수는 트루 비용에 상대적으로 저조사될 수 있으며, 드물지만 비싼 이벤트는 짧은 창에서 모두 나타나지 않을 수 있습니다. 연속 수집은 긴 기간에 걸쳐 집계하여 이를 완화합니다. 이는 항상 켜진 것 대신 온디맨드를 위한 또 다른 인수입니다.
실제 습관: 프로파일을 사용하여 가설을 형성한 다음, 행동하기 전에 목표 측정으로 그것을 확인합니다.
이것을 성실하게 채택합니다
실용적인 시퀀스는 모든 것을 배포하고 익사하는 공통 실패를 피합니다. 노드의 하위 집합에 연속 프로파일링으로 시작합니다. 가장 낮은 위험 소개이며, 즉시 가치를 제공합니다 (첫 주에 놀랄 수 있는 것을 찾을 것입니다), 그리고 당신의 커널과 기호가 어떻게 동작하는지 알아봅니다.
그 후 비교 워크플로를 추가합니다, 왜냐하면 그것이 집중되는 보상입니다: CPU 회귀가 3일 후 지연 경고로 잡히는 대신 그것이 프로파일 변화로서 잡혀야 하도록 릴리스 프로세스에 프로파일 차이를 연결합니다.
에이전트가 실제로 시스템 접근으로 실행할 때 에이전트 수준 추적을 추가합니다. 당신의 에이전트가 API를 호출하고 텍스트를 반환하는 경우만, 커널 추적은 과도합니다. 명령을 실행하거나, 파일을 작성하거나, 리포지토리에 작동하는 경우, 가시성 격차는 실제이고 폐쇄할 가치가 있습니다.
그리고 처음부터 공격적으로 필터합니다. 어느 경로, 프로세스, 이벤트 타입이 문제인지 미리 결정하고 나머지는 제외합니다. 나중에 좁은 필터를 넓히는 것이 이미 저장하고 있는 소방관에 필터링을 개선하는 것보다 훨씬 쉽습니다.
마지막으로, 온디맨드 도구를 날카로운 상태로 유지합니다. 연속 프로파일링은 함수가 뜨거워졌고 언제를 알려줍니다; perf, bpftrace, async-profiler는 깊은 다이빙을 위해 더 낫습니다. 작동하는 워크플로우는 감지 및 이력을 위한 연속 데이터, 진단을 위한 목표 도구입니다.
핵심 바닥
eBPF는 "추적을 붙일 때 문제를 의심"에서 "데이터가 이미 존재합니다, 쿼리합니다"로 관찰성을 이동했습니다. 왜냐하면 커널 측 실행이 검증된 샌드박스로 항상 켜진 수집을 1% 미만 비용으로 그리고 응용 프로그램 변경 없이 만들었기 때문입니다. Parca Agent는 연속, 레이블 쿼리 가능, 혼합 언어 CPU 프로파일링으로 이를 제공하며, 그것의 실제 초능력이 비교입니다: 배포 후 회귀가 프로파일 변화로 나타납니다. 새로운 경계는 자율 에이전트에 같은 가시성을 적용합니다: AgentSight는 에이전트가 응용 프로그램 추적이 남겨진 격차를 폐쇄하는 시스콜 수준에서 실제로 무엇을 했는지 보여줍니다. 몇 노드에서 프로파일링으로 시작하고, 당신의 기호를 검증하고, 릴리스에 비교를 구축하고, 에이전트가 실제 시스템을 건드릴 때 에이전트 추적을 추가하고, 처음부터 열심히 필터링하고, perf와 bpftrace를 깊은 다이빙을 위해 유지합니다.
참조 및 리소스
도구
배경 및 분석
관련 1337skills 치트시트