VPN सर्व्हरची डिस्क वाढ कुठून येते आणि ती कशी मर्यादित करावी

टनेलने कनेक्शन स्वीकारणे थांबवते, सेवा दोन वेळा पुन्हा सुरू होते आणि त्यानंतर तिच्या लॉगमध्ये काहीही दिसत नाही। तोच शांतपणा हा सुगावा आहे, कारण डिस्क भरणारा लॉगच आहे आणि तुम्ही प्रतीक्षा करत असलेली त्रुटी लिहिण्यासाठी डेमनकडे जागा नाही। कोणतीही दीर्घकाळ चालणारी सेवा या स्थितीत पोहोचू शकते, आणि logs नावाची डिरेक्टरी हटवल्याने ते क्वचितच सुधारते। टिकाऊ उपाय म्हणजे कोणते भांडार वाढले, त्याच्या धारणा धोरणाचा मालक कोण आहे आणि लेखकाने खरोखर जागा सोडली का हे जाणून घेणे।

वाढलेले भांडार आणि ते ज्या दराने वाढले तो शोधा

विसरण्यास सोप्या दोन संख्यांपासून सुरुवात करा: मुक्त ब्लॉक आणि मुक्त inode। फाइलसिस्टम भरपूर जागा सांगू शकते आणि तरीही लिहिण्यास नकार देऊ शकते, कारण inode शिल्लक नाहीत, आणि हे तेव्हा होते जेव्हा सेवा प्रत्येक सत्रासाठी एक फाइल तयार करते। दोन्ही रीडिंग एकाच व्हॉल्यूमवर मागा, कारण उत्तरे त्याच दुपारी वेगळी पडू शकतात। होस्ट निरोगी असताना हे करा, जेणेकरून संख्या सामान्य कार्यरत स्थिती दर्शवतील, खंड नाही।

df -h /var
df -i /var

नंतर वाढीचे श्रेय मालकाला द्या। journalची स्वतःची वापर संख्या केवळ journal ला व्यापते आणि ती त्याच्या कॉन्फिगरेशन फाइलमधील मार्गावर लिहिणाऱ्या डेमनला कधीही पाहणार नाही।

journalctl --disk-usage

कालांतराने होणारी वाढ कोणत्याही एका रीडिंगपेक्षा अधिक सांगते। सुरू ठेवलेला डीबग स्तर, प्रत्येक प्रयत्नाची नोंद करणारा पुनःप्रयत्न लूप, किंवा कोणीही न थांबवलेली कॅप्चर फाइल: यापैकी प्रत्येक एका क्षणी सामान्य आणि एका तासानंतर चिंताजनक वाटू शकते। एक रीडिंग घ्या, व्यस्त कालावधी थांबा, दुसरी घ्या आणि अंतराने भागा। तुम्ही सांगू शकता असा दर क्षमतेला आगीऐवजी निर्णय बनवतो।

रोटेशन उघड्या फाइलला काय करते

लॉग फाइल हे inode कडे निर्देश करणारे नाव आहे आणि जागा केवळ शेवटचे उघडे हँडल बंद झाल्यावर परत येते। फाइलचे नाव बदला, लेखक तोच inode भरत राहतो; ती हटवा, लेखक पूर्णपणे नाव नसलेला inode भरत राहतो। या स्थितीमुळेच 'मी फाइल हटवली पण डिस्क भरलेलीच राहिली' हे वाक्य तुटलेल्या फाइलसिस्टमबद्दल नाही तर फाइल डिस्क्रिप्टरबद्दल बोलते। लेखक पुन्हा सुरू करणे, किंवा फाइल पुन्हा उघडणारी रोटेशन पद्धत निवडणे, हेच ब्लॉक खरोखर परत देते।

lsof +L1 | head

धोरण फाइल लिहिणाऱ्या घटकाचे असते। journal त्याच्या कॉन्फिगरेशन फाइलमधून स्वतःच्या साठवण मर्यादा लागू करते, तर फाइल-आधारित सेवा सामान्यतः logrotate वर अवलंबून असते, एकतर तयार करण्याचा नियम आणि पुन्हा उघडण्याचा संकेत, किंवा लेखक पुन्हा उघडू शकत नसल्यास जागेवरच छाटण्याची पद्धत। आधी काहीही न बदलता निर्णयाची खात्री करा:

logrotate -d /etc/logrotate.conf

मर्यादा कुठे असावी आणि किती मोठी असावी

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

ती मर्यादा तुम्ही समर्थनीय धारणेतून ठरवा, उपलब्ध मोकळ्या जागेवरून नाही। पुनरावलोकनासाठी आठवडाभराच्या कनेक्शन प्रयत्नांची आवश्यकता असल्यास, journal ने सर्वाधिक व्यस्त अपेक्षित दराने आठवडाभर ठेवावे, आणि तो दर म्हणजे आधी मोजलेली संख्या।

डीबग लॉगिंग ही सुरुवातीची वेळ नोंदवलेली तात्पुरती पद्धत आहे, साठवण योजना नाही। गोपनीयतेचा प्रश्न त्याच निर्णयात ठेवा, कारण कनेक्शन लॉग पत्ते आणि ओळखकर्ते वाहतात। दीर्घ धारणा ही देखील माहिती हाताळणीची निवड आहे आणि ती दोन्ही मर्यादा जाणणाऱ्या व्यक्तीने घ्यावी।

रीस्टार्टनंतर मर्यादा तपासा

पुढील रीबूटपर्यंत टिकणारा धारणा बदल हा बदल नाही। लेखक पुन्हा सुरू करा, नवीन मर्यादा लागू होते याची खात्री करा आणि त्यानंतरही रोटेशन चालते का ते तपासा। journal साठी, एक रीस्टार्ट आणि एक वापर रीडिंग दोन्ही प्रश्नांची उत्तरे देतात:

systemctl restart systemd-journald
journalctl --disk-usage

फाइल-आधारित सेवेसाठी, रोटेशनचे काम एकदा हाताने चालवा आणि फाइल बदलली गेली व डिस्क्रिप्टर पुन्हा उघडले गेले याची खात्री करा। जुने हँडल ठेवणारा लेखक वरवरच्या तपासणीत उत्तीर्ण होतो आणि पुढील वेळी व्हॉल्यूम भरल्यावर अयशस्वी होतो। चाचणीदरम्यान मोकळी जागा पहा, कारण फाइल लहान झाली पण जागा परत आली नाही म्हणजे जुना inode अजून धरलेला आहे।

पुढील रीडिंगची याशी तुलना करा

आठवडाभरानंतर परत या आणि वाढीच्या दराची नोंदवलेल्या दराशी तुलना करा। जुळणारा दर म्हणजे मर्यादा टिकते आणि भार स्थिर आहे; दुप्पट दर म्हणजे काहीतरी बदलले आहे, आणि उपयुक्त प्रश्न हा आहे की काय। आधी वारंवार होणाऱ्या अपयशांसाठी लॉगचा आशय वाचा, कारण पुनःप्रयत्न लूप एकाच वेळी लक्षण आणि प्रमाणाचे कारण आहे। नंतर नव्याने सक्षम केलेली सर्व गोष्टी तपासा, घटनेदरम्यान सुरू केलेले आणि कधीही बंद न केलेले डीबग स्तर यासह।

बॅकअप त्याच व्हॉल्यूमबाहेर ठेवा, किंवा एक भरलेली डिस्क बॅकअपही घेऊन जाईल हे मान्य करा। ज्या होस्टचे ते संरक्षण करते त्यावरच लिहिलेली प्रत ही पुनर्प्राप्ती योजना नाही, आणि तिच्या धारणेला स्वतःचे उत्तर हवे आहे।

काय, कुठे, किती काळ ठेवले जाते आणि कोण ते काढते हे लिहून ठेवा। तेच वाक्य हा निकाल आहे, आणि या कामाचा पुढील रीस्टार्टपर्यंत टिकणारा एकमेव भाग आहे।