Supervision avec Prometheus - ABBYY Documentation

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 pour un déploiement en service géré reposant sur la même approche.

Les exemples utilisent 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.

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.

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), activez la fonctionnalité otlp-write-receiver et passez l’argument --web.enable-otlp-receiver à l’instance Prometheus. Ajoutez le dépôt Helm :

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Créez un fichier de valeurs (observability-values.yaml) :

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 :

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 :

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 :

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 :

Activez l’injection Linkerd pour l’espace de noms observability afin que Prometheus participe au maillage.
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 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 :

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

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 :

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. Ensuite, installez le chart vantage-selfhosted afin que le(s) ServiceMonitor soient configuré(s) pour utiliser ces certificats :

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

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 :

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 :

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

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

http://observability-kube-prometheus-prometheus.observability:9090/api/v1/otlp/v1/metrics

​Comment Vantage publie les métriques

​Prérequis

​Configurer Prometheus

​Configurer Prometheus pour collecter les métriques de Vantage

​mTLS Linkerd

​Istio mTLS

​Vérifiez que les métriques remontent

​Accéder à Grafana

​Métriques disponibles

​Ingestion OTLP

Comment Vantage publie les métriques

Prérequis

Configurer Prometheus

Configurer Prometheus pour collecter les métriques de Vantage

mTLS Linkerd

Istio mTLS

Vérifiez que les métriques remontent

Accéder à Grafana

Métriques disponibles

Ingestion OTLP