कामाची स्थिती यश सांगते, लॉग पूर्ण झालेला रन दाखवतो, आणि डेटा जुना किंवा अनुपस्थित आहे. हे संयोजन सहसा सांगते की नियोजित कामाला आवश्यक असलेल्या मार्गाशिवाय सुरुवात झाली, आणि खाली काहीतरी अपयश गिळून गेले. वेळेवर चालणारे वेळापत्रक नेटवर्क तयार होते की नाही याबद्दल काहीही सांगत नाही. या दोन तथ्यांमधील अंतर हीच ती जागा आहे जिथे हे अपयश राहते.

प्रवेश रनचा आहे, cron फाइलच्या अस्तित्वाचा नाही.

हिरवा रन पूर्ण झालेले काम नाही

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

कसे तपासायचे हे ठरवण्यापूर्वी रनला प्रत्यक्षात काय हवे आहे त्याला नाव द्या. बॅकअपला खाजगी DNS आणि प्रमाणित एंडपॉइंट लागू शकते, केवळ टनेल प्रक्रिया नाही.

कनेक्शन तपासा, इंटरफेसचे नाव नाही

tun0 नावाचा इंटरफेस महत्त्वाच्या सत्राशिवाय अस्तित्वात असू शकतो, आणि दुसरे कनेक्शन त्या नावाचे मालक असू शकते. काम ज्या विशिष्ट वस्तूवर अवलंबून आहे ती तपासा: एक प्रोफाइल ओळख, एक सेवा उदाहरण, किंवा संसाधनाविरुद्ध एक छोटे मंजूर ऑपरेशन. तपासणी वेळेच्या मर्यादेत ठेवा, आणि क्रेडेन्शियल्स प्रक्रिया आर्ग्युमेंट्स आणि निदान लॉगपासून दूर ठेवा.

डिस्कनेक्टचा निकाल देखील परिभाषित करा. सामान्य वगळणे, लहान खिडकीत पुन्हा प्रयत्न, आणि ऑपरेटरला दिसणारी चुकलेली मुदत ही तीन वेगळी उत्तरे आहेत, आणि आवर्ती वेळापत्रक त्यांच्यात निवड करत नाही.

वगळणे आणि अपयश वेगवेगळे निकाल आहेत

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

systemd तैनातीत, ExecCondition= कामाच्या भारापूर्वी तो तपासणीकर्ता चालवतो. त्याचे बाहेर पडण्याचे वर्तन विशिष्ट आहे: शून्य पुढे जाते, एक ते 254 पर्यंतचे कोड युनिटला अपयशी चिन्हांकित न करता उर्वरित सुरू आदेश वगळतात, आणि 255 किंवा असामान्य समाप्ती ते अपयशी करते. यामुळे तीन वेगळे संकेत मिळतात, जे तपासणीकर्त्याचा करार जाणीवपूर्वक त्यांच्याशी जोडला असेल तरच उपयुक्त आहेत. यश पुन्हा परिभाषित करणारी सेटिंग्ज चित्र बदलू शकतात, म्हणून जोडणीचे दस्तऐवजीकरण करा.

वगळण्यांची नोंद ठेवणे हेच रचनेला प्रामाणिक बनवते. कुठेही न दिसणारा वगळलेला रन यशस्वी झालेल्या रनपासून वेगळा ओळखता येत नाही, आणि प्रत्येक तपासणीकर्ता त्रुटी शांत वगळणे मानणे तुटलेली तैनाती अनिश्चित काळासाठी लपवते.

संपूर्ण रनचे रक्षण करा, केवळ सुरुवातीचे नाही

तयारीची तपासणी प्रक्षेपणापूर्वी जगाचे निरीक्षण करते; ती नंतर प्रत्येक सॉकेटवर पहारा देत नाही. जेव्हा या कामासाठी थेट मार्ग कधीही स्वीकारार्ह नसतो, तेव्हा DNS, IPv6 आणि टनेलचे स्वतःचे वाहतूक व्यापून सतत लागू होणारे मंजूर बाहेरगामी धोरण जोडा. होस्टची जागतिक IPv6 स्थिती बदलणे हे कामावरील मर्यादित धोरणाचा पर्याय नाही.

नवीन घटना अजून चालू असलेल्या कामाला ओव्हरलॅप करू शकते का ते ठरवा, तो नियम कामाच्या भाराच्या मालकाकडे ठेवा, आणि डेटा ऑपरेशनसाठी पुन्हा प्रयत्न सुरक्षित करा. डिस्कनेक्टवर काम थांबवणे काम मर्यादित करते पण फॉलबॅक रहदारीबद्दल काहीही हमी देत नाही.

तीन प्रकरणांमध्ये कार्यप्रवाह स्वीकारा: तयार मार्ग, अनुपलब्ध मार्ग, आणि रनच्या मध्यातील हानी. यापेक्षा कमी काही वेळापत्रकाची परीक्षा करते, कामाची नाही.

संबंधित लेख