CIAN वर आम्ही टेराबाइट्स लॉग कसे नियंत्रित केले

सर्वांना नमस्कार, माझे नाव अलेक्झांडर आहे, मी एक अभियंता म्हणून CIAN मध्ये काम करतो आणि सिस्टम प्रशासन आणि पायाभूत सुविधांच्या ऑटोमेशनमध्ये सहभागी आहे. मागील लेखांपैकी एकाच्या टिप्पण्यांमध्ये, आम्हाला दररोज 4 TB लॉग कोठे मिळतात आणि आम्ही त्यांचे काय करतो हे सांगण्यास सांगितले होते. होय, आमच्याकडे बरेच लॉग आहेत आणि त्यांच्यावर प्रक्रिया करण्यासाठी एक स्वतंत्र पायाभूत सुविधा क्लस्टर तयार केला गेला आहे, जो आम्हाला समस्यांचे द्रुतपणे निराकरण करण्यास अनुमती देतो. या लेखात मी एका वर्षाच्या कालावधीत डेटाच्या सतत वाढत्या प्रवाहासह कार्य करण्यासाठी ते कसे रुपांतरित केले याबद्दल बोलेन.

आम्ही कुठे सुरुवात केली?

गेल्या काही वर्षांमध्ये, cian.ru वरील भार खूप लवकर वाढला आहे आणि 2018 च्या तिसऱ्या तिमाहीपर्यंत, संसाधन रहदारी दरमहा 11.2 दशलक्ष अद्वितीय वापरकर्त्यांपर्यंत पोहोचली आहे. त्या वेळी, गंभीर क्षणी आम्ही 40% लॉग गमावले, म्हणूनच आम्ही घटनांना त्वरित सामोरे जाऊ शकलो नाही आणि त्यांचे निराकरण करण्यात बराच वेळ आणि प्रयत्न खर्च केले. आम्ही देखील अनेकदा समस्येचे कारण शोधू शकत नाही, आणि काही काळानंतर ती पुन्हा होते. तो नरक होता आणि त्याबद्दल काहीतरी केले पाहिजे.

त्या वेळी, आम्ही लॉग संग्रहित करण्यासाठी मानक इंडेक्स सेटिंग्जसह ElasticSearch आवृत्ती 10 सह 5.5.2 डेटा नोड्सचा क्लस्टर वापरला. हे एक वर्षापूर्वी लोकप्रिय आणि परवडणारे समाधान म्हणून सादर केले गेले होते: नंतर लॉगचा प्रवाह इतका मोठा नव्हता, गैर-मानक कॉन्फिगरेशनसह येण्यात काही अर्थ नव्हता. 

पाच इलास्टिकसर्च कोऑर्डिनेटरवर वेगवेगळ्या पोर्टवर लॉगस्टॅशद्वारे इनकमिंग लॉगची प्रक्रिया प्रदान केली गेली. एका निर्देशांकात, आकाराची पर्वा न करता, पाच शार्ड्स असतात. तासाभराने आणि दैनंदिन रोटेशनचे आयोजन केले होते, परिणामी, क्लस्टरमध्ये दर तासाला सुमारे 100 नवीन शार्ड्स दिसू लागले. बरेच लॉग नसताना, क्लस्टरने चांगले सामना केले आणि कोणीही त्याच्या सेटिंग्जकडे लक्ष दिले नाही. 

वेगवान वाढीची आव्हाने

दोन प्रक्रिया एकमेकांवर आच्छादित झाल्यामुळे व्युत्पन्न लॉगचे प्रमाण खूप लवकर वाढले. एकीकडे सेवेचा वापर करणाऱ्यांची संख्या वाढली. दुसरीकडे, आम्ही C# आणि Python मधील आमच्या जुन्या मोनोलिथ्स पाहत, मायक्रोसर्व्हिस आर्किटेक्चरवर सक्रियपणे स्विच करण्यास सुरुवात केली. अनेक डझन नवीन मायक्रोसर्व्हिसेस ज्यांनी मोनोलिथचे काही भाग बदलले, त्यांनी पायाभूत सुविधा क्लस्टरसाठी लक्षणीयरीत्या अधिक लॉग व्युत्पन्न केले. 

हे स्केलिंगमुळे आम्हाला अशा ठिकाणी नेले की क्लस्टर व्यावहारिकदृष्ट्या अव्यवस्थापित झाले. जेव्हा लॉग 20 हजार संदेश प्रति सेकंद या दराने येऊ लागले, तेव्हा वारंवार निरुपयोगी रोटेशनमुळे शार्ड्सची संख्या 6 हजारांपर्यंत वाढली आणि प्रति नोड 600 पेक्षा जास्त शार्ड्स होते. 

यामुळे RAM च्या वाटपात समस्या निर्माण झाल्या आणि जेव्हा नोड क्रॅश झाला तेव्हा सर्व शार्ड्स एकाच वेळी हलू लागले, ट्रॅफिक गुणाकार आणि इतर नोड लोड करणे, ज्यामुळे क्लस्टरमध्ये डेटा लिहिणे जवळजवळ अशक्य झाले. आणि या काळात आम्ही नोंदीशिवाय राहिलो. आणि सर्व्हरमध्ये समस्या असल्यास, आम्ही मुळात क्लस्टरचा 1/10 गमावला. मोठ्या संख्येने लहान निर्देशांकांनी जटिलता जोडली.

नोंदीशिवाय, आम्हाला घटनेची कारणे समजली नाहीत आणि लवकरच किंवा नंतर पुन्हा त्याच रेकवर पाऊल ठेवू शकलो आणि आमच्या कार्यसंघाच्या विचारसरणीनुसार हे अस्वीकार्य आहे, कारण आमच्या सर्व कार्य यंत्रणा अगदी उलट करण्यासाठी डिझाइन केल्या आहेत - कधीही पुनरावृत्ती करू नका समान समस्या. हे करण्यासाठी, आम्हाला लॉगची संपूर्ण व्हॉल्यूम आणि जवळजवळ रिअल टाइममध्ये त्यांची डिलिव्हरी आवश्यक होती, कारण ऑन-ड्यूटी अभियंत्यांच्या टीमने केवळ मेट्रिक्सवरूनच नव्हे तर लॉगमधून देखील अलर्टचे निरीक्षण केले. समस्येचे प्रमाण समजून घेण्यासाठी, त्या वेळी लॉगची एकूण मात्रा दररोज सुमारे 2 टीबी होती. 

आम्ही लॉगचे नुकसान पूर्णपणे काढून टाकण्याचे आणि ELK क्लस्टरला त्यांच्या वितरणाचा वेळ फोर्स मॅजेअर दरम्यान जास्तीत जास्त 15 मिनिटांपर्यंत कमी करण्याचे ध्येय ठेवले (आम्ही नंतर अंतर्गत KPI म्हणून या आकृतीवर अवलंबून राहिलो).

नवीन रोटेशन यंत्रणा आणि गरम-उबदार नोड्स

आम्ही 5.5.2 ते 6.4.3 पर्यंत ElasticSearch आवृत्ती अपडेट करून क्लस्टर रूपांतरण सुरू केले. पुन्हा एकदा आमची आवृत्ती 5 क्लस्टर मरण पावला, आणि आम्ही ते बंद करण्याचा आणि पूर्णपणे अद्यतनित करण्याचा निर्णय घेतला - अद्याप कोणतेही लॉग नाहीत. त्यामुळे आम्ही अवघ्या काही तासांत हे संक्रमण केले.

या टप्प्यावर सर्वात मोठ्या प्रमाणात होणारे परिवर्तन म्हणजे अपाचे काफ्काचे तीन नोड्सवर इंटरमीडिएट बफर म्हणून समन्वयक असलेली अंमलबजावणी. संदेश ब्रोकरने इलास्टिकसर्चच्या समस्यांदरम्यान लॉग गमावण्यापासून आम्हाला वाचवले. त्याच वेळी, आम्ही क्लस्टरमध्ये 2 नोड जोडले आणि डेटा सेंटरमधील वेगवेगळ्या रॅकमध्ये असलेल्या तीन "हॉट" नोड्ससह गरम-उबदार आर्किटेक्चरवर स्विच केले. आम्ही मास्क वापरून त्यांच्याकडे लॉग पुनर्निर्देशित केले जे कोणत्याही परिस्थितीत गमावले जाऊ नये - nginx, तसेच अनुप्रयोग त्रुटी लॉग. उर्वरित नोड्सवर किरकोळ लॉग पाठवले गेले - डीबग, चेतावणी इ. आणि 24 तासांनंतर, "हॉट" नोड्समधील "महत्त्वाचे" लॉग हस्तांतरित केले गेले.

लहान निर्देशांकांची संख्या वाढू नये म्हणून, आम्ही टाइम रोटेशनपासून रोलओव्हर यंत्रणेकडे स्विच केले. फोरमवर बरीच माहिती होती की अनुक्रमणिका आकारानुसार रोटेशन खूप अविश्वसनीय आहे, म्हणून आम्ही निर्देशांकातील दस्तऐवजांच्या संख्येनुसार रोटेशन वापरण्याचा निर्णय घेतला. आम्ही प्रत्येक निर्देशांकाचे विश्लेषण केले आणि दस्तऐवजांची संख्या रेकॉर्ड केली ज्यानंतर रोटेशन कार्य करावे. अशा प्रकारे, आम्ही इष्टतम शार्ड आकारापर्यंत पोहोचलो आहोत - 50 GB पेक्षा जास्त नाही. 

क्लस्टर ऑप्टिमायझेशन

तथापि, आम्ही समस्यांपासून पूर्णपणे मुक्त झालो नाही. दुर्दैवाने, लहान निर्देशांक अजूनही दिसू लागले: ते निर्दिष्ट व्हॉल्यूमपर्यंत पोहोचले नाहीत, फिरवले गेले नाहीत आणि तीन दिवसांपेक्षा जुन्या निर्देशांकांच्या जागतिक साफसफाईद्वारे हटवले गेले, कारण आम्ही तारखेनुसार रोटेशन काढून टाकले आहे. क्लस्टरमधील निर्देशांक पूर्णपणे गायब झाल्यामुळे डेटा गमावला आणि अस्तित्वात नसलेल्या निर्देशांकावर लिहिण्याच्या प्रयत्नामुळे आम्ही व्यवस्थापनासाठी वापरलेल्या क्युरेटरचे तर्क मोडले. लेखनासाठी उपनाव निर्देशांकात रूपांतरित केले गेले आणि रोलओव्हर लॉजिक तोडले, ज्यामुळे 600 GB पर्यंत काही निर्देशांकांची अनियंत्रित वाढ झाली. 

उदाहरणार्थ, रोटेशन कॉन्फिगरेशनसाठी:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

रोलओव्हर उपनाव नसल्यास, एक त्रुटी आली:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

आम्ही या समस्येचे निराकरण पुढील पुनरावृत्तीसाठी सोडले आणि दुसरा मुद्दा घेतला: आम्ही लॉगस्टॅशच्या पुल लॉजिकवर स्विच केले, जे इनकमिंग लॉग्सवर प्रक्रिया करते (अनावश्यक माहिती काढून टाकणे आणि समृद्ध करणे). आम्ही ते डॉकरमध्ये ठेवले, जे आम्ही डॉकर-कंपोजद्वारे लॉन्च करतो आणि आम्ही तेथे लॉगस्टॅश-एक्सपोर्टर देखील ठेवले, जे लॉग स्ट्रीमच्या ऑपरेशनल मॉनिटरिंगसाठी प्रोमिथियसला मेट्रिक्स पाठवते. अशा प्रकारे आम्ही प्रत्येक प्रकारच्या लॉगवर प्रक्रिया करण्यासाठी जबाबदार असलेल्या लॉगस्टॅश उदाहरणांची संख्या सहजतेने बदलण्याची संधी दिली.

आम्ही क्लस्टरमध्ये सुधारणा करत असताना, cian.ru ची रहदारी दरमहा १२.८ दशलक्ष अद्वितीय वापरकर्त्यांपर्यंत वाढली. परिणामी, असे दिसून आले की आमची परिवर्तने उत्पादनातील बदलांच्या मागे आहेत आणि आम्हाला या वस्तुस्थितीचा सामना करावा लागला की "उबदार" नोड्स लोडचा सामना करू शकत नाहीत आणि लॉगची संपूर्ण वितरण कमी करतात. आम्हाला अपयशाशिवाय "हॉट" डेटा प्राप्त झाला, परंतु आम्हाला उर्वरित वितरणामध्ये हस्तक्षेप करावा लागला आणि निर्देशांकांचे समान वितरण करण्यासाठी मॅन्युअल रोलओव्हर करावे लागले. 

त्याच वेळी, क्लस्टरमधील लॉगस्टॅश घटनांची सेटिंग्ज स्केलिंग करणे आणि बदलणे हे एक स्थानिक डॉकर-कंपोज असल्यामुळे क्लिष्ट होते आणि सर्व क्रिया व्यक्तिचलितपणे केल्या गेल्या होत्या (नवीन टोके जोडण्यासाठी, सर्व गोष्टी व्यक्तिचलितपणे पार पाडणे आवश्यक होते. सर्व्हर आणि सर्वत्र डॉकर-कंपोज अप -डी करतात).

लॉग पुनर्वितरण

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

आम्ही हार्डवेअर अपडेटसह पुढील पुनरावृत्ती सुरू केली. आम्ही पाच समन्वयकांवरून तीनवर स्विच केले, डेटा नोड्स बदलले आणि पैसे आणि स्टोरेज स्पेसच्या बाबतीत जिंकलो. नोड्ससाठी आम्ही दोन कॉन्फिगरेशन वापरतो: 

• "हॉट" नोड्ससाठी: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 साठी 1 आणि Hot3 साठी 2).
• "उबदार" नोड्ससाठी: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

या पुनरावृत्तीवर, आम्ही मायक्रोसर्व्हिसेसच्या ऍक्सेस लॉगसह अनुक्रमणिका हलवली, जी फ्रंट-लाइन nginx लॉग सारखीच जागा घेते, तीन "हॉट" नोड्सच्या दुसऱ्या गटात. आम्ही आता "हॉट" नोड्सवर 20 तासांसाठी डेटा संग्रहित करतो आणि नंतर त्यांना उर्वरित लॉगमध्ये "उबदार" नोड्समध्ये स्थानांतरित करतो. 

आम्ही त्यांच्या रोटेशनची पुनर्रचना करून लहान निर्देशांकांच्या अदृश्य होण्याच्या समस्येचे निराकरण केले. आता प्रत्येक 23 तासांनी निर्देशांक फिरवले जातात, जरी तेथे थोडासा डेटा असला तरीही. यामुळे शार्ड्सची संख्या किंचित वाढली (त्यापैकी सुमारे 800 होते), परंतु क्लस्टर कामगिरीच्या दृष्टिकोनातून ते सुसह्य आहे. 

परिणामी, क्लस्टरमध्ये सहा "गरम" आणि फक्त चार "उबदार" नोड होते. यामुळे दीर्घ कालावधीत विनंत्यांवर थोडा विलंब होतो, परंतु भविष्यात नोड्सची संख्या वाढवल्याने ही समस्या सोडवली जाईल.

या पुनरावृत्तीने अर्ध-स्वयंचलित स्केलिंगच्या अभावाची समस्या देखील निश्चित केली. हे करण्यासाठी, आम्ही एक इन्फ्रास्ट्रक्चर नोमॅड क्लस्टर तैनात केले - जे आम्ही उत्पादनात आधीच तैनात केले आहे. सध्या, लोडवर अवलंबून लॉगस्टॅशची रक्कम आपोआप बदलत नाही, परंतु आम्ही यावर येऊ.

भविष्यासाठी योजना

अंमलात आणलेले कॉन्फिगरेशन उत्तम प्रकारे मोजले जाते आणि आता आम्ही 13,3 TB डेटा संग्रहित करतो - सर्व लॉग 4 दिवसांसाठी, जे अलर्टच्या आणीबाणीच्या विश्लेषणासाठी आवश्यक आहे. आम्ही काही लॉग मेट्रिक्समध्ये रूपांतरित करतो, जे आम्ही ग्रेफाइटमध्ये जोडतो. अभियंत्यांचे काम सोपे करण्यासाठी, आमच्याकडे पायाभूत सुविधा क्लस्टरसाठी मेट्रिक्स आणि सामान्य समस्यांच्या अर्ध-स्वयंचलित दुरुस्तीसाठी स्क्रिप्ट आहेत. डेटा नोड्सची संख्या वाढवल्यानंतर, जे पुढील वर्षासाठी नियोजित आहे, आम्ही 4 ते 7 दिवसांपर्यंत डेटा स्टोरेजवर स्विच करू. ऑपरेशनल कामासाठी हे पुरेसे असेल, कारण आम्ही नेहमी शक्य तितक्या लवकर घटनांचा तपास करण्याचा प्रयत्न करतो आणि दीर्घकालीन तपासणीसाठी टेलिमेट्री डेटा असतो. 

ऑक्टोबर 2019 मध्ये, cian.ru वरील रहदारी आधीच दरमहा 15,3 दशलक्ष अद्वितीय वापरकर्त्यांपर्यंत वाढली आहे. नोंदी वितरीत करण्यासाठी आर्किटेक्चरल सोल्यूशनची ही एक गंभीर चाचणी बनली. 

आता आम्ही इलास्टिकसर्चला आवृत्ती ७ वर अपडेट करण्याची तयारी करत आहोत. तथापि, यासाठी आम्हाला इलास्टिकसर्चमधील अनेक निर्देशांकांचे मॅपिंग अद्यतनित करावे लागेल, कारण ते आवृत्ती ५.५ वरून हलवले गेले आहेत आणि आवृत्ती ६ मध्ये बहिष्कृत म्हणून घोषित करण्यात आले आहेत (ते फक्त आवृत्तीमध्ये अस्तित्वात नाहीत. 7). याचा अर्थ अद्ययावत प्रक्रियेदरम्यान निश्चितपणे एक प्रकारचा फोर्स मॅजेअर असेल, जो समस्येचे निराकरण होत असताना आम्हाला लॉगशिवाय सोडेल. आवृत्ती 5.5 ची, आम्ही सुधारित इंटरफेस आणि नवीन फिल्टरसह किबानाची सर्वात जास्त वाट पाहत आहोत. 

आम्ही आमचे मुख्य उद्दिष्ट साध्य केले: आम्ही लॉग गमावणे थांबवले आणि इन्फ्रास्ट्रक्चर क्लस्टरचा डाउनटाइम दर आठवड्याला 2-3 क्रॅश वरून दर महिन्याला काही तासांच्या देखभाल कार्यापर्यंत कमी केला. उत्पादनातील हे सर्व काम जवळजवळ अदृश्य आहे. तथापि, आता आम्ही आमच्या सेवेमध्ये नेमके काय घडत आहे हे निर्धारित करू शकतो, आम्ही ते शांत मोडमध्ये पटकन करू शकतो आणि लॉग गमावले जातील याची काळजी करू नका. सर्वसाधारणपणे, आम्ही समाधानी, आनंदी आणि नवीन शोषणांसाठी तयार आहोत, ज्याबद्दल आम्ही नंतर बोलू.

स्त्रोत: www.habr.com