j’ai achetĂ© un PC...
Grafana Stack 📈 2. Collecte des mĂ©triques avec OpenTelemetry

Grafana Stack 📈 2. Collecte des mĂ©triques avec OpenTelemetry

⏱ 6 mn

Dans l’article prĂ©cĂ©dent , nous avons activĂ© l’observabilitĂ© de Spring Boot 3 et vu comment ajouter des mĂ©triques personnalisĂ©es Ă  une application.

Maintenant, il est nécessaire de collecter ces métriques et de les stocker avant de pouvoir les afficher dans Grafana.

Les autres articles de la série :

  1. Observabilité avec Spring Boot 3
  2. Collecte des métriques avec OpenTelemetry
  3. Collecte des logs avec OpenTelemetry

OpenTelemetry

Liste des cibles de prometheus
OpenTelemetry est un collecteur de … tĂ©lĂ©mĂ©trie. Cela inclut les mĂ©triques, les logs et les traces. Mais OpenTelemetry, c’est aussi une communautĂ© qui essaye de dĂ©crire une spĂ©cification pour dĂ©finir la mĂ©trologie. Par exemple, la spĂ©cification propose des conventions pour les noms de mĂ©triques.

Prérequis au déploiement

Docker Compose

L’application que l’on a prise comme exemple dans l’article prĂ©cĂ©dent est dĂ©ployĂ©e via docker-compose . Un script Ansible automatise le dĂ©ploiement de la configuration du service sur le serveur et il suffit de faire un dc up -d pour dĂ©marrer l’application et tous les services dĂ©pendants en production.

On va rester sur la mĂȘme techno pour dĂ©ployer la collecte des tĂ©lĂ©mĂ©tries.

Service prometheus

Comme expliquĂ© dans l’article prĂ©cĂ©dent, les mĂ©triques seront stockĂ©es par un serveur Prometheus . Il faut donc commencer par en dĂ©ployer un. Rien de compliquĂ© pour ce composant, voilĂ  la dĂ©claration du service dans le compose.

services:
  prometheus:
    image: prom/prometheus:v2.44.0
    restart: unless-stopped
    command:
    - --config.file=/etc/prometheus/prometheus.yml
    - --storage.tsdb.path=/prometheus
    # - --storage.tsdb.retention.time=90d
    - --web.console.libraries=/usr/share/prometheus/console_libraries
    - --web.console.templates=/usr/share/prometheus/consoles
    volumes:
    - /opt/bw/prometheus/:/etc/prometheus/
    - prometheus_data:/prometheus
    networks:
      metrics: {}

volumes:
  prometheus_data: {}

networks:
  metrics: {}

Par dĂ©faut Prometheus garde les donnĂ©es pendant 15 jours. Il peut ĂȘtre intĂ©ressant d’étendre la durĂ©e de rĂ©tention Ă  90 jours ou plus. Pour cela ajouter l’options storage.tsdb.retention.time= Ă  la ligne de commande.

Prometheus se configure au travers d’un unique fichier prometheus.yml passĂ© en paramĂštre de la ligne de commande dans le dockerfile ci-dessus. Les paramĂštres de configuration sont dĂ©taillĂ©s dans la documentation , voilĂ  le fichier utilisĂ© pour notre application.

---

global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.
  evaluation_interval: 15s # By default, scrape targets every 15 seconds.
  # scrape_timeout is set to the global default (10s).

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:

  # Le job pour se collecter lui mĂȘme (optionel)
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Le job de collecte OpenTelemetry
  - job_name: 'otel-exporter'
    scrape_interval: 15s
    file_sd_configs:
      - files:
        - 'targets/otel_targets.yml'

enfin, targets/otel_targets.yml.

test

---

- targets:
  - 'opentelemetry:9091'

L’intĂ©rĂȘt de passer par file_sd_configs est que Prometheus va pouvoir faire du hot reload quand le fichier de cibles sera mis Ă  jour. Il ne sera pas nĂ©cessaire de redĂ©marrer le serveur pour ajouter une cible.

DĂ©tail important, le service prometheus est placĂ© dans un rĂ©seau metrics, ce qui l’isolera du rĂ©seau sur lequel l’application est placĂ©e. C’est le service opentelemetry qui fera le lien entre les deux sous-rĂ©seaux de docker.

Service OpenTelemetry

Il Ă©tait possible et sĂ»rement plus simple de configurer le prometheus pour aller scraper directement l’application. Mais c’est aussi beaucoup moins Ă©volutif. En effet, dans le cas d’infrastructure rĂ©seau plus complexe, un collecteur OpenTelemetry peu servir de collecteur intermĂ©diaire. De plus OTEL vient avec toute une panoplie de fonctionnalitĂ© pour la collecte et le traitement des mĂ©triques qui vont grandement simplifier certaines Ă©tapes lorsque l’on ajoutera les logs et les traces.

Liste des cibles de prometheus
L’infrastructure une fois le prometheus dĂ©ployĂ©

La version “standard” d’OpenTelemetry ne contient que les fonctionnalitĂ©s de base. Pour mettre en place toute une stack de mĂ©trologie, il sera plus intĂ©ressant d’utiliser la distribution contrib qui vient avec un ensemble de plugins permettant de s’interfacer avec Ă  peu prĂšs tout.

https://github.com/open-telemetry/opentelemetry-collector-contrib

Configuration OpenTelemetry

OTEL se configure en 4 Ă©tapes :

  • Les receveurs, qui rĂ©cupĂšrent la mĂ©trologie
  • Les processeurs, qui traitent et transforment les Ă©vĂ©nements
  • Les exporteurs, qui renvoient les Ă©vĂ©nements vers leurs points de stockage
  • Le service, qui relie et ordonne les prĂ©cĂ©dentes configurations
receivers:
  prometheus/myapp:
    config:
      scrape_configs:
        - job_name: 'otel-collector'
          scrape_interval: 15s
          metrics_path: '/actuator/prometheus'
        #   Si vous avez sĂ©curisĂ© la route comme prĂ©cognisĂ© dans l’article prĂ©cĂ©dent
        #   basic_auth:
        #     username: "otel_collector"
        #     password: "otel_password"
          static_configs:
            - targets: [myappservice:8081]
              labels:
                platform: 'prod'

On utilise le Prometheus Receiver qui va scraper la route de mĂ©trique de notre application au format prometheus. La configuration se fait exactement de la mĂȘme façon que pour un scraper prometheus normal.

À noter que Spring possĂšde un exporteur vers OTEL et serait donc capable d’envoyer directement la tĂ©lĂ©mĂ©trie vers ce dernier. J’aime moins cette approche, car elle rend l’application consciente de l’existence du collecteur. Changer de collecteur demanderait de changer la configuration de l’application et crĂ©e une sorte de dĂ©pendance.

processors:
  batch:
    send_batch_size: 10000
    send_batch_max_size: 11000
    timeout: 10s

Parmi les bonnes pratiques OTEL, il est conseillé de toujours utiliser le Batch Processor , il va permettre de batcher les envoies de métriques et autres pour ne pas multiplier le nombre de connexions au serveur de destination.

exporters:
  prometheus:
    endpoint: '0.0.0.0:9091'
    send_timestamps: true
    enable_open_metrics: true

Le Prometheus Exporter va mettre Ă  disposition d’un scraper les mĂ©triques rĂ©cupĂ©rĂ©es au format prometheus.

Le endpoint permet de dĂ©terminer l’interface rĂ©seau utilisĂ© pour dĂ©ployer la route de collecte et le port. 0.0.0.0 dĂ©ploie la route de collecte sur toutes les interfaces rĂ©seaux.

service:
  pipelines:
    metrics:
      receivers: [prometheus/myapp]
      processors: [batch]
      exporters: [prometheus]

On dĂ©clare le pipeline pour les mĂ©triques en assemblant toutes les configurations que l’on vient de faire.

Service compose

services:
  opentelemetry:
    image: otel/opentelemetry-collector-contrib:0.77.0
    user: 0:0
    command:
    - --config=/etc/otel/receivers.yaml
    - --config=/etc/otel/processors.yaml
    - --config=/etc/otel/exporters.yaml
    - --config=/etc/otel/service.yaml
    logging:
      driver: local
      options:
        max-size: 10m
    volumes:
    - /opt/opentelemetry:/etc/otel:ro
    networks:
      myappnet: {}
      metrics: {}

networks:
  metrics: {}
  myappnet: {}

On utilise l’image opentelemetry-collector-contrib qui contient tous les plugins supplĂ©mentaires dont on a besoin.

Dans la command on inclut les fichiers de configuration que l’on vient de crĂ©er.

On place le service dans le rĂ©seau metrics pour que le service prometheus le voit et dans le rĂ©seau myappnet pour qu’il puisse se connecter Ă  myappservice:8081 que l’on a dĂ©clarĂ© dans le scraper.

On monte un volume en lecture seule pour accéder aux fichiers de configurations.

Image contrib pour open telemetry
L’ensemble des fichiers de configuration est disponible sur github .

Une fois la configuration en place, un dc up -d devrait démarrer tous les services et commencer la collecte des métriques.

VĂ©rifications et debugging

À ce stade, Ă©tant donnĂ© qu’il n’y a pas encore d’interface pour visualiser les mĂ©triques, il n’est pas facile de voir ce qu’il se passe sous le capot et de comprendre ce qu’il se passe quand un problĂšme survient.

Interface Prometheus

Prometheus possÚde une interface capable de visualiser certains éléments comme les valeurs des métriques recueilli ou la liste des cibles de scraping.

Liste des cibles de prometheus
Liste des cibles de prometheus

Open Telemetry en verbose

Autre astuce qui peut servir, mettre OpenTelemetry en verbose. Cela se fait grĂące au Logging Exporter .

exporters:
  logging:
    verbosity: detailed

En l’ajoutant au pipeline, Open Telemetry va cracher beaucoup de logs, vraiment beaucoup. Chaque mĂ©trique y sera dĂ©taillĂ©e. C’est trĂšs pratique mais, on se noie rapidement dans la masse de logs qui sortent.

Conclusion

Nous avons mis en place un collecteur et de quoi stocker les métriques de notre application. Grùce à Open Telemetry les métriques de notre application sont bien au chaud dans Prometheus.

Dans l’article suivant, nous ferons la mĂȘme chose avec les logs de l’application.


Grafana Stack 📈 2. Collecte des mĂ©triques avec OpenTelemetry est paru le