उच्च सीएफएच लेटेंसी से कर्नेल पैच के साथ ईआरपीएफ / बीसीसी

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

कुछ साल पहले, एक और उपकरण विकसित किया गया था - eBPF। यह कर्नेल और उपयोगकर्ता अनुप्रयोगों को कम ओवरहेड के साथ ट्रेस करना और कार्यक्रमों के पुनर्निर्माण की आवश्यकता के बिना और कर्नेल में तृतीय-पक्ष मॉड्यूल लोड करना संभव बनाता है।

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

सिफ धीमी है

सेफह क्लस्टर में एक नया होस्ट जोड़ा गया है। इसमें से कुछ डेटा को माइग्रेट करने के बाद, हमने देखा कि लिखने के अनुरोधों को संसाधित करने की गति अन्य सर्वरों की तुलना में बहुत कम है।


अन्य प्लेटफार्मों के विपरीत, इस होस्ट पर bcache और नए linux 4.15 कर्नेल का उपयोग किया गया था। इस विन्यास का एक मेजबान पहली बार यहाँ इस्तेमाल किया गया था। और उस समय यह स्पष्ट था कि सैद्धांतिक रूप से समस्या की जड़ कुछ भी हो सकती है।

मेज़बान की जाँच

शुरुआत करने के लिए, आइए देखें कि सीफ-ओएसडी प्रक्रिया के अंदर क्या होता है। ऐसा करने के लिए, हम perf और flamescope का उपयोग करते हैं (अधिक जिनके बारे में यहां पढ़ा जा सकता है ):


चित्र हमें बताता है कि fdatasync () फ़ंक्शन ने जेनेरिक_मेक_रेक्वेस्ट () फ़ंक्शन के लिए अनुरोध भेजने में बहुत समय बिताया है। इसका मतलब यह है कि सबसे अधिक संभावना है कि समस्याओं का कारण कहीं न कहीं ओएसडी डेमॉन के बाहर है। यह कर्नेल या डिस्क हो सकता है। Iostat आउटपुट ने bcache डिस्क के साथ प्रसंस्करण अनुरोधों में एक उच्च विलंबता दिखाई।

होस्ट की जाँच करते समय, हमने पाया कि सिस्टम-यूडव्ड डेमन बड़ी मात्रा में सीपीयू समय की खपत करता है - कई कोर पर लगभग 20%। यह एक अजीब व्यवहार है, इसलिए आपको इसका कारण जानने की जरूरत है। चूंकि Systemd-udevd uevents के साथ काम करता है, हमने उन्हें udvadm मॉनिटर के माध्यम से देखने का फैसला किया। यह पता चलता है कि सिस्टम में प्रत्येक ब्लॉक डिवाइस के लिए बड़ी संख्या में परिवर्तन की घटनाएं उत्पन्न हुई थीं। यह काफी असामान्य है, इसलिए आपको यह देखने की आवश्यकता होगी कि इन सभी घटनाओं को क्या उत्पन्न करता है।

बीसीसी टूलकिट का उपयोग करना

जैसा कि हम पहले ही पता लगा चुके हैं, कर्नेल (और सिस्टम कॉल में सेफ डेमन) जेनेरिक_मेके_रेक्वेस्ट () में बहुत समय बिताता है। आइए इस फ़ंक्शन की गति को मापने का प्रयास करें। बीसीसी में पहले से ही एक महान उपयोगिता है - फंगलसिटी । हम 1 सेकंड के सूचना आउटपुट के बीच अंतराल के साथ पीआईडी ​​द्वारा डेमन का पता लगाएंगे और मिलीसेकंड में परिणाम का उत्पादन करेंगे।


आमतौर पर यह फंक्शन फास्ट होता है। वह जो कुछ भी करती है वह डिवाइस ड्राइवर कतार को अनुरोध भेजती है।

Bcache एक जटिल उपकरण है जिसमें वास्तव में तीन डिस्क होते हैं:

• बैकिंग डिवाइस (कैश्ड डिस्क), इस मामले में यह एक धीमी एचडीडी है;
• कैशिंग डिवाइस (कैशिंग डिस्क), यहां यह NVMe डिवाइस का एक सेक्शन है;
• bcache वर्चुअल डिवाइस जिसके साथ एप्लिकेशन काम करता है।

हम जानते हैं कि अनुरोध संचरण धीमा है, लेकिन इनमें से किस उपकरण के लिए? हम इससे थोड़ी देर बाद निपटेंगे।

अब हम जानते हैं कि uevents शायद समस्याएं पैदा कर रहे हैं। यह जानना कि वास्तव में उनकी पीढ़ी क्या कारण है, इतना सरल नहीं है। मान लीजिए यह किसी प्रकार का सॉफ्टवेयर है जो समय-समय पर चलता है। आइए देखें कि बीसीसी उपयोगिताओं के एक ही सेट से निष्पादित स्क्रिप्ट का उपयोग करके सिस्टम पर किस तरह का सॉफ्टवेयर लॉन्च किया गया है। इसे चलाएँ और आउटपुट को किसी फ़ाइल में निर्देशित करें।

उदाहरण के लिए, इस तरह:

/usr/share/bcc/tools/execsnoop | tee ./execdump 

हम यहाँ पर execsnoop का पूरा आउटपुट नहीं देंगे, लेकिन हमारे लिए ब्याज की एक पंक्ति इस तरह दिखती है:

 sh 1764905 5802 0 sudo arcconf getconfig 1 AD | grep Temperature | awk -F '[:/]' '{print $2}' | sed 's/^ \([0-9]*\) C.*/\1/' 

तीसरा कॉलम प्रक्रिया का PPID (मूल पीआईडी) है। पीआईडी ​​5802 के साथ प्रक्रिया हमारी निगरानी प्रणाली के धागे में से एक बन गई। निगरानी प्रणाली के कॉन्फ़िगरेशन की जांच करते समय, गलत पैरामीटर पाए गए थे। एचबीए एडाप्टर का तापमान हर 30 सेकंड में एक बार लिया जाता था, जो कि आवश्यकता से बहुत अधिक होता है। सत्यापन अंतराल को एक लंबे समय तक बदलने के बाद, हमने पाया कि इस मेजबान पर प्रसंस्करण अनुरोधों में देरी मेजबान के बाकी हिस्सों से बाहर रहना बंद कर दिया है।

लेकिन यह अभी भी स्पष्ट नहीं है कि bcache डिवाइस इतना धीमा क्यों था। हमने एक समरूप विन्यास के साथ एक परीक्षण मंच तैयार किया और bcache पर फियो चलाकर समस्या को पुन: उत्पन्न करने की कोशिश की, समय-समय पर uevents उत्पन्न करने के लिए udevadm ट्रिगर शुरू किया।

लेखन BCC- आधारित उपकरण

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

योजना सरल है:

• जेनेरिक_मेक_रेक्वेस्ट () में रजिस्टर करें
  
  • हम फ़ंक्शन तर्क के माध्यम से सुलभ डिस्क नाम को बचाते हैं;
  • समय की मोहर बचाओ।
  
  

• Generic_make_request () से लौटने के लिए kretprobe को पंजीकृत करें:
  
  • वर्तमान टाइमस्टैम्प प्राप्त करें;
  • हम सहेजे गए समय टिकट की खोज करते हैं और वर्तमान के साथ इसकी तुलना करते हैं;
  • यदि परिणाम निर्दिष्ट एक से अधिक है, तो हम सहेजे गए डिस्क नाम को ढूंढते हैं और इसे टर्मिनल पर प्रदर्शित करते हैं।
  
  

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

पायथन लिपि के अंदर ईएक्सपीएफ पाठ इस तरह दिखता है:

 bpf_text = “”” # Here will be the bpf program code “”” 

फ़ंक्शंस के बीच डेटा का आदान-प्रदान करने के लिए, eBPF प्रोग्राम हैश टेबल का उपयोग करते हैं। तो हम करेंगे। कुंजी के रूप में, हम प्रक्रिया के पीआईडी ​​का उपयोग करेंगे, और मूल्य के रूप में हम संरचना को परिभाषित करते हैं:

 struct data_t { u64 pid; u64 ts; char comm[TASK_COMM_LEN]; u64 lat; char disk[DISK_NAME_LEN]; }; BPF_HASH(p, u64, struct data_t); BPF_PERF_OUTPUT(events); 

यहाँ हम एक हैश टेबल को रजिस्टर करते हैं, जिसे p कहा जाता है, जिसमें टाइप u64 की कुंजी और टाइप स्ट्रक्चर data_t का मान है। तालिका हमारे बीपीएफ कार्यक्रम के संदर्भ में उपलब्ध होगी। BPF_PERF_OUTPUT मैक्रो इवेंट्स नामक किसी अन्य तालिका को पंजीकृत करता है, जिसका उपयोग उपयोगकर्ता स्थान पर डेटा स्थानांतरित करने के लिए किया जाता है।

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

अगला, हमें उस कोड को लिखना होगा जो तब चलाया जाएगा जब जांच की जा रही फ़ंक्शन को कहा जाता है:

 void start(struct pt_regs *ctx, struct bio *bio) { u64 pid = bpf_get_current_pid_tgid(); struct data_t data = {}; u64 ts = bpf_ktime_get_ns(); data.pid = pid; data.ts = ts; bpf_probe_read_str(&data.disk, sizeof(data.disk), (void*)bio->bi_disk->disk_name); p.update(&pid, &data); } 

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

निम्नलिखित फ़ंक्शन को जेनेरिक_मेक_रेक्वेस्ट () से वापसी पर बुलाया जाएगा:

 void stop(struct pt_regs *ctx) { u64 pid = bpf_get_current_pid_tgid(); u64 ts = bpf_ktime_get_ns(); struct data_t* data = p.lookup(&pid); if (data != 0 && data->ts > 0) { bpf_get_current_comm(&data->comm, sizeof(data->comm)); data->lat = (ts - data->ts)/1000; if (data->lat > MIN_US) { FACTOR data->pid >>= 32; events.perf_submit(ctx, data, sizeof(struct data_t)); } p.delete(&pid); } } 

यह फ़ंक्शन पिछले एक के समान है: हम प्रक्रिया पीआईडी ​​और टाइमस्टैम्प को पहचानते हैं, लेकिन नए डेटा संरचना के लिए मेमोरी आवंटित नहीं करते हैं। इसके बजाय, हम कुंजी == वर्तमान पीआईडी ​​के साथ एक मौजूदा संरचना के लिए हैश तालिका में देखते हैं। यदि संरचना पाई जाती है, तो हम चल रही प्रक्रिया का नाम पता करेंगे और इसे इसमें जोड़ देंगे।

थ्रेड GID प्राप्त करने के लिए हमारे द्वारा उपयोग की जाने वाली बाइनरी शिफ्ट की आवश्यकता है। यानी मुख्य प्रक्रिया का पीआईडी ​​जिसने थ्रेड शुरू किया जिसके संदर्भ में हम काम कर रहे हैं। Bpf_get_current_pid_tgid () फ़ंक्शन जिसे हम थ्रेड के GID और इसके PID दोनों को एक 64-बिट मान में रिटर्न कह रहे हैं।

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

इस कोड को लोड करने वाले अजगर स्क्रिप्ट में, हमें देरी सीमा और समय इकाइयों के साथ MIN_US और FACTOR को बदलना होगा, जिसे हम तर्कों के माध्यम से पारित करेंगे:

 bpf_text = bpf_text.replace('MIN_US',str(min_usec)) if args.milliseconds: bpf_text = bpf_text.replace('FACTOR','data->lat /= 1000;') label = "msec" else: bpf_text = bpf_text.replace('FACTOR','') label = "usec" 

अब हमें BPF मैक्रो के माध्यम से BPF प्रोग्राम तैयार करने और नमूनों को पंजीकृत करने की आवश्यकता है:

 b = BPF(text=bpf_text) b.attach_kprobe(event="generic_make_request",fn_name="start") b.attach_kretprobe(event="generic_make_request",fn_name="stop") 

हमें अपनी स्क्रिप्ट में संरचनात्मक data_t को भी परिभाषित करना होगा, अन्यथा हम कुछ भी नहीं पढ़ पाएंगे:

 TASK_COMM_LEN = 16 # linux/sched.h DISK_NAME_LEN = 32 # linux/genhd.h class Data(ct.Structure): _fields_ = [("pid", ct.c_ulonglong), ("ts", ct.c_ulonglong), ("comm", ct.c_char * TASK_COMM_LEN), ("lat", ct.c_ulonglong), ("disk",ct.c_char * DISK_NAME_LEN)] 

अंतिम चरण टर्मिनल के लिए डेटा आउटपुट है:

 def print_event(cpu, data, size): global start event = ct.cast(data, ct.POINTER(Data)).contents if start == 0: start = event.ts time_s = (float(event.ts - start)) / 1000000000 print("%-18.9f %-16s %-6d %-1s %s %s" % (time_s, event.comm, event.pid, event.lat, label, event.disk)) b["events"].open_perf_buffer(print_event) # format output start = 0 while 1: try: b.perf_buffer_poll() except KeyboardInterrupt: exit() 

स्क्रिप्ट खुद GItHub पर उपलब्ध है। आइए इसे एक परीक्षण मंच पर चलाने की कोशिश करें जहां fio को bcache में लिखा गया है और udevadm मॉनीटर को कॉल करें:


अंत में! अब हम देखते हैं कि ब्रेकिंग bcache डिवाइस जैसा दिखने वाला वास्तव में कैश्ड ड्राइव पर generic_make_request () के लिए एक ब्रेकिंग कॉल है।

गिरी में खोदो

अनुरोध के प्रसारण के दौरान वास्तव में क्या धीमा हो जाता है? हम देखते हैं कि विलंब अनुरोध के शुरू होने से पहले ही होता है, अर्थात। इस पर आगे के आंकड़ों (/ proc / diskstats या iostat) के लिए एक विशेष अनुरोध के लिए लेखांकन अभी तक शुरू नहीं हुआ है। समस्या को पुन: पेश करते हुए, या बीसीसी बायोलैटी लिपि को पुन: प्रस्तुत करते हुए इसे आईओस्टेट से आसानी से सत्यापित किया जा सकता है, जो अनुरोधों के लेखांकन के आरंभ और अंत पर आधारित है। इन उपयोगिताओं में से कोई भी कैश्ड ड्राइव के लिए प्रश्नों के लिए समस्या नहीं दिखाएगी।

यदि हम जेनेरिक_मेक_रेक्वेस्ट () फ़ंक्शन पर एक नज़र डालते हैं , तो हम देखेंगे कि अनुरोध दर्ज होने से पहले दो और कार्य कहे जाते हैं। पहला, जेनेरिक_मेके_रेक्वेस्ट_चेक () , डिस्क सेटिंग्स के लिए अनुरोध की वैधता की जांच करता है। दूसरा blk_queue_enter () है , जिसमें Wait_event_interruptible () के लिए एक दिलचस्प कॉल है:

 ret = wait_event_interruptible(q->mq_freeze_wq, (atomic_read(&q->mq_freeze_depth) == 0 && (preempt || !blk_queue_preempt_only(q))) || blk_queue_dying(q)); 

इसमें, कर्नेल कतार के डीफ्रॉस्ट का इंतजार करता है। हम देरी blk_queue_enter () को मापते हैं :

 ~# /usr/share/bcc/tools/funclatency blk_queue_enter -i 1 -m Tracing 1 functions for "blk_queue_enter"... Hit Ctrl-C to end. msecs : count distribution 0 -> 1 : 341 |****************************************| msecs : count distribution 0 -> 1 : 316 |****************************************| msecs : count distribution 0 -> 1 : 255 |****************************************| 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 1 | | 

ऐसा लगता है कि हम एक समाधान के करीब हैं। कतार को "फ्रीज / अनफ्रीज" करने के लिए उपयोग किए जाने वाले कार्य blk_mq_freeze_queue और blk_mq_unfreeze_queue हैं । उनका उपयोग तब किया जाता है जब क्वेरी कतार की सेटिंग्स को बदलना आवश्यक होता है, जो इस कतार में प्रश्नों के लिए संभावित रूप से खतरनाक होते हैं। जब blk_mq_freeze_queue () कहा जाता है, तो blk_freeze_queue_start () फ़ंक्शन q-> mq_freeze_depth काउंटर बढ़ाता है । उसके बाद, कर्नेल blk_mq_freeze_queue_wait () में कतार के खाली होने का इंतजार करता है।

इस कतार को खाली करने के लिए प्रतीक्षा करने का समय डिस्क विलंबता के बराबर है, क्योंकि कर्नेल सभी कतारबद्ध कार्यों के पूरा होने की प्रतीक्षा करता है। जैसे ही कतार खाली होती है, सेटिंग्स में परिवर्तन लागू होते हैं। फिर blk_mq_unfreeze_queue () कहा जाता है, काउंटर फ्रीज_डेप को घटाकर ।

अब हम स्थिति को सुधारने के लिए पर्याप्त जानते हैं। ब्लॉक डिवाइस के लिए सेटिंग्स के आवेदन में udvadm ट्रिगर कमांड परिणाम होता है। इन सेटिंग्स को udv नियमों में वर्णित किया गया है। हम वास्तव में यह पता लगा सकते हैं कि कौन सी सेटिंग्स को "फ्रीज" करें उन्हें sysfs के माध्यम से या कर्नेल स्रोत कोड को देखकर बदलने की कोशिश करें। हम BCC ट्रेस उपयोगिता की भी कोशिश कर सकते हैं, जो प्रत्येक blk_freeze_queue कॉल के लिए टर्मिनल के लिए कर्नेल स्टैक और उपयोगकर्ता स्थान के निशान दिखाता है , उदाहरण के लिए:

 ~# /usr/share/bcc/tools/trace blk_freeze_queue -K -U PID TID COMM FUNC 3809642 3809642 systemd-udevd blk_freeze_queue blk_freeze_queue+0x1 [kernel] elevator_switch+0x29 [kernel] elv_iosched_store+0x197 [kernel] queue_attr_store+0x5c [kernel] sysfs_kf_write+0x3c [kernel] kernfs_fop_write+0x125 [kernel] __vfs_write+0x1b [kernel] vfs_write+0xb8 [kernel] sys_write+0x55 [kernel] do_syscall_64+0x73 [kernel] entry_SYSCALL_64_after_hwframe+0x3d [kernel] __write_nocancel+0x7 [libc-2.23.so] [unknown] 3809631 3809631 systemd-udevd blk_freeze_queue blk_freeze_queue+0x1 [kernel] queue_requests_store+0xb6 [kernel] queue_attr_store+0x5c [kernel] sysfs_kf_write+0x3c [kernel] kernfs_fop_write+0x125 [kernel] __vfs_write+0x1b [kernel] vfs_write+0xb8 [kernel] sys_write+0x55 [kernel] do_syscall_64+0x73 [kernel] entry_SYSCALL_64_after_hwframe+0x3d [kernel] __write_nocancel+0x7 [libc-2.23.so] [unknown] 

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

निष्कर्ष

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

EBPF पर आधारित अन्य दिलचस्प डिबगिंग और प्रोफाइलिंग टूल हैं। उनमें से एक bpftrace है , जो आपको अजीब -भाषा में शक्तिशाली सिंगल-लाइन और छोटे प्रोग्राम लिखने की अनुमति देता है। एक और एक - ebpf_exporter , आपको निम्न स्तर के उच्च-रिज़ॉल्यूशन मैट्रिक्स को सीधे अपने प्रोमेथियस सर्वर में इकट्ठा करने की अनुमति देता है, जिसमें भविष्य में सुंदर दृश्य और यहां तक ​​कि अलर्ट प्राप्त करने की क्षमता होती है।