Planification de la capacité du disque pour Whisper / Graphite

14

Quelqu'un a-t-il des formules, ou peut-être des exemples de données de son environnement qui peuvent m'aider à estimer l'espace disque utilisé par le graphite par point de données?

monitoring graphite Kyle Brandt
la source
2
Assurez-vous également de planifier correctement les E / S de votre disque, et pas seulement la capacité de votre disque. rrdtool a, au fil des ans, accumulé beaucoup de micro-optimisations qui le rendent beaucoup plus rapide (2x plus rapide?) sur les écritures que le format de base de données Whisper de Graphite. Si vous prévoyez de conserver toutes vos données sur un SSD décent, cela vous permettra de faire la plupart du chemin, mais je ne prévois pas de garder une tonne de bases de données Whisper sur le disque en rotation. À grande échelle, il n'est tout simplement pas rentable que les niveaux d'E / S de disque lancés par Graphite.
jgoldschrafe

Réponses:

7

whisper-info.py vous donne beaucoup d'informations sur quoi et comment chaque fichier est agrégé, y compris la taille du fichier.

Cependant, il n'est utile que pour les fichiers murmures existants.

Lorsque vous souhaitez voir le dimensionnement prédictif d'un schéma avant de le mettre en place, essayez une calculatrice Whisper, telle que celle disponible sur https://gist.github.com/jjmaestro/5774063

ÉDITER:

Lorsqu'on lui a demandé un exemple ...

schéma_stockage:

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

En regardant mon dossier applied-in-last-hour.wsp, les ls -lrendements

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

et whisper-info.py ./applied-in-last-hour.wsprendements

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

Donc, fondamentalement, vous combinez vos hôtes par correspondance de rétention par segment de période de rétention par statistique, multipliez par un facteur de systèmes que vous avez l'intention d'appliquer également, comptez le nombre de nouvelles statistiques que vous allez suivre. Ensuite, vous prenez toute la quantité de stockage qui est et au moins le double (parce que nous achetons du stockage, et nous savons que nous allons l'utiliser ...)

gWaldo
la source
Toutes les chances que vous en ayez quelques exemples (associés à des paramètres de conservation). En ce moment, je pense à différents magasins de données de séries chronologiques en termes d'utilisation du disque - donc obtenir du graphite en direct pour cela est un peu un todo.
Kyle Brandt
@KyleBrandt Réponse mise à jour.
gWaldo
Merci pour cela. Donc, avec la taille du fichier, est-ce que ce sera après une heure de collecte de données, ou est-ce que la taille du fichier sera presque toujours? Alors, 4415092 est-il représentatif de 5 années de données de cette rétention, ou est-ce représentatif d'une heure de 1 minute de données? Est-ce aussi des octets ou des bits?
Kyle Brandt
Il s'agit d'une nouvelle implémentation dans cette entreprise et je n'ai pas accès à l'ancienne. Étant donné que le résultat fileSize de niveau supérieur correspond au ls -lrésultat, je considère que ce sont des octets. Lorsque j'additionne les tailles des archives dans le fichier .wsp (comme indiqué par whisper-info.py), elles se rapprochent de la taille globale du fichier .wsp (le reste, je suppose qu'il s'agit de métadonnées et autres. Cela devrait être la taille du fichier pour tous temps, car les données tombent à des résolutions de données plus basses et les anciens points de données sont supprimés.
gWaldo
D'accord, donc avec ces paramètres de rétention. En gros:ServerCount * MetricCount * 4.5MBytes
Kyle Brandt
2

Dans la documentation de statsd, ils donnent un exemple de politique de conservation des données.

Les rétentions sont ce 10s:6h,1min:7d,10min:5yqui est 2160 + 10080 + 262800 = 275040 points de données et ils donnent une taille de l' archive de 3,2 MiB .

En supposant une relation linéaire, cela représenterait environ 12,2 octets par point de données .

AndreKR
la source
Les paires ops-school.readthedocs.org/en/latest/monitoring_201.html (horodatage, valeur) sont stockées sous la forme d'une valeur longue et d'une valeur double consommant 12 octets par paire. La différence de 0,2 est probablement due à la surcharge d'informations sur les métadonnées du fichier?!
user27465
1

Aucune expérience directe avec Graphite, mais j'imagine que la même logique que celle que nous avons utilisée pour Cacti ou tout autre élément piloté par RRD ou par retournement temporel s'appliquerait (Graphite n'utilise plus RRD en interne mais la logique de stockage semble comparable.)

La réponse rapide est "Probablement pas autant d'espace que vous pensez en avoir besoin."

La réponse longue implique des calculs spécifiques au site. Pour notre système de surveillance (InterMapper), je détermine les périodes de rétention, les résolutions et la taille des points de données, je multiplie et j'ajoute des frais généraux.

À titre d'exemple, je vais utiliser l'espace disque - nous stockons des chiffres avec une précision de 5 minutes pendant 30 jours, une précision de 15 minutes pendant 60 jours supplémentaires, puis une précision horaire pendant 300 jours supplémentaires, et nous utilisons un 64 -bit (8 octets) entier pour le stocker:

  • 21600 échantillons au total, répartis comme suit:
    • 8640 échantillons pour une précision de 30 jours sur 5 minutes
    • 5760 échantillons pour une précision de 60 jours sur 15 minutes
    • 7200 échantillons pour une précision d'une heure sur 300 jours

À 8 octets par échantillon, cela représente environ 173 Ko, plus une surcharge saine pour l'indexation du stockage, etc., ce qui le porte à environ 200 Ko pour les données d'utilisation du disque d'une partition (toute erreur tendant à la surestimation).

À partir des mesures de base, je peux calculer une taille moyenne «par machine» (10 partitions de disque, espace de swap, RAM, moyenne de charge, transfert réseau et quelques autres choses) - cela représente environ 5 Mo par machine.

J'ajoute également un bon 10% en plus du nombre final et arrondis, donc je dimensionne les choses à 6 Mo par machine.

Ensuite, je regarde l'espace de 1 To que j'ai pour stocker les données de métriques pour la cartographie et je dis "Ouais, je ne manquerai probablement pas de stockage de mon vivant à moins que nous ne grandissions beaucoup!" :-)

voretaq7
la source
1
Pour jeter un certain nombre de pratiques réelles, avec mes politiques de rétention de la production (9 mois à 5 minutes; 1 an toutes les heures; 5 ans au quotidien) et environ 20 machines avec environ 20 mesures de 8 octets chacune, plus l'avertissement / alarme / historique des événements critiques / pannes depuis 5 ans J'utilise 1,5 G d'espace disque. C'est avec InterMapper tout insérer dans une base de données Postgres. Encore une fois - la réponse rapide est "probablement pas autant d'espace que vous pensez en avoir besoin" :-)
voretaq7
Ya, que les mathématiques sont simples, je regarde vraiment plus sur la façon dont Graphite stocke les données - peut faire des différences majeures à l'échelle. La seule chose que j'ai trouvée, c'est que selon la documentation, elle n'est pas très peu encombrante (probablement parce qu'elle compte sur des rollups assez agressifs).
Kyle Brandt
Whisper (le back-end de stockage utilisé par Graphite) a des éléments intégrés à mâcher dans l'espace - vous avez probablement déjà vu cette page. La section sur les «périodes de chevauchement des archives» me tient à coeur car cela signifie que les archives sont plus grandes que mes exemples ci-dessus car elles remontent toutes au début du temps (l'archive de 60 jours est en fait de 90 jours; l'archive de 300 jours est 390 jours). Whisper conserve également un horodatage (4 ou 8 octets) avec chaque point de données qui doit également être ajouté. Cela n'a pas l'air compliqué, juste gonflé :)
voretaq7
0

J'ai 70 nœuds qui génèrent beaucoup de données. En utilisant Carbon / Whisper, un nœud a créé 91k fichiers seul (le nœud génère plusieurs schémas ayant chacun plusieurs compteurs et champs variables qui doivent être sélectionnables. Par exemple: (nom de nœud). (Schéma). (Compteur). (Sous-compteur). (Etc.) )....etc).

Cela a fourni la granularité dont j'avais besoin pour tracer n'importe quel graphique que je veux. Après avoir exécuté le script pour remplir les 69 nœuds restants, j'avais 1,3 To de données sur le disque. Et cela ne vaut que 6 heures de données / nœud. Ce qui m'obtient, c'est que le fichier csv plat réel pour 6 heures de données est d'environ 230 Mo / nœud. 70 nœuds, c'est ~ 16 Go de données. Mon schéma de stockage était de 120 s: 365 j.

Je suis relativement nouveau dans les bases de données, donc je fais peut-être quelque chose de mal, mais je suppose que c'est tout le surcoût pour chaque échantillon.

C'était donc une expérience amusante, mais je ne pense pas qu'il soit logique d'utiliser le chuchotement pour le type de données que je stocke. MongoDB semble être un meilleur soluton, mais j'ai besoin de comprendre comment l'utiliser comme backend pour Grafana.

musca999
la source