KubernetesでのGoアプリケーション監視

Site24x7 APMインサイトKubernetesは、extended Berkeley Packet Filter（eBPF）テクノロジーを用いて、Kubernetesクラスターで稼働するGoアプリケーションの自動監視を可能にします。このアプローチにより、アプリケーションコードの変更や言語固有のエージェントの挿入をすることなく、パフォーマンスを監視可能です。
このガイドでは、KubernetesにおけるGoアプリケーションのアーキテクチャ、コンポーネント、監視ワークフローについて説明します。

一般的な用語

• DaemonSet：クラスター内のすべてのノードで1つのエージェントポッドが自動的に実行されるようにし、すべてのアプリケーションポッドに対する一貫した可視性を提供します。.
• /host/proc mounts：ホストの/procファイルシステムがエージェントコンテナ内でアクセス可能になり、ホストレベルのプロセス情報を読み取ることが可能になります。
• Cgroup mappings：プロセスがどのコンテナまたはポッドに属しているかを識別します。
• Inode：ファイルのメタデータと場所を表す一意のファイルシステム識別子です。
• eBPF uprobe：コードを変更せずにアプリケーションバイナリ内の関数呼び出しをトレースするために使用されるユーザー空間プローブです。
• Instrumentor：eBPFプログラムをロードし、ランタイムテレメトリを収集する軽量プロセスです。
• Position-independent executables（PIE）：任意のメモリアドレスで実行できる実行可能ファイルで、アドレス空間レイアウトのランダム化（ASLR）などのセキュリティ機能を有効にします。
• OverlayFS：読み取り専用のイメージレイヤーと書き込み可能なレイヤーを組み合わせて単一の統合ビューを形成する階層化ファイルシステムです。
• Helm charts：Kubernetesアプリケーションのインストールと管理を簡素化する、事前にパッケージ化されたテンプレートです。

KubernetesでのGoアプリ監視のアーキテクチャ図

以下のアーキテクチャ図は、Kubernetesセットアップで監視がどのように機能するかの概要を示しています。

Goアプリケーションはアプリケーションポッド内で実行されます。専用のAPMインサイトエージェントポッドが、各ノード上のすべての監視タスクを処理します。このポッドはDaemonSetとしてデプロイされています。図に示されているコンポーネントを詳しく見ていきましょう。

APMインサイトGoエージェント

APMインサイトGoエージェントは、システム全体のコントローラーおよびオーケストレーターとして機能します。ホストプロセス識別子（PID）と/host/procマウントを使用して、ノード上のすべてのポッドで実行中のGoプロセスを検出します。コマンドライン引数、環境変数、コンテナID、ポッドの関連付け、cgroupマッピングなどのメタデータを抽出します。

エージェントはユーザー定義のルールを適用し、インストルメントするアプリケーションを決定します。共有ホストパスからバイナリパスを解決し、eBPF uprobeアタッチメントに必要なInode番号または装置番号の安定性を確保します。さらに、ポッドの出現、再起動、終了に応じて、インストルメンタープロセスのライフサイクルを管理します。

APMインサイトインストルメンター

インストルメンターはeBPFプログラムをカーネルにロードし、選択されたGo関数にuprobesをアタッチします。アプリケーションを変更したり、ライブラリをインジェクションしたりすることなく、関数呼び出し、戻り値、レイテンシ、エラー、実行パスをキャプチャします。また、位置独立実行ファイル（PIE）のシンボル解決、ランタイムオフセットマッピング、関数アドレス計算も実行します。最後に、軽量テレメトリイベントをリングバッファ経由でユーザー空間コレクターにストリーミングします。

S247データエクスポーター

S247DataExporterは、 eBPFイベントを標準的なOpenTelemetryスパンとメトリクスに変換します。ポッド名、名前空間、ノード、コンテナID、IPアドレス、ラベルなどのKubernetesメタデータでデータを拡充します。その後、エクスポーターはOpenTelemetryプロトコル（OTLP）を使用してテレメトリをSite24x7バックエンドに送信します。その際、バッチ処理、リトライロジック、バックプレッシャー管理を採用することで、信頼性の高い配信を実現します。

共有ボリュームとホストアクセス

共有ホストパスボリューム（例：/var/lib/apm-binaries）は、アプリケーションバイナリをノードの実ファイルシステムに保存します。この設定により、ほとんどのコンテナランタイムでOverlayFSによって発生する不整合を回避し、安定したinode番号と装置番号が確保されます。エージェントポッドは、/proc、/sys/kernel/debug、/sys/fs/bpfなどのホストリソースにもアクセスして、プロセスを検出し、eBPFプログラムを管理します。アプリケーションポッドは共有ホストパスから直接バイナリを実行するため、エージェントがインストルメントしたバイナリがカーネルに正確に認識されます。

監視ワークフロー全体をまとめると、DaemonSetは各ノードで1つのエージェントポッドが実行され、クラスターへのノードの追加または削除に応じて自動的に調整されます。Goエージェントは実行中のプロセスを検出し、対象となるGoアプリケーションごとにインストルメンターを起動します。インストルメンターはeBPFプローブをアタッチして、パフォーマンスへの影響を最小限に抑えながらパフォーマンスデータを取得します。最後に、S247データエクスポーターはトレース、メトリクス、エラーなどのテレメトリをSite24x7バックエンドに転送し、可視化と分析を行います。

このアーキテクチャの主な利点

このアーキテクチャは完全にイベント駆動型で適応型であり、新しいポッドを自動的に検出し、ローリングアップデートまたは再起動中にプローブを再接続します。CI/CDパイプライン、アプリケーションイメージ、helmチャート、または起動スクリプトを変更する必要はありません。

サポートされているKubernetesプラットフォーム

Site24x7 APMインサイトKubernetesは、次のマネージドKubernetesプラットフォームでサポートされています。

Kuberneteプラットフォーム	ノードOSとカーネルの要件	追加の考慮事項
EKS（Amazon Elastic Kubernetesサービス）	Amazon Linux 2（カーネル5.10+）	-
GKE（Google Kubernetesエンジン）	Ubuntuまたはコンテナ最適化OS（カーネル5.10+）	eBPFプローブ接続にはホストPID（ホストプロセス名前空間へのアクセス）と特権モードが必要です。
AKS（Azure Kubernetesサービス）	Ubuntu（カーネル5.10+）	Azure CNIまたはKubenetネットワークをサポートします。

KubernetesでのGoアプリ監視のベストプラクティス

KubernetesでGoアプリケーションをスムーズかつ確実に監視するには、次のベストプラクティスに従います。

• 専用の名前空間を使用する：監視エージェントを別の監視名前空間にデプロイして、アプリケーションのワークロードから分離します。
• 適切なリソース制限を設定する：クラスタのサイズに基づいてCPUとメモリの制限を割り当て、リソースの競合を防ぎ、エージェントの安定したパフォーマンスを確保します。
• ノードにラベルを付ける：監視対象のノードでのみエージェントが実行されるように、ノードラベルとセレクターを適用します。
• イメージのバージョンをピン留めする：予期しない更新や動作の変更を回避するために、実稼働環境では最新のイメージタグではなく固定のイメージタグを使用します。
• エージェントの健全性の監視：DaemonSetポッドの障害、再起動、またはエージェントの健全性の変動を通知するアラートを設定します。
• エージェントを定期的に更新する：最新の修正、機能強化、セキュリティの改善を活用するために、エージェントのバージョンを最新の状態に保ちます。
• ステージングでの変更の検証：新しいエージェントバージョンまたは構成の変更を本番環境に展開する前に、ステージング環境でテストします。
• 一貫したバイナリ名を使用する：検出の問題を回避するために、Go アプリケーションバイナリが環境間で予測可能で一貫した命名規則に従っていることを確認します。
• hostPath権限を確認する：エージェントがエラーなくバイナリにアクセスできるように、/var/lib/apm-binariesディレクトリに正しい権限（755）があることを確認します。
• ネットワーク アクセスの確保：Kubernetesネットワークポリシーを使用している場合は、エージェントがSite24x7エンドポイントへの送信アクセス権を持ち、メトリクスとトレースデータを正常に送信できることを確認します。

よくある質問

1.なぜhostPathが必要なのでしょうか。エージェントはコンテナから直接バイナリにアクセスできないのでしょうか。

コンテナ化されたアプリケーションは、多くの場合OverlayFS上で実行されます。OverlayFSでは、バイナリが複数のファイルシステム層にまたがって保存されます。その結果、inode番号と装置番号に一貫性がなくなり、eBPF uprobeが関数に確実にアタッチできなくなります。

hostPathボリュームを使用すると、次のことが実現されます。

• バイナリの一貫性のある安定したビュー
• アプリケーションとエージェントの両方のinodeまたは装置番号を一致
• OverlayFSの制限を完全に回避する回避策

2.エージェントは装置上で実行されているすべてのGoプロセスを監視しますか。

いいえ。エージェントはマシン上のすべてのプロセスを検出しますが、GO_APPS（Goアプリケーション）環境変数に明示的にリストされているプロセスのみをインストルメントします。インストルメントは設定によって完全に制御されます。

3.エージェントはGoアプリケーションのバイナリを変更または改変しますか。

いいえ。エージェントは、カーネルレベルでランタイムプロセスにアタッチされたeBPFアップローブを使用して、実行時にアプリケーションをメモリ内にインストルメントします。ディスク上のアプリケーションバイナリは変更されません。

4.アプリケーションを再起動するとどうなりますか。

エージェントには、30秒ごとに実行されるオーケストレーターが含まれています。再起動（PIDの変更）が検出されると、自動的に以下の処理が実行されます。

1. 既存のインストルメンターを停止します。
2. 新しいプロセスPIDを識別します。
3. 新しいインストルメンターを起動します。
4. eBPFプローブを新しいプロセスに再接続します。

5.異なるKubernetes名前空間で実行されているアプリケーションを監視できますか。

はい。DaemonSetはhostPIDで実行されます。trueに設定すると、名前空間に関係なく、ノード上のすべてのプロセスが可視化されます。GO_APPS設定に必要なプロセス名がすべて含まれていることを確認します。

6.eBPFベースのインストルメンテーションを使用する場合のオーバーヘッドはどれくらいですか。

eBPFインストルメンテーションは軽量かつ効率的に設計されており、システムパフォーマンスへの影響を最小限に抑えて監視します。

典型的なオーバーヘッド：

• CPU：5%
• メモリ：最小限（カーネル空間内の小さなeBPFマップ）
• レイテンシ：トレースされた関数あたりマイクロ秒

実際のオーバーヘッドは、アプリケーションの負荷とインストルメントされた関数の数によって異なります。

7.このソリューションはEKS、GKE、AKSでサポートされていますか。

はい、Site24x7 APMインサイトKubernetesは、プラットフォーム固有の要件がいくつかあるものの、マネージドKubernetesプラットフォーム3つすべてでサポートされています。

関連記事

• KubernetesでのGoアプリケーションの監視設定
• KubernetesでGoアプリケーションを監視するためのトラブルシューティングのヒント