> ## 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.

# Vue d’ensemble du monitoring

> Fonctionnement du monitoring pour Vantage 3.0 auto-hébergé dans les maillages de services Istio et Linkerd.

Vantage 3.0 auto-hébergé s’exécute au sein d’un maillage de services, avec mTLS sur le trafic applicatif. La configuration de scraping dépend de l’utilisation d’Istio ou de Linkerd pour le déploiement.

<div id="how-vantage-exposes-metrics">
  ## Comment Vantage expose les métriques
</div>

Les pods d’application Vantage sont instrumentés à l’aide des SDK OpenTelemetry et exposent des métriques au format Prometheus sur `/metrics-text`, via le port 8080 du conteneur. Les services qui exposent ce point de terminaison portent le label :

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

Chaque service redirige le port 80 vers le port 8080, avec le nom de port `http`. Prometheus découvre ces services et en récupère les métriques via un `ServiceMonitor` qui sélectionne ce label.

<div id="service-mesh-considerations">
  ## Considérations sur le maillage de services
</div>

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

Le trafic applicatif sur le port 8080 est intercepté par le sidecar Envoy et soumis au mTLS STRICT. Tout collecteur souhaitant lire ces métriques doit présenter un certificat client mTLS valide aux pods cibles. L’injection d’un sidecar Istio dans le collecteur ne suffit pas à elle seule : les scrape targets Prometheus se résolvent en adresses IP de pod et en ports de conteneur, que le sidecar Envoy ne peut pas acheminer ; par conséquent, chaque scrape échoue avec une erreur HTTP 503. Dans la configuration opérationnelle documentée, Prometheus s’exécute **dans le maillage** avec un sidecar Istio qui exporte les certificats du maillage vers un volume partagé (`OUTPUT_CERTS`), et Prometheus présente lui-même ces certificats en scrappant via `scheme: https`, avec les chemins des certificats définis dans le `tlsConfig` du ServiceMonitor.

Cela exclut les collecteurs qui s’exécutent en dehors du maillage, y compris l’agent `ama-metrics` fourni par Azure avec son offre de Prometheus managé. Pour collecter les métriques applicatives de Vantage sur AKS, vous déployez une instance de Prometheus à l’intérieur du maillage, qui scrape Vantage via mTLS et effectue un remote-write vers Azure Monitor.

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

La stratégie permissive par défaut de Linkerd permet normalement à un Prometheus non maillé de récupérer en clair les points de terminaison des métriques Vantage proxifiés. Vérifiez que chaque cible Vantage est `UP` avant d'activer KEDA.

Si votre stratégie d'autorisation Linkerd exige un trafic maillé authentifié, injectez l'espace de noms `observability` dans le maillage ou configurez Prometheus et le `ServiceMonitor` avec les certificats clients requis par votre stratégie. L'essentiel est que Prometheus puisse récupérer `/metrics-text` avec succès ; Vantage n'impose aucune méthode de déploiement de Prometheus particulière.

<div id="recommended-approach">
  ## Approche recommandée
</div>

<CardGroup cols={2}>
  <Card title="Supervision avec Prometheus" icon="chart-line" href="/fr/vantage/self-hosted/v3.0/monitoring/prometheus">
    Prometheus géré par vos soins (kube-prometheus-stack), compatible avec tous les environnements, avec des configurations pour Istio et Linkerd.
  </Card>

  <Card title="Supervision gérée par Azure" icon="cloud" href="/fr/vantage/self-hosted/v3.0/monitoring/azure-managed">
    Azure Monitor Workspace + Azure Managed Grafana, avec un Prometheus dans le maillage qui collecte les métriques de Vantage via mTLS et les envoie à Azure Monitor via remote-write. L’agent `ama-metrics` continue de prendre en charge les métriques d’infrastructure Kubernetes.
  </Card>
</CardGroup>

<div id="available-metrics">
  ## Métriques disponibles
</div>

Les applications Vantage exposent trois catégories de métriques via le SDK OpenTelemetry :

* **Métriques de processus** : `process_cpu_count`, `process_memory_usage_bytes`, `process_cpu_time_seconds_total`, `process_thread_count`. Utilisation des ressources du Runtime par pod.
* **Métriques client et serveur HTTP** : `http_client_active_requests`, `http_client_connection_duration_seconds`, etc. Latence des requêtes et suivi des connexions.
* **Métriques de la plateforme ABBYY** : `abbyy_platform_listener_*`, `abbyy_platform_redisstreamscontroller_*`. Métriques de traitement et de file d’attente au niveau de l’application.

Toutes les métriques incluent des labels pour `service`, `pod`, `namespace` et `otel_scope_name`.