Skip to main content
Vantage 3.0 self-hosted runs inside a service mesh with mTLS on application traffic. The scrape configuration depends on whether the deployment uses Istio or Linkerd.

​
How Vantage exposes metrics

Vantage application pods are instrumented with OpenTelemetry SDKs and expose Prometheus-format metrics on /metrics-text at container port 8080. Services that expose this endpoint carry the label:
Each service maps port 80 → 8080 with a port name of http. Prometheus discovers and scrapes these services via a ServiceMonitor selecting that label.

​
Service-mesh considerations

​
Istio

Application traffic on port 8080 is intercepted by the Envoy sidecar and subject to STRICT mTLS. Any scraper that wants to read those metrics must present a valid mTLS client cert to the target pods. Injecting an Istio sidecar into the scraper is not enough on its own: Prometheus scrape targets resolve to pod IP and container port, which the Envoy sidecar cannot route, so every scrape fails with HTTP 503. In the documented working configuration, Prometheus runs inside the mesh with an Istio sidecar that exports the mesh certificates to a shared volume (OUTPUT_CERTS), and Prometheus itself presents those certificates by scraping over scheme: https with the certificate paths set in the ServiceMonitor’s tlsConfig. This rules out scrapers that run outside the mesh, including the ama-metrics agent that Azure ships with its managed Prometheus offering. To collect Vantage application metrics on AKS, you deploy a Prometheus instance inside the mesh that scrapes Vantage over mTLS and remote-writes to Azure Monitor.

​
Linkerd

Linkerd’s default permissive policy normally allows an unmeshed Prometheus to scrape the proxied Vantage metrics endpoints over plaintext. Confirm that every Vantage target is UP before enabling KEDA. If your Linkerd authorization policy requires authenticated mesh traffic, inject the observability namespace into the mesh or configure Prometheus and the ServiceMonitor with the client certificates required by your policy. The requirement is that Prometheus can successfully scrape /metrics-text; Vantage does not require a specific Prometheus deployment method.

Monitoring with Prometheus

Self-managed Prometheus (kube-prometheus-stack) that works in any environment, with Istio and Linkerd configuration paths.

Azure Managed Monitoring

Azure Monitor Workspace + Azure Managed Grafana, with an in-mesh Prometheus that scrapes Vantage over mTLS and remote-writes to Azure Monitor. The ama-metrics agent continues to handle Kubernetes infrastructure metrics.

​
Available metrics

Vantage applications expose three categories of metrics through the OpenTelemetry SDK:
  • Process metrics: process_cpu_count, process_memory_usage_bytes, process_cpu_time_seconds_total, process_thread_count. Runtime resource usage per pod.
  • HTTP client/server metrics: http_client_active_requests, http_client_connection_duration_seconds, etc. Request latency and connection tracking.
  • ABBYY platform metrics: abbyy_platform_listener_*, abbyy_platform_redisstreamscontroller_*. Application-level processing and queue metrics.
All metrics include labels for service, pod, namespace, and otel_scope_name.