Linux में eBPF और bpftrace का उपयोग करते हुए फुल डायनेमिक ट्रेसिंग

विकिपीडिया हमें बताता है, "ट्रेस मोड में, प्रोग्रामर प्रोग्राम निष्पादन के इस चरण पर कमांड निष्पादन के अनुक्रम और चर के मूल्यों को देखता है, जिससे त्रुटियों का पता लगाना आसान हो जाता है।" खुद लिनक्स के प्रशंसक के रूप में, हम नियमित रूप से इस सवाल पर आते हैं कि इसे लागू करने के लिए कौन से विशिष्ट उपकरण सर्वोत्तम हैं। और हम प्रोग्रामर होंगले लाई द्वारा एक लेख के अनुवाद को साझा करना चाहते हैं जो bpftrace की सिफारिश करता है। आगे देखते हुए, मैं कहता हूं कि यह लेख सफलतापूर्वक समाप्त होता है: "bpftrace is the future"। तो उन्होंने लाई के सहयोगी को इतना प्रभावित क्यों किया? कटौती के तहत एक विस्तृत जवाब।

लिनक्स पर दो मुख्य ट्रेस उपकरण हैं:
स्ट्रेस आपको यह देखने की अनुमति देता है कि कौन से सिस्टम कॉल किए जा रहे हैं;
ltrace आपको यह देखने की सुविधा देता है कि कौन से गतिशील पुस्तकालयों को बुलाया जा रहा है।

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

2019 में, हमें अंततः Linux: bpftrace पर आधारित इन सवालों का एक अच्छा जवाब मिला। Bpftrace आपको छोटे प्रोग्राम लिखने की अनुमति देता है जो हर बार एक घटना होती है।

इस लेख में मैं वर्णन करूँगा कि bpftrace कैसे स्थापित करें और इसके मूल अनुप्रयोग को कैसे सिखाएँ। मैं यह भी बताऊँगा कि ट्रेस इकोसिस्टम कैसा दिखता है (उदाहरण के लिए, "ईएफ़पीएफ क्या है?") का अवलोकन और कैसे यह आज हमारे पास है।

ट्रेस क्या है?

जैसा कि पहले उल्लेख किया गया है, bpftrace आपको छोटे प्रोग्राम लिखने की अनुमति देता है जो हर बार एक घटना होती है।

एक घटना क्या है? यह इस तरह के अनुरोधों के अंदर एक सिस्टम कॉल, एक फ़ंक्शन कॉल, या यहां तक ​​कि कुछ भी हो सकता है। यह एक टाइमर या एक हार्डवेयर घटना भी हो सकती है, उदाहरण के लिए, "50 एमएस एक ही घटनाओं के आखिरी के बाद से पारित हो गया है", "पृष्ठ विफलता हुई", "संदर्भ स्विच हुआ" या "काश-मिस प्रोसेसर हुआ"।

किसी घटना के जवाब में क्या किया जा सकता है? आप कुछ प्रतिज्ञा कर सकते हैं, आंकड़े एकत्र कर सकते हैं और मनमाने ढंग से शेल कमांड निष्पादित कर सकते हैं। आपके पास विभिन्न संदर्भ जानकारी तक पहुंच होगी, जैसे कि वर्तमान पीआईडी, स्टैक ट्रेस, समय, कॉल तर्क, वापसी मान आदि।

कब करें इस्तेमाल? बहुतों में। आप पता लगा सकते हैं कि सबसे धीमी कॉल की सूची का संकलन करके एप्लिकेशन धीमा क्यों है। आप यह निर्धारित कर सकते हैं कि क्या अनुप्रयोग में मेमोरी लीक हैं, और यदि हां, तो कहां। मैं इसका उपयोग यह समझने के लिए करता हूं कि रूबी इतनी मेमोरी का उपयोग क्यों करती है।

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

DTrace: ट्रेस का पिता

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


एस। त्रिपाठी, सन माइक्रोसिस्टम्स द्वारा सोलारिस रिट्रेस परिचय (2009)

कुछ बिंदु पर, सूर्य ने DTrace के लिए स्रोत खोला। आज, DTrace Solaris, FreeBSD, और macOS पर उपलब्ध है (हालांकि macOS संस्करण आमतौर पर अक्षम है क्योंकि सिस्टम इंटीग्रिटी प्रोटेक्शन, SIP, कई सिद्धांतों को तोड़ चुका है जो DTrace चलता है)।

हां, आपने सही तरीके से देखा ... लिनक्स इस सूची में नहीं है। यह इंजीनियरिंग की समस्या नहीं है, यह लाइसेंस की समस्या है। DTD को GPL के बजाय CDDL के तहत खोला गया था। लिनक्स DTrace पोर्ट 2011 से उपलब्ध है, लेकिन इसे कभी भी प्रमुख लिनक्स डेवलपर्स द्वारा समर्थित नहीं किया गया है। 2018 की शुरुआत में, ओरेकल ने जीपीएल के तहत रिट्रेस को फिर से खोल दिया , लेकिन तब तक पहले ही बहुत देर हो चुकी थी।

लिनक्स ट्रेसिंग इकोसिस्टम

इसमें कोई संदेह नहीं है कि अनुरेखण बहुत उपयोगी है, और लिनक्स समुदाय ने इस विषय पर अपने स्वयं के समाधान विकसित करने की मांग की है। लेकिन, सोलारिस के विपरीत, लिनक्स एक विशिष्ट विक्रेता द्वारा विनियमित नहीं है, और इसलिए DTrace के लिए पूरी तरह कार्यात्मक प्रतिस्थापन विकसित करने का कोई जानबूझकर प्रयास नहीं किया गया था। लिनक्स ट्रेस इकोसिस्टम धीरे-धीरे और स्वाभाविक रूप से विकसित हुआ है, समस्याओं को हल करते हुए। और केवल हाल ही में इस पारिस्थितिकी तंत्र ने गंभीरता से DTrace के साथ प्रतिस्पर्धा करने के लिए पर्याप्त वृद्धि की है।

प्राकृतिक विकास के कारण, यह पारिस्थितिकी तंत्र थोड़ा अव्यवस्थित लग सकता है, जिसमें कई अलग-अलग घटक होते हैं। सौभाग्य से, जूलिया इवांस ने इस पारिस्थितिकी तंत्र (ध्यान, प्रकाशन की तारीख - 2017, bpftrace के आगमन से पहले) की समीक्षा लिखी।


जूलिया इवांस द्वारा वर्णित लिनक्स ट्रेस इकोसिस्टम

सभी तत्व समान रूप से महत्वपूर्ण नहीं हैं। मुझे संक्षेप में बताएं कि मैं किन तत्वों को सबसे महत्वपूर्ण मानता हूं।

घटना के सूत्र

इवेंट डेटा कर्नेल या उपयोगकर्ता स्थान (एप्लिकेशन और लाइब्रेरी) से आ सकता है। उनमें से कुछ अतिरिक्त डेवलपर प्रयासों के बिना स्वचालित रूप से उपलब्ध हैं, जबकि अन्य को मैनुअल घोषणा की आवश्यकता होती है।


लिनक्स में ट्रेस किए गए घटनाओं के सबसे महत्वपूर्ण स्रोतों का अवलोकन

कर्नेल साइड पर, kprobes है ( "कर्नेल जांच", "कर्नेल सेंसर", लगभग प्रति )) - एक तंत्र जो आपको कर्नेल के अंदर किसी भी फ़ंक्शन कॉल का पता लगाने की अनुमति देता है। इसके साथ, आप न केवल सिस्टम को स्वयं कॉल कर सकते हैं, बल्कि उनके अंदर क्या होता है (क्योंकि सिस्टम कॉल के प्रवेश बिंदु अन्य आंतरिक कार्यों को कॉल करते हैं)। आप कर्नेल घटनाओं का पता लगाने के लिए kprobes का उपयोग कर सकते हैं जो सिस्टम कॉल नहीं हैं, उदाहरण के लिए, "बफर डेटा डिस्क पर लिखा जा रहा है", "टीसीपी पैकेट नेटवर्क पर भेजा गया है" या "संदर्भ स्विचिंग प्रगति पर है"।

कर्नेल ट्रेसप्वाइंट कर्नेल डेवलपर्स द्वारा परिभाषित गैर-मानक घटनाओं का पता लगाने की अनुमति देता है। ये घटनाएँ फ़ंक्शन कॉल के स्तर पर नहीं हैं। ऐसे बिंदु बनाने के लिए, कर्नेल डेवलपर्स मैन्युअल रूप से TRACE_EVENT मैक्रो को कर्नेल कोड में रखते हैं।

दोनों स्रोतों में पेशेवरों और विपक्ष हैं। Kprobes "स्वचालित रूप से" काम करता है क्योंकि कोड को मैन्युअल रूप से कोड करने के लिए कर्नेल डेवलपर्स की आवश्यकता नहीं होती है। लेकिन kprobe घटनाएँ मनमाने ढंग से कर्नेल के एक संस्करण से दूसरे में बदल सकती हैं, क्योंकि फ़ंक्शंस लगातार बदल रहे हैं - उन्हें जोड़ा जाता है, हटाया जाता है, नाम बदला जाता है।

कर्नेल ट्रेस पॉइंट आम तौर पर समय के साथ और अधिक स्थिर होते हैं और उपयोगी प्रासंगिक जानकारी प्रदान कर सकते हैं जो कि kprobes का उपयोग करने पर उपलब्ध नहीं हो सकता है। Kprobes का उपयोग करके, आप फ़ंक्शन कॉल आर्गुमेंट्स तक पहुँच सकते हैं। लेकिन ट्रेस पॉइंट्स की मदद से, आप कोई भी जानकारी प्राप्त कर सकते हैं जो कर्नेल डेवलपर मैन्युअल रूप से वर्णन करने का निर्णय लेता है।

उपयोगकर्ता अंतरिक्ष में kprobes - upboards का एक एनालॉग है। इसे यूजर स्पेस में फंक्शन कॉल्स ट्रेस करने के लिए बनाया गया है।

यूएसडीटी सेंसर ("स्टेटिकली डिफाइंड यूजर स्पेस ट्रैस") यूजर स्पेस में कर्नेल ट्रेस पॉइंट्स का एक एनालॉग है। एप्लिकेशन डेवलपर्स को अपने कोड में मैन्युअल रूप से यूएसडीटी सेंसर जोड़ने की आवश्यकता है।

दिलचस्प तथ्य: डीट्रेस ने लंबे समय से यूएसटी सेंसर के अपने स्वयं के एनालॉग (DTRACE_PROP मैक्रो का उपयोग करके) को परिभाषित करने के लिए सी एपीआई प्रदान किया है। लिनक्स पर ट्रेस पारिस्थितिकी तंत्र डेवलपर्स ने इस एपीआई के साथ स्रोत कोड को छोड़ने का फैसला किया, इसलिए किसी भी DTRACE_PROBE मैक्रोज़ को स्वचालित रूप से USDT सेंसर में बदल दिया जाता है!

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

इंटरफेस

इंटरफेस ऐसे एप्लिकेशन हैं जो उपयोगकर्ताओं को आसानी से ईवेंट स्रोतों का उपयोग करने की अनुमति देते हैं।

आइए देखें कि इवेंट स्रोत कैसे काम करते हैं। वर्कफ़्लो इस प्रकार है:

1. कर्नेल एक तंत्र का प्रतिनिधित्व करता है - आम तौर पर / proc या sys फ़ाइल लिखने के लिए खुली होती है - जो कि घटना का पता लगाने के इरादे को पंजीकृत करता है और घटना का पालन करना चाहिए।
2. पंजीकरण करने के बाद, कर्नेल मेमोरी में कर्नेल / फ़ंक्शन को यूजर स्पेस / ट्रेस पॉइंट / यूएसडीटी-सेंसरों में स्थानीय कर देता है और उनका कोड बदल देता है ताकि कुछ और हो सके।
3. इस "कुछ और" का परिणाम बाद में कुछ तंत्र का उपयोग करके एकत्र किया जा सकता है।

मैं यह सब मैन्युअल रूप से नहीं करना चाहता! इसलिए, बचाव के लिए इंटरफेस आते हैं: वे आपके लिए यह सब करते हैं।

हर स्वाद और रंग के लिए इंटरफेस हैं। ईएक्सपीएफ - आधारित इंटरफेस के क्षेत्र में , निम्न-स्तर वाले होते हैं, जिन्हें इवेंट स्रोतों के साथ बातचीत करने और ईआरपीएफ बायोटेक काम करने के तरीके की गहरी समझ की आवश्यकता होती है। और उच्च-स्तर और संचालित करने में आसान हैं, हालांकि उनके अस्तित्व के दौरान उन्होंने महान लचीलापन प्रदर्शित नहीं किया।

यही कारण है कि bpftrace - नवीनतम इंटरफ़ेस - मेरा पसंदीदा है। यह उपयोगकर्ता के अनुकूल है और DTrace की तरह लचीला है। लेकिन यह काफी नया है और इसे चमकाने की आवश्यकता है।

eBPF

eBPF एक नया लिनक्स ट्रेस स्टार है जिस पर bpftrace आधारित है। जब आप किसी ईवेंट को ट्रेस करते हैं, तो आप चाहते हैं कि कर्नेल में कुछ घटित हो। यह "कुछ" क्या है यह निर्धारित करने के लिए कितना लचीला तरीका है? बेशक, एक प्रोग्रामिंग भाषा (या मशीन कोड का उपयोग करके)।

EBPF (बर्कले पैकेट फ़िल्टर का उन्नत संस्करण)। यह एक उच्च-प्रदर्शन वाली वर्चुअल मशीन है जो कर्नेल में चलती है और इसमें निम्नलिखित गुण / सीमाएँ हैं:

• सभी उपयोगकर्ता अंतरिक्ष इंटरैक्शन ईजीपीएफ "कार्ड" के माध्यम से होते हैं, जो कुंजी-मूल्य डेटा स्टोरेज हैं।
• कोई चक्र नहीं है ताकि प्रत्येक ईएक्सपीएफ कार्यक्रम एक विशिष्ट समय पर समाप्त हो जाए।
• रुको, हमने कहा कि बैच फ़िल्टर? आप सही हैं: वे मूल रूप से नेटवर्क पैकेट फ़िल्टर करने के लिए डिज़ाइन किए गए थे। यह एक समान कार्य है: जब अग्रेषण पैकेट (किसी घटना की घटना) आपको कुछ प्रशासनिक कार्रवाई करने की आवश्यकता होती है (एक पैकेट को स्वीकार करना, छोड़ना, पत्रिका या पुनर्निर्देशित करना, आदि) ऐसी क्रियाओं को तेज करने के लिए एक आभासी मशीन का आविष्कार किया गया था (जेआईटी क्षमता के साथ) -kompilyatsii)। एक "विस्तारित" संस्करण को इस तथ्य के कारण माना जाता है कि, बर्कले पैकेट फ़िल्टर के मूल संस्करण की तुलना में, नेटवर्क संदर्भ के बाहर eBPF का उपयोग किया जा सकता है।

वहां तुम जाओ। बीपीट्रेस के साथ, आप यह निर्धारित कर सकते हैं कि किन घटनाओं को ट्रैक करना है और प्रतिक्रिया में क्या होना चाहिए। Bpftrace आपके उच्च-स्तरीय bpftrace प्रोग्राम को eBPF bytecode में संकलित करता है, घटनाओं को ट्रैक करता है, और bytecode को कर्नेल में लोड करता है।

EBPF से पहले के काले दिन

EBPF से पहले, समाधान विकल्प थे, इसे हल्के ढंग से, अजीब रूप से डालने के लिए। SystemTap लिनक्स परिवार में bpftrace के लिए "सबसे गंभीर" पूर्ववर्ती का एक सा है। SystemTap स्क्रिप्ट को C भाषा में अनुवादित किया जाता है और मॉड्यूल के रूप में कर्नेल में लोड किया जाता है। परिणामस्वरूप कर्नेल मॉड्यूल तब लोड किया जाता है।

यह दृष्टिकोण Red Hat Enterprise Linux के बाहर बहुत नाजुक और खराब समर्थित था। मेरे लिए, इसने उबंटू पर कभी अच्छा काम नहीं किया, जो कि कोरनेटिक संरचना में बदलाव के कारण हर कर्नेल अपडेट पर SystemTap को तोड़ने में सक्षम था। यह भी कहा जाता है कि अपने अस्तित्व के शुरुआती दिनों में, सिस्टमटैप ने आसानी से कर्नेल आतंक पैदा कर दिया था ।

Bpftrace स्थापना

यह अपनी आस्तीन ऊपर रोल करने के लिए समय है! इस गाइड में, हम Ubuntu 18.04 पर bpftrace स्थापित करने पर ध्यान देंगे। वितरण के नए संस्करण अवांछनीय हैं, क्योंकि स्थापना के दौरान, हमें उन पैकेजों की आवश्यकता होगी जो अभी तक उनके लिए संकलित नहीं हैं।

निर्भरता स्थापना

सबसे पहले, Clang 5.0, lbclang 5.0, और LLVM 5.0, सभी हेडर फ़ाइलों सहित स्थापित करें। हम llvm.org द्वारा उपलब्ध कराए गए पैकेजों का उपयोग करेंगे, क्योंकि उबंटू रिपॉजिटरी के लोग समस्याग्रस्त हैं ।

wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add - cat <<EOF | sudo tee -a /etc/apt/sources.list deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial main deb-src http://apt.llvm.org/xenial/ llvm-toolchain-xenial main deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-5.0 main deb-src http://apt.llvm.org/xenial/ llvm-toolchain-xenial-5.0 main EOF sudo apt update sudo apt install clang-5.0 libclang-5.0-dev llvm-5.0 llvm-5.0-dev 

अगला:

 sudo apt install bison cmake flex g++ git libelf-dev zlib1g-dev libfl-dev 

और अंत में, उबंटू रिपॉजिटरी से नहीं, अपस्ट्रीम से लिबफेक-देव स्थापित करें। उबंटू में जो पैकेज है उसमें कोई हेडर फाइल नहीं है। और यह समस्या 18.10 पर भी हल नहीं हुई।

 sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4052245BD4284CDD echo "deb https://repo.iovisor.org/apt/$(lsb_release -cs) $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/iovisor.list sudo apt update sudo apt install bcc-tools libbcc-examples linux-headers-$(uname -r) 

Bpftrace मुख्य स्थापना

यह स्रोत से खुद bpftrace स्थापित करने का समय है! चलो इसे क्लोन करें, इसे इकट्ठा करें और इसे / usr / स्थानीय में स्थापित करें:

 git clone https://github.com/iovisor/bpftrace cd bpftrace mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=DEBUG .. make -j4 sudo make install 

और आप कर रहे हैं! निष्पादन योग्य / usr / स्थानीय / बिन / bpftrace में स्थापित किया जाएगा। आप cmake तर्क का उपयोग करके गंतव्य को बदल सकते हैं, जो डिफ़ॉल्ट रूप से इस तरह दिखता है:

 DCMAKE_INSTALL_PREFIX=/usr/local. 

एक पंक्ति के उदाहरण

चलो हमारी क्षमताओं को समझने के लिए कुछ bpftrace सिंगल-लाइनर्स चलाते हैं। मैंने उन्हें ब्रेंडन ग्रेग के गाइड से लिया, जिसमें उनमें से प्रत्येक का विस्तृत विवरण है।

# 1. सेंसर की एक सूची प्रदर्शित करें

 bpftrace -l 'tracepoint:syscalls:sys_enter_*' 

2. “अभिवादन

 bpftrace -e 'BEGIN { printf("hello world\n"); }' 

3. 3. एक फ़ाइल को खोलना

 bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }' 

# 4. प्रति सिस्टम कॉल की संख्या

 bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' 

5. "रीड ऑफ () कॉल बाइट्स की संख्या द्वारा

 bpftrace -e 'tracepoint:syscalls:sys_exit_read /pid == 18644/ { @bytes = hist(args->retval); }' 

6. 6. रीड () सामग्री का सर्जिकल अनुरेखण

 bpftrace -e 'kretprobe:vfs_read { @bytes = lhist(retval, 0, 2000, 200); }' 

# 7. पढ़ने () कॉल पर खर्च किया गया समय

 bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } kretprobe:vfs_read /@start[tid]/ { @ns[comm] = hist(nsecs - @start[tid]); delete(@start[tid]); }' 

* 8. गणना प्रक्रिया स्तर की घटनाओं

 bpftrace -e 'tracepoint:sched:sched* { @[name] = count(); } interval:s:5 { exit(); }' 

# 9. कर्नेल काम कर रहे ढेर को प्रोफाइल करना

 bpftrace -e 'profile:hz:99 { @[stack] = count(); }' 

# 10. ट्रेस प्लानर

 bpftrace -e 'tracepoint:sched:sched_switch { @[stack] = count(); }' 

11. 11. ट्रेस अवरुद्ध I / O

 bpftrace -e 'tracepoint:block:block_rq_complete { @ = hist(args->nr_sector * 512); }' 

उपरोक्त टीमों को किस प्रकार का आउटपुट मिल सकता है , यह जानने के लिए ब्रेंडन ग्रेग की वेबसाइट देखें।

स्क्रिप्ट सिंटैक्स और I / O टाइमिंग उदाहरण

'-ई' स्विच के माध्यम से पारित स्ट्रिंग bpftrace स्क्रिप्ट की सामग्री है। इस मामले में वाक्य रचना, सशर्त रूप से, निर्माण का एक सेट है:

 <event source> /<optional filter>/ { <program body> } 

आइए सातवें उदाहरण को देखें, फ़ाइल सिस्टम रीड ऑपरेशंस के समय के बारे में:

 kprobe:vfs_read { @start[tid] = nsecs; } <- 1 -><-- 2 -> <---------- 3 ---------> 

हम kprobe तंत्र से घटना का पता लगाते हैं, अर्थात्, हम कर्नेल फ़ंक्शन की शुरुआत का पता लगाते हैं।
ट्रेसिंग के लिए कर्नेल फ़ंक्शन vfs_read है , यह फ़ंक्शन तब कहा जाता है जब कर्नेल फ़ाइल सिस्टम से रीड ऑपरेशन करता है ("वर्चुअल फ़ाइलसिस्टम से VFS", कर्नेल के अंदर फ़ाइल सिस्टम का एब्सट्रैक्ट)।

जब vfs_read निष्पादित करना शुरू कर देता है (यानी जब फ़ंक्शन ने कोई उपयोगी काम किया है), bpftrace प्रोग्राम शुरू होता है। यह वर्तमान टाइमस्टैम्प (नैनोसेकंड में) को सेंट आर्ट नामक वैश्विक साहचर्य सरणी में बचाता है। कुंजी tid है , वर्तमान थ्रेड आईडी का संदर्भ है।

 kretprobe:vfs_read /@start[tid]/ { @ns[comm] = hist(nsecs - @start[tid]); delete(@start[tid]); } <-- 1 --> <-- 2 -> <---- 3 ----> <----------------------------- 4 -----------------------------> 

1. हम kretprobe तंत्र से घटना का पता लगाते हैं , जो कि kprobe के समान है, सिवाय इसके कि जब फ़ंक्शन अपने निष्पादन का परिणाम देता है तो इसे कहा जाता है।

2. ट्रेसिंग के लिए कर्नेल फ़ंक्शन vfs_read है ।

3. यह एक वैकल्पिक फिल्टर है। यह जांचता है कि क्या प्रारंभ समय पहले दर्ज किया गया है। इस फिल्टर के बिना, प्रोग्राम को पढ़ने के दौरान लॉन्च किया जा सकता है और केवल अंत को पकड़ सकता है, जिसके परिणामस्वरूप अनुमानित समय nsecs - 0 , nsecs के बजाय - शुरू होता है ।

4. कार्यक्रम का मुख्य भाग।

nsecs - st art [tid] गणना करता है कि vfs_read फ़ंक्शन की शुरुआत के बाद कितना समय बीत चुका है।
@ns [comm] = hist (...) निर्दिष्ट डेटा को @ns में संग्रहीत दो-आयामी हिस्टोग्राम में जोड़ता है । कॉम कुंजी वर्तमान एप्लिकेशन के नाम को संदर्भित करती है। तो हमारे पास कमांड द्वारा हिस्टोग्राम कमांड होगी।

हटाएं (...) प्रारंभ समय को साहचर्य सरणी से हटाता है, क्योंकि अब हमें इसकी आवश्यकता नहीं है।

यह अंतिम निष्कर्ष है। कृपया ध्यान दें कि सभी हिस्टोग्राम स्वचालित रूप से प्रदर्शित होते हैं। प्रिंट हिस्टोग्राम कमांड के स्पष्ट उपयोग की आवश्यकता नहीं है। @ एक विशेष चर नहीं है, इसलिए हिस्टोग्राम इसके कारण प्रदर्शित नहीं होता है।

 @ns[snmp-pass]: [0, 1] 0 | | [2, 4) 0 | | [4, 8) 0 | | [8, 16) 0 | | [16, 32) 0 | | [32, 64) 0 | | [64, 128) 0 | | [128, 256) 0 | | [256, 512) 27 |@@@@@@@@@ | [512, 1k) 125 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | [1k, 2k) 22 |@@@@@@@ | [2k, 4k) 1 | | [4k, 8k) 10 |@@@ | [8k, 16k) 1 | | [16k, 32k) 3 |@ | [32k, 64k) 144 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [64k, 128k) 7 |@@ | [128k, 256k) 28 |@@@@@@@@@@ | [256k, 512k) 2 | | [512k, 1M) 3 |@ | [1M, 2M) 1 | | 

USDT सेंसर उदाहरण

आइए इस C कोड को लें और इसे tracetest.c फ़ाइल में सहेजें :

 #include <sys/sdt.h> #include <sys/time.h> #include <unistd.h> #include <stdio.h> static long myclock() { struct timeval tv; gettimeofday(&tv, NULL); DTRACE_PROBE1(tracetest, testprobe, tv.tv_sec); return tv.tv_sec; } int main(int argc, char **argv) { while (1) { myclock(); sleep(1); } return 0; } 

यह कार्यक्रम एक बार प्रति सेकंड myclock () कहकर चलाता है। myclock () वर्तमान समय पर सवाल उठाता है और युग की शुरुआत से सेकंड की संख्या लौटाता है।

यहां DTRACE_PROBE1 पर कॉल एक स्थिर USDT ट्रेस बिंदु को परिभाषित करता है।

• मैक्रो DTRACE_PROBE1 sys / sdt.h से लिया गया है आधिकारिक USDT मैक्रो, जो ऐसा ही करता है, STAP_PROBE1 ( सिस्टमटैप से STAP, जिसे यूएसडीटी में समर्थित पहला लिनक्स तंत्र था) कहा जाता है। लेकिन चूंकि USDT DTrace यूजर स्पेस सेंसर के साथ संगत है, DTRACE_PROBE1 सिर्फ STAP_PROBE1 का संदर्भ है।
• पहला पैरामीटर प्रदाता का नाम है। मेरा मानना ​​है कि यह DTrace से बचा हुआ एक वेस्टेस्टियल है, क्योंकि bpftrace इसके साथ कुछ भी उपयोगी नहीं लगता है। हालाँकि, एक अति सूक्ष्म अंतर है ( जिसे मैंने 328 अनुरोध पर समस्या को डीबग करते समय खोजा था ): प्रदाता का नाम आवेदन के बाइनरी फ़ाइल नाम के समान होना चाहिए, अन्यथा bpftrace ट्रेस बिंदु को खोजने में सक्षम नहीं होगा।
• दूसरा पैरामीटर ट्रेस बिंदु का नाम है।
• किसी भी अतिरिक्त पैरामीटर डेवलपर्स द्वारा प्रदान किए गए संदर्भ हैं। DTRACE_PROBE1 में नंबर 1 का मतलब है कि हम एक अतिरिक्त पैरामीटर पास करना चाहते हैं।

आइए सुनिश्चित करें कि sys / sdt.h हमारे लिए उपलब्ध है, और कार्यक्रम को एक साथ रखा जाए:

 sudo apt install systemtap-sdt-dev gcc tracetest.c -o tracetest -Wall -g 

हम पीआईडी ​​का उत्पादन करने के लिए bpftrace का निर्देश देते हैं और जब भी टेस्टप्रॉब पहुँचता है तो "समय [संख्या]" होता है :

 sudo bpftrace -e 'usdt:/full-path-to/tracetest:testprobe { printf("%d: time is %d\n", pid, arg0); }' 

Ctrl-C दबाते समय Bpftrace काम करना जारी रखता है। इसलिए, एक नया टर्मिनल खोलें और वहां ट्रेसटेस्ट चलाएं :

# नए टर्मिनल में
./tracetest

Bpftrace के साथ पहले टर्मिनल पर वापस जाएं, वहां आपको कुछ इस तरह देखना चाहिए:

 Attaching 1 probe... 30909: time is 1549023215 30909: time is 1549023216 30909: time is 1549023217 ... ^C 

उदाहरण मेमोरी आवंटन glibc ptmalloc का उपयोग करके

मैं समझने के लिए bpftrace का उपयोग करता हूं कि रूबी इतनी मेमोरी का उपयोग क्यों करती है। और मेरे शोध के हिस्से के रूप में, मुझे यह समझने की आवश्यकता है कि ग्लिबक के मेमोरी एलोकेटर मेमोरी क्षेत्रों का उपयोग कैसे करते हैं ।

बहु-कोर प्रदर्शन का अनुकूलन करने के लिए, glibc मेमोरी एलोकेटर OS से कई "क्षेत्र" आवंटित करता है। जब एप्लिकेशन मेमोरी आवंटन के लिए पूछता है, तो आवंटन एक ऐसे क्षेत्र का चयन करता है जो उपयोग में नहीं है, और इस क्षेत्र के हिस्से को "उपयोग" के रूप में चिह्नित करता है। चूंकि धागे विभिन्न क्षेत्रों का उपयोग करते हैं, तालों की संख्या कम हो जाती है, जिससे बेहतर बहु-थ्रेडेड प्रदर्शन होता है।

लेकिन यह दृष्टिकोण बहुत अधिक कचरा पैदा करता है, और ऐसा लगता है कि रूबी में इस तरह की उच्च मेमोरी खपत ठीक इसके कारण है। इस कचरे की प्रकृति को बेहतर ढंग से समझने के लिए, मैंने सोचा: इसका क्या मतलब है "ऐसा क्षेत्र चुनें जिसका उपयोग न हो"? इसका मतलब यह हो सकता है:

• हर बार मॉलॉक () को कहा जाता है, आवंटनकर्ता सभी क्षेत्रों में पुनरावृत्ति करता है और वह पाता है जो वर्तमान में बंद नहीं है। और केवल अगर वे सभी अवरुद्ध हैं, तो वह एक नया बनाने की कोशिश करेगा।
• पहली बार मॉलॉक () को एक विशिष्ट थ्रेड (या जब थ्रेड शुरू होता है) पर बुलाया जाता है, तो आवंटनकर्ता उस का चयन करेगा जो वर्तमान में अवरुद्ध नहीं है। और अगर वे सभी अवरुद्ध हैं, तो वह एक नया बनाने की कोशिश करेगा।
• पहली बार मॉलॉक () को एक विशिष्ट थ्रेड (या जब थ्रेड शुरू होता है) पर बुलाया जाता है, तो आवंटनकर्ता एक नया क्षेत्र बनाने की कोशिश करेगा, चाहे वे अनलॉक किए गए क्षेत्र हों। केवल अगर एक नया क्षेत्र नहीं बनाया जा सकता है (उदाहरण के लिए, जब सीमा समाप्त हो जाती है), यह मौजूदा एक का पुन: उपयोग करेगा।
• शायद अधिक विकल्प हैं जिन्हें मैंने नहीं माना है।

प्रलेखन में कोई विशिष्ट उत्तर नहीं है, इन सुविधाओं में से कौन सा आपको उस क्षेत्र का चयन करने की अनुमति देता है जिसका उपयोग नहीं किया जाता है। मैंने ग्लिबक के लिए स्रोत कोड का अध्ययन किया, जो सुझाव दिया कि विकल्प 3 ऐसा कर सकता है। लेकिन मैं प्रायोगिक रूप से सत्यापित करना चाहता था कि मैंने glibc में कोड डीबगिंग की आवश्यकता के बिना स्रोत कोड की सही व्याख्या की है।

यहाँ glibc मेमोरी एलोकेटर फ़ंक्शन है जो एक नया क्षेत्र बनाता है। लेकिन आप लिमिट की जांच के बाद ही इसे कॉल कर सकते हैं।

 static mstate _int_new_arena(size_t size) { mstate arena; size = calculate_how_much_memory_to_ask_from_os(size); arena = do_some_stuff_to_allocate_memory_from_os(); LIBC_PROBE(memory_arena_new, 2, arena, size); do_more_stuff(); return arena; } 

क्या मैं _int_new_arena फ़ंक्शन को ट्रेस करने के लिए अपबोर्स का उपयोग कर सकता हूं? दुर्भाग्य से, नहीं। किसी कारण से यह प्रतीक ग्लिब उबंटू 18.04 में उपलब्ध नहीं है। डिबगिंग प्रतीकों को स्थापित करने के बाद भी।

सौभाग्य से, इस फ़ंक्शन में एक USDT सेंसर है। LIBC_PROBE STAP_PROBE के लिए एक स्थूल उपनाम है।
प्रदाता का नाम libc है।
सेंसर का नाम memory_arena_new है।
नंबर 2 का मतलब है कि डेवलपर द्वारा निर्दिष्ट 2 अतिरिक्त तर्क हैं।
अखाड़ा उस क्षेत्र का पता है जिसे ओएस से निकाला गया था, और आकार इसका आकार है।

इससे पहले कि हम इस सेंसर का उपयोग कर सकें, हमें लगभग अंक 328 प्राप्त करने की आवश्यकता है । हमें नाम libc के साथ कहीं न कहीं glibc के साथ एक प्रतीकात्मक लिंक बनाने की आवश्यकता है, क्योंकि bpftrace से पुस्तकालय का नाम (जो अन्यथा libc-2.27.so होगा) प्रदाता नाम (libc) के समान होने की उम्मीद करता है।

 ln -s /lib/x86_64-linux-gnu/libc-2.27.so /tmp/libc 

अब हम bpftrace को USDT memory_arena_new सेंसर पर हुक करने का निर्देश देते हैं, जिसका विक्रेता नाम libc है :

 sudo bpftrace -e 'usdt:/tmp/libc:memory_arena_new { printf("PID %d: created new arena at %p, size %d\n", pid, arg0, arg1); }' 

एक अन्य टर्मिनल में, हम रूबी चलाएंगे, जो तीन धागे बनाएगा जो कुछ नहीं करते हैं और एक सेकंड में समाप्त हो जाते हैं। दुभाषिया के वैश्विक अवरोध के कारण, रूबी मॉलोक () को अलग-अलग थ्रेड द्वारा समानांतर में नहीं बुलाया जाना चाहिए।

 ruby -e '3.times { Thread.new { } }; sleep 1' 

Bpftrace के साथ टर्मिनल पर लौटते हुए, हम देखेंगे:

 Attaching 1 probe... PID 431: created new arena at 0x7f40e8000020, size 576 PID 431: created new arena at 0x7f40e0000020, size 576 PID 431: created new arena at 0x7f40e4000020, size 576 

यहाँ हमारे सवाल का जवाब है! हर बार जब आप रूबी में एक नया धागा बनाते हैं, तो प्रतिस्पर्धा की परवाह किए बिना एक नए क्षेत्र पर प्रकाश डाला जाता है।

क्या ट्रेस पॉइंट उपलब्ध हैं? मुझे क्या पता लगाना चाहिए?

आप सभी हार्डवेयर, टाइमर, kprobe और स्टेटिक कर्नेल ट्रेस पॉइंट को कमांड चलाकर सूचीबद्ध कर सकते हैं:

 sudo bpftrace -l 

आप किसी एप्लिकेशन या लाइब्रेरी के सभी अपवर्ड ट्रेस पॉइंट्स (फंक्शन कैरेक्टर) को सूचीबद्ध कर सकते हैं:

 nm /path-to-binary 

आप निम्नलिखित कमांड को चलाकर USDT एप्लिकेशन या लाइब्रेरी के सभी ट्रेस पॉइंट्स को सूचीबद्ध कर सकते हैं:

 /usr/share/bcc/tools/tplist -l /path-to/binary 

किस ट्रेस के उपयोग के बारे में: यह पता लगाने के लिए कि आप जो ट्रेस करने जा रहे हैं, उसके स्रोत कोड को समझने में दुख नहीं होगा। मैं आपको स्रोत कोड का अध्ययन करने की सलाह देता हूं।

युक्ति: कर्नेल में ट्रेस बिंदुओं के लिए एक संरचनात्मक प्रारूप

यहां कर्नेल ट्रेस पॉइंट्स पर एक उपयोगी टिप दी गई है। आप जाँच सकते हैं कि फ़ाइल / sys / कर्नेल / डीबग / ट्रेसिंग / ईवेंट्स को पढ़कर कौन से तर्क फ़ील्ड उपलब्ध हैं!

उदाहरण के लिए, मान लें कि आप मैडवाइज़ (..., MADV_DONTNEED) को कॉल ट्रेस करना चाहते हैं:

 sudo bpftrace -l | grep madvise 

- हमें बताएगा कि हम ट्रेसपॉइंट का उपयोग कर सकते हैं: syscalls: sys_enter_madvise।

 sudo cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_madvise/format 

- हमें निम्नलिखित जानकारी देंगे:

 name: sys_enter_madvise ID: 569 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int __syscall_nr; offset:8; size:4; signed:1; field:unsigned long start; offset:16; size:8; signed:0; field:size_t len_in; offset:24; size:8; signed:0; field:int behavior; offset:32; size:8; signed:0; print fmt: "start: 0x%08lx, len_in: 0x%08lx, behavior: 0x%08lx", ((unsigned long)(REC->start)), ((unsigned long)(REC->len_in)), ((unsigned long)(REC->behavior)) 

मैनुअल के अनुसार Madvise हस्ताक्षर: (शून्य * addr, size_t लंबाई, int सलाह) । इस संरचना के अंतिम तीन क्षेत्र इन मापदंडों के अनुरूप हैं!

MADV_DONTNEED का अर्थ क्या है? Grep MADV_DONTNEED / usr / को शामिल करके देखते हुए, यह 4 के बराबर है:

 /usr/include/x86_64-linux-gnu/bits/mman-linux.h:80:# define MADV_DONTNEED 4 /* Don't need these pages. */ 

तो हमारी bpftrace टीम बन जाती है:

 sudo bpftrace -e 'tracepoint:syscalls:sys_enter_madvise /args->behavior == 4/ { printf("madvise DONTNEED called\n"); }' 

निष्कर्ष

Bpftrace अद्भुत है! Bpftrace भविष्य है!

यदि आप उसके बारे में अधिक जानना चाहते हैं, तो मेरा सुझाव है कि आप अपने नेतृत्व के साथ-साथ ब्रेंडन ग्रेग के ब्लॉग पर 2019 की पहली पोस्ट से परिचित हों।

अच्छा डिबगिंग!