eBPF インストルメンテーション: カーネル レベルでの可観測性
eBPF (拡張バークレー パケット フィルター) そしてそれを可能にする Linux カーネルテクノロジー カーネルのソース コードを変更せずに、カーネル内でサンドボックス プログラムを実行する それ自体を実行するか、カーネルモジュールをロードします。 eBPF を可観測性に適用すると、トレースを取得できるようになります 分散型のパフォーマンス メトリックとネットワークの可視性 コードを変更せずに 応用的かつエージェントレス.
OpenTelemetry の自動計測はアプリケーション レベルで動作しますが、 ライブラリ呼び出し）、eBPF はカーネル レベルで動作し、syscall、パケットをインターセプトします。 ネットワークとファイル システムの操作。このアプローチにより、オーバーヘッドとカバレッジが低くなります 従来は実装できなかったサービスも含めて、より広範です。
この記事で学べること
- eBPF の基礎と Linux カーネルでの eBPF の仕組み
- eBPF がゼロインストルメンテーションオブザーバビリティを実現する仕組み
- Pixie: eBPF に基づく Kubernetes の可観測性
- Cilium と Hubble: eBPF によるネットワークの可観測性
- eBPF と従来の自己計測の比較
- 電流制限と導入シナリオ
eBPF の仕組み
eBPF を使用すると、応答して実行される小さなプログラムを Linux カーネルにロードできます。 ある 特定のイベント: システムコール、ネットワークパケットの到着、間のコンテキストスイッチ プロセス、ファイル システム操作。これらのプログラムはカーネルによって検証され、 安全性 (クラッシュや無限ループがない) を実現し、効率的なバイトコードにコンパイルされます。
可観測性のための eBPF アーキテクチャ
応用 システムコールを実行します（例: 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;
}
可観測性のためのプローブの種類
| プローブの種類 | アタックポイント | 可観測性での使用 |
|---|---|---|
| kプローブ/クレットプローブ | カーネル関数 | システムコールのトレース (接続、読み取り、書き込み) |
| アッププローブ/ウレットプローブ | ユーザー空間関数 | ライブラリ呼び出しのトレース (SSL、HTTP パーサー) |
| トレースポイント | カーネル安定ポイント | スケジューリング、I/O、ネットワーキング |
| XDP | ネットワークドライバー (スタック前) | 高性能トラフィック分析 |
| TC（交通管制） | ネットワークスタック | L3/L4トラフィック監視 |
Pixie: eBPF を使用した可観測性 Kubernetes
ピクシー (現在は CNCF プロジェクトの一部) および可観測性プラットフォーム Kubernetes は eBPF を使用して、アプリケーション、ネットワーク、 コード変更、アプリケーション エージェント、サイドカーを必要としないインフラストラクチャ。
# 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 とハッブル: ネットワークの可観測性
繊毛 ネットワーキングとセキュリティに eBPF を使用する CNCF プロジェクト Kubernetesで。 ハッブル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 クラスター内のすべてのポッド間の L3/L4/L7 トラフィックを監視します
- レガシーサービス: インストルメントできないアプリケーションからトレースを取得します (バイナリ、C/C++)
- セキュリティ監視: 異常な接続、DNS トンネリング、横方向の移動を検出します。
- パフォーマンスプロファイリング: CPU フレーム グラフ、大幅なオーバーヘッドのない I/O プロファイリング
- OTelの補完: ネットワークには eBPF を使用し、アプリケーション コンテキストには OTel を使用します。
eBPF の電流制限
eBPF にはその革新的な可能性にもかかわらず、eBPF に影響を及ぼす重要な制限があります。 採用:
- Linuxのみ: eBPF は Linux カーネル テクノロジであり、Windows または macOS (運用環境) では利用できません。
- カーネルのバージョン: カーネル 4.14 以降 (高度な機能には 5.8 以降) が必要で、レガシー システムが制限されます
- TLSトラフィック: eBPF は、SSL ライブラリを介したアップローブでのみ復号化後のデータを参照しますが、さらに複雑になります
- ビジネスコンテキストなし: eBPF は注文 ID や顧客層ではなく、パケットとシステムコールを認識します
- 開発の複雑さ: カスタム eBPF プログラムの作成にはカーネルの知識が必要です
結論と次のステップ
eBPF は、低オーバーヘッドの可観測性の未来を表します。取得する能力 アプリケーションコードを変更せずに分散トレース、ネットワークメトリクス、プロファイリングを実行 特に数百のサービスを含む Kubernetes クラスターにとっては革命的です。
最適なアプローチでは、eBPF (ネットワークとインフラストラクチャの可視化) と OpenTelemetry (アプリケーションおよびビジネス コンテキスト用)。 Pixie や Cilium/Hubble を使用すると、カーネルの経験がないチームでも eBPF にアクセスできるようになります。
次の記事では、 サンプリング戦略、分析する 可視性を失わずにテレメトリの量と関連コストを削減する方法 重要な出来事について。