Supervision gérée par Azure - ABBYY Documentation

Ce guide explique comment collecter les métriques applicatives de Vantage sur un cluster AKS où la supervision Azure gérée est déjà activée (Azure Monitor Workspace + Managed Grafana + l’agent ama-metrics). Une fois la configuration terminée, les métriques applicatives de Vantage s’affichent aux côtés de vos métriques d’infrastructure dans le même Azure Managed Grafana, collectées par un Prometheus dans le mesh qui accède aux points de terminaison de Vantage via Istio mTLS.

Pour en savoir plus sur la raison d’être de ce modèle (y compris la contrainte Istio mTLS qui le motive), consultez la Vue d’ensemble de la supervision.

Pourquoi cette approche existe

L’agent ama-metrics déployé par Azure gère automatiquement les métriques d’infrastructure Kubernetes (kubelet, cadvisor, kube-state-metrics). Il peut aussi récupérer les métriques du proxy Istio, comme istio_requests_total, via des annotations de pod, car elles sont exposées sur des ports en clair par le sidecar Envoy. Les métriques applicatives de Vantage sont différentes : elles sont exposées sur le port 8080 du container, lequel est intercepté par le sidecar Envoy et soumis à une application stricte du mTLS. L’agent ama-metrics s’exécute dans kube-system sans sidecar Istio et ne peut pas présenter de certificats mTLS valides ; il ne peut donc pas récupérer les points de terminaison des métriques applicatives dans les namespaces maillés. Microsoft présente cela comme une limitation connue : “Currently, there’s no support to collect metrics from Istio setup with mutual TLS authentication.” Pour collecter les métriques applicatives de Vantage, vous déployez une instance Prometheus dans le mesh. Cette instance Prometheus s’exécute avec un sidecar Istio, exporte les certificats du maillage, les utilise pour récupérer les points de terminaison applicatifs via mTLS et effectue un remote-write vers le même Azure Monitor Workspace que ama-metrics.

Fonctionnement

Les applications Vantage sont instrumentées avec les SDK OpenTelemetry et exposent des métriques au format Prometheus sur /metrics-text, via le port 8080 du conteneur. Les services qui exposent des métriques portent le label abbyy.platform.metrics.text.endpoint: "1". Prometheus dans le mesh collecte ces métriques comme suit :

Il s’exécute avec un sidecar Istio (sidecar.istio.io/inject: "true").
Il exporte les certificats mTLS d’Istio via l’annotation de configuration du proxy OUTPUT_CERTS.
Il monte ces certificats dans le conteneur Prometheus à l’emplacement /etc/prom-certs/.
Il configure le ServiceMonitor (créé par le chart vantage-selfhosted à l’étape 6) pour collecter les métriques via scheme: https à l’aide du certificat d’autorité de certification Istio, du certificat client et de la clé.

Architecture

Composant	Rôle
Azure Monitor Workspace	Backend compatible avec Prometheus qui stocke toutes les métriques.
Azure Managed Grafana	Couche de visualisation, préconfigurée avec Azure Monitor Workspace comme source de données.
`ama-metrics` agent (géré par Azure)	Collecte les métriques d’infrastructure Kubernetes par défaut. Déployé automatiquement lorsque Prometheus est activé sur AKS.
Prometheus dans le mesh (personnalisé)	Prometheus injecté par Istio qui collecte les métriques de l’application Vantage via mTLS et les envoie à Azure Monitor Workspace via remote-write.
`ServiceMonitor` (personnalisé)	Définit les cibles de collecte de Vantage : `/metrics-text` sur les services étiquetés `abbyy.platform.metrics.text.endpoint: "1"`.

Prérequis

cluster AKS avec le module complémentaire de maillage de services Istio activé (mTLS STRICT).
Azure Monitor Workspace provisionné et associé au cluster AKS.
Azure Managed Grafana provisionné et associé à Azure Monitor Workspace.
agent ama-metrics en cours d’exécution sur le cluster (activé via AKS Monitor Settings).
émetteur OIDC activé sur le cluster AKS (requis pour l’identité de charge de travail).
CRD du Prometheus Operator installés (ils sont fournis avec ama-metrics).

Étape 1 : Créer les ressources Azure

Si vous n’avez pas encore créé les ressources de supervision, faites-le maintenant dans le portail Azure :

Azure Monitor Workspace: Portail Azure → “Azure Monitor workspaces” → Créer. Utilisez le même groupe de ressources et la même région que votre cluster AKS. Convention de nommage : amw-<cluster-name>.
Azure Managed Grafana: Portail Azure → “Azure Managed Grafana” → Créer. Même groupe de ressources et même région. Associez-le à l’espace de travail Azure Monitor lors de la création. Convention de nommage : amg-<cluster-name>.
Activer Prometheus sur AKS: Portail Azure → cluster AKS → Monitoring → Monitor Settings → activez “Metrics via managed Prometheus” et sélectionnez l’espace de travail de supervision et l’instance Grafana.

Vérifiez que les pods ama-metrics sont en cours d’exécution :

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

Étape 2 : Créez l’espace de noms d’observabilité avec l’injection Istio

Remarque : Vous pouvez utiliser n’importe quel nom d’espace de noms, mais certaines fonctionnalités facultatives de Vantage (comme la prise en charge de KEDA) dépendent des services Prometheus situés dans l’espace de noms observability. Il est donc recommandé d’utiliser observability.

kubectl create namespace observability

Vérifiez le label de révision Istio utilisé par les autres namespaces maillés :

# remplacez par votre namespace si nécessaire
kubectl get namespace app -o jsonpath='{.metadata.labels}' | grep istio

Appliquez le même label à l’espace de noms observability :

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

Étape 3 : Récupérer les détails d’ingestion d’Azure Monitor Workspace

Récupérez les ID de ressource de la règle de collecte de données et du point de terminaison :

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

Récupérez l’URL du point de terminaison d’ingestion des métriques :

az monitor data-collection endpoint show \
  --name <monitor-workspace-name> \
  --resource-group <managed-resource-group> \
  --query "metricsIngestion.endpoint"

Récupérez l’ID immuable du DCR :

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

Le groupe de ressources géré suit le modèle MA_<monitor-workspace-name>_<region>_managed.

Construisez l’URL complète de remote-write (vous l’utiliserez à l’étape 5) :

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

Étape 4 : Créer une identité managée pour Prometheus

Créez une identité managée attribuée par l’utilisateur :

az identity create \
  --name <cluster-name>-prometheus \
  --resource-group <resource-group> \
  --location <region>

Relevez les clientId et principalId dans la sortie. Attribuez le rôle Monitoring Metrics Publisher à la règle de collecte de données :

az role assignment create \
  --role "Monitoring Metrics Publisher" \
  --assignee-object-id <principalId> \
  --assignee-principal-type ServicePrincipal \
  --scope "<dataCollectionRuleResourceId>"

Récupérez l’URL de l’émetteur OIDC :

az aks show \
  --name <cluster-name> \
  --resource-group <resource-group> \
  --query "oidcIssuerProfile.issuerUrl" -o tsv

Créez un identifiant fédéré qui associe l’identité managée au compte de service Prometheus :

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"

Étape 5 : Installer le Prometheus Operator

L’agent ama-metrics installe les CRD Prometheus, mais n’exécute pas d’opérateur chargé de réconcilier automatiquement les ressources Prometheus personnalisées. Installez uniquement l’opérateur ; désactivez tout le reste :

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

Étape 6 : Appliquer les manifestes Prometheus

Trois manifestes sont nécessaires (compte de service, RBAC et instance Prometheus). Appliquez-les dans l’ordre indiqué. Le ServiceMonitor Vantage est créé séparément par le chart vantage-selfhosted (voir ci-dessous). service-account.yaml : compte de service Prometheus avec annotation de 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 et association pour la découverte des cibles :

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 : instance de Prometheus avec injection de sidecar Istio, export de certificats et remote-write vers 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>"

La méthode d’authentification azureAd.sdk utilise DefaultAzureCredential, qui récupère automatiquement le jeton d’identité de charge de travail injecté par le label azure.workload.identity/use: "true". Nécessite Prometheus v3.60+.

Appliquez les trois :

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

Configurer le ServiceMonitor de Vantage

Le ServiceMonitor de Vantage est créé par le Helm chart vantage-selfhosted plutôt que d’être appliqué manuellement. Installez le chart ou effectuez sa mise à niveau à l’aide d’un fichier de valeurs qui configure le ServiceMonitor pour collecter les métriques de Vantage via Istio mTLS en utilisant les certificats exportés par Prometheus dans le mesh :

# 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 ne prend pas en charge la dénomination de sécurité Istio, la vérification du certificat du pod cible est donc ignorée
      relabelings:
        - action: replace
          sourceLabels: [__meta_kubernetes_service_name]
          targetLabel: service_name
      metricRelabelings:
        - action: replace
          sourceLabels: [__meta_kubernetes_service_name]
          targetLabel: app_service

Pour une explication complète de la mise en place des certificats mTLS d’Istio dont dépendent ces chemins, consultez Monitoring avec Prometheus.

Étape 7 : Vérifier

Vérifiez que le pod Prometheus est en cours d’exécution avec trois conteneurs (prometheus, config-reloader, istio-proxy) :

kubectl get pods -n observability

Configurez une redirection de port pour inspecter les cibles de scraping :

kubectl port-forward -n observability prometheus-metrics-0 9090:9090

Ouvrez http://localhost:9090/targets. Les cibles doivent apparaître comme UP, avec une collecte en https sur /metrics-text:8080. Vérifiez les logs remote-write pour détecter d’éventuelles erreurs :

kubectl logs -n observability prometheus-metrics-0 -c prometheus | grep -i "remote" | tail -10

Un remote-write réussi affiche “Done replaying WAL” sans erreur d’authentification. Dans Managed Grafana, exécutez la requête up{cluster="<cluster-name>"} dans la vue Explore à l’aide de la source de données Managed Prometheus pour confirmer que les métriques remontent.

Notes opérationnelles

L’agent ama-metrics continue de gérer les métriques d’infrastructure Kubernetes (kubelet, cadvisor, kube-state-metrics, node-exporter). Ne le désactivez pas.
Prometheus dans le mesh gère uniquement les métriques applicatives de Vantage. Les deux écrivent dans le même Azure Monitor Workspace.
L’authentification remote-write azureAd.sdk utilise DefaultAzureCredential, qui récupère le jeton d’identité de charge de travail injecté dans le pod par le webhook d’identité de charge de travail AKS. Cela nécessite l’annotation du compte de service azure.workload.identity/client-id et le label du pod azure.workload.identity/use: "true".
La configuration azureAd.managedIdentity ne fonctionne pas pour ce cas d’usage : elle appelle le point de terminaison IMDS sur le nœud, et l’identité affectée par l’utilisateur n’est pas attribuée au Node Pool VMSS.
Les cibles UNKNOWN dans la vue des cibles Prometheus correspondent généralement à des pods dans un état dégradé ou en CrashLooping, et non à un problème de collecte.
logLevel: debug dans la CRD Prometheus peut être remplacé par info une fois la configuration vérifiée.

​Pourquoi cette approche existe

​Fonctionnement

​Architecture

​Prérequis

​Étape 1 : Créer les ressources Azure

​Étape 2 : Créez l’espace de noms d’observabilité avec l’injection Istio

​Étape 3 : Récupérer les détails d’ingestion d’Azure Monitor Workspace

​Étape 4 : Créer une identité managée pour Prometheus

​Étape 5 : Installer le Prometheus Operator

​Étape 6 : Appliquer les manifestes Prometheus

​Configurer le ServiceMonitor de Vantage

​Étape 7 : Vérifier

​Notes opérationnelles

Pourquoi cette approche existe

Fonctionnement

Architecture

Prérequis

Étape 1 : Créer les ressources Azure

Étape 2 : Créez l’espace de noms d’observabilité avec l’injection Istio

Étape 3 : Récupérer les détails d’ingestion d’Azure Monitor Workspace

Étape 4 : Créer une identité managée pour Prometheus

Étape 5 : Installer le Prometheus Operator

Étape 6 : Appliquer les manifestes Prometheus

Configurer le ServiceMonitor de Vantage

Étape 7 : Vérifier

Notes opérationnelles