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

# Übersicht zur Überwachung

> Wie die Überwachung für Vantage 3.0 selbstgehostet in Istio- und Linkerd-Service-Meshes funktioniert.

Vantage 3.0 selbstgehostet wird in einem Service-Mesh mit mTLS für den Anwendungsverkehr ausgeführt. Die Scrape-Konfiguration hängt davon ab, ob bei der Bereitstellung Istio oder Linkerd verwendet wird.

<div id="how-vantage-exposes-metrics">
  ## Wie Vantage Metriken offenlegt
</div>

Die Vantage-Anwendungs-Pods sind mit OpenTelemetry-SDKs instrumentiert und stellen Metriken im Prometheus-Format unter `/metrics-text` über Container-Port 8080 bereit. Services, die diesen Endpunkt verfügbar machen, tragen das Label:

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

Jeder Service ordnet Port 80 → 8080 zu und verwendet dabei den Portnamen `http`. Prometheus erkennt diese Services und scrapet ihre Metriken über einen `ServiceMonitor` aus, der dieses Label auswählt.

<div id="service-mesh-considerations">
  ## Aspekte des Service-Mesh
</div>

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

Der Anwendungsverkehr auf Port 8080 wird vom Envoy-Sidecar abgefangen und unterliegt STRICT mTLS. Jeder Scraper, der diese Metriken lesen möchte, muss den Ziel-Pods ein gültiges mTLS-Clientzertifikat vorlegen. Es reicht nicht aus, dem Scraper lediglich ein Istio-Sidecar zu injizieren: Prometheus-Scrape-Targets werden zur Pod-IP und zum Container-Port aufgelöst, die das Envoy-Sidecar nicht weiterleiten kann, sodass jeder Scrape mit HTTP 503 fehlschlägt. In der dokumentierten, funktionierenden Konfiguration läuft Prometheus **innerhalb des Mesh** mit einem Istio-Sidecar, das die Mesh-Zertifikate in ein gemeinsames Volume exportiert (`OUTPUT_CERTS`), und Prometheus selbst legt diese Zertifikate vor, indem es per `scheme: https` scrapt und die Zertifikatspfade in der `tlsConfig` des ServiceMonitor festgelegt sind.

Damit scheiden Scraper aus, die außerhalb des Mesh laufen, einschließlich des `ama-metrics`-Agenten, den Azure mit seinem verwalteten Prometheus-Angebot bereitstellt. Um Vantage-Anwendungsmetriken auf AKS zu erfassen, stellen Sie eine Prometheus-Instanz innerhalb des Mesh bereit, die Vantage per mTLS scrapet und per remote-write an Azure Monitor sendet.

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

Die standardmäßig permissive Richtlinie von Linkerd erlaubt es in der Regel, dass ein nicht ins Mesh eingebundener Prometheus die über den Proxy bereitgestellten Vantage-Metrikendpunkte per Klartext scrapen kann. Vergewissern Sie sich, dass jedes Vantage-Ziel `UP` ist, bevor Sie KEDA aktivieren.

Wenn Ihre Linkerd-Autorisierungsrichtlinie authentifizierten Mesh-Datenverkehr erfordert, binden Sie den Namespace `observability` in das Mesh ein oder konfigurieren Sie Prometheus und den `ServiceMonitor` mit den von Ihrer Richtlinie geforderten Client-Zertifikaten. Entscheidend ist, dass Prometheus `/metrics-text` erfolgreich scrapen kann; Vantage erfordert keine bestimmte Methode zur Bereitstellung von Prometheus.

<div id="recommended-approach">
  ## Empfohlene Vorgehensweise
</div>

<CardGroup cols={2}>
  <Card title="Monitoring mit Prometheus" icon="chart-line" href="/de/vantage/self-hosted/v3.0/monitoring/prometheus">
    Selbstverwaltetes Prometheus (kube-prometheus-stack), das in jeder Umgebung funktioniert, mit Konfigurationspfaden für Istio und Linkerd.
  </Card>

  <Card title="Azure Managed Monitoring" icon="cloud" href="/de/vantage/self-hosted/v3.0/monitoring/azure-managed">
    Azure Monitor Workspace + Azure Managed Grafana, mit einem In-mesh Prometheus, der Vantage-Metriken über mTLS scrapet und per remote-write an Azure Monitor sendet. Der `ama-metrics`-Agent übernimmt weiterhin die Kubernetes-Infrastrukturmetriken.
  </Card>
</CardGroup>

<div id="available-metrics">
  ## Verfügbare Metriken
</div>

Vantage-Anwendungen stellen über das OpenTelemetry SDK drei Kategorien von Metriken bereit:

* **Prozessmetriken**: `process_cpu_count`, `process_memory_usage_bytes`, `process_cpu_time_seconds_total`, `process_thread_count`. Ressourcennutzung der Runtime pro Pod.
* **HTTP-Client-/Servermetriken**: `http_client_active_requests`, `http_client_connection_duration_seconds` usw. Latenz von Anfragen und Nachverfolgung von Verbindungen.
* **ABBYY-Plattformmetriken**: `abbyy_platform_listener_*`, `abbyy_platform_redisstreamscontroller_*`. Metriken auf Anwendungsebene für die Verarbeitung und Warteschlangen.

Alle Metriken enthalten Labels für `service`, `pod`, `namespace` und `otel_scope_name`.