Introduction
Dans le monde de l'observabilité, Prometheus et OpenTelemetry sont deux solutions populaires pour la collecte et la transformation des métriques. Bien qu'ils partagent certains points communs, ils présentent également des différences significatives qui peuvent influencer votre choix en fonction de vos besoins spécifiques.
Prometheus : un outil d'observabilité complet
Prometheus est un outil d'observabilité qui inclut la collecte, le stockage et la requête des métriques. Il utilise un modèle de métriques conçu pour répondre à ses propres besoins, ce qui en fait une solution robuste et éprouvée pour la surveillance des infrastructures.
Collecte et stockage des métriques
Prometheus collecte les métriques via un système de scraping simple qui extrait les données des hôtes. Ces données sont ensuite stockées dans la base de données Prometheus, où elles peuvent être interrogées à l'aide du langage de requête PromQL.
Bien que Prometheus puisse gérer une grande quantité de données, il n'est pas conçu pour être une solution de stockage à long terme.
Les données sont souvent transférées vers une autre solution de stockage après un certain temps (comme par exemple Thanos), mais peuvent toujours être lues via PromQL.
Types de métriques
Prometheus prend en charge quatre types principaux de métriques : les compteurs, les jauges, les résumés et les histogrammes. Ces types de métriques sont bien adaptés pour une variété de cas d'utilisation dans la surveillance des infrastructures.
OpenTelemetry : Flexibilité et intégration
OpenTelemetry, en revanche, se concentre sur la collecte des métriques, des traces et des logs à l'aide d'une API consolidée. Il ne fournit pas de solution de stockage ou de requête, ce qui lui permet de se concentrer sur la flexibilité et l'intégration avec d'autres systèmes.
Collecte et transformation des métriques
OpenTelemetry collecte les métriques via des mécanismes de push ou de pull, les transforme potentiellement, puis les envoie à d'autres systèmes pour le stockage ou la requête (d'ailleurs, il est parfaitement possible que les métriques collectées via OpenTelemetry soient au final stockées dans une base Prometheus !).
En se concentrant uniquement sur les parties de l'observabilité avec lesquelles les applications interagissent, OpenTelemetry découple la création des signaux des préoccupations opérationnelles liées à leur stockage et leur requête.
Types de métriques
OpenTelemetry prend en charge cinq types de métriques : les sommes, les jauges, les résumés, les histogrammes et les histogrammes exponentiels. Ces types de métriques offrent une plus grande flexibilité et des capacités supplémentaires par rapport à Prometheus.
Comparaison des métriques
Types de métriques et représentation
OpenTelemetry permet la représentation de tous les types de métriques de Prometheus, mais Prometheus ne peut pas représenter certaines configurations de métriques d'OpenTelemetry, telles que les représentations delta et les histogrammes exponentiels. En d'autres termes, les métriques de Prometheus sont un sous-ensemble strict des métriques d'OpenTelemetry.
Instrumentation automatique
Les deux systèmes permettent l'instrumentation du code via un SDK, mais OpenTelemetry se distingue par son support de l'instrumentation automatique, qui n'ajoute aucun code aux applications lorsque cela est possible.
Choisir entre Prometheus et OpenTelemetry
Questions clés
Si vous ne disposez pas déjà d'un investissement dans l'une des deux technologies, le choix entre Prometheus et OpenTelemetry peut se résumer à quatre questions :
- Prévoyez-vous de capturer des traces, des logs et des métriques ?
Si oui, OpenTelemetry vous permettra d'utiliser les mêmes bibliothèques pour instrumenter les trois types de signaux, ce qui constitue un avantage significatif. - Valorisez-vous la stabilité et les systèmes éprouvés ?
Si oui, Prometheus pourrait être la réponse correcte pour quelques années encore, le temps qu'OpenTelemetry gagne en maturité. - Souhaitez-vous utiliser un pipeline de routage et de transformation multi-étapes ?
Si oui, OpenTelemetry pourrait valoir le coup d'œil. - Voulez-vous rester aussi flexible que possible ?
Alors OpenTelemetry est fait pour vous, car il n'implémente aucun stockage ou requête, vous offrant une flexibilité maximale.
Utilisation mixte
La plupart des organisations utiliseront probablement les deux standards : Prometheus pour la surveillance de l'infrastructure et OpenTelemetry pour les services développés. De nombreux ingénieurs utiliseront Prometheus comme backend pour stocker à la fois les métriques de Prometheus et d'OpenTelemetry, en veillant à ce que les métriques d'OpenTelemetry soient compatibles avec Prometheus.
Conversion entre Prometheus et OpenTelemetry
OpenTelemetry fournit l'OpenTelemetry Collector, qui peut aider à passer d'un standard à l'autre, y compris la conversion entre types de métriques si nécessaire. Le Collector est modulaire, permettant d'activer des composants récepteurs et exportateurs à l'aide d'un fichier de configuration au moment de l'exécution.
Exemple de configuration
Voici un exemple de fichier de configuration pour le Collector :
receivers:
prometheus:
config:
scrape_configs:
- job_name: demo
scrape_interval: 15s
static_configs:
- targets: ['localhost:9090']
exporters:
prometheus:
endpoint: "0.0.0.0:1234"
logging:
loglevel: debug
service:
telemetry:
logs:
level: debug
pipelines:
metrics:
receivers: [prometheus]
processors: []
exporters: [logging, prometheus]
Pour démarrer le Collector avec cette configuration, utilisez la commande suivante :
otelcol --config config.yaml
Le Collector utilisera le récepteur Prometheus pour essayer de scraper un service Prometheus à l'adresse http://localhost:9100. Les données seront disponibles à partir du point d'exportation Prometheus que le Collector exécutera sur http://localhost:1234.
Conclusion
Prometheus et OpenTelemetry sont deux outils puissants pour la collecte et la transformation des métriques, chacun ayant ses propres avantages et inconvénients. Le choix entre les deux dépendra de vos besoins spécifiques en matière de surveillance, de flexibilité et d'intégration. En fin de compte, une utilisation mixte des deux standards pourrait offrir le meilleur des deux mondes, en tirant parti de la maturité de Prometheus et de la flexibilité d'OpenTelemetry.
Pour en savoir plus sur l'utilisation de Prometheus, consultez notre autre article sur Prometheus et SpringBoot !
