Skip to main content
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.

​
Wie Vantage Metriken offenlegt

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

​
Aspekte des Service-Mesh

​
Istio

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.

​
Linkerd

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.

Monitoring mit Prometheus

Selbstverwaltetes Prometheus (kube-prometheus-stack), das in jeder Umgebung funktioniert, mit Konfigurationspfaden für Istio und Linkerd.

Azure Managed Monitoring

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.

​
Verfügbare Metriken

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.