La taille des octets facturés par l'écriture à distance de Prometheus peut être supérieure à celle des octets envoyés à New Relic. Pour vous assurer de ne pas être surpris par la différence, nous vous recommandons de vérifier comment la compression des données affecte les octets facturés.
Comprendre la compression des données et la facturation
Les données d'écriture à distance Prometheus sont envoyées à New Relic compressées pour une transmission plus rapide et sans perte. Une fois ingérées, ces données sont décompressées et décorées afin qu'elles puissent être correctement utilisées avec les fonctionnalités de New Relic, telles que la synthèse d'entités. Bien que vous deviez vous attendre à une différence entre le débit d'octets compressés et non compressés, la différence potentielle pour les données d'écriture à distance Prometheus est importante en raison du modèle de facturation de New Relic.
Vous êtes facturé en fonction de l'effort de calcul nécessaire pour ingérer vos données, ainsi que de la taille des données stockées dans New Relic. Le processus de décompression et les transformations de données peuvent entraîner que les octets finaux non compressés stockés soient environ 15 fois plus grands que leur équivalent compressé.
Par exemple, sur la base d'un échantillon de données de séries chronologiques que nous avons recueillies lors de la simulation du trafic dans le monde réel, vous pourriez voir quelque chose comme ceci :
~124 GB/day compressed data sent = ~1.86TB uncompressed data storedVous trouverez ci-dessous une simulation des changements de débit d'octets lorsque les données en lecture-écriture de Prometheus se déplacent dans notre système. Dans ce cas, les métriques ont été générées en ingérant le scrape d'écriture distant d'un serveur Prometheus local d'un exportateur de nœuds local.
Notez comment le débit d'octets envoyés par Prometheus correspond étroitement au nombre d'octets compressés en écriture à distance que nous enregistrons de notre côté juste avant de décompresser le(s) point(s) de données. Nous pouvons attribuer la variance accrue du taux d'octets compressés en écriture à distance à la nature du traitement des données via nos systèmes distribués :
Comme les points de données ne sont pas compressés, le facteur d'expansion 5 à 10x se reflète dans la différence entre le débit d'octets de données compressées en écriture à distance et le débit d'octets non compressés en écriture à distance, qui sont des mesures prises juste avant et après la décompression des données.
Enfin, à mesure que les données sont transformées et que des enrichissements sont effectués, la différence entre les octets non compressés d'écriture à distance et le bytecountestimate() peut être observée ci-dessous. Le bytecountestimate() répertorié est une mesure du nombre d'octets de l'état final des données avant d'être stockées.
Pour donner une meilleure compréhension des transformations/ajouts de données possibles que les données en lecture-écriture Prometheus peuvent subir, voici une comparaison de la métrique prometheus_remote_storage_bytes_total , une mesure signalée par le serveur Prometheus.
Le premier est une représentation telle que donnée par Prometheus, et le second est la contrepartie de la requête NRQL.
Représentation du serveur Prometheus :
"prometheus_remote_storage_bytes_total" { "instance=""localhost:9090" "job=""prometheus" "remote_name=""5dfb33" "url=""https://staging-metric-api.newrelic.com/prometheus/v1/write?prometheus_server=foobarbaz"}23051Représentation de requête NRQL
{ "endTimestamp": 1631305327668, "instance": "localhost:9090", "instrumentation.name": "remote-write", "instrumentation.provider": "prometheus", "instrumentation.source": "foobarbaz", "instrumentation.version": "0.0.2", "job": "prometheus", "metricName": "prometheus_remote_storage_bytes_total", "newrelic.source": "prometheusAPI", "prometheus_remote_storage_bytes_total": { "type": "count", "count": 23051 }, "prometheus_server": "foobarbaz", "remote_name": "5dfb33", "timestamp": 1631305312668, "url": "https://staging-metric-api.newrelic.com/prometheus/v1/write?prometheus_server=foobarbaz"}Conseil
L'exemple ci-dessus est une comparaison simplifiée destinée à illustrer les concepts sous-jacents, il fait donc un usage plus léger que la moyenne de l'étiquetage et des métriques en vedette. Les versions du monde réel seront un peu différentes car elles sont plus complexes.
Utilisez NRQL pour interroger le nombre de vos données
Vérifiez la requête NRQL suivante pour collecter des informations sur le nombre d’octets.
Pour afficher le nombre estimé d'octets stockés sur New Relic :
FROM Metric SELECT rate(bytecountestimate(), 1 minute) AS 'bytecountestimate()' WHERE prometheus_server = INSERT_PROMETHEUS_SERVER_NAME SINCE 1 hour ago TIMESERIES AUTOPour monitorer les octets Prometheus envoyés à New Relic :
FROM Metric SELECT rate(sum(prometheus_remote_storage_bytes_total), 1 minute) AS 'Prometheus sent bytes rate' WHERE prometheus_server = INSERT_PROMETHEUS_SERVER_NAME SINCE 1 hour ago TIMESERIES AUTORéférences externes
Voici quelques liens externes vers les documents Prometheus et GitHub qui clarifient la compression et l'encodage.
Prometheus fait référence à la compression Snappy utilisée dans l'encodage: les protocoles de lecture et d'écriture utilisent tous deux un encodage de tampon de protocole compressé Snappy sur HTTP. Les protocoles ne sont pas encore considérés comme des API stables et peuvent changer pour utiliser gRPC sur HTTP/2 à l'avenir, lorsque tous les sauts entre Prometheus et le stockage distant pourront être supposés en toute sécurité prendre en charge HTTP/2.