Passer au contenu principal
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.

​
Comment Vantage expose les métriques

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

​
Considérations sur le maillage de services

​
Istio

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.

​
Linkerd

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.

Supervision avec Prometheus

Prometheus géré par vos soins (kube-prometheus-stack), compatible avec tous les environnements, avec des configurations pour Istio et Linkerd.

Supervision gérée par Azure

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.

​
Métriques disponibles

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.