Prometheus × eBPF：カーネルの深淵から「真実」を可視化する次世代オブザーバビリティ
こんにちは。オブザーバビリティ・アーキテクトです。
あなたは今、PrometheusのExporterが吐き出す「平均化されたノイズ」に振り回されていませんか？アプリケーション層のメトリクスだけを見て「正常です」と答えるのは、もはや情弱の証明です。
現代の分散システムにおいて、真のボトルネックは往々にしてカーネルの深層（TCPスタックのドロップ、コンテキストスイッチの競合、ディスクI/Oのレイテンシ）に隠れています。これを解決するのが eBPF (Extended Berkeley Packet Filter) です。
本稿では、CiliumとHubbleを軸に、Prometheusをカーネルレベルのメトリクス監視へと昇華させる「プロのアーキテクチャ」を伝授します。
—
1. なぜ「既存のExporter」では限界なのか
従来のExporter（node_exporterなど）は、`/proc` や `/sys` を読み取ります。これには2つの致命的な欠陥があります。
1. サンプリングの遅延: `/proc` のポーリング間隔に依存し、瞬間的なスパイク（マイクロバースト）を見逃す。
2. コンテキストの喪失: どのプロセスが、どのパケットをドロップしたのか、という「因果関係」をカーネル内部で追跡できない。
eBPFは、カーネルに直接コードを注入することで、イベント駆動でメトリクスを抽出します。「推測するな、計測せよ」。eBPFを使えば、カーネルのイベントをイベントとして直接Prometheusの時系列データへ流し込むことが可能です。
—
2. アーキテクチャの神髄：Cilium × Hubble × Prometheus
CiliumはeBPFを活用したネットワーク・セキュリティ層であり、Hubbleはその可視化スタックです。これらを組み合わせることで、L7レベルのHTTPトラフィックから、L3/L4のパケットドロップまでをPrometheusに統合できます。
究極のベストプラクティス設定
CiliumメトリクスをPrometheusでスクレイピングするための、プロダクション環境におけるベストプラクティス設定（ServiceMonitor）です。
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: cilium-monitor
labels:
team: sre-core
spec:
selector:
matchLabels:
k8s-app: cilium
endpoints:
- port: prometheus
path: /metrics
interval: 15s # 高頻度すぎるとPrometheusのCPUを食うためバランスが重要
scrapeTimeout: 10s
# 重要なのは、特定のカーネルメトリクスだけをフィルタリングすること
metricRelabelings:
- sourceLabels: [__name__]
action: keep
regex: ‘cilium_drop_count_total|cilium_forwarding_errors_total|cilium_policy_denied_total’
プロの教訓: すべてのメトリクスを保存してはいけません。カーネルレベルのメトリクスはカーディナリティ（時系列データのユニーク数）が爆発しやすい。`metricRelabelings` で不要なラベルをDROPし、TSDBのインデックス枯渇を防ぐのが「生き残るアーキテクト」の作法です。
—
3. 生産性を加速させる「現場のテクニック」
① Hubble CLIの「隠し芸」：コマンドラインで解決する
Hubble CLIは単なる可視化ツールではありません。障害発生時、GUIを見ている暇はありません。
特定のサービス間通信でパケットがドロップされた瞬間のログを瞬時に抽出
hubble observe –pod
このコマンドをターミナルで実行しながら、Prometheusのダッシュボードを横目に監視するのが、トラブルシューティングの「最短ルート」です。
② VS Code神プラグイン設定
Prometheus / KubernetesのYAMLを扱う際、チーム開発で導入すべきは以下のプラグインです。
- Prometheus Query Editor: クエリのシンタックスハイライト、補完が強力。
- Kubernetes YAML Generator: 複雑なリソース設定をテンプレートから生成し、ヒューマンエラーを排除。
③ チーム設定の共有化ルール
設定ファイル（Prometheus RuleやServiceMonitor）は、必ず CUE言語 または Jsonnet で管理してください。YAMLのコピペによる設定ミスは、障害の温床です。
// Jsonnetによる設定の抽象化例
local cilium_metrics = import ‘cilium-metrics.libsonnet’;
{
groups: [
cilium_metrics.alert_on_packet_drops(‘critical-app’, threshold=100),
]
}
—
4. 最後に：エンジニアの皆様へ
eBPFによる監視は、魔法ではありません。しかし、従来の「ブラックボックス」であったカーネル内部を、Prometheusのクエリ一つで照らせるようになることは、まさに革命です。
明日からのアクションアイテム:
1. 既存のCiliumクラスターで `cilium_drop_count_total` をPrometheusで可視化せよ。
2. そのグラフのスパイクと、アプリケーションのレイテンシ上昇が一致するか確認せよ。
3. もし一致していたら、あなたは「アプリケーションのせい」という無意味な議論から解放されます。
オブザーバビリティとは、ツールを入れることではありません。「システムが何をしているか、その真実を誰よりも速く理解する能力」のことです。
さあ、カーネルの深層を覗きに行きましょう。そこに答えはあります。