Von Azure verwaltete Überwachung

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.

Hintergrundinformationen dazu, warum dieses Muster verwendet wird (einschließlich der Istio-mTLS-Einschränkung, die es erforderlich macht), finden Sie unter Überwachungsübersicht.

Warum dieses Muster existiert

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

So funktioniert es

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:

Er wird mit einem Istio-Sidecar ausgeführt (sidecar.istio.io/inject: "true").
Er exportiert Istios mTLS-Zertifikate über die Proxy-Konfigurationsannotation OUTPUT_CERTS.
Er bindet diese Zertifikate im Prometheus-Container unter /etc/prom-certs/ ein.
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.

Architektur

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"`.

Voraussetzungen

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

Schritt 1: Azure-Ressourcen bereitstellen

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

Azure Monitor Workspace: Portal → “Azure Monitor workspaces” → Erstellen. Verwenden Sie dieselbe Ressourcengruppe und Region wie für Ihren AKS-Cluster. Benennungskonvention: amw-<cluster-name>.
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>.
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:

kubectl get pods -n kube-system | grep ama-metrics

Schritt 2: Erstellen Sie den Namespace `observability` mit Istio-Injektion

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.

kubectl create namespace observability

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

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

kubectl label namespace observability istio.io/rev=<revision>

Schritt 3: Details zur Datenerfassung für Azure Monitor Workspace abrufen

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

az monitor account show \
  --name <monitor-workspace-name> \
  --resource-group <resource-group> \
  --query "defaultIngestionSettings"

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

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:

az monitor data-collection rule show \
  --name <monitor-workspace-name> \
  --resource-group <managed-resource-group> \
  --query "immutableId"

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

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

https://<endpoint>/dataCollectionRules/<dcr-immutable-id>/streams/Microsoft-PrometheusMetrics/api/v1/write?api-version=2023-04-24

Schritt 4: Eine benutzerzugewiesene verwaltete Identität für Prometheus erstellen

Erstellen Sie eine benutzerzugewiesene verwaltete Identität:

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:

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:

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:

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"

Schritt 5: Den Prometheus Operator installieren

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:

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

Schritt 6: Die Prometheus-Manifeste anwenden

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:

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:

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:

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>"

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

Wenden Sie alle drei an:

kubectl apply -f service-account.yaml
kubectl apply -f rbac.yaml
kubectl apply -f prometheus.yaml

Den Vantage `ServiceMonitor` konfigurieren

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:

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

Schritt 7: Prüfen

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

kubectl get pods -n observability

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

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:

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.

Betriebshinweise

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.

​Warum dieses Muster existiert

​So funktioniert es

​Architektur

​Voraussetzungen

​Schritt 1: Azure-Ressourcen bereitstellen

​Schritt 2: Erstellen Sie den Namespace observability mit Istio-Injektion

​Schritt 3: Details zur Datenerfassung für Azure Monitor Workspace abrufen

​Schritt 4: Eine benutzerzugewiesene verwaltete Identität für Prometheus erstellen

​Schritt 5: Den Prometheus Operator installieren

​Schritt 6: Die Prometheus-Manifeste anwenden

​Den Vantage ServiceMonitor konfigurieren

​Schritt 7: Prüfen

​Betriebshinweise

Warum dieses Muster existiert

So funktioniert es

Architektur

Voraussetzungen

Schritt 1: Azure-Ressourcen bereitstellen

Schritt 2: Erstellen Sie den Namespace `observability` mit Istio-Injektion

Schritt 3: Details zur Datenerfassung für Azure Monitor Workspace abrufen

Schritt 4: Eine benutzerzugewiesene verwaltete Identität für Prometheus erstellen

Schritt 5: Den Prometheus Operator installieren

Schritt 6: Die Prometheus-Manifeste anwenden

Den Vantage `ServiceMonitor` konfigurieren

Schritt 7: Prüfen

Betriebshinweise