🥇लोकी से लॉग एकत्रित करना

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

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

लोकी क्या है?

ग्राफाना लोकी लॉग के साथ काम करने के लिए एक संपूर्ण सिस्टम के लिए घटकों का एक सेट है। अन्य समान प्रणालियों के विपरीत, लोकी केवल लॉग मेटाडेटा - लेबल (प्रोमेथियस के समान) को अनुक्रमित करने और लॉग को अलग-अलग हिस्सों में संपीड़ित करने के विचार पर आधारित है।

होम पेज, GitHub

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

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&amp;item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

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

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

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

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

लॉग खोजें

आप लॉग को एक विशेष ग्राफाना इंटरफ़ेस - एक्सप्लोरर में खोज सकते हैं। क्वेरीज़ LogQL भाषा का उपयोग करती हैं, जो प्रोमेथियस में प्रयुक्त PromQL के समान है। सिद्धांत रूप में, इसे एक वितरित ग्रेप के रूप में सोचा जा सकता है।

खोज इंटरफ़ेस इस तरह दिखता है:

अनुरोध में स्वयं दो भाग होते हैं: चयनकर्ता और फ़िल्टर। चयनकर्ता अनुक्रमित मेटाडेटा (लेबल) का उपयोग करके एक खोज है जो लॉग को सौंपा गया है, और फ़िल्टर एक खोज स्ट्रिंग या regexp है जो चयनकर्ता द्वारा परिभाषित रिकॉर्ड को फ़िल्टर करता है। दिए गए उदाहरण में: घुंघराले ब्रेसिज़ में एक चयनकर्ता होता है, उसके बाद सब कुछ एक फ़िल्टर होता है।

{image_name="nginx.promtail.test"} |= "index"

लोकी के काम करने के तरीके के कारण, आप चयनकर्ता के बिना प्रश्न नहीं बना सकते हैं, लेकिन लेबल को आपकी इच्छानुसार सामान्य बनाया जा सकता है।

चयनकर्ता घुंघराले ब्रेसिज़ में एक कुंजी-मूल्य मान है। आप चयनकर्ताओं को जोड़ सकते हैं और ऑपरेटरों =, != या नियमित अभिव्यक्तियों का उपयोग करके विभिन्न खोज स्थितियाँ निर्दिष्ट कर सकते हैं:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev

फ़िल्टर टेक्स्ट या regexp है जो चयनकर्ता द्वारा प्राप्त सभी डेटा को फ़िल्टर कर देगा।

मेट्रिक्स मोड में प्राप्त डेटा के आधार पर तदर्थ ग्राफ़ प्राप्त करना संभव है। उदाहरण के लिए, आप पता लगा सकते हैं कि nginx लॉग में स्ट्रिंग इंडेक्स वाली प्रविष्टि कितनी बार दिखाई देती है:

क्षमताओं का पूरा विवरण दस्तावेज़ में पाया जा सकता है लॉगक्यूएल.

लॉग पार्सिंग

लॉग एकत्रित करने के कई तरीके हैं:

लॉग एकत्र करने के लिए स्टैक के एक मानक घटक, प्रोमटेल का उपयोग करना।
सीधे डॉकर कंटेनर का उपयोग करके लोकी डॉकर लॉगिंग ड्राइवर।
फ्लुएंटडी या फ्लुएंट बिट का उपयोग करें, जो लोकी को डेटा भेज सकता है। प्रोमटेल के विपरीत, उनके पास लगभग किसी भी प्रकार के लॉग के लिए तैयार पार्सर हैं और मल्टीलाइन लॉग को भी संभाल सकते हैं।

आमतौर पर प्रोमटेल का उपयोग पार्सिंग के लिए किया जाता है। यह तीन काम करता है:

डेटा स्रोत ढूँढता है.
उन पर लेबल लगाता है.
लोकी को डेटा भेजता है।

वर्तमान में प्रोमटेल स्थानीय फाइलों और सिस्टमडी जर्नल से लॉग पढ़ सकता है। इसे प्रत्येक मशीन पर स्थापित किया जाना चाहिए जिससे लॉग एकत्र किए जाते हैं।

Kubernetes के साथ एकीकरण है: Promtail स्वचालित रूप से, Kubernetes REST API के माध्यम से, क्लस्टर की स्थिति को पहचानता है और नोड, सेवा या पॉड से लॉग एकत्र करता है, Kubernetes (पॉड नाम, फ़ाइल नाम, आदि) से मेटाडेटा के आधार पर तुरंत लेबल पोस्ट करता है। .

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

पार्सिंग चरण. यह रेगेक्स और JSON चरण है। इस स्तर पर, हम लॉग से डेटा को तथाकथित निकाले गए मानचित्र में निकालते हैं। हम JSON से निकाले गए मानचित्र में आवश्यक फ़ील्ड की प्रतिलिपि बनाकर, या रेगुलर एक्सप्रेशन (RegEx) के माध्यम से JSON से निकाल सकते हैं, जहां नामित समूह निकाले गए मानचित्र में "मैप" किए जाते हैं। एक्सट्रेक्टेड मैप एक कुंजी-मूल्य भंडार है, जहां कुंजी फ़ील्ड का नाम है, और मान लॉग से उसका मूल्य है।
परिवर्तन चरण. इस चरण में दो विकल्प हैं: परिवर्तन, जहां हम परिवर्तन नियम निर्धारित करते हैं, और स्रोत - निकाले गए मानचित्र से परिवर्तन के लिए डेटा स्रोत। यदि निकाले गए मानचित्र में ऐसा कोई फ़ील्ड नहीं है, तो इसे बनाया जाएगा। इस तरह ऐसे लेबल बनाना संभव है जो निकाले गए मानचित्र पर आधारित नहीं हैं। इस स्तर पर हम काफी शक्तिशाली का उपयोग करके निकाले गए मानचित्र में डेटा में हेरफेर कर सकते हैं गोलांग टेम्पलेट. इसके अलावा, हमें यह याद रखना चाहिए कि निकाले गए मानचित्र को पार्सिंग के दौरान पूरी तरह से लोड किया गया है, जो उदाहरण के लिए, इसमें मान की जांच करना संभव बनाता है: "{{यदि .tag}टैग मान मौजूद है{अंत}}"। टेम्प्लेट स्थितियों, लूपों और कुछ स्ट्रिंग फ़ंक्शंस जैसे रिप्लेस और ट्रिम का समर्थन करता है।
कार्रवाई के चरण. इस बिंदु पर आप निकाली गई सामग्री के साथ कुछ कर सकते हैं:
- निकाले गए डेटा से एक लेबल बनाएं, जिसे लोकी द्वारा अनुक्रमित किया जाएगा।
- लॉग से ईवेंट समय बदलें या सेट करें।
- डेटा (लॉग टेक्स्ट) बदलें जो लोकी में जाएगा।
- मेट्रिक्स बनाएं.
फ़िल्टरिंग चरण. मिलान चरण, जहां हम या तो ऐसी प्रविष्टियां भेज सकते हैं जिनकी हमें /dev/null करने की आवश्यकता नहीं है या उन्हें आगे की प्रक्रिया के लिए अग्रेषित कर सकते हैं।

नियमित nginx लॉग को संसाधित करने के एक उदाहरण का उपयोग करते हुए, मैं दिखाऊंगा कि आप Promtail का उपयोग करके लॉग को कैसे पार्स कर सकते हैं।

परीक्षण के लिए, आइए nginx-proxy के रूप में एक संशोधित nginx छवि jwilder/nginx-proxy:alpine और एक छोटा डेमॉन लें जो HTTP के माध्यम से खुद से पूछ सकता है। डेमॉन के पास कई समापन बिंदु हैं, जिन पर यह विभिन्न आकारों, विभिन्न HTTP स्थितियों और विभिन्न विलंबों के साथ प्रतिक्रियाएँ प्रदान कर सकता है।

हम डॉकर कंटेनरों से लॉग एकत्र करेंगे, जो /var/lib/docker/containers//-json.log पथ पर पाए जा सकते हैं

Docker-compose.yml में हम Promtail को कॉन्फ़िगर करते हैं और कॉन्फ़िगरेशन के लिए पथ निर्दिष्ट करते हैं:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

लॉग में पथ को promtail.yml में जोड़ें (कॉन्फ़िगरेशन में एक "डॉकर" विकल्प है, जो एक ही पंक्ति में एक ही काम करता है, लेकिन यह इतना स्पष्ट नहीं होगा):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

जब यह कॉन्फ़िगरेशन सक्षम हो जाता है, तो सभी कंटेनरों से लॉग लोकी को भेज दिए जाएंगे। इससे बचने के लिए, हम docker-compose.yml में परीक्षण nginx की सेटिंग्स बदलते हैं - एक लॉगिंग टैग फ़ील्ड जोड़ें:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

promtail.yml का संपादन और पाइपलाइन की स्थापना। इनपुट में निम्न प्रकार के लॉग शामिल हैं:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

पाइपलाइन चरण:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

हम आने वाले JSON से फ़ील्ड स्ट्रीम, attrs, attrs.tag (यदि वे मौजूद हैं) निकालते हैं और उन्हें निकाले गए मानचित्र में डालते हैं।

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

यदि हम निकाले गए मानचित्र में टैग फ़ील्ड डालने में कामयाब रहे, तो regexp का उपयोग करके हम छवि और कंटेनर के नाम निकालते हैं।

 - labels:
     image_name:
     container_name:

हम लेबल निर्दिष्ट करते हैं. यदि निकाले गए डेटा में छवि_नाम और कंटेनर_नाम कुंजी पाई जाती हैं, तो उनके मान संबंधित लेबल को निर्दिष्ट किए जाएंगे।

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

हम उन सभी लॉग को हटा देते हैं जिनमें छवि_नाम और कंटेनर_नाम लेबल स्थापित नहीं हैं।

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

उन सभी लॉग के लिए जिनका छवि_नाम nginx.promtail.test है, स्रोत लॉग से लॉग फ़ील्ड निकालें और इसे पंक्ति कुंजी के साथ निकाले गए मानचित्र में डालें।

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

हम रेगुलर एक्सप्रेशन के साथ इनपुट लाइन को साफ़ करते हैं और nginx वर्चुअल होस्ट और nginx लॉग लाइन को बाहर निकालते हैं।

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

रेगुलर एक्सप्रेशन का उपयोग करके nginx लॉग को पार्स करें।

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

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

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

टेम्प्लेट में सशर्त ऑपरेटरों का उपयोग करते हुए, हम निकाले गए मानचित्र में स्थापित फ़ील्ड की जांच करते हैं और request_type फ़ील्ड के लिए आवश्यक मान सेट करते हैं: फोटो, स्टेटिक, एपीआई। यदि यह विफल रहता है तो अन्य को नियुक्त करें। request_type में अब अनुरोध प्रकार शामिल है।

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

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

       - output:
           source: nginx_log_row

आउटपुट बदलें. अब निकाले गए मानचित्र से साफ़ किया गया nginx लॉग लोकी में जाता है।

उपरोक्त कॉन्फ़िगरेशन को चलाने के बाद, आप देख सकते हैं कि प्रत्येक प्रविष्टि को लॉग से डेटा के आधार पर लेबल दिए गए हैं।

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

लॉग का विज़ुअलाइज़ेशन

लोकी LogQL का उपयोग करके ग्राफाना ग्राफ़ के लिए डेटा स्रोत के रूप में कार्य कर सकता है। निम्नलिखित सुविधाएँ समर्थित हैं:

दर - प्रति सेकंड रिकॉर्ड की संख्या;
समय के साथ गिनती - निर्दिष्ट सीमा में रिकॉर्ड की संख्या।

योग, औसत और अन्य एकत्रीकरण कार्य भी हैं। आप काफी जटिल ग्राफ़ बना सकते हैं, उदाहरण के लिए HTTP त्रुटियों की संख्या का ग्राफ़:

प्रोमेथियस डेटा स्रोत की तुलना में मानक डेटा स्रोत लोकी की कार्यक्षमता कुछ हद तक कम हो गई है (उदाहरण के लिए, आप किंवदंती को नहीं बदल सकते हैं), लेकिन लोकी को प्रोमेथियस प्रकार के स्रोत के रूप में जोड़ा जा सकता है। मुझे यकीन नहीं है कि यह दस्तावेजी व्यवहार है, लेकिन डेवलपर्स की प्रतिक्रिया को देखते हुए "लोकी को प्रोमेथियस डेटास्रोत के रूप में कैसे कॉन्फ़िगर करें? · अंक #1222 · ग्राफाना/लोकी”, उदाहरण के लिए, पूरी तरह से कानूनी है, और लोकी PromQL के साथ पूरी तरह से संगत है।

प्रोमेथियस प्रकार के साथ लोकी को डेटा स्रोत के रूप में जोड़ें और यूआरएल /लोकी जोड़ें:

और हम ग्राफ़ बना सकते हैं, जैसे कि हम प्रोमेथियस के मेट्रिक्स के साथ काम कर रहे हों:

मुझे लगता है कि कार्यक्षमता में विसंगति अस्थायी है और डेवलपर्स भविष्य में इसे ठीक कर देंगे।

मेट्रिक्स

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

Promtail.yml में एक और अनुभाग जोड़ें:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

विकल्प आपको निकाले गए मानचित्र से डेटा के आधार पर मेट्रिक्स को परिभाषित और अपडेट करने की अनुमति देता है। ये मेट्रिक्स लोकी को नहीं भेजे जाते हैं - वे प्रोमटेल/मेट्रिक्स एंडपॉइंट में दिखाई देते हैं। इस स्तर पर प्राप्त डेटा प्राप्त करने के लिए प्रोमेथियस को कॉन्फ़िगर किया जाना चाहिए। उपरोक्त उदाहरण में, request_type=“api” के लिए हम एक हिस्टोग्राम मीट्रिक एकत्र करते हैं। इस प्रकार के मेट्रिक्स से प्रतिशत प्राप्त करना सुविधाजनक होता है। स्टेटिक और फोटो के लिए, हम औसत की गणना करने के लिए बाइट्स का योग और उन पंक्तियों की संख्या एकत्र करते हैं जिनमें हमें बाइट्स प्राप्त हुए थे।

मेट्रिक्स के बारे में और पढ़ें यहां.

Promtail पर पोर्ट खोलें:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

सुनिश्चित करें कि promtail_custom उपसर्ग वाले मेट्रिक्स दिखाई दें:

प्रोमेथियस की स्थापना. जॉब प्रोमटेल जोड़ें:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

और हम एक ग्राफ़ बनाते हैं:

इस तरह आप, उदाहरण के लिए, चार सबसे धीमी क्वेरी का पता लगा सकते हैं। आप इन मेट्रिक्स के लिए निगरानी भी सेट कर सकते हैं.

स्केलिंग

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

टुकड़ों को S3-संगत स्टोरेज में संग्रहीत किया जा सकता है, और क्षैतिज रूप से स्केलेबल डेटाबेस का उपयोग इंडेक्स को स्टोर करने के लिए किया जा सकता है: कैसेंड्रा, बिगटेबल या डायनेमोडीबी। लोकी के अन्य भाग - डिस्ट्रीब्यूटर (लेखन के लिए) और क्वैरियर (प्रश्नों के लिए) - स्टेटलेस हैं और क्षैतिज रूप से स्केल भी हैं।

DevOpsDays वैंकूवर 2019 सम्मेलन में, प्रतिभागियों में से एक कैलम स्टैन ने घोषणा की कि लोकी के साथ उनके प्रोजेक्ट में कुल आकार के 1% से कम इंडेक्स वाले पेटाबाइट लॉग हैं: "लोकी मेट्रिक्स और लॉग्स को कैसे सहसंबंधित करता है - और आपका पैसा बचाता है".

लोकी और ईएलके की तुलना

सूचकांक आकार

परिणामी सूचकांक आकार का परीक्षण करने के लिए, मैंने nginx कंटेनर से लॉग लिया जिसके लिए उपरोक्त पाइपलाइन कॉन्फ़िगर की गई थी। लॉग फ़ाइल में 406 एमबी की कुल मात्रा के साथ 624 लाइनें थीं। लॉग एक घंटे के भीतर तैयार किए गए, प्रति सेकंड लगभग 109 प्रविष्टियाँ।

लॉग से दो पंक्तियों का उदाहरण:

जब ईएलके द्वारा अनुक्रमित किया गया, तो इसने 30,3 एमबी का सूचकांक आकार दिया:

लोकी के मामले में, इसके परिणामस्वरूप लगभग 128 केबी सूचकांक और लगभग 3,8 एमबी डेटा टुकड़ों में प्राप्त हुआ। यह ध्यान देने योग्य है कि लॉग कृत्रिम रूप से तैयार किया गया था और इसमें बड़ी संख्या में डेटा नहीं था। डेटा के साथ मूल डॉकर JSON लॉग पर एक साधारण gzip ने 95,4% का संपीड़न दिया, और इस तथ्य को ध्यान में रखते हुए कि केवल साफ किया गया nginx लॉग ही लोकी को भेजा गया था, 4 एमबी तक का संपीड़न समझ में आता है। लोकी लेबल के लिए अद्वितीय मानों की कुल संख्या 35 थी, जो सूचकांक के छोटे आकार की व्याख्या करती है। ईएलके के लिए लॉग भी साफ़ कर दिया गया था। इस प्रकार, लोकी ने मूल डेटा को 96% और ईएलके ने 70% तक संपीड़ित किया।

मेमोरी खपत

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

गति

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

लॉग खोजें

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

अंतराफलक

सबसे पहले, यह सुंदर है (क्षमा करें, विरोध नहीं कर सका)। ग्राफाना का इंटरफ़ेस अच्छा दिखता है, लेकिन किबाना कहीं अधिक सुविधाओं से भरपूर है।

लोकी के पक्ष और विपक्ष

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

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

निष्कर्ष

लोकी एक 100% दिलचस्प तकनीक है जो छोटी और मध्यम आकार की परियोजनाओं के लिए उपयुक्त है, जो आपको लॉग एकत्रीकरण, लॉग खोज, निगरानी और लॉग विश्लेषण की कई समस्याओं को हल करने की अनुमति देती है।

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

और यद्यपि शोध के बाद यह स्पष्ट हो गया कि हम लोकी का उपयोग नहीं कर सकते, हमें उम्मीद है कि यह पोस्ट आपको अपनी पसंद में मदद करेगी।

आलेख में प्रयुक्त कोड वाला भंडार स्थित है यहां.

स्रोत: www.habr.com

लोकी से लॉग एकत्रित करना