Prometheus: Stockage à distance

Y a-t-il quelqu'un qui envisage de travailler là-dessus ? Le travail effectué dans la branche opentsdb-integration est-il toujours valide ou le reste de la base de code a-t-il dépassé cela?

La branche opentsdb-integration est en effet complètement obsolète (utilisant toujours l'ancien backend de stockage, etc.). Personnellement, je suis un grand fan de l'intégration d'OpenTSDB, mais là où je travaille, il n'y a pas de besoin suffisamment urgent pour justifier une priorité élevée de ma part...

Pour être clair, l'"intégration opensdb" obsolète n'était destinée qu'aux
prise en charge de la preuve de concept _read-back_ (interrogation d'OpenTSDB via Prometheus).

_Writing_ into OpenTSDB devrait être supporté expérimentalement dans master, mais
la dernière fois que nous l'avons essayé, c'était il y a un an sur un OpenTSDB à nœud unique.

Vous avez initialement demandé sur https://github.com/prometheus/prometheus/issues/10 :

"J'ai ajouté l'indicateur de ligne de commande storage.remote.url, mais pour autant que je sache
Prometheus n'essaie pas d'y stocker des métriques."

Quelques questions :

• avez-vous activé l'option OpenTSDB "tsd.core.auto_create_metrics" ?
  Sinon, OpenTSDB ne créera pas automatiquement de métriques pour vous, car l'option est
  faux par défaut. Voir
  http://opensdb.net/docs/build/html/user_guide/configuration.html
• si vous exécutez Prometheus avec -logtostderr, voyez-vous un journal pertinent
  sortir? S'il y a une erreur lors de l'envoi d'échantillons à TSDB, elle doit être enregistrée
  (glog.Warningf("erreur lors de l'envoi de %d échantillons à TSDB : %s", len(s), err))
• Prometheus exporte également lui-même des métriques sur l'envoi à OpenTSDB. Au
  /metrics de votre serveur Prometheus, vous devriez trouver les métriques du compteur
  "prometheus_remote_storage_sent_errors_total" et
  "prometheus_remote_storage_sent_samples_total". Que disent ceux-ci ?

Acclamations,
Jules

Le jeu. 5 février 2015 à 9h22, Björn Rabenstein [email protected]
a écrit:

La branche opentsdb-integration est en effet complètement obsolète (utilisant toujours
l'ancien backend de stockage, etc.). Personnellement, je suis un grand fan de l'OpenTSDB
l'intégration, mais là où je travaille, il n'y a pas une exigence suffisamment urgente pour
justifier une haute priorité de mon côté...

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -73010313
.

Je ne peux pas assez +1

InfluxDB est-il sur les cartes de quelque façon que ce soit ? :)

Radio Erevan : "En principe oui." (Veuillez pardonner cette digression d'Europe de l'Est... ;)

:D C'était un peu avant mon heure ;)

Voir aussi : https://twitter.com/juliusvolz/status/569509228462931968

Nous attendons juste InfluxDB 0.9.0, qui a un nouveau modèle de données qui
devrait être plus compatible avec celui de Prometheus.

Le jeu. 5 mars 2015 à 10h31, Michal Witkowski [email protected]
a écrit:

:D C'était un peu avant mon heure ;)

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -77332742
.

Nous attendons juste InfluxDB 0.9.0, qui a un nouveau modèle de données qui
devrait être plus compatible avec celui de Prometheus.

Puis-je dire génial plus d'une fois ? Impressionnant!

Malheureusement, @juliusv a effectué des tests avec 0.9 et InfluxDB a consommé 14 fois plus de stockage que Prometheus.

Auparavant, il s'agissait d'une surcharge de 11x, mais Prometheus a pu réduire considérablement la taille du stockage depuis lors - donc en réalité, InfluxDB s'est apparemment amélioré à cet égard.
Néanmoins, InfluxDB ne s'est pas encore avéré être la réponse finale pour le stockage à long terme.

Au moins, la prise en charge de l'écriture expérimentale est dans le maître, à partir d'aujourd'hui, donc tout le monde peut jouer avec Influxdb en recevant les métriques Prometheus. Il est fort possible que quelqu'un trouve la raison de l'explosion dans l'espace de stockage et tout sera finalement des licornes et des arcs-en-ciel...

@beorn7 c'est super. TBH Je ne suis pas préoccupé par l'espace disque, c'est la ressource la moins chère sur le cloud après tout. Sans oublier que je m'attends à conserver des données avec un très petit TTL, c'est-à-dire quelques semaines.

@pires Dans ce cas, pourquoi ne pas simplement exécuter deux Prometheis configurés de manière identique avec un disque raisonnablement volumineux ?
Quelques semaines ou mois suffisent généralement comme temps de rétention pour Prometheus. (La valeur par défaut est 15d pour une raison... :) Le seul problème est que si votre disque tombe en panne, vos données sont parties, mais pour cela, vous avez l'autre serveur.

@pires avez-vous une raison particulière de conserver les données dans une autre base de données pendant cette période ? "Quelques semaines" ne semble pas nécessiter de solution de stockage à long terme. La durée de conservation par défaut de Prometheus est de 15 jours - l'augmenter à 30 ou même 60 jours ne devrait pas être un problème.

@beorn7 @fabxc J'utilise actuellement une solution propriétaire et très spécifique qui écrit des métriques de surveillance dans InfluxDB. Cela peut éventuellement être remplacé par Prometheus.

Le fait est que j'ai des applications personnalisées qui lisent les métriques d'InfluxDB afin d'augmenter/réduire de manière réactive, qui devraient être réécrites pour être lues à partir de Prometheus à la place. Aussi, j'utilise continuous queries . Prometheus propose-t-il une telle fonctionnalité ?

http://prometheus.io/docs/querying/rules/#recording -rules sont l'équivalent des requêtes continues d'InfluxDB.

+1

:+1:

Comment le stockage à distance tel qu'il est actuellement mis en œuvre interagit-il avec PromDash ou grafana ?

J'ai un cas d'utilisation dans lequel je souhaite exécuter Prometheus dans un environnement « de type heroku », où les instances pourraient éventuellement disparaître à tout moment.

Ensuite, je configurerais un cluster influxdb traditionnel distant pour stocker les données.

Cette configuration pourrait-elle fonctionner normalement ?

Cela dépend de votre définition de "normalement", mais surtout, non.

Le stockage distant tel qu'il est est en écriture seule ; de Prometheus, vous n'obtiendrez que ce qu'il a localement.

Pour accéder à des données plus anciennes, vous devez interroger directement OpenTSDB ou InfluxDB, en utilisant leurs propres interfaces et langages de requête. Avec PromDash, vous n'avez pas de chance à cet égard ; AFAIK Grafana les connaît tous.

Vous pourriez créer vos tableaux de bord entièrement en les interrogeant et laisser Prometheus être un moteur de collecte et d'évaluation de règles, mais vous passeriez à côté de son langage de requête pour des explorations ad hoc sur des périodes prolongées.

Notez également que la prise en charge d'InfluxDB et d'OpenTSDB est quelque peu expérimentale, sous-exercée de notre côté et en évolution.

Nous lançons l'idée d'un exportateur de fichiers plats, nous pouvons donc commencer à stocker des données à long terme, puis une fois le problème d'importation en bloc terminé, nous pouvons l'utiliser https://github.com/prometheus/prometheus/issues/535. Seriez-vous ouvert à une relation de presse à ce sujet ?

Pour #535, jetez un œil à ma branche obsolète import-api , où j'ai une fois ajouté une API d'importation comme preuve de concept : https://github.com/prometheus/prometheus/commits/import-api . C'est à partir de mars, donc cela ne s'applique plus au master, mais cela montre simplement qu'en principe, l'ajout d'une telle API en utilisant les formats de transfert existants serait trivial. Nous devons juste convenir que nous voulons cela (c'est une question controversée, /cc @brian-brazil) et s'il doit utiliser le même format de transfert d'échantillon que nous utilisons pour le scraping. Le problème avec ce format de transfert est qu'il est optimisé pour le cas de plusieurs séries-un-échantillon (grattage), alors qu'avec les importations par lots, vous vous souciez souvent davantage d'importer tous les échantillons d'une série à la fois, sans avoir à répéter le nom de la métrique et étiquettes pour chaque échantillon (overhead massif). Mais peut-être que nous ne nous soucions pas de l'efficacité dans le cas (rare ?) d'importation en masse, donc le format existant pourrait convenir.

Pour la partie stockage distant, il y a eu cette discussion
https://groups.google.com/forum/#!searchin/prometheus -developers/json/prometheus-developers/QsjXwQDLHxI/Cw0YWmevAgAJ à propos du découplage du stockage distant d'une manière générique, mais certains détails n'ont pas encore été résolus. L'idée de base était que Prometheus puisse envoyer tous les échantillons dans un format bien défini (JSON, protobuf ou autre) à un point de terminaison spécifié par l'utilisateur qui pourrait ensuite en faire tout ce qu'il veut (écrire dans un fichier, l'envoyer à un autre système, etc.).

Il peut donc être acceptable d'ajouter un exportateur de fichiers plats en tant que backend de stockage à distance directement à Prometheus, ou de résoudre cette discussion ci-dessus et d'utiliser ledit format de transfert bien défini et un démon externe.

Je pense que pour le fichier plat, nous parlerions du démon externe, car ce n'est pas quelque chose que nous ne pourrons jamais lire.

Donc, plus j'y pense, ce serait bien d'avoir cette api / import-api (une donnée brute), afin que nous puissions avoir des nœuds de sauvegarde reflétant les données du prometheus principal. Seraient-ils désireux d'un PR pour cela et d'un élément correspondant à l'intérieur de prometheus pour importer les données. Vous pouvez donc avoir essentiellement des esclaves lus ?

Pour ce cas d'utilisation, nous recommandons généralement d'exécuter plusieurs serveurs Prometheus identiques. Le stockage à distance concerne les données à long terme, pas la redondance ou la mise à l'échelle.

Je pense que l'exécution de plusieurs scrapers n'est pas une bonne solution car les données ne correspondent pas, il n'y a également aucun moyen de remplir les données. Nous avons donc un problème où je dois faire tourner des nœuds redondants et il leur manque maintenant un mois de données. Si vous avez une API pour importer les données brutes, vous pouvez au moins les rattraper. La même interface peut également être utilisée pour les sauvegardes

Nous avons donc un problème où je dois faire tourner des nœuds redondants et il leur manque maintenant un mois de données. Si vous avez une API pour importer les données brutes, vous pouvez au moins les rattraper. La même interface peut également être utilisée pour les sauvegardes

C'est le cas d'utilisation pour le stockage à distance, vous extrayez les anciennes données du stockage à distance plutôt que de dépendre du fait que Prometheus soit avec état. De même, dans une telle configuration, aucune sauvegarde n'est nécessaire, car Prometheues n'a aucun état notable.

Le stockage à distance n'est toujours pas très utile car il n'y a aucun moyen de l'interroger. Il semble que vous puissiez créer une solution de stockage à long terme assez rapide avec les primitives existantes si vous autorisez les nœuds à effectuer un remplissage initial.

Le plan est d'avoir un moyen de l'interroger. Les primitives actuelles ne permettent pas un bon stockage à long terme, car vous allez être limité par la quantité de SSD que vous pouvez mettre sur un seul nœud. Quelque chose de plus groupé est requis.

Le schéma de mode de hachage existant vous permet déjà d'étendre au-delà d'un seul nœud. Si vous aviez un moyen de faire tourner un nouveau cluster lorsque vous souhaitez redimensionner et importer d'anciennes données, vous pourriez avoir une mauvaise approche de la mise à l'échelle. À l'avenir, vous pourriez ajouter des techniques de repartitionnement plus intelligentes. Je ne pense pas qu'aucune des options de stockage externe ne soit même si bonne en ce moment pour être des solutions légitimes

Le hachage sert à mettre à l'échelle l'ingestion et le traitement, pas le stockage, et s'accompagne d'une surcharge de complexité importante. Il devrait être évité à moins que vous n'ayez pas d'autre choix à cause de cela. Comme vous le constatez, vous avez une discontinuité à chaque fois que vous effectuez un upshard, et généralement vous souhaitez garder le stockage et le calcul désagrégés pour une meilleure mise à l'échelle et une meilleure efficacité.

Nous ne voulons pas avoir à implémenter un système de stockage en cluster au sein de Prometheus, car cela ajoute beaucoup de complexité et de modes de défaillance potentiels à un système de surveillance critique. Nous préférerions de loin utiliser quelque chose d'externe et les laisser résoudre ces problèmes difficiles, même si aucune des options actuelles ne semble trop bonne. Si cela ne fonctionne pas, nous pouvons envisager d'écrire le nôtre en tant que composant séparé, mais nous espérons que cela n'y arrivera pas.

Je comprends que vous voudriez un stockage à long terme. Je vous demande d'attendre que nous puissions le prendre en charge correctement, plutôt que de dépendre des utilisateurs pour pirater quelque chose d'une manière qui va à l'encontre de l'architecture globale du système et qui finit par devenir un fardeau opérationnel et de maintenance à l'avenir.

c'est bien d'avoir de grandes visions, cela ne veut pas dire que nous ne pouvons rien faire à court terme. Graphite utilise le sharding pour le stockage et les performances des requêtes. Il peut même fragmenter les requêtes entrantes et ce n'est pas un système particulièrement sophistiqué.

Bien que je convienne que le stockage à long terme et robuste doit être résolu correctement, je vois certains avantages à avoir un point de terminaison d'importation par lots indépendant de cela. C'est au moins utile pour des choses telles que les tests (lorsque vous souhaitez importer rapidement un tas de données dans Prometheus pour jouer avec ou faire des tests) ou pour le remplissage de données dans certaines situations (comme l'importation de lots de métriques générés à partir du traitement retardé du journal des événements Hadoop qui vous souhaitez établir une corrélation avec d'autres métriques).

L'inconvénient serait bien sûr que cela pourrait inciter de nombreux utilisateurs à faire la mauvaise chose (par exemple, pousser des données alors qu'ils devraient vraiment les extraire), et que toute fonctionnalité en général aggrave un produit pour tous les utilisateurs qui ne l'utilisent pas (plus complexité perçue du produit, etc.).

Vous pouvez faire en sorte que l'importation par lots soit un processus d'extraction, le nouveau prometheus secondaire (ou esclave) peut extraire les données existantes d'un autre prometheus via un point de terminaison /raw. Pas sûr que ce soit si déroutant pour les nouveaux utilisateurs car il existe d'autres fonctionnalités comme la fédération qui effectuent des tâches quelque peu similaires mais sont probablement inutilisées par 95% des utilisateurs

le remplissage de données dans certaines situations (comme l'importation de lots de métriques générés à partir du traitement retardé du journal des événements Hadoop que vous souhaitez mettre en corrélation avec d'autres métriques).

C'est le frontfilling, qui est un cas d'utilisation différent et où se situe le problème push vs pull. Le backfiling est ce dont nous parlons ici car nous insérons des données avant les données existantes, où les questions portent davantage sur les attentes de durabilité du stockage Prometheus. Le remblayage est moins problématique sur le plan conceptuel, car il s'agit principalement d'une question opérationnelle.

Si nous devions implémenter le remplissage, je pense que quelque chose de poussé aurait plus de sens car il s'agit d'une action administrative contre un serveur particulier plutôt que d'une "exposition des données à utiliser d'une manière ou d'une autre". Vous voudriez probablement également un contrôle raisonnable sur la rapidité avec laquelle cela est fait, etc. afin de ne pas interférer avec la surveillance continue.

Est-ce vraiment différent sur le plan conceptuel de votre point de terminaison / fédérer ? ce qui permet aux systèmes en aval de le gratter. Je pense juste que nous pouvons exposer toute la série temporelle avec une pagination.

Oui, /federate consiste uniquement à obtenir de nouvelles données pour fournir des agrégations de haut niveau et n'a aucune incidence sur la sémantique ou les attentes de stockage.

Ce dont vous parlez, c'est d'ajouter des données dans le temps, ce qui n'est pas pris en charge par le moteur de stockage (et pas quelque chose qui devrait même être considéré en dehors de ce cas d'utilisation exact). Cela change la position par défaut selon laquelle si un Prometheus perd ses données, en amenez-en une nouvelle et passez à autre chose.

Juste en y pensant, l'autre endroit pour lequel nous devrons avoir un remplissage est lorsque quelqu'un veut faire en sorte qu'une expression prenne effet dans le temps. Donc, indépendamment des discussions liées au stockage, nous ajouterons probablement du remplissage à un moment donné.

@brian-brasil pensez-vous à un sous-échantillonnage ou à des agrégations en arrière dans le temps

Agrégations/règles dans le temps. Le sous-échantillonnage est un non-objectif explicite, nous pensons qu'il appartient au stockage à long terme.

Dans https://github.com/prometheus/prometheus/issues/10#issuecomment -90591577 @fabxc a déclaré :

a effectué des tests avec 0.9 et InfluxDB a consommé 14 fois plus de stockage que Prometheus.

Je voulais juste souligner que le dernier InfluxDB 0.10 GA semble avoir amélioré son moteur de stockage de manière agressive. Leur article de blog déclare :

Prise en charge de centaines de milliers d'écritures par seconde et une meilleure compression de 98 %

Cela pourrait valoir la peine d'être revisité.

Avec https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ InfluxDB n'est plus sur la table.

Blueflood a-t-il un modèle de données compatible ?

Avec InfluxDB sur la table, il semble être le TSDB open source le plus prometteur, soutenu par Cassandra.

Rackspace a une assez bonne réputation pour garder les choses ouvertes.

http://blueflood.io/

Blueflood semble avoir des horodatages en millisecondes, il n'est pas clair s'il prend en charge float64 en tant que type de données (je suppose que c'est le cas), mais il n'a aucune notion d'étiquettes. Il semble avoir la bonne idée architecturale, mais ne convient pas tout à fait.

Newts est une autre option soutenue par Cassandra.

Le modèle de données est décrit sur https://github.com/OpenNMS/newts/wiki/DataModel , prend en charge les étiquettes.

Je vois un peu de controverse sur la qualité de Cassandra pour les séries chronologiques, mais quelques-uns des TSDB s'appuient dessus (KairosDB, Heroic et Newts).

Newts n'a pas vraiment de notion d'étiquettes, et je ne pense pas que le schéma de Cassandra s'adaptera bien à la quantité de données que nous traitons.

Oui, la plupart des options externes ne sont pas très bonnes ou nécessitent plus de gestion que l'investissement ne le justifie. Donc, actuellement, chez DigitalOcean, nous avons des configurations de partitions assez volumineuses avec prometheus. Nous étudions la possibilité de ne pas avoir besoin de stockage à long terme, en faisant en sorte que les instances de prometheus permettent aux données d'être sauvegardées sur d'autres nœuds. Peut-être que si vous avez un moyen de rediffuser les données. Je n'ai encore entendu personne parler d'étendre simplement les capacités existantes au lieu de les pousser vers une autre base de données, qui aura un langage de requête différent de celui de prometheus.

Votre dernière partie est plus ou moins ce vers quoi elle convergera finalement – ​​du moins dans ma tête.
Avec leurs langages de requête et modèles personnalisés, les solutions existantes ont leurs propres surcharges et limitations. Pour un chemin de lecture/écriture cohérent, il n'a pas vraiment de sens d'appliquer un mappage pour les contourner.

Ils sont pour la plupart basés sur Cassandra ou HBase de toute façon et cela pour de bonnes raisons. Nous devons trouver un bon modèle d'indexation et de stockage de blocs qui soit applicable à des backends de stockage similaires, qui pourraient alors même être choisis.

C'est facile de parler de tout ça – ça ne vaut pas grand chose sans une implémentation, ce qui prendra du temps bien sûr :)

Je vois des défis importants avec cette approche, car elle fait finalement de Prometheus un système de stockage distribué complet. Je pense que nous devons garder le stockage à long terme découplé de Prometheus lui-même, afin de ne pas menacer son objectif principal d'être un système de surveillance critique. Nous ne voudrions pas qu'un blocage ou un bogue de code dans un système aussi complexe supprime la surveillance, il est beaucoup plus facile d'obtenir des échéances correctes sur quelques appels RPC.

Je n'ai encore entendu personne parler d'étendre simplement les capacités existantes au lieu de les pousser vers une autre base de données, qui aura un langage de requête différent de celui de prometheus.

Le plan est que, quelle que soit la résolution de ce problème, vous pourrez interroger de manière transparente les anciennes données via Prometheus. Si nous voulions simplement pomper les données vers un autre système sans relecture, cela rendrait les choses beaucoup plus faciles - vous pouvez déjà le faire si vous le souhaitez.

Oui, cela en fait un système de stockage distribué complet. Et il ne devrait pas faire partie du serveur principal, bien sûr.
Ce serait son propre truc, mais qui répondrait directement à notre modèle de données et d'interrogation.

Je sais que cela a des implications difficiles. Mais ceux qui attendent un TSDB qui correspond à notre modèle sans limitations sont pires. Celles existantes semblent inadaptées. Et je ne connais personne qui travaille sur quelque chose qui le sera.

Tant qu'il y a un découplage via un système RPC générique, ça me va.

Celles existantes et stables semblent inadaptées.

Certains sont proches.

Il y a en fait plus de problèmes avec OpenTSDB que les 8 balises, il y a aussi des limites sur le nombre de valeurs qu'une étiquette peut avoir, donc nous ne pouvons même pas vraiment l'utiliser comme stockage - bien que nous ayons plusieurs utilisateurs qui prévoient d'y mettre leurs données.

Et je ne connais personne qui travaille sur quelque chose qui le sera.

:le sourire:

Il s'avère que la question n'est pas tant de savoir comment le résoudre, mais plutôt de savoir quel est votre budget.

Il y a en fait plus de problèmes avec OpenTSDB que les 8 balises

Ce n'est plus un problème.

il y a aussi des limites sur le nombre de valeurs qu'une étiquette peut avoir, donc nous ne pouvons même pas vraiment l'utiliser comme stockage - bien que nous ayons plusieurs utilisateurs qui prévoient d'y mettre leurs données.

Les limites sont assez grandes (16M) et vous pouvez les augmenter encore plus.

Je suis un comitter OpenTSDB, je serais heureux de coordonner la feuille de route pour
répondre à vos besoins si possible.

Cela me serait très bénéfique. Je crois que l'authentification et
les plugins de démarrage seront utiles pour cela. Vous pourriez avoir un démarrage TSD et
obtenir sa configuration de Prometheus. Les plugins de démarrage sont conçus pour
permettre un couplage étroit entre les systèmes.

Une autre façon de procéder serait potentiellement d'utiliser le Realtime
Plugin de publication dans OpenTSDB pour accepter les données dans OpenTSDB et publier
en plus de Prométhée. Il y a des avantages et des inconvénients à ce que je suis
Bien sur.

-Jonathan
Le 30 mars 2016 à 07h42, "Ivan Babrou" [email protected] a écrit :

Il y a en fait plus de problèmes avec OpenTSDB que les 8 balises

Ce n'est plus un problème.

il y a aussi des limites sur le nombre de valeurs qu'une étiquette peut avoir donc nous ne pouvons pas
même vraiment l'utiliser comme stockage - bien que nous ayons plusieurs utilisateurs
y mettre leurs données.

Les limites sont assez grandes (16M) et vous pouvez les augmenter encore plus.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -203414217

Éléments supplémentaires que je devrais mentionner, j'ai subi 10 millions d'écritures par
seconde à OpenTSDB, et répété cela sur une autre configuration à un autre
entreprise. HBase s'adapte très bien pour cela.

La branche 2.3.0, qui devrait avoir un RC1 n'importe quel jour a maintenant une expression
support, des choses comme Sum(), Timeshift(), etc. Cela devrait rendre l'écriture
votre support de requête plus facile.

Il existe un nouveau moteur de requête Splicer, écrit par Turn qui fournit
des améliorations significatives du temps de requête. Cela fonctionne en brisant le
requêtes entrantes en tranches et interrogeant le TSD local au
Serveur de région. Il mettra également en cache les résultats par blocs d'une heure à l'aide de Redis.
Nous l'utilisons en conjonction avec plusieurs instances tsd par Regionserver
s'exécutant dans des conteneurs Docker. Cela nous permet d'exécuter des requêtes en parallèle
blocs.

Ces nouvelles fonctionnalités et mon expérience de la mise à l'échelle d'OpenTSDB devraient aider à faire
une solution de stockage à long terme idéale, à mon avis.
Le 30 mars 2016 à 08h47, "Jonathan Creasy" [email protected] a écrit :

Je suis un comitter OpenTSDB, je serais heureux de coordonner la feuille de route pour
répondre à vos besoins si possible.

Cela me serait très bénéfique. Je crois que l'authentification et
les plugins de démarrage seront utiles pour cela. Vous pourriez avoir un démarrage TSD et
obtenir sa configuration de Prometheus. Les plugins de démarrage sont conçus pour
permettre un couplage étroit entre les systèmes.

Une autre façon de procéder serait potentiellement d'utiliser le Realtime
Plugin de publication dans OpenTSDB pour accepter les données dans OpenTSDB et publier
en plus de Prométhée. Il y a des avantages et des inconvénients à ce que je suis
Bien sur.

-Jonathan
Le 30 mars 2016 à 07h42, "Ivan Babrou" [email protected] a écrit :

Il y a en fait plus de problèmes avec OpenTSDB que les 8 balises

Ce n'est plus un problème.

il y a aussi des limites sur le nombre de valeurs qu'une étiquette peut avoir donc nous ne pouvons pas
même vraiment l'utiliser comme stockage - bien que nous ayons plusieurs utilisateurs
y mettre leurs données.

Les limites sont assez grandes (16M) et vous pouvez les augmenter encore plus.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -203414217

Ce n'est plus un problème.

C'est bon à savoir, combien de balises prend-il en charge maintenant ?

Les limites sont assez grandes (16M) et vous pouvez les augmenter encore plus.

Je peux imaginer que les utilisateurs frappent cela, principalement par accident.

Vous pouvez avoir un démarrage TSD et obtenir sa configuration auprès de Prometheus.

Cela n'a pas de sens pour moi, je m'attendrais à ce que Prometheus soit configuré pour envoyer des informations à un point de terminaison OpenTSB donné et ce serait toute la configuration requise du côté de l'écriture.

Plugin de publication en temps réel dans OpenTSDB pour accepter les données dans OpenTSDB et publier
en plus de Prométhée.

Ce n'est pas l'architecture Prometheus, Prometheus recueillerait des données et les enverrait également à OpenTSDB.

Si nous voulions extraire les données dans l'autre sens, nous écririons un exportateur OpenTSDB, similaire au fonctionnement de l'exportateur InfluxDB.

Éléments supplémentaires que je devrais mentionner, j'ai subi 10 millions d'écritures par
seconde à OpenTSDB, et répété cela sur une autre configuration à un autre
entreprise. HBase s'adapte très bien pour cela.

Pouvez-vous donner une idée du matériel impliqué?

Ceux-ci devraient faciliter l'écriture de votre support de requête.

Le support minimal dont nous avons besoin est la possibilité de spécifier un sélecteur de vecteur comme {__name__="up",job="myjob",somelabel!="foo",otherlabel~="a|b"} et de récupérer efficacement toutes les données pour toutes les séries temporelles correspondantes pour une période de temps donnée. Les requêtes peuvent ne pas inclure de nom (bien qu'elles le devraient généralement), et il n'est pas exclu qu'un seul nom ait des millions de séries temporelles à travers le temps et des milliers ne seraient pas inhabituels.

Je suis un comitter OpenTSDB, je serais heureux de coordonner la feuille de route pour
répondre à vos besoins si possible.

Il est important pour nous de stocker des float64 complets. Étant donné que vous prenez en charge les entiers 64 bits, pourrions-nous simplement les envoyer en tant que tels ou la prise en charge complète est-elle une option ?

Une prise en charge complète de l'utf-8 dans les valeurs des balises serait également utile, bien que nous ayons déjà travaillé autour de cela.

@bobrik @johann8384 Merci pour ces infos, c'est bon à savoir !

Pour tout ce qui va au-delà des cas d'utilisation petits ou jouets, nous devrons déplacer le calcul des requêtes vers le stockage à long terme (sinon, les ensembles de données qui doivent être transférés vers Prometheus deviendraient trop volumineux). Ainsi, tout stockage distant existant devrait implémenter à peu près toutes les fonctionnalités du langage de requête de Prometheus d'une manière sémantiquement compatible (même si l'agrégation est peut-être la plus importante, ce n'est pas nécessairement au nœud feuille d'une requête).

La prise en charge de la valeur float64 est donc cruciale si vous voulez atteindre ce qui précède, mais les documents OpenTSDB mentionnent en fait que cela figure sur la feuille de route, donc c'est bien : http://opensdb.net/docs/build/html/user_guide/writing .html#floating -point-values

La question de savoir si OpenTSDB sera un jour capable d'exécuter de manière compatible toutes les fonctionnalités du langage de requête de Prometheus est une autre question.

Pour tout ce qui va au-delà des cas d'utilisation petits ou jouets, nous devrons déplacer le calcul des requêtes vers le stockage à long terme (sinon, les ensembles de données qui doivent être transférés vers Prometheus deviendraient trop volumineux). Ainsi, tout stockage distant existant devrait implémenter à peu près toutes les fonctionnalités du langage de requête de Prometheus d'une manière sémantiquement compatible (même si l'agrégation est peut-être la plus importante, ce n'est pas nécessairement au nœud feuille d'une requête).

Bien que ce soit le cas idéal, je ne pense pas que ce soit réalisable. Je penserais plutôt aux lignes de Brian ci-dessus : un sélecteur de vecteur nous donne toutes les données pour l'intervalle de temps pertinent, puis l'évaluation de la requête est effectuée du côté de Prometheus. Évidemment, cela limite les requêtes à celles qui ne nécessitent pas des gigabits d'échantillons de données. Mais c'est probablement bien. La même prudence que d'habitude s'applique lorsque vous créez des règles d'enregistrement pour des requêtes coûteuses.

Ouais. Je peux nous voir repousser certaines parties de certaines requêtes à l'avenir, mais probablement uniquement vers d'autres serveurs Prometheus dans une configuration partitionnée. Plus que cela serait bien, mais je ne vois pas cela se produire dans un avenir prévisible.

Pour le stockage à long terme, la quantité de données que vous auriez besoin d'extraire dans le système de stockage lui-même est susceptible d'être un goulot d'étranglement suffisant pour empêcher une requête importante de fonctionner, avant de renvoyer le résultat à Prometheus.

Les limites sont assez grandes (16M) et vous pouvez les augmenter encore plus.

Je peux imaginer que les utilisateurs frappent cela, principalement par accident.

Je serais prêt à vivre avec cette limitation.

Pour tout ce qui va au-delà des cas d'utilisation petits ou jouets, nous devrons déplacer le calcul des requêtes vers le stockage à long terme

Si Open TSDB s'avérait finalement approprié, je doute que nous puissions obtenir la parité des fonctionnalités de requête. Si nous le faisons, ce sera toujours un facteur limitant lorsque nous souhaitons étendre notre PromQL.
Avec un chemin de lecture/écriture "générique", il utilisera de toute façon un pont. Cela pourrait être étendu pour se soucier de l'évaluation distribuée.

D'accord, si nous sommes d'accord pour ne pas prendre en charge les cas d'utilisation de grandes agrégations (mais gardez une route ouverte à l'avenir), cela rend les choses plus faciles bien sûr. Je suppose qu'il y a un argument à faire valoir pour les cas d'utilisation plus petits car généralement les gens ne se soucient pas d'autant de dimensions (comme instance ) pour les données historiques, donc vous n'opérez peut-être que sur des métriques avec beaucoup moins de séries.

(modifié le commentaire ci-dessus pour plus de clarté, pour les personnes qui ne lisent que les e-mails)

Je pense que le remblayage serait plus important avec le stockage à long terme, pour prendre en charge les agrégations nécessaires - ce n'est cependant pas une préoccupation principale (et le remblayage dans le stockage à long terme peut éviter d'en avoir besoin dans Prometheus lui-même).

Le mer. 30 mars 2016 à 9h39, Brian Brazil [email protected]
a écrit:

Ce n'est plus un problème.

C'est bon à savoir, combien de balises prend-il en charge maintenant ?

La limitation des balises était auparavant une constante codée en dur, j'ai généralement toujours
réglez-le sur 16 dans mes configurations. Ce n'est pas une valeur de configuration plutôt qu'un
constante dans le code.

Les limites sont assez grandes (16M) et vous pouvez les augmenter encore plus.

Je peux imaginer que les utilisateurs frappent cela, principalement par accident.

J'utilise une largeur UID de 4 au lieu de trois, je n'ai pas fait le calcul mais ceci
augmente considérablement ce nombre. Même sur les plus grandes configurations que j'ai
déployés, il n'y a eu que 3 ou 4 millions d'affectations UID, et ce
comprend, les métriques, les clés de balise et les valeurs de balise combinées.

Vous pouvez avoir un démarrage TSD et obtenir sa configuration auprès de Prometheus.

Cela n'a pas de sens pour moi, je m'attendrais à ce que Prometheus soit configuré pour
envoyer des informations à un point de terminaison OpenTSB donné et ce serait l'intégralité
configuration requise côté écriture.

Oui, ce serait le cas d'utilisation le plus courant, mais techniquement, vous pourriez avoir
un nœud TSD "lié" à chaque nœud prometheus, ou un ensemble de TSD par prometheus
nœud, et permettre à chaque nœud Prometheus d'avoir son propre cluster de requêtes qui
chemin. Une façon peut-être plus courante de dire ce que j'essayais de dire est que le
l'utilisation prévue des plugins de démarrage est pour la découverte de services. Quand OpenTSDB
démarre, il peut s'inscrire auprès de Curator (ZooKeeper), Consul, Etcd,
etc. Il pourrait techniquement également obtenir des paramètres de la découverte de service
comme l'emplacement du zkQuorum, les tables HBase à utiliser ou les ports
à écouter.

Plugin Realtime Publishing dans OpenTSDB pour accepter les données dans OpenTSDB et
publier
en plus de Prométhée.

Ce n'est pas l'architecture Prometheus, Prometheus recueillerait des données
et également l'envoyer à OpenTSDB.

Si nous voulions extraire des données dans l'autre sens, nous écririons un OpenTSDB
exportateur, similaire au fonctionnement de l'exportateur InfluxDB.

Éléments supplémentaires que je devrais mentionner, j'ai subi 10 millions d'écritures par
seconde à OpenTSDB, et répété cela sur une autre configuration à un autre
entreprise. HBase s'adapte très bien pour cela.

Pouvez-vous donner une idée du matériel impliqué?

Je crois que le cluster d'origine était composé de 24 machines Dell R710, peut-être de 64 Go de RAM, je
ne me souviens pas beaucoup des autres spécifications. Le cluster à Turn est de 36 nœuds, 24
cœurs, 128 Go de RAM, 8 disques.

Ceux-ci devraient faciliter l'écriture de votre support de requête.

Le support minimal dont nous avons besoin est la possibilité de spécifier un sélecteur de vecteur
comme { name ="up",job="myjob",somelabel!="foo",otherlabel~="a|b"} et
récupérer toutes les données pour toutes les séries temporelles correspondantes pour une période donnée
efficacement. Les requêtes peuvent ne pas inclure de nom (bien qu'elles le devraient généralement), et
il n'est pas exclu qu'un seul nom ait des millions de
des séries temporelles à travers tous les temps et des dizaines de milliers ne seraient pas inhabituels.

Je suis un comitter OpenTSDB, je serais heureux de coordonner la feuille de route pour
répondre à vos besoins si possible.

Il est important pour nous de stocker des float64 complets. Étant donné que vous supportez 64 bits
entiers, pourrions-nous simplement les envoyer comme cela ou la prise en charge complète est-elle une option ?

Une prise en charge complète de l'utf-8 dans les valeurs des balises serait également utile, bien que nous ayons
déjà travaillé autour de ça.

Pour autant que je sache, rien n'est exclu, travaillons ensemble pour
mettre en œuvre cela.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -203463519

Je suis certain que j'ai besoin d'en savoir plus sur la structure de requête Prometheus, mais
OpenTSDB (semble être) assez bon pour l'agrégation entre les séries au sein du
même nom de métrique. Il existe également de nouveaux agrégateurs, filtres d'agrégation et
bien sûr l'expression support.

Je recommanderais que nous trouvions un moyen de soutenir la pré-agrégation et
sous-échantillonner les données au fur et à mesure que nous les stockons dans OpenTSDB. Ainsi, par exemple, nous pouvons
fournir une liste de balises à supprimer lors de l'écriture. Une autre pensée est d'écrire
${metric}.1m-avg, ${metric}.5m-avg et sélectionnez-les automatiquement
extensions lors de la lecture de grandes plages de temps. Cela imiterait la façon dont un RRD
système de stockage pourrait fonctionner. Donc, pour la partie récente de la requête, nous tirons plein
résolution mais au fur et à mesure que nous reculons, nous pouvons tirer de la moyenne de 1 m, et
Série 5m-moy.

Juste des pensées bien sûr.

Le mer. 30 mars 2016 à 10h39, Julius Volz [email protected]
a écrit:

D'accord, si nous ne prenons pas en charge les cas d'utilisation de grande agrégation (mais gardez un
route qui leur est ouverte à l'avenir), cela facilite bien sûr les choses. je
supposer qu'il y a un argument à faire valoir pour ces cas d'utilisation car généralement
les gens ne se soucient pas d'autant de dimensions (comme par exemple) pour l'historique
données, de sorte que vous n'opérez peut-être que sur des métriques avec beaucoup moins de séries.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -203494343

Je recommanderais que nous trouvions un moyen de soutenir la pré-agrégation et
sous-échantillonner les données au fur et à mesure que nous les stockons dans OpenTSDB.

Ce n'est pas quelque chose que nous pouvons faire sans la saisie de l'utilisateur pour à peu près toutes les métriques, car nous ne savons pas quelles étiquettes peuvent être supprimées. Cela interromprait également les requêtes des utilisateurs car ce n'est plus la même série temporelle.

Oui, la pré-agrégation serait délicate.

Je vais juste dire que je pense que beaucoup de gens sont enthousiasmés par Prometheus en partie pour sa simplicité en matière de déploiement. Je pense aussi que c'est pourquoi InfluxDB était un bon candidat car il suit de la même manière Go-single-statically-linked-binary-.

Je comprends qu'InfluxDB a été retiré de l'équation pour de bonnes raisons, mais je pense également qu'OpenTSDB est un monstre en matière de déploiement ; Aucune entreprise de moins de 10 employés ne souhaite exécuter un Hadoop à part entière avec HBase et je pense que le stockage à long terme devrait être une alternative viable également pour les petites organisations n'exécutant pas Hadoop + HBase. J'espère que la solution « stockage long », quelle qu'elle soit, est une solution qui peut être facilement déployée. Les deux entreprises avec et sans Hadoop voudront un stockage à long terme. C'était mes deux cents...

C'est une observation tout à fait valable et bonne. HBase peut fonctionner en mode autonome, il utilise des fichiers locaux pour le stockage plutôt que HDFS. On n'en parle pas vraiment dans la documentation, mais je l'ai utilisé pour quelques petits déploiements OpenTSDB où la durabilité et les performances du cluster n'étaient pas importantes. Cela peut ou non être une bonne option ici, pour des raisons évidentes.

L'exécution de hbase en standalone va à l'encontre de l'intérêt de sa distribution ;) Prometheus a déjà son propre magasin. Honnêtement, j'espère que cela ne va pas vers OpenTSDB. Nous avions l'habitude d'exécuter un cluster de 50 nœuds et c'était un travail à temps plein de gérer le cluster.

Oui, OpenTSDB étant complexe à utiliser est une plainte courante et me rend également très méfiant à ce sujet. Bien sûr, vous devrez toujours peser cela contre la probabilité qu'une autre alternative viable se matérialise de sitôt... en espérant toujours quelque chose de plus Go-ey et avec moins de dépendances, mais je ne le vois pas encore tout à fait :)

Est-ce que quelqu'un travaille vraiment dessus en ce moment ?

@ johann8384 Personne ne travaille actuellement sur un tout nouveau système de stockage distribué, non. Mais il y a des travaux et des discussions connexes autour d'une API d'écriture à distance générique (https://github.com/prometheus/prometheus/pull/1487), mais rien de concret pour le moment sur la relecture.

Je voulais juste réitérer le sentiment des autres ci-dessus... même si nous sommes une équipe de taille raisonnable, nous ne voulons pas opérationnaliser HBase. OpenTSDB n'est même pas sur notre liste restreinte pour cette raison.

Avis de non-responsabilité : nous ne sommes techniquement pas des utilisateurs de Prometheus pour le moment, mais nous devrions l'être dans les prochaines semaines :).

L'exécution de hbase en standalone va à l'encontre de l'intérêt de sa distribution ;)

@mattkanwicher Vrai.

Prometheus a déjà son propre magasin.

Vrai. Cependant, le stockage AFAIK Prometheus ne prend pas en charge le sous-échantillonnage. AFAIK, OpenTSDB ne le fait pas. Cela pourrait être une raison pour vouloir exécuter OpenTSDB (ou autre chose) non distribué.

Est-ce que quelqu'un travaille vraiment dessus en ce moment ?

Bonne question. Je ne serais pas surpris d'entendre que personne n'y travaille car ce problème est vaste et mal défini. À mon avis, il y a en fait plusieurs sous-problèmes :

• Prometheus ne prend pas en charge le sous-échantillonnage des données, ce qui signifie que les données occupent plus d'espace que nécessaire. Solution : utilisez des disques plus volumineux.
• Prometheus ne prend pas en charge la réplication des données. Perdre un master signifie que vous perdrez ces données. Solution : utilisez un système de fichiers distribué.

Quelque chose manque?

Avis de non-responsabilité Tout comme @jkinred , je ne suis pas un utilisateur Prometheus. Cependant, j'y reviens toujours...

L'idée générale est que c'est le stockage distant qui est distribué et qui effectue le sous-échantillonnage. Le stockage local de Prometheus est assez efficace, mais en fin de compte, vous ne souhaitez conserver que quelques semaines de données dans Prometheus lui-même pour un accès rapide/fiable et dépendre du stockage à distance au-delà. Ensuite, vous ne vous souciez pas vraiment de l'espace utilisé par Prometheus (tant qu'il tient au moins quelques jours, c'est bon) ou si vous perdez l'une d'une paire HA de temps en temps.

Qu'en est-il d'un exportateur BigQuery par chargement de flux ? Devrait être l'option analogue à borgmon -> tsdb ?

Je ne vois aucun moyen d'utiliser BigQuery ici en raison du modèle de données en colonnes, sauf si vous interrogez les données extrêmement rarement.

Qu'en est-il de https://github.com/hawkular/hawkular-metrics
Hawkular Metrics est le magasin de données métriques du projet Hawkular. Il peut également être utilisé indépendamment.

Voir aussi https://github.com/kubernetes/heapster/blob/master/docs/storage-schema.md#hawkular

Collecte de métriques à partir des points de terminaison Prometheus : http://www.hawkular.org/blog/2016/04/22/collecting-metrics-from-prometheus-endpoints.html
L'agent a désormais la possibilité de surveiller les points de terminaison Prometheus et de stocker leurs métriques dans Hawkular Metrics. Cela signifie que tout composant qui exporte des données métriques Prometheus via les formats binaires ou texte Prometheus peut avoir ces données métriques collectées par l'agent et transférées dans Hawkular Metrics

Grattoir de mesures Prometheus : https://github.com/hawkular/hawkular-agent/tree/master/prometheus-scraper

Hawkular a float64, des horodatages en millisecondes et des étiquettes de paire clé/valeur. Une métrique donnée n'a qu'un seul ensemble de balises, mais que nous pourrions contourner. L'API est JSON, donc pas clair si elle peut gérer des valeurs non réelles. C* est le backend. Semble prendre en charge les opérations dont nous avons besoin sur les étiquettes.

Ce qui n'est pas clair, c'est comment il utilise exactement en C* et comment il a implémenté les recherches d'étiquettes. En regardant le schéma, aucun des deux ne semble assez efficace pour notre cas d'utilisation.

Voir :

• tags et recherche basée sur les étiquettes (https://github.com/openshift/origin-metrics/issues/34)
• Interrogation basée sur la balise (https://github.com/openshift/origin-metrics/blob/master/docs/hawkular_metrics.adoc#querying-based-on-tag)

De plus, Cassandra 3.4 a ajouté la prise en charge de l'index personnalisé SASI :

• SASIIndex (https://github.com/apache/cassandra/blob/trunk/doc/SASI.md)
• Indexation secondaire améliorée avec de nouvelles capacités de requête (OU, portée) pour Cassandra (https://github.com/xedin/sasi)
• Indices secondaires d'habilitation SASI (http://www.planetcassandra.org/blog/sasi-empowering-secondaire-indexes/)
• Indexation avec les index secondaires attachés SSTable (SASI) (https://docs.datastax.com/en/cql/3.3/cql/cql_using/useSASIIndexConcept.html)
• SASI : Recherche et analyse en temps réel avec Cassandra (http://www.meetup.com/fr-FR/DataStax-Cassandra-South-Bay-Users/events/229467895/?eventId=229467895)

Cas d'utilisation SASI : Implémenter le type de métrique de chaîne (https://issues.jboss.org/browse/HWKMETRICS-384)

J'ai créé le problème "Hawkular metrics as the Long term storage backend for prometheus.io" (https://issues.jboss.org/browse/HWKMETRICS-400)

Je pense qu'il faudrait une refonte majeure de Hawkular pour le faire fonctionner pour les volumes de données que Prometheus produit. Par exemple, un matcher à une seule étiquette tel que job=node peut facilement faire correspondre des dizaines de millions de séries temporelles sur une grande configuration. Cela va dépasser la limite de taille de ligne de 4 Go en C* pour metrics_tags_idx.

Hawkular semble également utiliser au moins 32 octets par échantillon, avant la réplication.

Je ne connais pas la limite de taille de ligne de 4 Go en C*
Cassandra a une limite de 2 milliards de colonnes (https://github.com/kairosdb/kairosdb/issues/224)
Limites CQL (https://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html)

Quelle est la relation avec PR "Ecriture générique #1487" (https://github.com/prometheus/prometheus/pull/1487) ?

Je pense qu'il faudrait une refonte majeure de Hawkular pour le faire fonctionner pour les volumes de données que Prometheus produit. Par exemple, un matcher d'étiquette unique tel que job=node peut facilement faire correspondre des dizaines de millions de séries temporelles sur une grande configuration. Cela va dépasser la limite de taille de ligne de 4 Go en C* pour metrics_tags_idx.

Vous avez raison de dire qu'il est possible que nous nous retrouvions avec des rangées très larges dans metrics_tags_idx . Cela n'a pas été un problème parce que nous n'avons pas eu affaire à des ensembles de données suffisamment volumineux pour nécessiter un changement.

Changer le schéma pour metrics_tags_idx ainsi que nos autres tables d'index est quelque chose que nous pourrions certainement faire. Une possibilité serait de mettre en œuvre un partitionnement manuel. Nous ajouterions une colonne shard ou hash id à la clé de partition. Cela nous permettrait également de limiter efficacement le nombre de lignes par partition. Au fur et à mesure que l'ensemble de données augmente, nous pourrions avoir besoin de repartager et d'augmenter le nombre de fragments. Je pense que la solution devrait également en tenir compte.

Hawkular semble également utiliser au moins 32 octets par échantillon, avant la réplication.

De quel(s) tableau(s) parles-tu ? Nous avons récemment migré vers Cassandra 3.x qui inclut une refactorisation majeure du moteur de stockage sous-jacent. J'ai besoin de revoir les modifications avant de pouvoir dire précisément combien d'octets sont utilisés par échantillon. Gardez ce qui suit à l'esprit cependant. Dans Cassandra 2.x, la partie du nom de colonne des colonnes de regroupement était répétée sur le disque pour chaque cellule. Ce n'est plus le cas dans Cassandra 3. Cela peut se traduire par un gain de place considérable. Et Cassandra stocke les données au format compressé par défaut.

Je veux juste m'assurer que je comprends l'état de ce domaine d'amélioration... les fournisseurs distants dans /storage/remote sont-ils maintenant pris en charge ? Si oui, que reste-t-il à compléter ici ?

Ils sont effectivement obsolètes. Ils seront supprimés une fois que nous aurons une forme d'écriture générique dans Prometheus (par exemple #1487).

Salut à tous, je voulais évoquer une autre possibilité pour une couche de stockage : Apache Kudu (incubating) . Kudu se présente comme une couche de stockage analytique pour l'écosystème Hadoop. Kudu apporte quelques fonctionnalités intéressantes :

• Format sur disque en colonnes : prend en charge une excellente compression des données de séries chronologiques et permet des analyses extrêmement rapides. Des encodages sophistiqués tels que bitshuffle, dictionnaire et longueur d'exécution, ainsi que plusieurs types de compression (LZ4, etc.) sont intégrés
• Réplication fortement cohérente via Raft
• Aucune dépendance : ne nécessite pas HDFS/Zookeeper/rien d'autre
• Conçu avec des opérations à l'esprit : aucune pause de récupération de place et des heuristiques avancées pour les compactages de disque qui les rendent prévisibles et fluides
• Partitionnement avancé : les métriques peuvent être distribuées par hachage entre les nœuds, les partitions _et_ peuvent être organisées par temps, de sorte que de nouvelles partitions peuvent être mises en ligne et les anciennes partitions peuvent être supprimées au fur et à mesure de leur ttl. Cela offre une grande évolutivité pour les charges de travail de métriques
• Conçu pour les charges de travail lourdes d'analyses - contrairement à de nombreuses bases de données qui sont optimisées en premier lieu pour un seul enregistrement ou la récupération de valeurs, Kudu est optimisé pour les analyses

Mon objectif est de vous faire connaître Kudu en tant que solution de stockage potentielle et de vous demander ce que Prometheus recherche dans une couche de stockage. J'ai eu un certain succès expérimental avec un point de terminaison HTTP compatible TSDB devant Kudu, mais peut-être que Prometheus recherche un autre type d'API ? Ce serait formidable d'avoir une idée de ce dont Prometheus a besoin d'une couche de stockage distribuée, et si Kudu pouvait remplir le rôle.

En ce qui concerne la maturité de Kudu, nous prévoyons d'avoir une version 1.0 prête pour la production plus tard cet été. Le projet est en cours de développement depuis plus de trois ans, et nous avons déjà de très grandes installations de production (75 nœuds, ingérant 250 000 enregistrements/sec en continu) et testons régulièrement sur plus de 200 clusters de nœuds.

Je m'attends à ce que Kudu tombe en panne pour les mêmes raisons que BigQuery, les modèles d'accès aux données de séries temporelles et aux données en colonnes sont très différents.

75 nœuds, ingérant 250 000 enregistrements/s en continu

Un seul serveur Prometheus peut générer plus de trois fois cette charge.

@brian-brazil pourriez-vous être plus précis sur les modèles d'accès problématiques ? À part le fait qu'elle est en colonnes, notre architecture n'est pas vraiment comparable à BigQuery. Kudu est conçu pour des analyses à faible latence et hautement simultanées.

Un seul serveur Prometheus peut générer plus de trois fois cette charge.

Oui, c'est probablement un mauvais exemple, ce cas d'utilisation n'est pas une collecte de métriques et je pense que les tailles d'enregistrement sont assez grandes en comparaison. J'ai pu maximiser une configuration Kudu à nœud unique à environ 200 000 écritures de points de données par seconde sans que Kudu transpire sur mon ordinateur portable (il y avait un goulot d'étranglement dans la couche proxy HTTP). Cependant, je n'ai pas encore vraiment creusé et obtenu des chiffres solides. Certainement sur ma liste TODO.

En particulier - Kudu conserve les données triées par un index de clé primaire, donc la recherche d'une métrique et d'une plage de temps particulières ne nécessite que la lecture des données requises. Par conséquent, les analyses de séries temporelles peuvent avoir des latences inférieures à 10 ms.

Si j'avais un TSDB avec 1 milliard de métriques et que je vous donnais une expression correspondant à 100 d'entre eux sur un an, comment cela fonctionnerait-il ?

Avec le projet expérimental auquel j'ai lié plus tôt, il conserve un index secondaire dans une table annexe de (tag key, tag value) -> [series id] , puis utilise les identifiants résultants pour effectuer l'analyse. Ainsi, si vous disposez d'un jeu de données d'un milliard de points mais que votre requête ne correspond qu'à 100 points en fonction du nom de la métrique, de l'ensemble de balises et de l'heure, la table de données ne sera analysée que pour exactement ces 100 points. Il est calqué sur la façon dont OpenTSDB utilise HBase, mais avec quelques différences importantes. Il y a un peu plus d'infos à ce sujet ici . Un énorme avantage d'avoir un format en colonnes au lieu de lignes, est qu'un système comme celui-ci n'a pas besoin de faire de compactages externes/réécriture de points de données, comme OpenTSDB doit le faire pour HBase. Les options d'encodage et de compression en colonnes sont déjà intégrées et meilleures que tout ce qu'OpenTSDB fera.

Ce n'est qu'un exemple particulier de la façon dont le stockage de séries temporelles pourrait être effectué avec Kudu. Si le modèle de données ne ressemble pas au metric/tagset/timestamp/value de style OpenTSDB, cela peut être fait différemment.

L'un de ces matchs de tag (dont il y en a probablement 2-4) pourrait facilement concerner une série chronologique de 10 millions. Pour 100 séries temporelles sur un an avec une résolution de 5 m, cela représente environ 10 milliards de points.

Désolé, je ne suis pas. Donc, pour une requête telle que

SELECT * WHERE
   metric = some_metric AND
   timestamp >= 2015-01-01T00:00:00 AND
   timestamp < 2016-01-01T00:00:00 AND
   tag_a = "val_a" AND
   tag_b = "val_b" AND
   tag_c = "val_c";

il trouve l'ensemble des séries temporelles où tag_a = "val_a" , l'ensemble où tag_b = "val_b" et l'ensemble où tag_c = "val_c" . Il prend ces trois ensembles, trouve l'intersection (afin de trouver les séries qui correspondent aux trois prédicats), puis lance un balayage en parallèle pour chacun. Chacune de ces analyses ne peut relire que les données nécessaires (bien que les données puissent être réparties sur plusieurs partitions). Le schéma n'a pas vraiment été conçu pour le cas où une paire (tag_key, tag_value) individuelle pourrait avoir des millions de séries correspondantes, il y a donc probablement un moyen plus efficace de le faire avec cette contrainte à l'esprit.

Oui, une étiquette telle que job=node pourrait facilement avoir des dizaines de millions de métriques correspondantes.

La recherche de balise vers l'ID de série que j'ai mentionnée plus tôt est indépendante de la métrique, de sorte que de nombreuses métriques peuvent partager un seul ID de série. Un ID de série ne décrit en réalité qu'un ensemble unique d'étiquettes, en termes Prometheus. Encore une fois, c'est ainsi que j'ai structuré cette solution, elle n'est donc pas inhérente à Kudu en tant que couche de stockage. De toute évidence, l'indexation multi-attributs est un problème difficile et il existe de nombreuses façons de s'y prendre.

@brian-brasil plus généralement, il semble que vous ayez une assez bonne idée de ce que vous recherchez dans un système de stockage externe. Est-ce écrit quelque part, ou pourriez-vous élucider?

Salut,

C'est un fil conducteur intéressant, et oui, même moi j'étais sur le point de demander s'il y avait quelque part une proposition concernant le stockage à long terme. Cela nous permettrait d'obtenir facilement le contexte et de comprendre s'il s'agit d'une tâche que nous pouvons entreprendre et expérimenter.

Merci,
Goutham.

L'idée derrière #1487 est d'exposer une interface pour permettre aux utilisateurs d'expérimenter des solutions. La solution complète est assez difficile, mais des formes plus contraignantes du problème (telles que l'absence d'indexation) sont plus faciles à traiter.

En réalité, un index capable de gérer ces exigences serait un
problème différent du stockage des données d'échantillon réelles.
Peut-être qu'il peut tirer parti de certaines efficacités de recherche fournies par cette couche.

Le jeu. 9 juin 2016 à 00:51 Brian Brazil [email protected]
a écrit:

L'idée derrière #1487 https://github.com/prometheus/prometheus/pull/1487
est d'exposer une interface pour permettre aux utilisateurs d'expérimenter des solutions. le
solution complète est assez difficile, mais des formes plus contraignantes de la
problème (comme ne pas avoir besoin d'indexation) sont plus faciles à traiter.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -224754971,
ou couper le fil
https://github.com/notifications/unsubscribe/AEuA8ic17IjFeYvqWQSZvGBp35BcK4tHks5qJ0dmgaJpZM4AV6IB
.

Bonjour,

@brian-brazil Je me demandais si cette relecture d'une fonction de base de données de séries temporelles était en cours d'élaboration en ce moment et si oui, avez-vous des estimations approximatives du moment où une version bêta pourrait être publiée, que ce soit cette année ou la prochaine ? La société pour laquelle je travaille est très intéressée par cet outil et la fonctionnalité permettant d'interroger des données à long terme pour un service sur lequel nous travaillons pour une sortie en mars 2017. Toute information serait grandement appréciée.

Merci,
Gustavo

Il n'y a pas de calendrier défini, mais je m'attendrais à ce que quelque chose soit possible à ce moment-là. #1487 est une proposition pour nous mettre sur la bonne voie, et Weave avait également une proposition qui impliquerait à la fois les aspects de lecture et d'écriture.

Quelques questions :

1. Avez-vous récemment consulté InfluxDB ? Bien que le clustering ne soit plus disponible (et en quelque sorte à mon humble avis), il existe un projet open source appelé influxdb-relay qui gère la réplication et l'équilibrage de charge entre plusieurs nœuds InfluxDB. https://github.com/influxdata/influxdb-relay/blob/master/README.md
2. Avez-vous pensé au Riak TS ? Je n'ai vu personne le mentionner, alors j'ai pensé que je demanderais. http://basho.com/products/riak-ts/

Nous n'avons pas réévalué Influx après l'annonce de la fermeture de la source, si une solution de clustering ouverte fonctionnant à faible maintenance devient disponible, nous pouvons la réexaminer.

J'ai jeté un coup d'œil à Riak TS il y a quelque temps, mon souvenir est que le stockage n'était pas assez efficace pour le type de volumes que nous avons et vous auriez toujours besoin de quelque chose pour l'indexation.

Vous vous demandez simplement si vous avez des idées sur l'utilisation de Prometheus avec le stockage OpenTSDB construit sur Amazon EMR ? Il semble que cela pourrait réduire la charge de maintenance du cluster, êtes-vous d'accord avec cela et si oui, l'exportation OpenTSDB serait-elle une meilleure option ?

Toute solution doit être utilisable sur site, ce qui signifie que nous ne pouvons pas déléguer Hadoop au cloud (et la dernière fois que j'ai vérifié, EMR n'est pas une solution entièrement gérée de toute façon).

Qu'en est-il d'Elasticsearch 5 (actuellement chez alpha5) ? Ils ont annoncé que la nouvelle version utilisera Lucene 6 , qui a beaucoup d'optimisations spécifiquement pour l'indexation des données numériques.

du blog Elastic :

Lucene 6 apporte une nouvelle fonctionnalité majeure (implémentée depuis alpha2) appelée Dimensional Points : une nouvelle structure de données arborescente qui sera utilisée pour les champs numériques, de date et géospatiaux. Par rapport au format de champ existant, cette nouvelle structure utilise la moitié de l'espace disque, est deux fois plus rapide à indexer et augmente les performances de recherche de 25 %. Cela sera particulièrement bénéfique pour les cas d'utilisation de la journalisation et des métriques.

Je ne pense pas que ES soit une solution appropriée pour un magasin de données principal, et le type et le volume de données ne sont pas vraiment ce à quoi il est destiné.

Je ne suis plus sûr que ce soit vrai. Kibana est déjà un outil populaire pour afficher les métriques d'ElasticSearch. Je pense qu'il y a un effort concerté pour le rendre plus efficace pour ce type de travail. De plus, je ne pense pas que le volume sera un problème s'il est correctement configuré.

En outre, c'est le meilleur magasin de données que j'ai utilisé en termes de clustering. Certes, je n'en ai pas utilisé beaucoup, mais cela a bien fonctionné dans un cluster en direct jusqu'à présent, même avec des défaillances de nœud occasionnelles.

@sybrandy était exactement mon propos, la pile élastique comme pour Today est beaucoup plus axée sur la surveillance. Par exemple, les outils beats sont similaires dans leur objectif à exporters dans Prometheus. Et la sortie va dans ES.

Compte tenu du fait que le projet est entièrement open source, qu'il dispose d'un clustering facile, d'une interface REST agréable et qu'avec Lucene 6 (lorsque ES5 sortira), il peut potentiellement servir Prometheus comme stockage à long terme. A mon humble avis

ES est couramment utilisé pour les journaux, les métriques sont un cas d'utilisation très différent. Lucene n'est pas pertinent par exemple.

De plus, je ne pense pas que le volume sera un problème s'il est correctement configuré.

Je n'associerais pas ES à des ensembles de données à l'échelle du pétaoctet qui doivent être stockés en toute sécurité pendant des années, c'est ce dont nous parlons ici. C'est un moteur de recherche de texte, pas un magasin de données en masse.

En outre, c'est le meilleur magasin de données que j'ai utilisé en termes de clustering. Certes, je n'en ai pas utilisé beaucoup, mais cela a bien fonctionné dans un cluster en direct jusqu'à présent, même avec des défaillances de nœud occasionnelles.

Ce n'est pas mon expérience, et je note un certain nombre de bogues en suspens concernant la gestion incorrecte des défaillances de nœuds.

Aborder cette question d'un point de vue agnostique semblait raisonnable. S'il existe un moyen bien documenté d'extraire des données de Prometheus, nous pouvons construire des solutions pour les tester.

DalmatierDB a été conçu pour les données de séries chronologiques et est basé sur Riak Core (pas KV) et possède un index Postgres spécialement conçu pour accélérer les requêtes de séries chronologiques dimensionnelles. Nous pourrions faire un travail supplémentaire pour augmenter le stockage de précision de 62 bits à 64 bits ou plus. Nous travaillons actuellement à rendre la fonctionnalité de langage de requête comparable.

S'il y avait un moyen sensé de pousser ou d'extraire les données de Prometheus, moi-même ou quelqu'un d'autre chez Dataloop ou Project Fifo écrirait une implémentation initiale pour stocker les données dans un cluster DalmatinerDB. Si cela fonctionne, nous pourrions envisager d'écrire une traduction de requête de Prometheus vers DalmatinerDB.

Ce serait bien de voir du mouvement sur celui-ci, car il semble que cela dure depuis quelques années maintenant. J'ai l'impression qu'une grande partie du travail pourrait être effectuée et maintenue en dehors de l'équipe de projet principale de Prometheus si l'interface était simplement définie, publiée et itérée.

J'ai l'impression qu'une grande partie du travail pourrait être effectuée et maintenue en dehors de l'équipe de projet principale de Prometheus si l'interface était simplement définie, publiée et itérée.

C'est aussi mon avis. #1487 est une approche à cela.

Je pense que beaucoup de gens sont à bord pour l'interface comme d'autres propriétaires
Les dB peuvent également être utilisés (ce qui peut ne pas être conforme à la fonctionnalité actuelle
spécification)
Le jeu. 11 août 2016 à 7h12 Brian Brazil [email protected]
a écrit:

J'ai l'impression qu'une grande partie du travail pourrait être effectuée et maintenue en dehors du
équipe principale du projet Prometheus si l'interface vient d'être définie, publiée
et itéré.

C'est aussi mon avis. #1487
https://github.com/prometheus/prometheus/pull/1487 est une approche pour
cette.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/prometheus/prometheus/issues/10#issuecomment -239006063,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA-K-9aHZrtjg3cWCVWml-ajEKoRyu3Oks5qej7CgaJpZM4AV6IB
.

Je n'associerais pas ES à des ensembles de données à l'échelle du pétaoctet qui doivent être stockés en toute sécurité pendant des années, c'est ce dont nous parlons ici. C'est un moteur de recherche de texte, pas un magasin de données en masse.

Premièrement, quelques recherches rapides sur Google montrent que les gens le font. Je sais que c'est techniquement un moteur de recherche de texte, mais il semble qu'il aille au-delà. Même dans ce cas, vous disposez de capacités de réplication et de sauvegarde, de sorte que le risque de perte de données est atténué. (Je ne suis pas convaincu qu'un système ne garantisse à 100% aucune perte de données.)

Deuxièmement, tout le monde n'a pas besoin de données à long terme. Peut-être que je ne me soucie que de ce qui s'est passé le mois dernier. Je ne pense pas qu'une solution de stockage doive être écartée simplement parce qu'elle ne correspond pas à un cas d'utilisation.

Cependant, si le travail pour créer une interface générique est finalisé et fonctionne bien, c'est un point discutable et, à mon humble avis, cela devrait vraiment l'être. Laissez les gens contribuer au code pour leur permettre d'utiliser ElasticSearch, InfluxDB, RiakTS, tout ce qu'ils veulent. C'est bien de recommander certaines solutions car "c'est ce que nous avons trouvé qui fonctionne le mieux", mais parfois vous devez simplement travailler avec ce qui se trouve dans votre pile ou avec ce que votre équipe connaît le mieux.

Par exemple, dans notre système actuel, nous utilisons InfluxDB pour nos métriques. Cela fonctionne très bien, mais nous pouvons déplacer cela dans notre cluster ElasticSearch existant. Pourquoi? Eh bien, nous y mettons déjà des journaux, cela se regroupe / s'adapte beaucoup plus facilement, Kibana s'est amélioré dans certains domaines, et c'est une chose de moins à configurer et à entretenir. Est-ce le meilleur ajustement? Probablement pas. Cependant, il y a des avantages importants à avancer vers cela qui ne peuvent être ignorés.

Deuxièmement, tout le monde n'a pas besoin de données à long terme. Peut-être que je ne me soucie que de ce qui s'est passé le mois dernier. Je ne pense pas qu'une solution de stockage doive être écartée simplement parce qu'elle ne correspond pas à un cas d'utilisation.

Le sujet de ce PR est le stockage à long terme. Prometheus gère déjà le stockage à court terme.

Ah, excusez-moi. Il y a si longtemps que je n'ai pas lu le top, j'ai oublié.

J'ai commencé une feuille de calcul comparant les bases de données de séries chronologiques, ce qui est probablement assez pertinent pour ce ticket.

https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCEWdPtAoccJ4a-IuZv4fXDHxM/edit#gid =0

Si quelqu'un souhaite modifier les droits pour apporter des modifications, faites-le moi savoir et j'enverrai une invitation.

Il y a un blog correspondant pour l'accompagner, mais il résume vraiment le sentiment dans ce fil donc n'est probablement pas très utile.

https://blog.dataloop.io/top11-open-source-time-series-databases

Nous approchons d'un état où DalmatinerDB fonctionnerait bien avec Prometheus en tant que stockage à long terme. Il est extrêmement rapide en écriture et peut donc facilement gérer plusieurs serveurs Prometheus de données. Voici un benchmark reproductible montrant 3 millions d'écritures par seconde sur certaines VM Joyent :

https://gist.github.com/sacreman/b77eb561270e19ca973dd5055270fb28

Les requêtes sont également rapides et nous évitons tous les problèmes rencontrés dans les solutions en colonnes. La configuration est assez simple par rapport aux systèmes basés sur Hadoop. Ce n'est pas encore très bien annoncé car nous nettoyons les versions et publions les packages la semaine prochaine, bien que ce Gist fonctionne en ce moment :

https://gist.github.com/sacreman/9015bf466b4fa2a654486cd79b777e64

Le seul point négatif est la précision de la valeur. J'ai soulevé un ticket pour que nous puissions enquêter :

https://github.com/dalmatinerdb/dalmatierdb/issues/77

Cependant, cela ne bloque aucun travail de démarrage sur une intégration. Maintenant qu'il existe une base de données qui est au moins théoriquement viable, il semble dommage que je n'aie aucun moyen de jouer pour le moment.

@sacreman Merci, bonne comparaison. Heureux que Prometheus ait remporté le concours de langage de requête avec seulement 5/5 points :) Je préfère PromQL aux dialectes SQL pour le type de calculs de séries chronologiques qui sont courants dans Prometheus...

En ce qui concerne le stockage : un groupe d'entre nous et des gens d'entreprises qui construisent les premiers stockages à distance ont collé nos têtes ensemble aujourd'hui (un samedi - juste pour vous :)) pour enfin débloquer toute cette discussion sur le stockage à distance. Nous avons conclu comment nous voulons créer une interface générique pour l'écriture et la lecture de données, puis n'importe qui pourrait créer son propre adaptateur sur n'importe quel système de stockage à long terme de son choix (puisque nous ne pourrons jamais en prendre en charge un seul directement et que ce soit assez bon pour tout le monde).

Cela se passera à peu près comme ceci : nous enverrons des échantillons bruts via protobuf+gRPC en écriture. Pour les lectures, nous enverrons une plage de temps, un ensemble de sélecteurs d'étiquettes et un champ de données opaque (utile pour des choses comme faire allusion au sous-échantillonnage souhaité), et attendons en retour une liste de séries temporelles (ensembles d'étiquettes + échantillons) pour ces sélecteurs et plages horaires. Les implémentations exactes de ceci vont suivre bientôt... attendez-vous d'abord au côté écriture générique, suivi du côté lecture.

@juliusv c'est une excellente nouvelle ! Maintenant, quand je fais un futur blog classant tous les outils de surveillance open source dans un top 10, je peux classer Prometheus/Grafana/DalmatinerDB comme numéro 1 :)

Gardera un œil sur la première version, puis commencera à jouer.

@sacreman Voir aussi les notes que nous avons prises (nous avons d'abord eu une discussion générale sur la feuille de route, puis l'API distante générique) : https://docs.google.com/document/d/1Qj_m-lbatySAU0vsVfAPG7mduN1-nevrpD85uQhi4sY/edit#heading =h.6xcexetcoa4g

@juliusv que tout a l'air bien. DalmatierDB dispose d'un proxy de métriques que nous mettrons à jour à la fois pour les lectures et les écritures.

https://github.com/dalmatierdb/ddb_proxy

On peut lui faire faire ça :

@sacreman Ça a l'

Pour ce que ça vaut, nous sommes prêts à travailler avec la communauté Prometheus pour faire de Warp 10 (www.warp10.io) une solution viable pour le stockage à long terme.

Étant donné que les fonctionnalités de borgmon/promql peuvent probablement être entièrement couvertes par WarpScript, cela en fait une solution très flexible à considérer à mon avis (partial).

@hbs cool. Le plan est toujours tel que décrit dans https://github.com/prometheus/prometheus/issues/10#issuecomment -242937078, nous n'aurons donc pas d'intégrations spécifiques dans Prometheus lui-même, juste le générique, puis les gens peuvent construire tout ce qu'ils veulent avec. Je serais heureux de voir une intégration de Warp 10.

Mon $dayjob a des exigences qui vont nous pousser vers un stockage à long terme (> 5 ans) de certaines métriques, ou au moins effectuer un sous-échantillonnage des données sur une ou plusieurs métriques à des intervalles beaucoup plus longs. Il serait très pratique d'avoir cette fonctionnalité "transparente" dans Prometheus, où les données seraient déplacées vers le magasin à long terme et seraient réimportées lors de requêtes à long terme, même si l'examen des données plus anciennes était plus lent d'accès en raison de latence du disque, points non mis en cache, retards de l'API, etc. Je laisse "significativement" comme terme volontairement vague. J'espère éviter de diviser les données en deux silos pour obtenir les fonctionnalités dont nous avons besoin, et d'avoir à réécrire mes vues/graphiques/etc. que j'ai avec Grafana posé sur Prométhée. Nous sommes même probablement prêts à consacrer une petite somme de dollars/euros au développement de cette capacité car cela résoudrait de nombreux problèmes et nous ferait gagner du temps. J'ai été encouragé à lire ce fil au cours des trois dernières années pour les idées, et j'espère que l'activité récente est de bon augure pour l'exécution du code. Alternativement, disposer d'une capacité de sous-échantillonnage des données pourrait grandement contribuer à résoudre nos besoins particuliers.

Vérifiés dans le binaire prometheus v1.4.1, ces paramètres "-storage.remote.influxdb. " et "-storage.remote.opensdb " existent toujours, doivent-ils être supprimés ?

$ prometheus --help
usage: prometheus [<args>]
...
   -storage.remote.graphite-address
      The host:port of the remote Graphite server to send samples to.  None, if empty.

   -storage.remote.graphite-prefix
      The prefix to prepend to all metrics exported to Graphite. None, if empty.

   -storage.remote.graphite-transport "tcp"
      Transport protocol to use to communicate with Graphite. 'tcp', if empty.

   -storage.remote.influxdb-url
      The URL of the remote InfluxDB server to send samples to. None, if empty.

   -storage.remote.influxdb.database "prometheus"
      The name of the database to use for storing samples in InfluxDB.

   -storage.remote.influxdb.retention-policy "default"
      The InfluxDB retention policy to use.

   -storage.remote.influxdb.username
      The username to use when sending samples to InfluxDB. The corresponding password must be provided via the INFLUXDB_PW environment variable.

   -storage.remote.opentsdb-url
      The URL of the remote OpenTSDB server to send samples to. None, if empty.
...

@linfan Ils seront supprimés à un moment donné, mais cela n'a pas encore été décidé exactement quand. À tout le moins avec Prometheus 2.0, je suppose, sinon bien avant.

J'espérais obtenir les bases pour les supprimer à Noël, mais les tests de charge ont pris mon temps à la place. Fondamentalement, je pense que nous devrions proposer des exemples de récepteurs pour ceux-ci avant de les supprimer, afin de ne laisser aucun utilisateur existant dans le pétrin. C'est une tâche assez facile si quelqu'un souhaite s'en occuper, et nous pouvons ensuite supprimer en 1-2 révisions mineures.

OpenTSDB lui-même n'est pas très difficile à exécuter, surtout si vous pouvez décharger la base de données vers Google ou l'équipe interne de haoop (bien qu'elle ne doive pas vraiment être co-localisée avec les clusters MapReduce, il est préférable d'en utiliser un petit dédié). Activez le salage avec une largeur du nombre de serveurs régionaux que vous aurez, jusqu'à un maximum d'environ 12. C'est à peu près le seul bouton dont vous devez vous soucier, car il affecte la création de la table.

HBase est beaucoup plus difficile à régler lors de la configuration initiale. Si vous avez plus d'une poignée de serveurs, augmentez la taille maximale de la région jusqu'à 300 ou 400 Go. Assurez-vous que vous utilisez HBase 1.2+ afin que le normalisateur de région puisse s'exécuter pour empêcher les petites régions de s'étendre. J'ai vu d'autres conseils à ce sujet, mais il utilise une tonne de ressources sur le serveur régional et dans le tsd pour garder une trace de trop de régions. Trop de régions nuisent également aux performances de démarrage à froid et à la décompression/rééquilibrage des nœuds. Vous n'en voulez que quelques centaines à quelques milliers pour un très très grand ensemble de données. En tout, il y a environ 40 boutons que vous devez monter très haut, associés à un énorme tas JVM (ou un tas de taille moyenne et un cache L2 hors tas) et le ramasse-miettes G1 pour maintenir le temps de pause dans le pire des cas à environ 100 ms. Après une bonne configuration, c'est à peu près les mains. Vous pouvez ajouter et supprimer des nœuds de manière élastique et vous rapprocher de l'évolutivité linéaire. Je l'ai détesté jusqu'à ce que nous trouvions le réglage magique HBase, et maintenant c'est plutôt bon et nécessite peu d'entretien.

Pour info : nous ajouterons la prise en charge des étiquettes à BigGraphite pour le rendre utilisable comme stockage à distance pour Prometheus (https://github.com/criteo/biggraphite/issues/95).

Pour rendre le chemin d'écriture efficace, nous aurons besoin d'un moyen de contrôler le traitement par lots des échantillons. Nous aurons également besoin de la découverte de services et d'un équilibrage de charge de base si nous voulons quelque chose d'assez fiable. Faut-il créer une étiquette spécifique pour le stockage à distance afin de suivre toutes les choses nécessaires pour y arriver ?

L'API est ce qu'elle est, tout traitement par lots ou équilibrage de charge doit être effectué de votre côté.

Mon souci est que je ne suis pas sûr que l'API actuelle permette de créer facilement quelque chose de fiable sans trop de travail en double.

Sur le chemin d'écriture, l'équilibrage de charge n'est pas si important tant que le pont est au moins aussi performant que prometheus lui-même. La découverte de service reste cependant indispensable (même logique que pour le gestionnaire d'alertes). Pour le traitement par lots, étant donné que prometheus a déjà ce qui ressemble à un cache tampon à points de contrôle, il serait triste de devoir réimplémenter cette partie dans chaque pont qui veut faire des choses intelligentes telles que l'encodage double delta, mais c'est probablement bien si cela n'est pas présent dans la première version.

Sur le chemin de lecture, l'équilibrage de charge de base par tourniquet + la découverte de service seront probablement nécessaires.

L'objectif de l'API est de dissocier les problèmes de performances et de fiabilité, car l'écriture de ce type de système est difficile et il n'est pas particulièrement difficile pour des éléments tels que des tampons de sauvegarder et de supprimer la surveillance.

Ok, d'accord pour la mise en mémoire tampon / le traitement par lots. Au moins dans un premier temps.

L'autre point était la découverte de services pour le stockage distant, qu'en pensez-vous ? (À mon humble avis, c'est un peu le même raisonnement que pour le gestionnaire d'alertes : vous en avez besoin si vous ne voulez pas le contourner sur la couche réseau)

SD car c'est certain. L'équilibrage de charge n'est pas déterminé, je ne pense pas que cela appartienne à Prometheus.

Quel est l'état actuel ?
S'il y a quelque chose que d'autres personnes peuvent aider à obtenir le stockage API enfichable ?

@danni-m Il y a plusieurs parties ici :

• Le chemin d'écriture : Il existe et peut être utilisé aujourd'hui. Voir https://prometheus.io/docs/operating/configuration/#

• Le chemin de lecture, Prometheus relisant à partir du stockage distant. Cela n'existe pas encore, mais j'espère en construire une première version d'ici un ou deux mois.

• Le stockage distant lui-même : n'importe qui peut créer des implémentations de stockage distant en utilisant les interfaces de lecture/écriture génériques mentionnées ci-dessus (enfin, pour le moment, seule celle en écriture existe). Deux exemples réels très différents existent déjà (https://github.com/weaveworks/cortex et https://github.com/ChronixDB/chronix.ingester). Il y aura probablement de nombreuses implémentations, car différentes personnes ont besoin de différentes choses. Mais peut-être y en aura-t-il un qui est si bien fait, facile à exécuter et génériquement utile qu'il deviendra le "par défaut" que nous recommandons. Ce n'est pas encore très clair, j'encourage les gens à au moins commencer à expérimenter le chemin d'écriture.

N'oubliez pas https://github.com/digitalocean/vulcan. Cela semble être le plus compliqué cependant.

Je travaille sur la lecture à distance maintenant.

Quelques questions/points pour @brian-brazil et. Al.:

• Je vais pour plusieurs points de terminaison de lecture à distance (via une configuration rechargeable), comme si nous avions plusieurs écrivains distants. Quelque chose qui s'oppose à ça ?
• Je ne prévois pas de prise en charge SD dans le premier passage, juste une URL statique.
• Quand interroger un point de terminaison distant sera configuré par point de terminaison comme une durée dans le passé (requête evth. antérieur à X) pour le moment si personne ne s'y oppose. Le stockage local sera interrogé pour l'ensemble de la plage de requêtes pour le moment, les résultats seront fusionnés/dédupliqués.
• La lecture à distance devrait-elle également avoir un réétiquetage ? Je laisserais probablement cela de côté au début.

Cool ! Ce serait intéressant de voir l'API que vous envisagez d'avoir. Ce que vous avez dit actuellement a l'air bien.

• Peut-être qu'à l'avenir, il serait intéressant d'avoir une option pour interroger le stockage distant jusqu'à la limite de début du stockage local (si nécessaire).
• Je suppose que vous prévoyez d'interroger le stockage distant à chaque fois pour le moment et nous verrons plus tard s'il existe une sorte de mise en cache (disque et/ou mémoire) ou non ?

@iksaif

Ce serait intéressant de voir l'API que vous envisagez d'avoir.

Cela ressemblera essentiellement à la requête/réponse de requête interne de Cortex : https://github.com/weaveworks/cortex/blob/master/cortex.proto#L24 -L28
https://github.com/weaveworks/cortex/blob/master/cortex.proto#L24 -L32

Nous l'enverrons sur HTTP simple, pas gRPC, cependant.

Peut-être qu'à l'avenir, il serait intéressant d'avoir une option pour interroger le stockage distant jusqu'à la limite de début du stockage local (si nécessaire).

Ce n'est pas très utile cependant, car le simple fait d'utiliser le temps de rétention ne signifie pas nécessairement que vous avez déjà des données dans Prometheus jusqu'au temps de rétention (comme lorsque vous effacez votre serveur Prometheus). De plus, votre serveur Prometheus peut présenter des lacunes aléatoires à différents moments, même s'il contient des données anciennes.

Je suppose que vous prévoyez d'interroger le stockage distant à chaque fois pour le moment et nous verrons plus tard s'il existe une sorte de mise en cache (disque et/ou mémoire) ou non ?

Oui, pour l'instant, il serait simplement interrogé chaque fois que vous effectuez une requête qui interroge des données antérieures à un âge configurable. Nous pouvons voir à faire quelque chose de plus intelligent plus tard.

Je vais pour plusieurs points de terminaison de lecture à distance (via une configuration rechargeable), comme si nous avions plusieurs écrivains distants. Quelque chose qui s'oppose à ça ? Je ne prévois pas de prise en charge SD dans le premier passage, juste une URL statique.

Ceux-ci sont essentiels, mais ne doivent pas nécessairement être en v1.

Nous aurons également besoin de la possibilité d'activer/désactiver la lecture à distance sur la base d'une requête/groupe de règles HTTP, et de l'ignorer à nouveau pour être forcé de toujours l'activer pour certains points de terminaison (pas LTS).

Quand interroger un point de terminaison distant sera configuré par point de terminaison comme une durée dans le passé (requête evth. antérieur à X) pour le moment si personne ne s'y oppose. Le stockage local sera interrogé pour l'ensemble de la plage de requêtes pour le moment, les résultats seront fusionnés/dédupliqués.

Pour la v1, j'interrogeais toujours tout.

Une simple durée statique n'est pas suffisante, car le stockage distant peut ne pas être rattrapé aussi loin ou Prometheus peut avoir une rétention plus ancienne. Je pense que c'est quelque chose que nous devrons comprendre au fil du temps pour les vrais LTS (je suppose que nous nous retrouverons avec min (période de rétention, lorsque le stockage local a été initialisé) ), et pour les non-LTS, vous voulez toujours interroger c'est donc la façon la plus simple de commencer.

La lecture à distance devrait-elle également avoir un réétiquetage ? Je laisserais probablement cela de côté au début.

C'est un peu compliqué. Nous n'aurons pas besoin de réétiquetage (c'est la responsabilité de l'autre extrémité). La sémantique des étiquettes que nous voulons consiste à ajouter des étiquettes externes par défaut et à les supprimer si nous les avons ajoutées. Cela peut éventuellement être traité un peu plus tard.

Nous devrons peut-être également transmettre directement les étiquettes externes, mais attendons un peu et voyons si cela est nécessaire, car j'espère que ce ne sera pas le cas.

Cela ressemblera essentiellement à la requête/réponse de requête interne de Cortex

LGTM

Ce n'est pas très utile cependant, car le simple fait d'utiliser le temps de rétention ne signifie pas nécessairement que vous avez déjà des données dans Prometheus jusqu'au temps de rétention (comme lorsque vous effacez votre serveur Prometheus). De plus, votre serveur Prometheus peut présenter des lacunes aléatoires à différents moments, même s'il contient des données anciennes.

C'est cependant, par exemple, nous exécutons prometheus sur marathon et chaque fois qu'une instance redémarre, elle se déplace vers un nouveau "disque" vide. C'est plus vrai pour les lacunes si vous avez des problèmes de réseau, mais je pense que cela améliorerait considérablement les performances des requêtes courantes si vous acceptez de perdre un peu de cohérence. Mais parlons des optimisations plus tard.

@brian-brazil Ok, je vais laisser de côté tout étiquetage foo et toujours interroger tout pour l'instant. La question est de savoir si nous voulons la détermination LTS par requête/règle dans la v1. Cela pourrait influencer un peu le design, alors j'y penserai au moins.

@iksaif ok ouais, donc vous ne parlez pas de la durée de rétention, mais du premier échantillon d'horodatage dans la base de données actuelle de Prometheus. Nous ne suivons pas cela actuellement, mais cela aurait généralement plus de sens, oui.

La question est de savoir si nous voulons la détermination LTS par requête/règle dans la v1. Cela pourrait influencer un peu le design, alors j'y penserai au moins.

Ce n'est pas la v1, mais c'est quelque chose que nous devrions avoir avant de commencer à utiliser la production car c'est essentiel pour la fiabilité.

@brian-brasil Bien sûr !

L'autre chose à considérer est que l'API autorise plusieurs sélecteurs de vecteurs (chacun avec leurs propres horodatages en raison de offset ), afin que les LTS puissent optimiser et mieux gérer la limitation/les abus.

@brian-brazil Oh oui, j'ai plusieurs ensembles de sélecteurs vectoriels, mais bon point sur les différents décalages !

Une simple durée statique n'est pas suffisante, car le stockage distant peut ne pas être rattrapé aussi loin ou Prometheus peut avoir une rétention plus ancienne. Je pense que c'est quelque chose que nous devrons comprendre

Je ne pense pas que Prometheus ait une rétention plus ancienne soit vraiment un problème ici, tant que la télécommande peut (déjà) fournir les données. Dans le pire des cas, avec le sous-échantillonnage, vous perdez de la granularité.

@pilhuhn Je voulais dire l'inverse: si vous avez une rétention Prometheus de 15d et que vous interrogez uniquement les données antérieures à 15d à partir du stockage distant, cela ne signifie pas nécessairement que Prometheus aura déjà toutes les données inférieures à 15d (en raison de lingette de stockage ou autre).

Eh bien, pour une première itération, nous allons simplement interroger toutes les plages de temps de partout.

Il existe un PR WIP pour l'intégration de la lecture à distance ici pour tous ceux qui souhaitent y jeter un coup d'œil : https://github.com/prometheus/prometheus/pull/2499

J'essaie d'utiliser remote_storage_adapter pour envoyer des métriques de prometheus à opentsdb. Mais j'obtiens ces erreurs dans les journaux :

WARN[0065] cannot send value NaN to OpenTSDB, skipping sample &model.Sample{Metric:model.Metric{"instance":"localhost:9090", "job":"prometheus", "monitor":"codelab-monitor", "location":"archived", "quantile":"0.5", "__name__":"prometheus_local_storage_maintain_series_duration_seconds"}, Value:NaN, Timestamp:1492267735191}  source=client.go:78

WARN[0065] Error sending samples to remote storage       err=invalid character 'p' after top-level value num_samples=100 source=main.go:281 storage=opentsdb

J'ai également essayé d'utiliser influxdb au lieu d'opentsdb, avec des résultats similaires :

EBU[0001] cannot send value NaN to InfluxDB, skipping sample &model.Sample{Metric:model.Metric{"job":"prometheus", "instance":"localhost:9090", "scrape_job":"ns1-web-pinger", "quantile":"0.99", "__name__":"prometheus_target_sync_length_seconds", "monitor":"codelab-monitor"}, Value:NaN, Timestamp:1492268550191}  source=client.go:76

Voici comment je démarre l'adaptateur remote_storage_adapter :

# this is just for influxdb, i make the appropriate changes if trying to use opentsdb
./remote_storage_adapter -influxdb-url=http://138.197.107.211:8086 -influxdb.database=prometheus -influxdb.retention-policy=autogen -log.level debug

Voici la configuration de Prometheus :

global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'codelab-monitor'

remote_write:
  url: "http://localhost:9201/write"

Y a-t-il quelque chose que je comprends mal sur la façon de configurer l'adaptateur remote_storage_adapter ?

@tjboring Ni OpenTSDB ni InfluxDB ne prennent en charge les valeurs float64 NaN (pas un nombre), donc ces échantillons sont ignorés lors de l'envoi d'échantillons. Nous avons mentionné ce problème à InfluxDB, et si nous avons de la chance, ils prendront en charge les valeurs NaN dans le futur, ou peut-être que nous pourrons trouver une autre solution de contournement.

Problème OpenTSDB : https://github.com/OpenTSDB/opensdb/issues/183
Problème InfluxDB : https://github.com/influxdata/influxdb/issues/4089

Je ne sais pas d'où vient l'erreur invalid character 'p' after top-level value .

@juliusv Merci pour les pointeurs sur les problèmes opentsdb/influxdb. Je voyais juste les messages d'erreur sur la console et je pensais que rien n'était écrit, sans me rendre compte que ce ne sont que des échantillons qui sont ignorés. J'ai depuis confirmé que les échantillons parviennent effectivement à la base de données de stockage distant. :)

Maintenant que les API de lecture et d'écriture à distance sont en place (bien qu'expérimentales), ce problème doit-il être clos au profit de problèmes plus spécifiques au fur et à mesure qu'ils surviennent ?

https://prometheus.io/docs/operating/configuration/#
https://prometheus.io/docs/operating/configuration/#

Un corps a essayé avec un conteneur? Veuillez coller Dockerfile

Parce que je ne parviens pas à trouver le fichier exécutable "remote_storage_adapter" dans le docker "prom/prometheus" version 1.6

/prometheus # find / -name remote_storage_adapter
/prometheus #

S'il te plaît

@prasenforu J'ai construit une image docker avec remote_storage_adapter à partir du code maître actuel : gra2f/remote_storage_adapter, n'hésitez pas à l'utiliser.

@juliusv J'ai des problèmes similaires à ceux de @tjboring :

time="2017-04-21T17:45:00Z" level=warning msg="impossible d'envoyer la valeur NaN à Graphite, ignorer l'échantillon &model.Sample{ Metric:model.Metric {\"__name__\":\"prometheus_target_sync_length_seconds\", \"monitor\":\"codelab-monitor\", \"job\":\"prometheus\", \"instance\":\" localhost:9090\ ", \"scrape_job\":\"prometheus\ ", \"quantile\":\"0.9\"}, Valeur :NaN , Horodatage :1492796695772 }" source="client.go:90"

mais j'utilise du graphite. Ça va?

@sans tristesse

Voyez-vous d'autres métriques dans Graphite dont vous savez qu'elles proviennent de Prometheus ?

Dans mon cas, j'ai vérifié cela en me connectant au serveur Influxdb que j'utilisais et en exécutant une requête. Cela m'a rendu des métriques, ce qui a confirmé que Prometheus écrivait bien des métriques ; c'est juste que certains ont été ignorés, selon le message du journal.

@tjboring oui, je peux voir certaines des métriques dans Graphite et ce qui est plus étrange pour moi, c'est que je ne peux pas comprendre pourquoi certaines sont là et d'autres pas. Par exemple, sy et us par CPU stocké dans Graphite mais la charge moyenne ne l'est pas.

@sans tristesse

Impossible de trouver l'image, pouvez-vous s'il vous plaît partager l'url.

Merci d'avance.

@prasenforu vient de courir
$ docker pull gra2f/remote_storage_adapter
dans votre ligne de commande, c'est tout ce dont vous avez besoin

@sans tristesse

Merci.

@mattbostock Comme vous l'avez suggéré, je ferme ce problème. Nous devrions ouvrir des problèmes liés au stockage à distance plus spécifiques à l'avenir.

D'autres questions d'utilisation sont mieux posées sur nos listes de diffusion ou IRC (https://prometheus.io/community/).

@sans tristesse

Je cherchais les images, j'ai vu qu'il y avait un fichier remote_storage_adapter dans /usr/bin

mais le reste du fichier et du volume de prometheus n'est pas là,

~ # find / -name remote_storage_adapter
/usr/bin/remote_storage_adapter
~ # find / -name prometheus.yml
~ # find / -name prometheus

Quoi qu'il en soit, pouvez-vous s'il vous plaît m'envoyer le fichier docker de "gra2f/remote_storage_adapter"

@prasenforu
vous n'avez pas besoin de l'exécutable principal de prometheus pour utiliser l'adaptateur de stockage à distance. Utilisez l'image prom/prometheus pour cela.
Ce qui concerne Dockerfile - tout ce qu'il fait est de copier remote_storage_adapter préconstruit dessus et de l'exécuter, c'est tout.

Si quelqu'un veut le tester (comme j'en ai besoin), j'ai écrit une petite configuration basée sur docker-compose pour le faire fonctionner localement - https://github.com/gdmello/prometheus-remote-storage.

Ce fil a été automatiquement verrouillé car il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème pour les bogues liés.