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

> How monitoring works for Vantage 3.0 self-hosted across Istio and Linkerd service meshes.

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:

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

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.

## Recommended approach

<CardGroup cols={2}>
  <Card title="Monitoring with Prometheus" icon="chart-line" href="/vantage/self-hosted/v3.0/monitoring/prometheus">
    Self-managed Prometheus (kube-prometheus-stack) that works in any environment, with Istio and Linkerd configuration paths.
  </Card>

  <Card title="Azure Managed Monitoring" icon="cloud" href="/vantage/self-hosted/v3.0/monitoring/azure-managed">
    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.
  </Card>
</CardGroup>

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