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

# Von Azure verwaltete Überwachung

> Erfassen Sie Vantage-Anwendungsmetriken von Vantage 3.0 selbstgehostet auf einem AKS Cluster mithilfe von Azure Monitor Workspace, Azure Managed Grafana und einem In-mesh Prometheus, der sie über Istio mTLS abruft.

Diese Anleitung zeigt Ihnen, wie Sie Vantage-Anwendungsmetriken auf einem AKS Cluster erfassen, für den die von Azure verwaltete Überwachung bereits aktiviert ist (Azure Monitor Workspace + Managed Grafana + der `ama-metrics` Agent). Nach Abschluss werden die Vantage-Anwendungsmetriken zusammen mit Ihren Infrastrukturmetriken im selben Azure Managed Grafana angezeigt und von einem In-mesh Prometheus abgerufen, der die Endpunkte von Vantage über Istio mTLS erreicht.

<Note>
  Hintergrundinformationen dazu, warum dieses Muster verwendet wird (einschließlich der Istio-mTLS-Einschränkung, die es erforderlich macht), finden Sie unter [Überwachungsübersicht](/de/vantage/self-hosted/v3.0/monitoring/overview).
</Note>

<div id="why-this-pattern-exists">
  ## Warum dieses Muster existiert
</div>

Der von Azure bereitgestellte `ama-metrics`-Agent verarbeitet Kubernetes-Infrastrukturmetriken (kubelet, cadvisor, kube-state-metrics) automatisch. Über Pod-Annotationen kann er auch Istio-Proxy-Metriken wie `istio_requests_total` scrapen, da diese vom Envoy-Sidecar auf unverschlüsselten Ports bereitgestellt werden.

Bei den Vantage-Anwendungsmetriken ist das anders: Sie werden über Container-Port 8080 bereitgestellt, der vom Envoy-Sidecar abgefangen wird und der strikten mTLS-Durchsetzung unterliegt. Der `ama-metrics`-Agent läuft in `kube-system` ohne Istio-Sidecar und kann keine gültigen mTLS-Zertifikate vorlegen. Deshalb kann er keine Anwendungsmetrik-Endpunkte in Namespaces scrapen, die Teil des Mesh sind. Microsoft dokumentiert dies als bekannte Einschränkung: ["Derzeit wird das Sammeln von Metriken aus einem Istio-Setup mit gegenseitiger TLS-Authentifizierung nicht unterstützt."](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-istio-integration#limitations)

Um Vantage-Anwendungsmetriken zu erfassen, stellen Sie eine Prometheus-Instanz **innerhalb des Istio-Meshs** bereit. Diese Prometheus-Instanz läuft mit einem Istio-Sidecar, exportiert die Mesh-Zertifikate, verwendet sie zum Scrapen der Anwendungs-Endpunkte über mTLS und nutzt Remote-Write an denselben Azure Monitor Workspace, den auch `ama-metrics` verwendet.

<div id="how-it-works">
  ## So funktioniert es
</div>

Vantage-Anwendungen sind mit OpenTelemetry-SDKs instrumentiert und stellen Metriken im Prometheus-Format unter `/metrics-text` über den Container-Port 8080 bereit. Services, die Metriken bereitstellen, tragen das Label `abbyy.platform.metrics.text.endpoint: "1"`.

Der In-mesh Prometheus ruft diese Metriken wie folgt ab:

1. Er wird mit einem Istio-Sidecar ausgeführt (`sidecar.istio.io/inject: "true"`).
2. Er exportiert Istios mTLS-Zertifikate über die Proxy-Konfigurationsannotation `OUTPUT_CERTS`.
3. Er bindet diese Zertifikate im Prometheus-Container unter `/etc/prom-certs/` ein.
4. Er konfiguriert den `ServiceMonitor` (der vom `vantage-selfhosted` chart in Schritt 6 erstellt wird) so, dass er über `scheme: https` mithilfe des Istio-CA-Zertifikats, des Client-Zertifikats und des Schlüssels abruft.

<div id="architecture">
  ## Architektur
</div>

| Komponente                                 | Rolle                                                                                                                                        |
| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Azure Monitor Workspace**                | Prometheus-kompatibles Backend, das alle Metriken speichert.                                                                                 |
| **Azure Managed Grafana**                  | Visualisierungsebene, die bereits als Datenquelle mit dem Azure Monitor Workspace verbunden ist.                                             |
| **`ama-metrics` agent** (Azure-verwaltet)  | Erfasst standardmäßige Kubernetes-Infrastrukturmetriken. Wird automatisch bereitgestellt, wenn Prometheus in AKS aktiviert ist.              |
| **In-mesh Prometheus** (benutzerdefiniert) | Ein per Istio injiziertes Prometheus, das Vantage-App-Metriken über mTLS erfasst und per remote-write an den Azure Monitor Workspace sendet. |
| **`ServiceMonitor`** (benutzerdefiniert)   | Definiert die Vantage-Scrape-Targets: `/metrics-text` auf Services mit dem Label `abbyy.platform.metrics.text.endpoint: "1"`.                |

<div id="prerequisites">
  ## Voraussetzungen
</div>

* AKS-Cluster mit aktiviertem Istio-Service-Mesh-Add-on (STRICT mTLS).
* Azure Monitor Workspace bereitgestellt und mit dem AKS-Cluster verknüpft.
* Azure Managed Grafana bereitgestellt und mit dem Azure Monitor Workspace verknüpft.
* `ama-metrics`-Agent wird im Cluster ausgeführt (aktiviert über AKS Monitor Settings).
* OIDC-Issuer auf dem AKS-Cluster aktiviert (erforderlich für Workload Identity).
* Prometheus Operator CRDs installiert (diese sind in `ama-metrics` enthalten).

<div id="step-1-provision-azure-resources">
  ## Schritt 1: Azure-Ressourcen bereitstellen
</div>

Falls Sie die Überwachungsressourcen noch nicht erstellt haben, tun Sie dies jetzt im Azure portal:

1. **Azure Monitor Workspace**: Portal → "Azure Monitor workspaces" → Erstellen. Verwenden Sie dieselbe Ressourcengruppe und Region wie für Ihren AKS-Cluster. Benennungskonvention: `amw-<cluster-name>`.
2. **Azure Managed Grafana**: Portal → "Azure Managed Grafana" → Erstellen. Verwenden Sie dieselbe Ressourcengruppe und Region. Verknüpfen Sie die Instanz bei der Erstellung mit dem Azure Monitor Workspace. Benennungskonvention: `amg-<cluster-name>`.
3. **Prometheus auf AKS aktivieren**: Portal → AKS-Cluster → Überwachung → Monitor Settings → "Metrics via managed Prometheus" aktivieren und den Azure Monitor Workspace sowie die Grafana-Instanz auswählen.

Stellen Sie sicher, dass die `ama-metrics`-Pods laufen:

```bash theme={null}
kubectl get pods -n kube-system | grep ama-metrics
```

<div id="step-2-create-the-observability-namespace-with-istio-injection">
  ## Schritt 2: Erstellen Sie den Namespace `observability` mit Istio-Injektion
</div>

> **Hinweis:** Es kann zwar jeder Namespace-Name verwendet werden, aber bestimmte optionale Vantage-Funktionen (wie die KEDA-Unterstützung) setzen voraus, dass die Prometheus-Service im Namespace `observability` ausgeführt werden. Daher wird empfohlen, `observability` zu verwenden.

```bash theme={null}
kubectl create namespace observability
```

Prüfen Sie das Istio-Revisionslabel, das von anderen am Mesh teilnehmenden Namespaces verwendet wird:

```bash theme={null}
# falls nötig, durch Ihren Namespace ersetzen
kubectl get namespace app -o jsonpath='{.metadata.labels}' | grep istio
```

Weisen Sie dem `observability`-Namespace dasselbe Label zu:

```bash theme={null}
kubectl label namespace observability istio.io/rev=<revision>
```

<div id="step-3-gather-azure-monitor-workspace-ingestion-details">
  ## Schritt 3: Details zur Datenerfassung für Azure Monitor Workspace abrufen
</div>

Rufen Sie die Ressourcen-IDs der Datensammlungsregel und des Endpunkts ab:

```bash theme={null}
az monitor account show \
  --name <monitor-workspace-name> \
  --resource-group <resource-group> \
  --query "defaultIngestionSettings"
```

Rufen Sie die Endpunkt-URL für die Metrikaufnahme ab:

```bash theme={null}
az monitor data-collection endpoint show \
  --name <monitor-workspace-name> \
  --resource-group <managed-resource-group> \
  --query "metricsIngestion.endpoint"
```

Rufen Sie die unveränderliche DCR-ID ab:

```bash theme={null}
az monitor data-collection rule show \
  --name <monitor-workspace-name> \
  --resource-group <managed-resource-group> \
  --query "immutableId"
```

<Note>
  Die verwaltete Ressourcengruppe folgt dem Namensschema `MA_<monitor-workspace-name>_<region>_managed`.
</Note>

Erstellen Sie die vollständige remote-write-URL (Sie benötigen sie in Schritt 5):

```text theme={null}
https://<endpoint>/dataCollectionRules/<dcr-immutable-id>/streams/Microsoft-PrometheusMetrics/api/v1/write?api-version=2023-04-24
```

<div id="step-4-create-a-managed-identity-for-prometheus">
  ## Schritt 4: Eine benutzerzugewiesene verwaltete Identität für Prometheus erstellen
</div>

Erstellen Sie eine benutzerzugewiesene verwaltete Identität:

```bash theme={null}
az identity create \
  --name <cluster-name>-prometheus \
  --resource-group <resource-group> \
  --location <region>
```

Notieren Sie die `clientId` und `principalId` aus der Ausgabe.

Weisen Sie der Datensammlungsregel die Rolle `Monitoring Metrics Publisher` zu:

```bash theme={null}
az role assignment create \
  --role "Monitoring Metrics Publisher" \
  --assignee-object-id <principalId> \
  --assignee-principal-type ServicePrincipal \
  --scope "<dataCollectionRuleResourceId>"
```

Rufen Sie die OIDC-Issuer-URL ab:

```bash theme={null}
az aks show \
  --name <cluster-name> \
  --resource-group <resource-group> \
  --query "oidcIssuerProfile.issuerUrl" -o tsv
```

Erstellen Sie eine föderierte Anmeldeinformation, die die verwaltete Identität mit dem Prometheus-Servicekonto verknüpft:

```bash theme={null}
az identity federated-credential create \
  --name prometheus-federated \
  --identity-name <cluster-name>-prometheus \
  --resource-group <resource-group> \
  --issuer "<oidc-issuer-url>" \
  --subject "system:serviceaccount:observability:prometheus" \
  --audiences "api://AzureADTokenExchange"
```

<div id="step-5-install-the-prometheus-operator">
  ## Schritt 5: Den Prometheus Operator installieren
</div>

Der `ama-metrics`-Agent installiert die Prometheus-CRDs, stellt jedoch keinen Operator bereit, der benutzerdefinierte Prometheus-Ressourcen reconciliiert. Installieren Sie nur den Operator und deaktivieren Sie alles andere:

```bash theme={null}
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install prometheus-operator prometheus-community/kube-prometheus-stack \
  --namespace observability \
  --set prometheus.enabled=false \
  --set alertmanager.enabled=false \
  --set grafana.enabled=false \
  --set defaultRules.create=false \
  --set nodeExporter.enabled=false \
  --set kubeStateMetrics.enabled=false
```

<div id="step-6-apply-the-prometheus-manifests">
  ## Schritt 6: Die Prometheus-Manifeste anwenden
</div>

Drei Manifeste sind erforderlich (Servicekonto, RBAC und die Prometheus-Instanz). Wenden Sie sie in der angegebenen Reihenfolge an. Der Vantage-`ServiceMonitor` wird separat durch das `vantage-selfhosted`-Chart erstellt (siehe unten).

**`service-account.yaml`**: Prometheus-Servicekonto mit Annotation für Workload Identity:

```yaml theme={null}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: observability
  annotations:
    azure.workload.identity/client-id: "<managed-identity-clientId>"
  labels:
    azure.workload.identity/use: "true"
```

**`rbac.yaml`**: `ClusterRole` und Bindung für die Erkennung von Zielen:

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
  - apiGroups: [""]
    resources: [nodes, nodes/metrics, services, endpoints, pods]
    verbs: [get, list, watch]
  - apiGroups: ["networking.k8s.io"]
    resources: [ingresses]
    verbs: [get, list, watch]
  - nonResourceURLs: ["/metrics", "/metrics/cadvisor"]
    verbs: [get]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
  - kind: ServiceAccount
    name: prometheus
    namespace: observability
```

**`prometheus.yaml`**: Prometheus-Instanz mit Istio-Sidecar-Injektion, Zertifikatexport und remote-write an Azure Monitor:

```yaml theme={null}
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: metrics
  namespace: observability
spec:
  replicas: 1
  scrapeInterval: 60s
  logLevel: debug
  serviceAccountName: prometheus
  podMetadata:
    annotations:
      proxy.istio.io/config: |
        proxyMetadata:
          OUTPUT_CERTS: /etc/istio-output-certs
      sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'
    labels:
      sidecar.istio.io/inject: "true"
      azure.workload.identity/use: "true"
  volumes:
    - name: istio-certs
      emptyDir:
        medium: Memory
  volumeMounts:
    - name: istio-certs
      mountPath: /etc/prom-certs/
      readOnly: true
  resources:
    requests:
      memory: 3Gi
      cpu: 600m
    limits:
      memory: 6Gi
      cpu: 1000m
  serviceMonitorNamespaceSelector: {}
  serviceMonitorSelector: {}
  remoteWrite:
    - url: "<remote-write-url>"
      azureAd:
        cloud: AzurePublic
        sdk:
          tenantId: "<azure-tenant-id>"
  replicaExternalLabelName: "__replica__"
  externalLabels:
    cluster: "<cluster-name>"
```

<Note>
  Die Authentifizierungsmethode `azureAd.sdk` verwendet `DefaultAzureCredential`, das das durch das Label `azure.workload.identity/use: "true"` eingebundene Workload-Identity-Token verwendet. Erfordert Prometheus v3.60+.
</Note>

Wenden Sie alle drei an:

```bash theme={null}
kubectl apply -f service-account.yaml
kubectl apply -f rbac.yaml
kubectl apply -f prometheus.yaml
```

<div id="configure-the-vantage-servicemonitor">
  ### Den Vantage `ServiceMonitor` konfigurieren
</div>

Der Vantage-`ServiceMonitor` wird vom Helm-Chart `vantage-selfhosted` erstellt und nicht manuell angewendet. Installieren oder aktualisieren Sie das Chart mit einer Values-Datei, die den `ServiceMonitor` so konfiguriert, dass er Vantage über Istio mTLS mithilfe der Zertifikate scrapen kann, die In-mesh Prometheus exportiert:

```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 Zertifikatsprüfung des Ziel-Pods übersprungen
      relabelings:
        - action: replace
          sourceLabels: [__meta_kubernetes_service_name]
          targetLabel: service_name
      metricRelabelings:
        - action: replace
          sourceLabels: [__meta_kubernetes_service_name]
          targetLabel: app_service
```

Eine vollständige Erläuterung der Istio-mTLS-Zertifikatskonfiguration, auf der diese Pfade basieren, finden Sie unter [Überwachung mit Prometheus](/de/vantage/self-hosted/v3.0/monitoring/prometheus#istio-mtls).

<div id="step-7-verify">
  ## Schritt 7: Prüfen
</div>

Prüfen Sie, ob der Prometheus-Pod mit drei Containern (`prometheus`, `config-reloader`, `istio-proxy`) läuft:

```bash theme={null}
kubectl get pods -n observability
```

Port-Forwarding zum Prüfen von Scrape-Targets:

```bash theme={null}
kubectl port-forward -n observability prometheus-metrics-0 9090:9090
```

Öffnen Sie `http://localhost:9090/targets`. Die Targets sollten als **UP** angezeigt werden und über `https` von `/metrics-text:8080` abgerufen werden.

Prüfen Sie die remote-write-Protokolle auf Fehler:

```bash theme={null}
kubectl logs -n observability prometheus-metrics-0 -c prometheus | grep -i "remote" | tail -10
```

Ein erfolgreiches remote-write zeigt „Done replaying WAL“ ohne Authentifizierungsfehler an.

Fragen Sie in Managed Grafana in der Explore-Ansicht mit der Managed-Prometheus-Datenquelle `up{cluster="<cluster-name>"}` ab, um zu bestätigen, dass Metriken eingehen.

<div id="operational-notes">
  ## Betriebshinweise
</div>

* Der `ama-metrics`-Agent verarbeitet weiterhin Kubernetes-Infrastrukturmetriken (kubelet, cadvisor, kube-state-metrics, node-exporter). Deaktivieren Sie ihn **nicht**.
* In-mesh Prometheus verarbeitet nur Vantage-Anwendungsmetriken. Beide schreiben in denselben Azure Monitor Workspace.
* Die `azureAd.sdk`-Authentifizierung für `remote-write` verwendet `DefaultAzureCredential`. Dabei wird das Workload-Identity-Token verwendet, das vom AKS-Workload-Identity-Webhook in den Pod projiziert wird. Dafür sind die Service-Account-Annotation `azure.workload.identity/client-id` und das Pod-Label `azure.workload.identity/use: "true"` erforderlich.
* Die Konfiguration `azureAd.managedIdentity` funktioniert für diesen Anwendungsfall **nicht**: Sie ruft den IMDS-Endpunkt auf dem Knoten auf, und die benutzerseitig zugewiesene Identität ist dem VMSS-Knotenpool nicht zugewiesen.
* `UNKNOWN`-Ziele in der Prometheus-Targets-Ansicht sind typischerweise Pods im Status Degraded oder CrashLooping und kein Scraping-Problem.
* `logLevel: debug` in der Prometheus-CRD kann nach erfolgreicher Überprüfung des Setups auf `info` geändert werden.