Überwachung mit Prometheus

In dieser Anleitung richten Sie ein selbstverwaltetes Prometheus ein, das die Metriken von Vantage 3.0 Self-Hosted in jeder Umgebung erfasst. Wenn in AKS Azure Monitor Workspace und Azure Managed Grafana verfügbar sind, finden Sie unter Azure Managed Monitoring eine Managed-Service-Bereitstellung desselben Musters.

Die Beispiele verwenden kube-prometheus-stack, aber das Vorgehen ist allgemein und gilt für jede Prometheus-Bereitstellung. Informationen zu den mesh-spezifischen Einschränkungen finden Sie unter Überwachungsübersicht.

Wie Vantage Metriken offenlegt

Die Anwendungs-Pods von Vantage sind mit OpenTelemetry-SDKs instrumentiert und stellen Metriken im Prometheus-Format unter /metrics-text über den Container-Port 8080 bereit. Services, die diesen Endpunkt bereitstellen, tragen das Label abbyy.platform.metrics.text.endpoint: "1" und ordnen einen Service-Port (in der Regel 80) dem Container-Port mit dem Portnamen http zu. Prometheus erkennt diese Services über einen ServiceMonitor und liest ihre Metriken ab; für die Metrikenerfassung ist kein separater OpenTelemetry Collector erforderlich. Das vollständige Konzept sowie die Einschränkungen des Service-Mesh finden Sie unter Überwachungsübersicht.

Voraussetzungen

Eine laufende Vantage-Installation (Operator und Workloads sind bereitgestellt).
Helm 3.
kubectl-Zugriff auf das Cluster.
Wenn KEDA aktiviert ist, eine Prometheus-Instanz, die unter prometheus-operated.observability.svc.cluster.local:9090 erreichbar ist.

Prometheus konfigurieren

Wenn Sie OTLP-Metriken erfassen möchten (siehe OTLP-Ingestion), aktivieren Sie die Funktion otlp-write-receiver und übergeben Sie das Argument --web.enable-otlp-receiver an die Prometheus-Instanz. Fügen Sie das Helm-Repository hinzu:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Erstellen Sie eine Values-Datei (observability-values.yaml):

prometheus:
  prometheusSpec:
    enableFeatures:
      - otlp-write-receiver
    additionalArgs:
      - name: web.enable-otlp-receiver
        value: ""
    retention: 15d
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        cpu: "2"
        memory: 4Gi
grafana:
  enabled: true
  adminPassword: "changeme"  # In der Produktion überschreiben
  persistence:
    enabled: true
    size: 10Gi
alertmanager:
  enabled: false
nodeExporter:
  enabled: true
kube-state-metrics:
  enabled: true
# Verwaltetes Kubernetes (z. B. AKS, EKS, GKE) legt die Control Plane nicht frei.
# Deaktivieren Sie diese, um Scrape-Fehler zu vermeiden.
kubeApiServer:
  enabled: false
kubeControllerManager:
  enabled: false
kubeScheduler:
  enabled: false
kubeEtcd:
  enabled: false
kubeProxy:
  enabled: false

Installation:

helm install observability prometheus-community/kube-prometheus-stack \
  -n observability --create-namespace \
  -f observability-values.yaml

Prüfen Sie, ob die Pods gestartet sind:

kubectl get pods -n observability

Sie sollten sehen, dass Pods für Prometheus, Grafana, den Operator, kube-state-metrics und node-exporter laufen. Node-exporter läuft als DaemonSet; Pods im Status Pending sind normal, wenn die Knoten noch skaliert werden.

Prometheus zum Scraping von Vantage konfigurieren

Das vantage-selfhosted-Chart kann die erforderlichen ServiceMonitor-Objekte erstellen, um Vantage zu überwachen:

helm upgrade --install abbyy-vantage \
  # ...
  --set observability.prometheus.serviceMonitor.create=true

Weitere Optionen finden Sie in der Dokumentation zum Chart. Der Schlüssel observability befindet sich auf oberster Ebene und darf nicht unter vantage verschachtelt werden.

Linkerd mTLS

Mit der standardmäßig permissiven Richtlinie von Linkerd kann Prometheus die von Linkerd proxierten Vantage-Endpunkte normalerweise unverschlüsselt abfragen. Installieren Sie Prometheus im Namespace observability, aktivieren Sie den Vantage-ServiceMonitor, und vergewissern Sie sich, dass jedes Vantage-Ziel den Status UP hat. Wenn eine strikte Linkerd-Autorisierungsrichtlinie das Abfragen blockiert, verwenden Sie einen der folgenden Ansätze:

Aktivieren Sie die Linkerd-Injektion für den Namespace observability, damit Prometheus am Mesh teilnimmt.
Konfigurieren Sie observability.prometheus.serviceMonitor.scheme: https und eine tlsConfig, die auf die Client-Zertifikate verweist, die Prometheus durch Ihre Linkerd-Konfiguration zur Verfügung gestellt werden.

Aktivieren Sie KEDA erst, wenn Prometheus aktuelle Werte für die Vantage-Metriken zurückgibt, die von den ScaledObject-Ressourcen verwendet werden. Siehe Autoskalierung mit KEDA für die Prüfabfragen und Readiness-Checks.

Istio mTLS

Wenn Vantage in einem Istio-Mesh mit STRICT mTLS eingesetzt wird (standardmäßig, wenn ingress.enabled auf true und ingress.type auf istio gesetzt ist), müssen Prometheus und der ServiceMonitor so konfiguriert werden, dass sie Endpoints über mTLS abfragen, da Prometheus Pod-IPs direkt verwendet und nicht den Service-Namen. Konfigurieren Sie die Prometheus-Pods mit den folgenden Annotationen:

annotations:
  proxy.istio.io/config: |
    proxyMetadata:
      OUTPUT_CERTS: /etc/istio-output-certs
  sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'

und die folgenden volume und volumeMount (Namen und Pfade sind anpassbar; in den folgenden Beispielen werden sie verwendet):

volumes:
  - name: istio-certs
    emptyDir:
      medium: Memory
volumeMounts:
  - name: istio-certs
    mountPath: /etc/prom-certs/
    readOnly: true

Mit kube-prometheus-stack ist dies mit den folgenden Werten möglich:

prometheus:
  prometheusSpec:
    podMetadata:
      annotations:
        # Istio zwingen, Zertifikate in ein lokales Volume-Verzeichnis zu generieren
        "proxy.istio.io/config": |
          proxyMetadata:
            OUTPUT_CERTS: /etc/istio-output-certs
        "sidecar.istio.io/userVolumeMount": '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'
    # Gemeinsames Volume, in das Istio Zertifikate schreibt
    volumes:
      - name: istio-certs
        emptyDir: {}
    volumeMounts:
      - name: istio-certs
        mountPath: /etc/prom-certs

Alternativ finden Sie weitere Informationen in der offiziellen Istio-Dokumentation. Installieren Sie als Nächstes das vantage-selfhosted-Chart, damit die ServiceMonitor(s) für die Verwendung dieser Zertifikate konfiguriert werden:

# values.vantage-selfhosted.yaml
observability:
  prometheus:
    serviceMonitor:
      scheme: https
      tlsConfig:
        caFile: /etc/prom-certs/root-cert.pem
        certFile: /etc/prom-certs/cert-chain.pem
        keyFile: /etc/prom-certs/key.pem
        insecureSkipVerify: true  # Prometheus unterstützt keine Istio-Sicherheitsbenennung, daher wird die Überprüfung des Ziel-Pod-Zertifikats übersprungen

Prüfen, ob Metriken ankommen

Richten Sie ein Port-Forwarding zur Prometheus-UI ein:

kubectl port-forward -n observability svc/observability-kube-prometheus-prometheus 9090:9090

Prüfen Sie, ob die Vantage-Ziele erkannt wurden und ordnungsgemäß funktionieren:

curl -s http://localhost:9090/api/v1/targets \
  | jq '[.data.activeTargets[] | select(.scrapePool // "" | contains("vantage"))] | group_by(.health) | map({health: .[0].health, count: length})'

Abfrage einer Vantage-Anwendungsmetrik:

curl -s "http://localhost:9090/api/v1/query?query=process_cpu_count" \
  | jq '.data.result | length'

Ein Ergebnis ungleich null bestätigt, dass Metriken abgerufen werden. Sie können auch die Targets unter http://localhost:9090/targets aufrufen, um den Scrape-Status der einzelnen Targets anzuzeigen.

Zugriff auf Grafana

kubectl port-forward -n observability svc/observability-grafana 3000:80

Öffnen Sie http://localhost:3000. Die Standard-Anmeldedaten sind admin / das in der values-Datei festgelegte Kennwort. Prometheus ist als Datenquelle vorkonfiguriert.

Verfügbare Metriken

Vantage-Anwendungen stellen über das OpenTelemetry SDK Prozess-, HTTP-Client-/Server- und ABBYY-Plattformmetriken bereit, die alle mit service, pod, namespace und otel_scope_name gekennzeichnet sind. Die vollständige Liste finden Sie unter Verfügbare Metriken.

OTLP-Ingestion

Die OTLP-Ingestion erfolgt pushbasiert und ist unabhängig vom oben beschriebenen scrape-basierten ServiceMonitor-Flow. Verwenden Sie sie nur für Services, die OpenTelemetry-Metriken per Push senden, anstatt einen Scrape-Endpunkt bereitzustellen.

Wenn Prometheus mit aktiviertem OTLP-Receiver konfiguriert ist (--web.enable-otlp-receiver), kann jeder Service, der OTLP-Metriken per HTTP pusht, diese an Folgendes senden:

http://observability-kube-prometheus-prometheus.observability:9090/api/v1/otlp/v1/metrics

Configuration

Lifecycle

Monitoring

Performance

Diagnostics

Migration

Wie Vantage Metriken offenlegt

Voraussetzungen

Prometheus konfigurieren

Prometheus zum Scraping von Vantage konfigurieren

Linkerd mTLS

Istio mTLS

Prüfen, ob Metriken ankommen

Zugriff auf Grafana

Verfügbare Metriken

OTLP-Ingestion

​Wie Vantage Metriken offenlegt

​Voraussetzungen

​Prometheus konfigurieren

​Prometheus zum Scraping von Vantage konfigurieren

​Linkerd mTLS

​Istio mTLS

​Prüfen, ob Metriken ankommen

​Zugriff auf Grafana

​Verfügbare Metriken

​OTLP-Ingestion

Wie Vantage Metriken offenlegt

Voraussetzungen

Prometheus konfigurieren

Prometheus zum Scraping von Vantage konfigurieren

Linkerd mTLS

Istio mTLS

Prüfen, ob Metriken ankommen

Zugriff auf Grafana

Verfügbare Metriken

OTLP-Ingestion