calcul des jours jusqu'à ce que le disque soit plein


9

Nous utilisons du graphite pour suivre l'historique de l'utilisation du disque au fil du temps. Notre système d'alerte examine les données du graphite pour nous alerter lorsque l'espace libre tombe en dessous d'un certain nombre de blocs.

J'aimerais recevoir des alertes plus intelligentes - ce qui m'importe vraiment , c'est "combien de temps ai-je avant de faire quelque chose pour l'espace libre?", Par exemple si la tendance montre que dans 7 jours, je serai à court de disque espace puis déclencher un avertissement, si c'est moins de 2 jours puis déclencher une erreur.

L'interface de tableau de bord standard de Graphite peut être assez intelligente avec les dérivés et les bandes de confiance Holt Winters, mais jusqu'à présent, je n'ai pas trouvé de moyen de convertir cela en mesures exploitables. Je suis également d'accord pour croquer les chiffres d'autres façons (il suffit d'extraire les chiffres bruts du graphite et d'exécuter un script pour le faire).

Une complication est que le graphique n'est pas fluide - les fichiers sont ajoutés et supprimés mais la tendance générale au fil du temps est d'augmenter l'utilisation de l'espace disque, donc il est peut-être nécessaire de regarder les minimums locaux (si vous regardez la métrique "sans disque") ) et tracer une tendance entre les creux.

Quelqu'un a-t-il fait cela?


quelle est votre infrastructure? par exemple, si vous êtes une maison de vmware, vous pouvez regarder leurs produits Operations Manager qui font ce genre de vue prédictive sur l'espace disque.
Chopper3

The volume of crap people have to store will expand to fill the disk available.- Old Sysadmin Axiom
voretaq7

Nos serveurs sont répartis entre les VM VMware utilisant IBM XIV pour les disques et les KVM utilisant les SD locales. Je ne suis pas sûr que nous ayons accès à ce type d'informations (mon équipe ne gère pas VMware ou XIV) et préférerais une solution indépendante du produit.
Amos Shapira

Réponses:


8

Honnêtement, "Days Until Full" est vraiment une métrique moche de toute façon - les systèmes de fichiers deviennent vraiment stupides à l'approche de l'utilisation à 100%.
Je recommande vraiment d'utiliser les seuils traditionnels de 85%, 90% et 95% (avertissement, alarme et critique que vous avez vraiment besoin de réparer cela MAINTENANT, respectivement) - cela devrait vous donner beaucoup de temps d'avertissement sur les disques modernes (disons un lecteur de 1 To: 85% d'un téraoctet vous laisse encore beaucoup d'espace mais vous êtes conscient d'un problème potentiel, à 90% vous devriez planifier une extension de disque ou une autre atténuation, et à 95% d'un téraoctet il vous reste 50 Go et vous devriez avoir un correctif en mouvement).

Cela garantit également que votre système de fichiers fonctionne de manière plus ou moins optimale: il dispose de beaucoup d'espace libre pour gérer la création / modification / déplacement de gros fichiers.

Si vos disques ne sont pas modernes (ou si votre modèle d'utilisation implique de plus grandes quantités de données jetées sur le disque), vous pouvez facilement ajuster les seuils.


Si vous êtes toujours prêt à utiliser une métrique "jours jusqu'à complet", vous pouvez extraire les données du graphite et faire quelques calculs. Les outils de surveillance d'IBM implémentent plusieurs mesures jusqu'à la fin, ce qui peut vous donner une idée de la façon de l'implémenter, mais en gros, vous prenez le taux de changement entre deux points de l'historique.

Pour votre santé mentale, vous pouvez utiliser le dérivé du graphite (qui vous donnera le taux de changement au fil du temps) et projeter en utilisant cela, mais si vous voulez VRAIMENT des alertes "plus intelligentes", je suggère d'utiliser le taux de changement quotidien et hebdomadaire (calculé sur la base d'une utilisation maximale pour la journée / la semaine).

La projection spécifique que vous utilisez (taux de variation le plus faible, taux de variation le plus élevé, taux de variation moyen, moyenne pondérée, etc.) dépend de votre environnement. Les outils d'IBM offrent tant de vues différentes, car il est vraiment difficile de définir un modèle unique.


En fin de compte, aucun algorithme ne sera très bon pour faire le type de calcul que vous souhaitez. L'utilisation du disque est dirigée par les utilisateurs, et les utilisateurs sont l'antithèse du modèle Rational Actor: toutes vos prédictions peuvent sortir de la fenêtre avec une personne folle décidant qu'aujourd'hui est le jour où ils vont effectuer un vidage de mémoire système complet vers leur répertoire personnel. Juste parce que.


Merci pour vos idées. Je vois vos points. Je pense toujours que des seuils constants essaient simplement de refléter "combien de temps ai-je pour corriger?" et se sentir quelque peu justifié par votre commentaire "ajustez vos seuils". Les dérivés simples du graphite ne fonctionnent pas car le graphique d'origine n'est pas lisse. Merci pour le pointeur sur les outils IBM, ce que vous décrivez ressemble à ce à quoi j'ai commencé à penser (extraire les deux derniers minimums et calculer la pente à partir d'eux).
Amos Shapira

Assurément, le point d'une métrique «jours à plein» est qu'avec des seuils statiques 85/90/95, vous n'avez aucune idée de la vitesse à laquelle le disque se remplit? Bien sûr, vous êtes conscient d'un problème potentiel, mais comment savoir si vous avez des jours pour le résoudre ou des semaines / mois?

Je trouve vraiment intéressant que vous ayez cette opinion. Permettez-moi de formuler les choses de cette façon: votre entreprise a un processus d'approvisionnement qui prend environ 6 semaines entre la demande initiale de plus de disques durs et le jour où ces disques durs sont effectivement installés dans les boîtes et la redistribution de la charge commence à avoir lieu. Étant donné que le délai de 6 semaines à quel% de disque avez-vous besoin d'être averti pour pouvoir installer un disque à temps? 80%? 75%? Le fait est que vous ne savez pas à moins que vous ne vous efforciez de calculer le taux de croissance.
JHixson

2

Nous avons récemment déployé une solution personnalisée pour cela en utilisant la régression linéaire.

Dans notre système, la principale source d'épuisement du disque est les fichiers journaux errants qui ne sont pas tournés.

Étant donné que ceux-ci croissent de manière très prévisible, nous pouvons effectuer une régression linéaire sur l'utilisation du disque (par exemple, z = numpy.polyfit(times, utilization, 1)) puis calculer la marque de 100% compte tenu du modèle linéaire (par exemple, (100 - z[1]) / z[0])

L'implémentation déployée ressemble à ceci en utilisant ruby ​​et GSL, bien que numpy fonctionne également très bien.

L'alimentation de cette valeur hebdomadaire de données d'utilisation moyenne à 90 minutes d'intervalle (112 points) a été en mesure de sélectionner des candidats probables pour l'épuisement du disque sans trop de bruit jusqu'à présent.

La classe dans l'essentiel est enveloppée dans une classe qui extrait les données du scout, alerte pour ralentir et envoie des données de télémétrie d'exécution à statsd. Je vais laisser ça de côté car c'est spécifique à notre infrastructure.


J'ai mis à jour la réponse avec quelques informations maintenant que nous l'avons déployée.
matschaffer

1
Je viens de trouver un piège drôle avec cette approche. Nous avons également 90% d'alarmes. L'un de nos hôtes grandissait si progressivement qu'il atteignait 90% et déclenchait cette alarme même s'il restait plus d'une semaine avant de se déclencher à 100%, donc l'alerte prédictive ne s'est jamais déclenchée;) Je suppose que je devrais utiliser à la (90 - z[1]) / z[0]place.
matschaffer
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.