> ## 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 avec Prometheus
> Collectez les métriques de Vantage 3.0 auto-hébergé avec Prometheus sur les maillages de services Istio et Linkerd.
Ce guide explique comment configurer un Prometheus autogéré pour collecter les métriques de Vantage 3.0 auto-hébergé dans n’importe quel environnement. Sur AKS, où Azure Monitor Workspace et Azure Managed Grafana sont disponibles, consultez [Azure Managed Monitoring](/fr/vantage/self-hosted/v3.0/monitoring/azure-managed) pour un déploiement en service géré reposant sur la même approche.
Les exemples utilisent [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack), mais la méthode est générique et s’applique à tout déploiement Prometheus. Pour connaître les contraintes propres au maillage, consultez [Vue d’ensemble de la supervision](/fr/vantage/self-hosted/v3.0/monitoring/overview).
## Comment Vantage publie les métriques
Les pods d’application Vantage sont instrumentés avec des SDK OpenTelemetry et exposent des métriques au format Prometheus sur `/metrics-text`, sur le port 8080 du conteneur. Les services qui exposent ce point de terminaison portent le label `abbyy.platform.metrics.text.endpoint: "1"` et mettent en correspondance un port de service (généralement 80) avec le port du conteneur portant le nom `http`. Prometheus découvre ces services et en collecte les métriques via un `ServiceMonitor` ; aucun OpenTelemetry Collector distinct n’est requis pour la collecte des métriques.
Pour une vue complète du concept et des contraintes du maillage de services, voir [Vue d’ensemble de la supervision](/fr/vantage/self-hosted/v3.0/monitoring/overview).
## Prérequis
* Une installation Vantage opérationnelle (opérateur et charges de travail déployés).
* Helm 3.
* Un accès `kubectl` au cluster.
* Lorsque KEDA est activé, une instance Prometheus joignable à l’adresse `prometheus-operated.observability.svc.cluster.local:9090`.
## Configurer Prometheus
Si vous prévoyez d’ingérer des métriques OTLP (voir [ingestion OTLP](#otlp-ingestion)), activez la fonctionnalité `otlp-write-receiver` et passez l’argument `--web.enable-otlp-receiver` à l’instance Prometheus.
Ajoutez le dépôt Helm :
```bash theme={null}
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
```
Créez un fichier de valeurs (`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" # À remplacer en production
persistence:
enabled: true
size: 10Gi
alertmanager:
enabled: false
nodeExporter:
enabled: true
kube-state-metrics:
enabled: true
# Kubernetes managé (ex. AKS, EKS, GKE) n'expose pas le plan de contrôle.
# Désactiver ces options pour éviter les erreurs de collecte.
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
```
Vérifiez que les pods sont bien démarrés :
```bash theme={null}
kubectl get pods -n observability
```
Vous devriez voir Prometheus, Grafana, l’operator, kube-state-metrics et les pods node-exporter en cours d’exécution. Node-exporter s’exécute sous forme de DaemonSet ; il est normal que des pods soient en attente si le nombre de nœuds est encore en cours d’augmentation.
## Configurer Prometheus pour collecter les métriques de Vantage
Le chart `vantage-selfhosted` peut créer les objets `ServiceMonitor` nécessaires pour surveiller Vantage :
```bash theme={null}
helm upgrade --install abbyy-vantage \
# ...
--set observability.prometheus.serviceMonitor.create=true
```
Consultez la documentation du chart pour connaître les autres options.
La clé `observability` se trouve au niveau racine et ne doit pas être placée sous `vantage`.
## mTLS Linkerd
Avec la politique permissive par défaut de Linkerd, Prometheus peut normalement collecter les métriques des points de terminaison Vantage via le proxy Linkerd en clair. Installez Prometheus dans l’espace de noms `observability`, activez le `ServiceMonitor` de Vantage et vérifiez que chaque cible Vantage est `UP`.
Si une politique d’autorisation stricte de Linkerd bloque la collecte, utilisez l’une des approches suivantes :
1. Activez l’injection Linkerd pour l’espace de noms `observability` afin que Prometheus participe au maillage.
2. Configurez `observability.prometheus.serviceMonitor.scheme: https` ainsi qu’un `tlsConfig` faisant référence aux certificats clients mis à la disposition de Prometheus par votre configuration Linkerd.
N’activez pas KEDA tant que Prometheus ne renvoie pas de valeurs à jour pour les métriques Vantage utilisées par les ressources `ScaledObject`. Voir [Autoscaling avec KEDA](/fr/vantage/self-hosted/v3.0/performance/autoscaling) pour les requêtes d’inspection et les vérifications de disponibilité.
## Istio mTLS
Lorsque Vantage est déployé dans un maillage Istio avec mTLS en mode STRICT (par défaut lorsque `ingress.enabled` est `true` et `ingress.type` est `istio`), Prometheus et le `ServiceMonitor` doivent être configurés pour collecter les métriques des points de terminaison via mTLS, car Prometheus utilise directement les adresses IP des pods plutôt que le nom du service.
Configurez le ou les pods Prometheus avec les annotations suivantes :
```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"}]'
```
et les `volume` et `volumeMount` suivants (les noms et les chemins sont personnalisables ; les exemples ci-dessous les utilisent) :
```yaml theme={null}
volumes:
- name: istio-certs
emptyDir:
medium: Memory
volumeMounts:
- name: istio-certs
mountPath: /etc/prom-certs/
readOnly: true
```
Avec kube-prometheus-stack, cela peut se faire avec les valeurs suivantes :
```yaml theme={null}
prometheus:
prometheusSpec:
podMetadata:
annotations:
# forcer Istio à générer des certificats dans un répertoire de volume local
"proxy.istio.io/config": |
proxyMetadata:
OUTPUT_CERTS: /etc/istio-output-certs
"sidecar.istio.io/userVolumeMount": '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'
# volume partagé dans lequel Istio écrira les certificats
volumes:
- name: istio-certs
emptyDir: {}
volumeMounts:
- name: istio-certs
mountPath: /etc/prom-certs
```
Vous pouvez également consulter la [documentation officielle d’Istio](https://istio.io/latest/docs/ops/integrations/prometheus/#tls-settings).
Ensuite, installez le chart `vantage-selfhosted` afin que le(s) `ServiceMonitor` soient configuré(s) pour utiliser ces certificats :
```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, donc la vérification du certificat du pod cible est ignorée
```
## Vérifiez que les métriques remontent
Effectuez une redirection de port vers l’UI de Prometheus :
```bash theme={null}
kubectl port-forward -n observability svc/observability-kube-prometheus-prometheus 9090:9090
```
Vérifiez que les cibles Vantage sont détectées et opérationnelles :
```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})'
```
Interrogez une métrique de l’application Vantage :
```bash theme={null}
curl -s "http://localhost:9090/api/v1/query?query=process_cpu_count" \
| jq '.data.result | length'
```
Un résultat non nul confirme que les métriques sont bien collectées. Vous pouvez également consulter les cibles à l’adresse `http://localhost:9090/targets` pour voir le statut de collecte de chacune.
## Accéder à Grafana
```bash theme={null}
kubectl port-forward -n observability svc/observability-grafana 3000:80
```
Ouvrez `http://localhost:3000`. Les identifiants par défaut sont `admin` / le mot de passe défini dans le fichier de valeurs. Prometheus est préconfiguré en tant que source de données.
## Métriques disponibles
Les applications Vantage exposent, via le SDK OpenTelemetry, des métriques de processus, de client/serveur HTTP et de la plateforme ABBYY, toutes associées à `service`, `pod`, `namespace` et `otel_scope_name`. Voir [Métriques disponibles](/fr/vantage/self-hosted/v3.0/monitoring/overview#available-metrics) pour consulter le catalogue complet.
## Ingestion OTLP
L’ingestion OTLP fonctionne en mode push et est indépendante du flow `ServiceMonitor` ci-dessus, qui repose sur le scrape. Utilisez-la uniquement pour les services qui envoient des métriques OpenTelemetry au lieu d’exposer un point de terminaison de scrape.
Lorsque Prometheus est configuré avec le récepteur OTLP activé (`--web.enable-otlp-receiver`), tout service qui envoie des métriques OTLP via HTTP peut les envoyer à :
```text theme={null}
http://observability-kube-prometheus-prometheus.observability:9090/api/v1/otlp/v1/metrics
```