eBPF 계측: 커널 수준의 관찰 가능성
eBPF(확장 버클리 패킷 필터) 그리고 Linux 커널 기술을 통해 커널 소스 코드를 수정하지 않고 커널 내에서 샌드박스 프로그램을 실행합니다. 자체적으로 실행하거나 커널 모듈을 로드합니다. 관찰 가능성에 적용되는 eBPF를 사용하면 추적을 얻을 수 있습니다. 분산, 성능 지표 및 네트워크 가시성 코드를 바꾸지 않고 적용 가능하고 에이전트 없음.
OpenTelemetry의 자동 계측은 애플리케이션 수준에서 작동하는 반면( 라이브러리 호출), eBPF는 커널 수준에서 작동하여 syscall, 패킷을 가로챕니다. 네트워크 및 파일 시스템 작업. 이 접근 방식은 더 낮은 오버헤드와 적용 범위를 제공합니다. 전통적으로 계측할 수 없는 서비스를 포함하여 더 광범위합니다.
이 기사에서 배울 내용
- eBPF의 기본 사항과 Linux 커널에서 작동하는 방식
- eBPF가 제로 계측 관찰 가능성을 활성화하는 방법
- Pixie: eBPF 기반 Kubernetes 관측성
- Cilium과 Hubble: eBPF를 통한 네트워킹 관찰성
- eBPF와 기존 자체 계측 비교
- 현재 한도 및 채택 시나리오
eBPF 작동 방식
eBPF를 사용하면 응답으로 실행되는 작은 프로그램을 Linux 커널에 로드할 수 있습니다. 에 특정 이벤트: syscall, 네트워크 패킷 도착, 컨텍스트 전환 프로세스, 파일 시스템 작업. 이러한 프로그램은 커널에 의해 검증되어 다음을 보장합니다. 안전(충돌 없음, 무한 루프 없음) 및 효율적인 바이트코드로 컴파일됩니다.
관찰 가능성을 위한 eBPF 아키텍처
애플리케이션 syscall을 실행합니다(예: connect(), write()) →
핵심 연관된 eBPF 프로브를 활성화합니다 →
eBPF 프로그램 메타데이터(PID, 타임스탬프, 매개변수) 캡처 →
사용자 공간 수집기 eBPF 버퍼에서 데이터를 읽습니다 →
오텔 콜렉터 수신하여 백엔드로 내보냅니다.
eBPF 프로브 유형
eBPF 프로그램은 커널의 여러 위치에 연결될 수 있습니다. 관찰 가능성의 다른 측면:
// Esempio concettuale: probe eBPF per catturare connessioni TCP
// Questo programma si attacca alla syscall connect()
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
struct connection_event {
__u32 pid;
__u32 tid;
__u64 timestamp_ns;
__u32 src_addr;
__u32 dst_addr;
__u16 dst_port;
char comm[16]; // nome del processo
};
// Buffer per inviare eventi allo user-space
struct {
__uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
__uint(key_size, sizeof(int));
__uint(value_size, sizeof(int));
} events SEC(".maps");
// Probe attaccato a tcp_connect
SEC("kprobe/tcp_connect")
int trace_tcp_connect(struct pt_regs *ctx) {
struct connection_event event = {};
event.pid = bpf_get_current_pid_tgid() >> 32;
event.tid = bpf_get_current_pid_tgid();
event.timestamp_ns = bpf_ktime_get_ns();
bpf_get_current_comm(&event.comm, sizeof(event.comm));
// Estrarre indirizzo e porta di destinazione
// ... (accesso alle strutture del kernel)
// Inviare l'evento allo user-space
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
&event, sizeof(event));
return 0;
}
관찰 가능성을 위한 프로브 유형
| 프로브 유형 | 공격 포인트 | 관찰 가능성에 사용 |
|---|---|---|
| kprobe/kretprobe | 커널 기능 | syscall 추적(연결, 읽기, 쓰기) |
| uprobe/uretprobe | 사용자 공간 기능 | 추적 라이브러리 호출(SSL, HTTP 파서) |
| 추적점 | 커널 안정 지점 | 스케줄링, I/O, 네트워킹 |
| XDP | 네트워크 드라이버(스택 전) | 고성능 트래픽 분석 |
| TC(교통관제) | 네트워크 스택 | L3/L4 트래픽 모니터링 |
Pixie: eBPF를 사용한 관측성 Kubernetes
픽시 (현재 CNCF 프로젝트의 일부) 및 관찰 가능성 플랫폼 eBPF를 사용하여 애플리케이션, 네트워크 및 네트워크에 대한 자동 가시성을 제공하는 Kubernetes 코드 변경, 애플리케이션 에이전트 또는 사이드카가 필요 없는 인프라입니다.
# Installare Pixie su un cluster Kubernetes
# Prerequisiti: Kubernetes 1.21+, kernel Linux 4.14+
# 1. Installare la CLI di Pixie
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"
# 2. Deploy di Pixie nel cluster
px deploy
# 3. Verificare lo stato
px get viziers
# 4. Eseguire query dal terminale
# Visualizzare le connessioni HTTP tra servizi
px run px/http_data
# Latenza per endpoint
px run px/service_stats
# Traffico DNS
px run px/dns_data
# Profiling CPU (flame graph)
px run px/perf_flamegraph -- --pod=order-service
Pixie는 HTTP, gRPC, MySQL, PostgreSQL, Redis, Kafka 및 DNS 트래픽을 자동으로 캡처합니다. 커널 수준에서 요청을 재구성하고 지연 시간을 계산합니다. 응용 계측.
Cilium과 Hubble: 네트워크 관측성
섬모 네트워킹 및 보안을 위해 eBPF를 사용하는 CNCF 프로젝트 쿠버네티스에서. 허블Cilium의 관찰성 구성요소인 는 다음을 제공합니다. L3/L4/L7 지표, 정책을 포함하여 포드 간 네트워크 트래픽에 대한 완벽한 가시성 네트워크 및 자동 서비스 맵.
# Installare Cilium con Hubble abilitato
# helm install cilium cilium/cilium --version 1.15.0
# Configurazione Cilium con Hubble
apiVersion: v1
kind: ConfigMap
metadata:
name: cilium-config
namespace: kube-system
data:
# Abilitare Hubble per observability
enable-hubble: "true"
hubble-listen-address: ":4244"
hubble-metrics-server: ":9965"
# Metriche L7 per HTTP
hubble-metrics: >-
dns
drop
tcp
flow
icmp
http
httpV2:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity
# Esportazione verso OpenTelemetry
hubble-export-file-max-size-mb: "10"
hubble-export-file-max-backups: "5"
# Abilitare il relay per la UI
hubble-relay-enabled: "true"
hubble-ui-enabled: "true"
# Comandi Hubble per network observability
# Osservare il traffico in tempo reale
hubble observe --namespace ecommerce
# Filtrare per protocollo HTTP
hubble observe --namespace ecommerce --protocol http
# Visualizzare solo gli errori (4xx, 5xx)
hubble observe --namespace ecommerce --http-status 400-599
# Traffico tra servizi specifici
hubble observe --from-pod ecommerce/order-service \
--to-pod ecommerce/payment-service
# Metriche per Prometheus
# Le metriche Hubble sono esposte su :9965/metrics
# e possono essere scrappate da Prometheus
eBPF와 자동 계측: 비교
eBPF와 자체 계측은 대안이 아닌 보완적인 접근 방식입니다. 누구나 가지고 있다 다양한 시나리오에 적합하게 만드는 특정 강점과 한계.
자세한 비교
| 나는 기다린다 | eBPF | 자동 계측 Otel |
|---|---|---|
| 코드 편집 | 없음 | 없음(JVM 에이전트/플래그) |
| 간접비 | 매우 낮음(커널 수준) | 낮음-중간(사용자 공간) |
| 프로토콜 범위 | HTTP, gRPC, DNS, SQL, Redis | 언어당 100개 이상의 라이브러리 |
| 맞춤 속성 | 제한됨(네트워크 데이터만 해당) | 완료(범위, 속성, 이벤트) |
| 비즈니스 컨텍스트 | 사용할 수 없음 | 수동 SDK와 함께 사용 가능 |
| OS 지원 | Linux 전용(커널 4.14+) | 크로스 플랫폼 |
| 응용 언어 | 불가지론(모든 언어) | 언어별 |
관찰 가능성을 위해 eBPF를 사용해야 하는 경우
- 네트워크 가시성: Kubernetes 클러스터의 모든 Pod 간 L3/L4/L7 트래픽을 모니터링합니다.
- 레거시 서비스: 계측할 수 없는 애플리케이션(바이너리, C/C++)에서 추적을 가져옵니다.
- 보안 모니터링: 비정상적인 연결, DNS 터널링, 측면 이동 감지
- 성능 프로파일링: 상당한 오버헤드 없이 CPU 플레임 그래프, I/O 프로파일링
- Otel에 보완: 네트워크에는 eBPF를 사용하고 애플리케이션 컨텍스트에는 OTel을 사용합니다.
eBPF의 현재 한도
혁신적인 잠재력에도 불구하고 eBPF에는 영향을 미치는 중요한 제한 사항이 있습니다. 채택:
- 리눅스 전용: eBPF는 Linux 커널 기술이며 Windows 또는 macOS(프로덕션)에서는 사용할 수 없습니다.
- 커널 버전: 커널 4.14+(고급 기능의 경우 5.8+) 필요, 레거시 시스템 제한
- TLS 트래픽: eBPF는 SSL 라이브러리를 통한 uprobe를 통해서만 복호화 후 데이터를 볼 수 있으며 복잡성이 더 커집니다.
- 비즈니스 컨텍스트 없음: eBPF는 주문 ID나 고객 계층이 아닌 패킷과 시스템 호출을 확인합니다.
- 개발 복잡성: 맞춤형 eBPF 프로그램을 작성하려면 커널 지식이 필요합니다.
결론 및 다음 단계
eBPF는 낮은 오버헤드 관측 가능성의 미래를 나타냅니다. 획득하는 능력 애플리케이션 코드를 변경하지 않고 분산 추적, 네트워크 메트릭 및 프로파일링 특히 수백 개의 서비스가 포함된 Kubernetes 클러스터의 경우 혁신적입니다.
최적의 접근 방식은 eBPF(네트워크 및 인프라 가시성용)를 결합합니다. OpenTelemetry(애플리케이션 및 비즈니스 컨텍스트용) Pixie와 같은 도구 Cilium/Hubble을 사용하면 커널 경험이 없는 팀도 eBPF에 액세스할 수 있습니다.
다음 기사에서는 샘플링 전략, 분석 가시성을 잃지 않고 원격 측정 볼륨 및 관련 비용을 줄이는 방법 중요한 사건에 대해.