eBPF 공부방-Parca

아래는 10편(최종편) 전체 본문 확장판 초안입니다.이 편은 연재의 결론 + 도입 판단 가이드 역할을 하도록 구성했습니다.“Parca가 좋은가?”가 아니라 “누가 써야 하는가”기술적 적합성 + 조직적 적합성도입해도 실패하는 경우까지 포함CTO / SRE / 플랫폼 팀이 읽어도 설득되는 구조Parca는 누구에게 필요한 도구인가도입 판단 가이드 & 연재 정리이 연재를 여기까지 읽었다면,이제 질문은 단순해진다.“Parca는 쓸 수 있는 도구인가?” ❌“우리에게 필요한 도구인가?” ⭕Parca는 좋은 도구다.하지만 모두에게 필요한 도구는 아니다.이번 마지막 편에서는Parca 도입 여부를 판단할 수 있도록사람·조직·문제 유형 기준으로 정리한다.1️⃣ Parca는 어떤 문제를 푸는 도구인가Parca가 푸는 문제는 ..

Parca 도입 시 현실적인 고려사항운영, 보안, 성능 관점Parca를 어느 정도 이해한 뒤,실무에서는 결국 이 질문으로 수렴한다.“그래서… 운영 서버에 깔아도 되는가?”이 질문에 정직하게 답하지 못하면,Parca는 PoC에서 멈추거나“위험한 도구”라는 낙인이 찍힌다.이번 편에서는Parca 도입을 결정하기 전에 반드시 검토해야 할현실적인 체크 포인트를 정리한다.1️⃣ 운영 관점: 항상 켜도 되는가?Parca의 기본 전제상시 활성화를 전제로 설계장애 시에만 켜는 도구 ❌평상시 데이터를 쌓아두는 도구 ⭕️하지만 “설계상 가능”과 “우리 환경에서 가능”은 다르다.운영에서 가장 중요한 질문 3가지agent가 죽으면 서비스에 영향이 있는가?server가 죽으면 서비스에 영향이 있는가?네트워크가 끊기면 무슨 일이 ..

아래는 8편 전체 본문 확장판 초안입니다.이번 편은 Parca가 “운영 환경에서도 안전하게 eBPF를 쓰는 이유”를 설명하는 핵심 이론 편입니다.왜 eBPF가 커널 버전에 취약했는지CO-RE가 무엇을 해결했는지Parca / parca-agent가 이를 어떻게 활용하는지실무자가 반드시 알아야 할 한계까지 포함CO-RE와 Parca커널 의존성 문제는 어떻게 해결되는가eBPF를 공부하다 보면반드시 한 번은 이런 말을 듣게 된다.“eBPF는 좋은데,커널 버전 맞추는 게 너무 힘들다.”이 말은 과거에는 사실이었다.그리고 CO-RE(Compile Once – Run Everywhere)는이 문제를 정면으로 해결하기 위해 등장했다.Parca는 바로 이 CO-RE 위에 설계된운영 환경 친화적 eBPF 프로파일러다.1️..

아래는 7편 전체 본문 확장판 초안입니다.이번 편은 Parca를 Kubernetes 환경에서 “제대로” 쓰기 위한 핵심 이론 편입니다.컨테이너 환경에서 왜 profiling이 더 어려운지PID / Namespace / cgroup 관점에서 Parca가 무엇을 보고 있는지Flamegraph를 어디까지 믿어도 되는지실무에서 가장 많이 헷갈리는 포인트 정리컨테이너·Kubernetes 환경에서의 ParcaPID, Namespace, cgroup 관점Parca를 Kubernetes 환경에 배포한 뒤Flamegraph를 처음 보면 이런 생각이 들 수 있다.“이게 어느 컨테이너 거지?”“PID가 왜 이렇게 이상하지?”“노드 커널 함수가 왜 이렇게 많이 보이지?”이 혼란은 도구의 문제가 아니라,컨테이너 실행 모델을 충..

1. Datadog의 기본 수집 방식 (Push)Datadog은 호스트(또는 컨테이너)에 Datadog Agent를 설치하고,이 Agent가 주기적으로 Datadog SaaS 백엔드로 데이터를 전송(push) 합니다.흐름[Application / OS / Container] ↓ Datadog Agent ↓ (HTTPS, outbound) Datadog BackendAgent가 수집하는 것 • 시스템 메트릭 (CPU, Memory, Disk, Network) • 애플리케이션 메트릭 • 로그 (선택) • APM Trace • 프로파일링 데이터 • 컨테이너 / Kubernetes 메타데이터→ 모두 Agent가 주도적으로 전송합니다.⸻2. Prometheus와의 ..

Prometheus의 기본 수집 방식 (Pull) • Prometheus 서버가 주기적으로(Target scrape interval)각 대상(exporter, 애플리케이션)의 HTTP endpoint에 직접 요청합니다. • 보통 /metrics 엔드포인트를 사용합니다. • 대상이 제공하는 현재 시점의 메트릭 스냅샷을 가져옵니다.Prometheus Server ---> HTTP GET /metrics ---> Target (Exporter/App)이 구조가 Prometheus 설계의 중심입니다.⸻왜 Pull 모델을 선택했는가Pull 모델은 Prometheus 철학과 잘 맞습니다. 1. 서비스 디스커버리와 궁합이 좋음 • Kubernetes, Consul, EC2 등에서 대상이 동적으로 변해도 • P..

실전 사례 ①CPU 사용률은 정상인데, 성능은 느린 이유운영 중인 서버에서 다음과 같은 리포트를 받았다고 가정해 보자.CPU 사용률: 평균 40~50%Load Average: 정상메모리 여유 충분APM: 주요 API 응답 시간 “정상 범위”사용자 체감: “전체적으로 느림”이 상황은 의외로 매우 흔하다.그리고 가장 골치 아픈 유형이기도 하다.1. 문제의 핵심: “정상 지표”의 함정전통적 모니터링 지표CPU: 45%Memory: 62%Disk IO: 낮음Network: 정상→ 문제 없어 보인다.APM 지표/api/search 평균 110ms/api/order 평균 180ms에러율 0% → 역시 문제 없어 보인다.이 단계에서 흔히 나오는 결론은 이것이다.“일시적인 네트워크 문제였나 봅니다.”하지만 사용자는 여..

Flamegraph 제대로 읽기Parca UI 해석 가이드Parca를 처음 실행하면 대부분 이런 반응을 보인다.“그래프는 나오는데…이걸 어떻게 해석해야 하지?”Flamegraph는 직관적인 듯 보이지만,실제로는 매우 쉽게 오해되는 시각화다.이번 편의 목표는 단 하나다.Flamegraph를 ‘그림’이 아니라‘성능 설명 도구’로 읽게 만드는 것Flamegraph는 무엇을 보여주는가 (한 문장 정의)Flamegraph는CPU 시간이 어떤 함수 호출 경로에서얼마나 사용되었는지를 보여준다.여기서 핵심 단어는 세 가지다.CPU 시간함수 호출 경로 (call stack)누적 분포 Parca UI에서 보는 Flamegraph는 다음과 같은 규칙을 가진다.X축: 시간 비율 (가로 폭)가로 폭이 넓을수록→ CPU 시간을 ..

Parca와 기존 APM / 모니터링 에이전트 비교무엇이 같고, 무엇이 다른가Parca를 처음 접하면 많은 사람들이 이렇게 묻는다.“이거 APM이랑 뭐가 다른가요?”“기존 모니터링 에이전트랑 겹치지 않나요?”이 질문은 매우 자연스럽다.그리고 이 질문에 제대로 답하지 못하면Parca는 ‘굳이 써야 하나?’라는 도구로 남게 된다.이번 편에서는Parca, APM, 전통적 모니터링 에이전트를같은 테이블 위에 올려놓고 비교한다.먼저 한 문장 요약부터APM은 ‘요청’을 본다모니터링 에이전트는 ‘자원’을 본다Parca는 ‘CPU 시간의 실제 사용처’를 본다이 문장을 이해하면이번 글의 절반은 이미 이해한 셈이다.비교 대상 정리이번 글에서 비교할 대상은 다음 세 가지다.전통적 모니터링 에이전트CPU, Memory, Di..

parca-agent 내부 구조 분석eBPF 기반 수집 메커니즘Parca를 “설치해 보는 도구”가 아니라신뢰할 수 있는 성능 분석 도구로 받아들이기 위해서는반드시 한 번은 짚고 넘어가야 할 질문이 있다.parca-agent는 정확히 무엇을,어떤 방식으로,얼마나 자주 수집하는가?이번 편에서는 이 질문에 답한다.parca-agent의 역할 다시 정리먼저 역할을 다시 명확히 하자.parca-agent는:CPU 사용량을 계산하지 않는다병목을 판단하지 않는다Flamegraph를 만들지 않는다parca-agent가 하는 일은 단 하나다.“CPU가 인터럽트된 순간의실행 스택을 샘플링한다.”모든 분석은이 단순한 행위의 반복 위에 쌓인다.전체 수집 흐름 한눈에 보기 parca-agent의 내부 동작을 흐름으로 단순화하..