Cilium指標のすべてを解剖：エージェント、オペレーター、Envoy、Hubbleの4つの領域

状態：ドラフト（2026-10-05）、実測を反映。 指標のリストと値は、実験環境の1ノードにおけるエージェント、同一ノードのEnvoyとHubble、および1つのオペレーターから読み取り専用で取得したある時点のスナップショットです。指標の意味はHELP文字列とCiliumのドキュメントに基づいており、この記事の執筆時点でドキュメントを再度開いて突合はしていません（未確認）。PromQLの例は実行していません（未実行）。作成ルール：実測データが基本であり、測定できなかったものは「未実測」と表記します。

目次

• 1. 指標を出力する4つの場所
• 2. エージェント指標（cilium_* 約100系列）
  • 2.1 データプレーン：転送、ドロップ、接続追跡
  • 2.2 BPFリソース
  • 2.3 エンドポイント、アイデンティティ、ポリシー
  • 2.4 Kubernetes連携とコントロールプレーン
  • 2.5 ノードとクラスター
  • 2.6 機能有効化の表示（cilium_feature_* 32個）
  • 2.7 プロセスとランタイム
• 3. オペレーター指標（96系列）
• 4. Envoy指標（450系列）
• 5. 実測で読み解くエージェントの状態（1ノード、稼働約11.8日）
• 6. Hubble指標のカーディナリティの問題
• 7. アラートとダッシュボードの候補（未実行）
• 8. 面接で聞かれそうな質問
• 9. よくある誤解
• 確認できなかったこと
• 参考文献
• 確認したバージョンと日付

1. 指標を出力する4つの場所

Cilium 1.20.1（kube-proxy-replacement=true、VXLANトンネル、Hubble有効）は、4つの場所で別々に指標を出力します。すべてクラスター内のヘッドレスサービスとして公開されています。

設定は enable-metrics=true, enable-hubble-open-metrics=true です。Hubbleが出力する指標は hubble-metrics の設定で決まります。

dns drop tcp flow port-distribution icmp
httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction

数値の大半がHubbleの1箇所から来ているという点がこの記事の重要な着眼点であるため、第6節で個別に扱います。

2. エージェント指標（cilium_* 約100系列）

エージェントは169の系列のうち cilium_* が約100個であり、残りはGoランタイム（go_*）とプロセス指標です。意味はHELP文字列を日本語に翻訳したものです。

2.1 データプレーン：転送、ドロップ、接続追跡

2.2 BPFリソース

2.3 エンドポイント、アイデンティティ、ポリシー

2.4 Kubernetes連携とコントロールプレーン

2.5 ノードとクラスター

2.6 機能有効化の表示（cilium_feature_* 32個）

値が1であれば有効であるという意味のゲージの集まりです。設定の監査に便利です。1ノードから読み取った有効状態は以下の通りです。

• 有効（1）： 帯域幅マネージャー、Envoy設定とEnvoyプロキシ、kube-proxyの代替、ノードポート設定、ホストファイヤーウォール、デフォルト拒否以外のポリシー。（アイデンティティ割り当て、IPAM、データパスモードなどの項目は値ではなくモードラベルで区別されるため、ここでは解釈していません。）
• 無効（0）： BGP、エグレスゲートウェイ、L2ロードバランサーとL2ポッド広告、SCTP、VTEP、ローカルリダイレクトポリシー、相互認証、エンドポイントスライス、エンドポイントルート。
• 累積数（counter）： エージェント起動以降にロードしたポリシーの種類別の累積値が出力されます。

暗号化に関する指標はありません。 wireguard と encrypt が含まれる行が0でした。透過的暗号化（WireGuard）が無効になっている状態と一致しており、有効にした後に生成される指標は直接有効にして確認できていません（未実測、運用設定を変更しないため）。代わりにCilium公式指標ドキュメント（Feature Metricsの表）を読むと、透過的暗号化モードを通知するゲージ（transparent_encryption、ラベルは mode, node2node_enabled, strict_mode_enabled）があり、 mode の値に wireguard と ipsec が入り得ると記載されています。実際に露出される名前のプレフィックスは確認できなかったため、有効にした後は grep -i encryption で検索する必要があります。

2.7 プロセスとランタイム

cilium_process_*（CPU時間、オープンファイル、常駐メモリ、ネットワーク送受信バイトなど9系列）と go_*（メモリ統計22系列、GC、スケジューラー）があります。エージェントの常駐メモリは1ノードあたり約270MiB（283,545,600B）でした。

3. オペレーター指標（96系列）

実験環境でGateway APIとIngressコントローラーが有効になっているという事実が、この機能有効化指標と一致しています。

4. Envoy指標（450系列）

CiliumのEnvoyはGateway APIとL7ポリシーを処理し、標準的なEnvoy指標をそのまま出力します。系列数はプレフィックス基準で envoy_cluster_* 191, envoy_http_* 89, envoy_listener_* 78, envoy_server_* 28, envoy_cilium_* 14順です。

1ノードのEnvoyは、サーバー稼働時間1,019,397秒（約11.8日）、メモリ割り当て約10MBでした。ゲートウェイを通過したリクエストは1つのリスナーあたり14,270件であり、レスポンスコード系列別では2xxが12,916件、3xxが1,217件、4xxが51件、5xxが4件でした。5xxが全体の約0.03%です。ただし、これはそのノードのEnvoy単体が処理した分であり、他のノードのEnvoyは合算していません。

5. 実測で読み解くエージェントの状態（1ノード、稼働約11.8日）

• Unsupported L3 protocol がドロップのほぼすべてを占めています。 IPv4以外のパケット（IPv6など）である可能性を疑いますが、パケットを開いて確認することはできていません（未確認）。この理由はポリシー拒否ではないため、侵入の兆候として捉えてはならず、アラートを作成する際にはこの理由を別途除外することでノイズが減少すると考えられます。
• BPFマップの充填率はいずれも低いです。 サービス数が増加しても、当面は余裕があることを意味しています。
• Service backend not found 159件 は、エンドポイントが消失したサービスへ送信されたパケットです。ローリングアップデートの短い隙間に発生する正常な値である可能性がありますが、継続的に増加する場合は点検の対象となります。

6. Hubble指標のカーディナリティの問題

例えば、1ノードにおいてHubbleは指標系列が14個のみであるにもかかわらず、時系列が約8万個ありました。主な原因は3つの系列です。

原因は設定の labelsContext です。この設定が source_ip と destination_ip をラベルとして使うよう指示するため、リクエストが入ってくる クライアントIP一つひとつが個別の時系列になります。最大のエントリでは source_ip の異なる値が数千個あり、送信元名前空間やワークロードが空の項目が多く、クラスター外から入ってくるリクエストと見られ、この値は訪問者が増えるにつれて増え続けます（送信元の区別は確認していません）。

この構成には2つの問題があります。

1. Prometheusのメモリとストレージのコストが増加します。 1台のノードだけでも8万の時系列があり、外部リクエストを受信するノードが増えるとコストも増加します。
2. 訪問者のIPアドレスがそのままメトリックストレージに残ります。 個人情報の観点からも確認が必要な部分です。

改善の方向性は labelsContext から source_ip と destination_ip を除外して名前空間とワークロードのみを残すことのようです。ただしこれは提案にすぎず、実際に変更して時系列が減ることは確認していません（未検証）。

設定には dns がありますが、 hubble_dns_* メトリックは出力されていませんでした。 14の系列は、HTTP、ポート分布、フロー、ドロップ、TCPフラグ、ICMP、失われたイベント、メトリックハンドラー、gRPCです。DNSメトリックはDNS可視性の設定が別途必要であると知られていますが、この実験環境で確認したわけではなく、理由は不明です（未確認）。

7. アラートとダッシュボードの候補（未実行）

実行していない例です。メトリック名は上記の測定結果に合わせています。

# 연결할 수 없는 노드, 실패한 컨트롤러
cilium_unreachable_nodes > 0
cilium_controllers_failing > 0

# BPF 맵이 가득 차기 전에
cilium_bpf_map_pressure > 0.9

# 정책 거절과 서비스 백엔드 없음: 노이즈인 L2/L3 프로토콜 사유는 제외한다
sum by (reason) (rate(cilium_drop_count_total{reason!~"Unsupported.*"}[5m])) > 0

# 준비되지 않은 엔드포인트
cilium_endpoint_state{endpoint_state!="ready"} > 0

# 쿠버네티스 API 오류
sum by (return_code) (rate(cilium_k8s_client_api_calls_total{return_code=~"5.."}[5m])) > 0

8. 面接で想定される質問

• kube-proxyを置き換えた際、サービスのロードバランシング状態はどのようなメトリックで確認するか？ cilium_bpf_map_pressure の lb4_* マップの埋まり具合と、ドロップの理由 Service backend not found です。
• ポリシーによってブロックされたトラフィックはどこで確認するか？ エージェントの cilium_drop_count_total{reason="Policy denied"} と、Hubble の hubble_drop_total です。
• Hubbleのメトリックを有効にしたところ、Prometheusが遅くなった場合は？ labelsContext を真っ先に疑います。IPのように値の種類が多いラベルは、時系列を爆発的に増加させます。
• Ciliumの状態が正常であるかを一目で確認するには？ コントローラーの失敗数、到達不能ノード数、エンドポイントの状態、マップのプレッシャーです。

9. よくある誤解

• 「ドロップがあれば攻撃である」：この実験環境におけるドロップの大部分はポリシー拒否ではなく、サポートされていないプロトコルでした。
• 「メトリックの系列が少なければ時系列も少ない」：Hubbleは14の系列から約8万の時系列が発生しました。ラベルの値の種類がそれを決定します。
• 「Hubbleで dns だけを記載すればDNSメトリックが出力される」：この実験環境では出力されませんでした。

確認できなかったこと

• 時間経過による変化。すべての値は特定時点のスナップショットであり、速度（rate）や傾向は計算していません。
• 測定したノード以外のエージェントやEnvoy、および他のオペレーターPodが存在する場合のその値。
• Unsupported L3 protocol ドロップの実際のプロトコル。
• Hubble source_ip を除外したときに時系列がどれくらい減るか。
• DNSメトリックが出力されない理由。
• メトリックの意味の補足説明として引用されているCiliumのドキュメントを今回改めて開いて突き合わせることはしていません。

参考資料

• https://docs.cilium.io/en/stable/observability/metrics/
• https://docs.cilium.io/en/stable/observability/hubble/

確認したバージョンと日付

2026-10-05時点。Cilium 1.20.1、稼働約11.8日（エージェント起動時刻基準）。