डिस्क पूर्ण होने तक दिनों की गणना करना

9

हम समय के साथ डिस्क उपयोग के इतिहास को ट्रैक करने के लिए ग्रेफाइट का उपयोग करते हैं। हमारी चेतावनी प्रणाली ग्रेफाइट के डेटा को देखती है ताकि हमें सूचित किया जा सके कि जब खाली स्थान एक निश्चित संख्या में ब्लॉक से नीचे आता है।

मैं होशियार अलर्ट प्राप्त करना चाहता हूं - मुझे वास्तव में क्या परवाह है "मैं कितने समय से पहले मुक्त स्थान के बारे में कुछ करना है?", उदाहरण के लिए अगर प्रवृत्ति दिखाती है कि 7 दिनों में मैं डिस्क से बाहर चला जाऊंगा? अंतरिक्ष तो एक चेतावनी बढ़ा, अगर यह 2 दिन से कम है तो एक त्रुटि बढ़ा।

ग्रेफाइट के मानक डैशबोर्ड इंटरफ़ेस डेरिवेटिव और होल्ट विंटर्स कॉन्फिडेंस बैंड के साथ बहुत स्मार्ट हो सकते हैं लेकिन अभी तक मुझे इसे एक्शनेबल मेट्रिक्स में बदलने का कोई तरीका नहीं मिला है। मैं अन्य तरीकों से संख्या को कम करने के साथ भी ठीक हूं (बस ग्रेफाइट से कच्चे नंबर निकालें और ऐसा करने के लिए एक स्क्रिप्ट चलाएं)।

एक जटिलता यह है कि ग्राफ सुचारू नहीं है - फाइलें जुड़ जाती हैं और हटा दी जाती हैं लेकिन समय के साथ सामान्य प्रवृत्ति डिस्क स्थान के उपयोग को बढ़ाने के लिए होती है, इसलिए शायद स्थानीय न्यूनतम देखने की आवश्यकता है (यदि "डिस्क मुक्त" मीट्रिक देख रहे हैं) ) और गर्तों के बीच एक प्रवृत्ति बनाएं।

क्या किसी ने ऐसा किया है?

disk-space-utilization monitoring graphite

— अमोस शपीरा
स्रोत

आपका इन्फ्रास्ट्रक्चर क्या है? उदाहरण के लिए यदि आप एक vmware घर हैं, तो आप उनके संचालन प्रबंधक उत्पादों को देख सकते हैं, जो डिस्क स्थान पर इस तरह का भविष्य कहनेवाला दृश्य है।

— चॉपर 3

The volume of crap people have to store will expand to fill the disk available.- पुराने Sysadmin Axiom

— voretaq7

हमारे सर्वर VMware VM के डिस्क्स के लिए IBM XIV का उपयोग कर रहे हैं, और KVM स्थानीय SD का उपयोग कर के बीच विभाजित हैं। मुझे यकीन नहीं है कि हमारे पास इस तरह की जानकारी है (मेरी टीम VMware या XIV का प्रबंधन नहीं करती है) और उत्पाद-स्वतंत्र समाधान पसंद करेगी।

— अमोस शापिरा

8

ईमानदारी से "डेज तक फुल" वास्तव में एक घटिया मीट्रिक है वैसे भी - फाइल सिस्टम को 100% उपयोग के दृष्टिकोण के रूप में वास्तव में स्पष्ट रूप से मिलता है।
मैं वास्तव में पारंपरिक 85%, 90%, 95% थ्रेसहोल्ड (चेतावनी, अलार्म, और महत्वपूर्ण आप-वास्तव में जरूरत-से-तय-यह-अब, क्रमशः) का उपयोग करने की सलाह देता हूं - यह आपको आधुनिक डिस्क पर बहुत सारे चेतावनी समय देना चाहिए (मान लें कि 1TB ड्राइव: एक टेराबाइट का 85% हिस्सा अभी भी आपके पास बहुत सारी जगह छोड़ता है, लेकिन आप एक संभावित समस्या से अवगत हैं, 90% तक आपको डिस्क विस्तार या कुछ अन्य शमन की योजना बनानी चाहिए, और 95% टेराबाइट पर आपके पास 50GB बचा हुआ है और अच्छी तरह से गति में एक ठीक होना चाहिए)।

यह भी सुनिश्चित करता है कि आपका फाइलसिस्टम अधिक-या-कम आशावादी रूप से कार्य करता है: इसके पास बहुत अधिक खाली स्थान है जिससे अन्य फ़ाइलों को बनाने / संशोधित करने / चलाने में आसानी होती है।

यदि आपके डिस्क आधुनिक नहीं हैं (या आपके उपयोग के पैटर्न में डिस्क पर बड़ी मात्रा में डेटा डाला जा रहा है) तो आप आसानी से थ्रेसहोल्ड समायोजित कर सकते हैं।

यदि आप अभी भी "दिनों तक पूर्ण" का उपयोग करने पर सेट हैं, तो आप ग्रेफाइट से डेटा निकाल सकते हैं और उस पर कुछ गणित कर सकते हैं। आईबीएम के निगरानी उपकरण कई दिनों तक-पूर्ण मैट्रिक्स को लागू करते हैं जो आपको यह अनुमान लगा सकता है कि इसे कैसे लागू किया जाए, लेकिन मूल रूप से आप इतिहास में दो बिंदुओं के बीच परिवर्तन की दर ले रहे हैं।

अपनी पवित्रता के लिए आप ग्रेफाइट से व्युत्पन्न का उपयोग कर सकते हैं (जो आपको समय के साथ परिवर्तन की दर देगा) और उस का उपयोग करके परियोजना, लेकिन अगर आप वास्तव में "होशियार" अलर्ट चाहते हैं, तो मैं दैनिक और साप्ताहिक दर परिवर्तन का उपयोग करने की सलाह देता हूं (गणना की गई) दिन / सप्ताह के लिए चरम उपयोग के आधार पर)।

आपके द्वारा उपयोग किया जाने वाला विशिष्ट प्रक्षेपण (परिवर्तन की सबसे छोटी दर, परिवर्तन की सबसे बड़ी दर, परिवर्तन की औसत दर, भारित औसत, आदि ....) आपके वातावरण पर निर्भर करता है। आईबीएम के उपकरण इतने सारे अलग-अलग विचार पेश करते हैं क्योंकि एक आकार-फिट-सभी पैटर्न को नीचे रखना मुश्किल है।

अंततः कोई भी एल्गोरिथ्म उस तरह की गणना करने में बहुत अच्छा नहीं है जो आप चाहते हैं। डिस्क का उपयोग उपयोगकर्ताओं द्वारा संचालित होता है, और उपयोगकर्ता तर्कसंगत अभिनेता मॉडल के विरोधी होते हैं: आपकी सभी भविष्यवाणियां एक पागल व्यक्ति के साथ खिड़की से बाहर जा सकती हैं, यह निर्णय लेते हुए कि आज वह दिन है जब वे एक पूर्ण सिस्टम मेमोरी डंप करने जा रहे हैं घरेलू निर्देशिका। सिर्फ इसलिए कि।

— voretaq7
स्रोत

आपकी अंतर्दृष्टि के लिए धन्यवाद। मैं आपकी बातों को देखता हूं। मुझे अभी भी लगता है कि निरंतर थ्रेसहोल्ड केवल यह दर्शाने की कोशिश करते हैं कि "मुझे कितने समय के लिए छूट मिली है?" और अपनी "अपनी दहलीज को समायोजित करें" टिप्पणी से कुछ हद तक प्रेरित महसूस करें। सरल ग्रेफाइट डेरिवेटिव काम नहीं करता है क्योंकि मूल ग्राफ सुचारू नहीं है। आईबीएम के टूल के लिए पॉइंटर के लिए धन्यवाद, जो आप ध्वनियों का वर्णन करते हैं जैसे मैं क्या सोचने लगा था (अंतिम दो न्यूनतम निकालें और उनसे ढलान की गणना करें)।

— अमोस शापिरा

निश्चित रूप से 'डेज़ टू फुल' मीट्रिक की बात यह है कि स्थिर 85/90/95 थ्रेसहोल्ड के साथ, आपको पता नहीं है कि डिस्क कितनी तेजी से भर रही है? निश्चित रूप से, आप एक संभावित समस्या से अवगत हैं, लेकिन आप यह कैसे जान सकते हैं कि आपके पास इसे संबोधित करने के लिए दिन हैं या सप्ताह / महीने हैं?

मुझे यह वास्तव में दिलचस्प लगता है कि आपकी यह राय होगी। मुझे इसे इस तरह से फ्रेम करने दें: आपकी कंपनी के पास एक खरीद प्रक्रिया है जो दिन के लिए अधिक हार्ड ड्राइव के लिए प्रारंभिक अनुरोध के बीच लगभग 6 सप्ताह का समय लेती है जो कि हार्ड ड्राइव वास्तव में बक्से में स्थापित होते हैं और लोड पुनर्वितरण होने लगते हैं। यह देखते हुए कि समय पर स्थापित डिस्क को प्राप्त करने में सक्षम होने के लिए आपको किस डिस्क% पर 6 सप्ताह की समय सीमा की आवश्यकता है? 80%? 75%? इस तथ्य का तथ्य यह है कि आप तब तक नहीं जानते जब तक आप विकास दर की गणना में कुछ प्रयास नहीं करते।

— JHixson 16

2

हमने हाल ही में रैखिक रिग्रेशन का उपयोग करते हुए इसके लिए एक कस्टम समाधान निकाला है।

हमारे सिस्टम में डिस्क थकावट का प्राथमिक स्रोत आवारा लॉग फाइलें हैं जिन्हें घुमाया नहीं जा रहा है।

चूंकि ये बहुत अनुमानित रूप से बढ़ते हैं, हम डिस्क उपयोग पर एक रेखीय प्रतिगमन (उदाहरण के लिए z = numpy.polyfit(times, utilization, 1)) कर सकते हैं, फिर रेखीय मॉडल (जैसे, (100 - z[1]) / z[0]) दिए गए 100% अंक की गणना करें।

तैनात कार्यान्वयन रूबी और जीएसएल का उपयोग करके इस तरह दिखता है , हालांकि सुन्न काम भी काफी अच्छी तरह से करता है।

एक सप्ताह के औसत उपयोग के डेटा को 90 मिनट के अंतराल (112 अंक) पर फीड करना, डिस्क थकावट के लिए संभावित उम्मीदवारों को अब तक बहुत अधिक शोर के बिना बाहर निकालने में सक्षम है।

जिस्ट में वर्ग को एक वर्ग में लपेटा जाता है जो स्काउट से डेटा खींचता है, सुस्त करने के लिए अलर्ट करता है और कुछ रनटाइम टेलीमेट्री को सांख्यिकी में भेजता है। मैं उस बिट को छोड़ दूंगा क्योंकि यह हमारे बुनियादी ढांचे के लिए विशिष्ट है।

— matschaffer
स्रोत

मैंने उत्तर को कुछ जानकारी के साथ अद्यतन किया है जो अब हमारे पास है।

— मात्सचैफ़र

1

बस इस दृष्टिकोण के साथ एक अजीब गोटा मिला। हमारे पास 90% अलार्म भी हैं। हमारा एक मेजबान बढ़ रहा था इसलिए धीरे-धीरे यह 90% तक पहुंच गया और उस अलार्म को चालू कर दिया, भले ही यह 100% मारने से पहले एक सप्ताह से अधिक हो गया था, ताकि भविष्य कहनेवाला चेतावनी कभी भी निकाल न जाए;) लगता है कि मुझे (90 - z[1]) / z[0]इसके बजाय उपयोग करना चाहिए ।

— मत्सचैफर