> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitoring Overview

> Istio および Linkerd のサービスメッシュにおいて、Vantage 3.0 セルフホスト型の監視がどのように機能するかを説明します。

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

<div id="how-vantage-exposes-metrics">
  ## Vantage でのメトリクスの公開方法
</div>

Vantage アプリケーションの pod には OpenTelemetry SDK が組み込まれており、コンテナーの 8080 番ポートで `/metrics-text` に Prometheus 形式のメトリクスを公開します。このエンドポイントを公開するサービスには、次のラベルが付いています。

```text theme={null}
abbyy.platform.metrics.text.endpoint: "1"
```

各サービスでは、ポート名`http`でポート80が8080にマッピングされます。Prometheus は、そのラベルで選択する`ServiceMonitor`を通じてこれらのサービスを検出し、スクレイプします。

<div id="service-mesh-considerations">
  ## サービスメッシュの考慮事項
</div>

<div id="istio">
  ### Istio
</div>

ポート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 します。

<div id="linkerd">
  ### Linkerd
</div>

Linkerd のデフォルトの permissive ポリシーでは通常、メッシュ化されていない Prometheus でも、プロキシされた Vantage メトリクス エンドポイントを平文でスクレイプできます。KEDA を有効にする前に、すべての Vantage ターゲットが `UP` になっていることを確認してください。

Linkerd の認可ポリシーで認証済みのメッシュ トラフィックが必須の場合は、`observability` 名前空間をメッシュに参加させるか、ポリシーで必要なクライアント証明書を使用するよう Prometheus と `ServiceMonitor` を設定してください。要件は、Prometheus が `/metrics-text` を正常にスクレイプできることです。Vantage では、Prometheus の特定のデプロイ方法は必要ありません。

<div id="recommended-approach">
  ## 推奨アプローチ
</div>

<CardGroup cols={2}>
  <Card title="Prometheus による監視" icon="chart-line" href="/ja/vantage/self-hosted/v3.0/monitoring/prometheus">
    あらゆる環境で利用できるセルフマネージド Prometheus (kube-prometheus-stack) 。Istio と Linkerd 向けの構成パスを用意しています。
  </Card>

  <Card title="Azure マネージド監視" icon="cloud" href="/ja/vantage/self-hosted/v3.0/monitoring/azure-managed">
    Azure Monitor Workspace + Azure Managed Grafana。メッシュ内の Prometheus が mTLS 経由で Vantage をスクレイプし、Azure Monitor に remote-write します。`ama-metrics` エージェントは引き続き Kubernetes インフラストラクチャのメトリクスを処理します。
  </Card>
</CardGroup>

<div id="available-metrics">
  ## 利用可能なメトリクス
</div>

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` のラベルが含まれます。