> ## 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.
# Überwachung mit Prometheus
> Erfassen Sie mit Prometheus Metriken von Vantage 3.0 Self-Hosted in Istio- und Linkerd-Service-Meshes.
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](/de/vantage/self-hosted/v3.0/monitoring/azure-managed) eine Managed-Service-Bereitstellung desselben Musters.
Die Beispiele verwenden [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/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](/de/vantage/self-hosted/v3.0/monitoring/overview).
## 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](/de/vantage/self-hosted/v3.0/monitoring/overview).
## 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](#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:
```bash theme={null}
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
```
Erstellen Sie eine Values-Datei (`observability-values.yaml`):
```yaml theme={null}
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:
```bash theme={null}
helm install observability prometheus-community/kube-prometheus-stack \
-n observability --create-namespace \
-f observability-values.yaml
```
Prüfen Sie, ob die Pods gestartet sind:
```bash theme={null}
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:
```bash theme={null}
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:
1. Aktivieren Sie die Linkerd-Injektion für den Namespace `observability`, damit Prometheus am Mesh teilnimmt.
2. 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](/de/vantage/self-hosted/v3.0/performance/autoscaling) 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:
```yaml theme={null}
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):
```yaml theme={null}
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:
```yaml theme={null}
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](https://istio.io/latest/docs/ops/integrations/prometheus/#tls-settings).
Installieren Sie als Nächstes das `vantage-selfhosted`-Chart, damit die `ServiceMonitor`(s) für die Verwendung dieser Zertifikate konfiguriert werden:
```yaml theme={null}
# 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:
```bash theme={null}
kubectl port-forward -n observability svc/observability-kube-prometheus-prometheus 9090:9090
```
Prüfen Sie, ob die Vantage-Ziele erkannt wurden und ordnungsgemäß funktionieren:
```bash theme={null}
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:
```bash theme={null}
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
```bash theme={null}
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](/de/vantage/self-hosted/v3.0/monitoring/overview#available-metrics).
## 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:
```text theme={null}
http://observability-kube-prometheus-prometheus.observability:9090/api/v1/otlp/v1/metrics
```