Contents
EnvoyでgRPCトラフィック可視化を実現する意義と概要
マイクロサービスアーキテクチャにおいて、gRPC通信の状態把握はシステム安定性に直結します。Envoyのメトリクス収集機能とPrometheus/Grafanaの連携により、リアルタイムでのトラフィック可視化が可能になります。本記事では、EnvoyでgRPCトラフィックを可視化する具体的な手順を解説し、運用時の実践的な知識をお伝えします。
EnvoyのgRPCフィルタ設定手順（v1.20以降対応）
gRPC通信のメトリクス取得には、EnvoyのgRPCフィルタの有効化が不可欠です。以下に設定手順を示します。
gRPCフィルタの有効化方法
Envoy v1.20以降では、envoy.filters.http.grpc_statsを使用してgRPC通信を監視できます。ただし、v3alphaは非推奨または変更可能なバージョンであり、安定性リスクが存在するため、公式ドキュメントで推奨されているv3版を使用することを強く推奨します。
|
1 2 3 4 5 6 |
http_filters: - name: envoy.filters.http.grpc_stats typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_stats.v3.GrpcStatsConfig metrics_prefix: "grpc." |
重要:
v3alphaは非推奨バージョンであり、長期的な運用にはv3版の使用が必須です。
通信パラメータの指定仕様
gRPCリクエストのメトリクスを収集する際には、以下の項目を環境に応じて設定します。TLS通信の場合、証明書と鍵ファイルのパスをtls_contextに記載する必要があります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
listeners: - name: listener_0 address: socket_address: address: 0.0.0.0 port_value: 10000 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: ["*"] routes: - match: prefix: "/grpc" route: cluster: grpc_service http_filters: - name: envoy.filters.http.grpc_stats - name: envoy.filters.http.router |
注意: TLS通信時は
tls_contextの設定が必要です。証明書が不正な場合、メトリクス取得に失敗する可能性があります。
StatsD経由のメトリクス送信構成
Envoyから収集したメトリクスをPrometheusで利用するには、StatsDサーバーを介して転送する必要があります。
StatsDサーバーの選択基準
StatsDサーバーとして、以下が代表的です。それぞれの特徴を比較します。
| ツール | サポートメトリクス | スケーラビリティ | 推奨用途 |
|---|---|---|---|
| Telegraf | 高（Gauge/Counter） | 高 | 本番環境の監視 |
| StatsD | 基本的 | 中 | テスト環境 |
注意:
Pushgatewayは、定期的なメトリクスの集約には適していますが、長期的なリアルタイム監視には不向きであるため、運用設計に留意してください。
メトリクスラベルのカスタマイズ方法
メトリクスに任意のラベルを追加するには、statsd_stats_labelsパラメータを使用します。以下は例です。
|
1 2 3 4 5 6 7 |
envoy: statsd: address: "127.0.0.1:8125" statsd_stats_labels: - name: service value: "grpc_service_a" |
ベストプラクティス: メトリクスのフィルタリングには、
metrics_prefixを明確に設定し、不要なデータを転送しないようにしましょう。
Prometheusでのメトリクス収集設定
StatsD経由で送信されたメトリクスをPrometheusが収集するには、exporterを導入します。
exporterのデプロイ手順
以下のようにprom/statsd-exporterをDockerで起動します。最新版との互換性を確認するため、明示的にバージョンタグを指定してください（例: v0.21.0）。
|
1 2 3 4 5 |
docker run -d \ --name statsd-exporter \ -p 9126:9126 \ prom/statsd-exporter:v0.21.0 |
レプリケーション環境対応策
複数のEnvoyインスタンスが稼働する場合、Pushgatewayを用いてメトリクスを集約します。Prometheusのconfigに以下を追加してください。
|
1 2 3 4 5 6 |
scrape_configs: - job_name: 'statsd' honor_timestamps: true static_config: - targets: ['pushgateway:9091'] |
注意:
Pushgatewayは、短時間のジョブ監視向けに設計されており、長期的な運用には適さない可能性があります。本番環境では代替手段を検討してください。
Grafanaでのダッシュボード作成例
Prometheusから取得したメトリクスをGrafanaで可視化する手順です。
テンプレート変数の設定手順
ダッシュボードにサービス名やエンドポイントを動的に選択可能にするには、テンプレート変数を使用します。以下は例です。
|
1 2 3 |
__org__ = "default" __service__ = "grpc_service_a" |
gRPCメトリクスの可視化レイアウト
以下の2つが代表的です。
- リクエスト遅延のグラフ
- メトリクス:
grpc.request.latency -
グラフタイプ: 積み上げ棒グラフ
-
エラーレートの表示
- メトリクス:
grpc.request.error_rate - 表示形式: バーチャート（1分間平均）
TLS通信時の可視化対策と検証手順
TLS通信でもメトリクス取得可能な設定を確認します。
mTLS設定時のメトリクス取得方法
mTLSでEnvoyを構成する場合、upstream_tls_contextに証明書情報を記載します。以下の例です。
|
1 2 3 4 5 6 7 8 9 10 |
clusters: - name: grpc_service type: STRICT_DNS lb_policy: ROUND_ROBIN upstream_tls_context: common_tls_context: tls_certificates: - certificate_chain: "/etc/ssl/certs/grpc.crt" private_key: "/etc/ssl/private/grpc.key" |
注意:
upstream_tls_contextの配置場所や構文は、Envoy v1.20での確認が必要です。公式ドキュメントで最新情報をご確認ください。
暗号化通信のパフォーマンス影響測定
暗号化による遅延を比較するには、gRPCリクエストの平均処理時間をTLS有無で計測します。ただし、以下のようなデータでは信頼性が疑われるため、ソースや測定条件の明記が必須です。
| コンフィグ | 平均処理時間（ms） | パーセント変化 |
|---|---|---|
| 非暗号化 | 12.3 | - |
| TLS有効 | 15.8 | +28.4% |
運用開始までの確認チェックリスト
以下を順に確認し、不具合を早期に検出してください。
- [ ] EnvoyのgRPCフィルタ設定が正しく反映されているか
- [ ] StatsDサーバーがEnvoyと通信しているか（
netstat -an | grep 8125で確認） - [ ] PrometheusがStatsDからメトリクスを取得できているか（
curl http://localhost:9090/api/v1/query?query=grpc.request.latency） - [ ] Grafanaダッシュボードに正しいデータが表示されているか
- [ ] TLS通信時の証明書エラーがないか（
openssl s_client -connect grpc_service:443で確認）
本記事の手順を参考に、Envoy環境でのgRPCトラフィック監視システム構築を開始してください。