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

# Supervision gérée par Azure

> Collectez les métriques de Vantage 3.0 auto-hébergé sur un cluster AKS à l’aide d’Azure Monitor Workspace, d’Azure Managed Grafana et d’un Prometheus dans le mesh qui récupère les métriques via Istio mTLS.

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.

<Note>
  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](/fr/vantage/self-hosted/v3.0/monitoring/overview).
</Note>

<div id="why-this-pattern-exists">
  ## Pourquoi cette approche existe
</div>

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."](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/prometheus-istio-integration#limitations)

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

<div id="how-it-works">
  ## Fonctionnement
</div>

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 :

1. Il s’exécute avec un sidecar Istio (`sidecar.istio.io/inject: "true"`).
2. Il exporte les certificats mTLS d’Istio via l’annotation de configuration du proxy `OUTPUT_CERTS`.
3. Il monte ces certificats dans le conteneur Prometheus à l’emplacement `/etc/prom-certs/`.
4. 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é.

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

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

<div id="prerequisites">
  ## Prérequis
</div>

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

<div id="step-1-provision-azure-resources">
  ## Étape 1 : Créer les ressources Azure
</div>

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

1. **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>`.
2. **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>`.
3. **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 :

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

<div id="step-2-create-the-observability-namespace-with-istio-injection">
  ## Étape 2 : Créez l’espace de noms d’observabilité avec l’injection Istio
</div>

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

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

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

```bash theme={null}
# 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` :

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

<div id="step-3-gather-azure-monitor-workspace-ingestion-details">
  ## Étape 3 : Récupérer les détails d’ingestion d’Azure Monitor Workspace
</div>

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

```bash theme={null}
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 :

```bash theme={null}
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 :

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

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

Construisez l’URL complète de remote-write (vous l’utiliserez à l’étape 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">
  ## Étape 4 : Créer une identité managée pour Prometheus
</div>

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

```bash theme={null}
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 :

```bash theme={null}
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 :

```bash theme={null}
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 :

```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">
  ## Étape 5 : Installer le Prometheus Operator
</div>

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 :

```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">
  ## Étape 6 : Appliquer les manifestes Prometheus
</div>

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 :

```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` et association pour la découverte des cibles :

```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`** : instance de Prometheus avec injection de sidecar Istio, export de certificats et remote-write vers 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>
  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+.
</Note>

Appliquez les trois :

```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">
  ### Configurer le ServiceMonitor de Vantage
</div>

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 :

```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 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](/fr/vantage/self-hosted/v3.0/monitoring/prometheus#istio-mtls).

<div id="step-7-verify">
  ## Étape 7 : Vérifier
</div>

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

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

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

```bash theme={null}
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 :

```bash theme={null}
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.

<div id="operational-notes">
  ## Notes opérationnelles
</div>

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