はじめに
コンテナ技術の普及に伴い、観測データ（observability data）の正確な取得はシステム監視やトラブルシューティングにおいて不可欠な要素となっています。特に、コンテナIDはコンテナ化環境で唯一性と細粒度を保証する識別子として、観測データのフィルタリングや検索に不可欠です。しかし、cgroup v2の導入により、従來のcgroup v1でのコンテナID取得方法が破綻する問題が生じました。本記事では、この課題の背景と、cgroup v2環境でのコンテナID解決策として提案される「inodeを活用したアプローチ」について解説します。
観測データの流れとコンテナIDの重要性
観測データの収集には、**プルフロー（Pull Flow）とプッシュフロー（Push Flow）**の2つのパターンがあります。
- プルフロー：監視エンドポイント（例：Prometheus）が明示的に目標（コンテナ名、IDなど）を取得する方法です。この場合、コンテナIDは監視システムが直接取得する必要があります。
- プッシュフロー：アプリケーションが観測データを直接代理サーバー（例：トレースデータ）に送信する方法です。この場合、送信元のコンテナIDを自動的に識別してデータを豊かにする必要があります。
コンテナIDは、これらのフローにおいて観測データの精度を保証するための基盤となる要素です。
cgroup v1での解決策とcgroup v2の課題
cgroup v1の方法
cgroup v1では、/proc/self/cgroupファイルを読み込むことでコンテナIDを取得することができました。このファイルのパス形式は/path/to/container/...であり、正規表現を用いてコンテナIDを抽出することができました。この方法はシンプルで、多くの環境で利用可能でした。
cgroup v2の変化と課題
cgroup v2では、名前空間の仮想化が導入され、/proc/self/cgroupファイルの內容が/（空値）となりました。これは、仮想化された名前空間により、従來のパス解析が機能しなくなったためです。この変化により、cgroup v1での方法は機能しなくなり、新たな解決策が求められました。
解決策の検討とinodeを活用したアプローチ
代替案の検討
1. /proc/self/cgroupの利用（非推奨）
- 方法：
/proc/self/cgroupファイルを読み込む
- 問題：
- 某些場合、ボリュームIDが取得される可能性がある
- コンテナIDとボリュームIDの區別が困難
2. Mutating Webhook（Kubernetes専用）
- 方法：Kubernetes APIを介してPod IDやコンテナ名を注入
- 課題：
- Kubernetes環境に限定される
- コンテナ再起動時の解析遅延によるデータ不一致の可能性
3. Mount Namespace IDの利用（権限必要）
- 方法：Mount Namespace IDを読み込む（
CAP_SYS_ADMIN権限が必要）
- 課題：
- 安全性の観點からKubernetesのRestrictedモードでは利用不可
最終的な解決策：inodeを活用したアプローチ
コアコンセプト
- inodeの役割：
- コンテナ內から
/proc/self/cgroupのinode値を取得
- 主機側のエージェントがinodeをもとにコンテナIDをマッピング
実裝ステップ
アプリケーション側：
/proc/self/cgroupからinode値を取得し、観測データに付加
主機側エージェント：
- Cgroupfsをマウント（通常は既にマウント済み）
- inodeパスからコンテナIDを正規表現で解析
優位性
- 環境の柔軟性：Kubernetes以外の環境でも利用可能
- セキュリティ：追加の権限不要で、既存のセキュリティポリシーに適合
- 互換性：既存の監視システムとの連攜が可能
実裝詳細と検証結果
データ処理ロジック
- コンテナIDが解析成功：コンテナIDを送信
- 解析失敗：inode値を送信（KubernetesではPod IDとコンテナ名を補完）
- VMベースのランタイムではinode解析が失敗するため、別途対応が必要
技術実裝
- エージェント/コレクター：Cgroupfsをマウント（通常は既にマウント済み）
- サポートする監視アーキテクチャ：
- 単節點エージェントに依存しない設計（ゲートウェイ構成をサポート）
- OpenTelemetry Agentなど既存のオープンソースエージェントで実裝可能
検証結果
- 2023年初頭から本番環境で運用開始
- 多様なコンテナランタイムとクラウド環境をサポート
結論
キーテクノロジーポイント
- inodeをコンテナIDの代理として活用
- Cgroupfsのマウントとパス解析により環境の柔軟性を確保
- 應用や主機の設定変更なしにセキュリティと運用性を維持
今後の方向性
- inode解析の精度と効率の向上
- さらなるコンテナランタイムやクラウドプラットフォームへの対応拡大