Skip to main content
Vantage 3.0 セルフホスト型は、アプリケーショントラフィックに mTLS を適用するサービスメッシュ内で動作します。スクレイプ設定は、デプロイメントで Istio と Linkerd のどちらを使用するかによって異なります。

​
Vantage でのメトリクスの公開方法

Vantage アプリケーションの pod には OpenTelemetry SDK が組み込まれており、コンテナーの 8080 番ポートで /metrics-text に Prometheus 形式のメトリクスを公開します。このエンドポイントを公開するサービスには、次のラベルが付いています。
各サービスでは、ポート名httpでポート80が8080にマッピングされます。Prometheus は、そのラベルで選択するServiceMonitorを通じてこれらのサービスを検出し、スクレイプします。

​
サービスメッシュの考慮事項

​
Istio

ポート8080のアプリケーショントラフィックは Envoy サイドカーによってインターセプトされ、STRICT mTLS の対象になります。これらのメトリクスを読み取るスクレイパーは、対象の pod に対して有効な mTLS クライアント証明書を提示する必要があります。スクレイパーに Istio サイドカーを注入するだけでは不十分です。Prometheus の scrape target は pod IP とコンテナーのポートに解決されますが、Envoy サイドカーではそこにルーティングできないため、すべてのスクレイプは HTTP 503 で失敗します。ドキュメント化されている動作確認済みの構成では、Prometheus はメッシュ内で Istio サイドカーとともに稼働し、そのサイドカーがメッシュ証明書を共有ボリューム (OUTPUT_CERTS) にエクスポートします。さらに Prometheus 自体が、ServiceMonitor の tlsConfig で証明書パスを設定し、scheme: https を使用してスクレイプすることで、それらの証明書を提示します。 そのため、Azure のマネージド Prometheus オファリングに付属する ama-metrics エージェントを含め、メッシュ外で動作するスクレイパーは利用できません。AKS で Vantage のアプリケーションメトリクスを収集するには、メッシュ内に Prometheus インスタンスをデプロイし、mTLS 経由で Vantage をスクレイプして Azure Monitor に remote-write します。

​
Linkerd

Linkerd のデフォルトの permissive ポリシーでは通常、メッシュ化されていない Prometheus でも、プロキシされた Vantage メトリクス エンドポイントを平文でスクレイプできます。KEDA を有効にする前に、すべての Vantage ターゲットが UP になっていることを確認してください。 Linkerd の認可ポリシーで認証済みのメッシュ トラフィックが必須の場合は、observability 名前空間をメッシュに参加させるか、ポリシーで必要なクライアント証明書を使用するよう Prometheus と ServiceMonitor を設定してください。要件は、Prometheus が /metrics-text を正常にスクレイプできることです。Vantage では、Prometheus の特定のデプロイ方法は必要ありません。

Prometheus による監視

あらゆる環境で利用できるセルフマネージド Prometheus (kube-prometheus-stack) 。Istio と Linkerd 向けの構成パスを用意しています。

Azure マネージド監視

Azure Monitor Workspace + Azure Managed Grafana。メッシュ内の Prometheus が mTLS 経由で Vantage をスクレイプし、Azure Monitor に remote-write します。ama-metrics エージェントは引き続き Kubernetes インフラストラクチャのメトリクスを処理します。

​
利用可能なメトリクス

Vantage アプリケーションは、OpenTelemetry SDK を通じて 3 種類のメトリクスを公開します。
  • プロセスメトリクス: process_cpu_count, process_memory_usage_bytes, process_cpu_time_seconds_total, process_thread_count。pod ごとのランタイムリソース使用量。
  • HTTP クライアント/サーバーメトリクス: http_client_active_requests, http_client_connection_duration_seconds など。リクエストのレイテンシと接続状況の追跡。
  • ABBYY プラットフォームメトリクス: abbyy_platform_listener_*, abbyy_platform_redisstreamscontroller_*。アプリケーションレベルの処理およびキューに関するメトリクス。
すべてのメトリクスには、service、pod、namespace、otel_scope_name のラベルが含まれます。