Planification de la capacité du disque pour Whisper / Graphite

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?

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 ...)

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 .

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!" :-)

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.