🥇 Loki बाट लगहरू सङ्कलन गर्दै

Badoo मा, हामी निरन्तर नयाँ प्रविधिहरू निगरानी गर्छौं र तिनीहरू हाम्रो प्रणालीमा प्रयोग गर्न लायक छन् कि छैनन् भनेर मूल्याङ्कन गर्छौं। हामी यी मध्ये एउटा अध्ययन समुदायसँग साझा गर्न चाहन्छौं। यो Loki को लागि समर्पित छ, एक लग एकत्रीकरण प्रणाली।

Loki लगहरू भण्डारण र हेर्नको लागि एक समाधान हो, र यो स्ट्याकले तिनीहरूलाई विश्लेषण गर्न र Prometheus लाई डाटा पठाउनको लागि लचिलो प्रणाली पनि प्रदान गर्दछ। मे मा, अर्को अपडेट जारी गरिएको थियो, जुन सक्रिय रूपमा सिर्जनाकर्ताहरू द्वारा प्रचार गरिएको छ। लोकीले के गर्न सक्छ, यसले के क्षमताहरू प्रदान गर्दछ, र कुन हदसम्म यसले ELK को विकल्पको रूपमा काम गर्न सक्छ भन्ने कुरामा हामी चासो थियौं, स्ट्याक जुन हामीले अहिले प्रयोग गर्छौं।

लोकी के हो

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

गृह पृष्ठ, 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"

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

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

ठूलो, द्रुत सूचकांक र सानो, समानान्तर ब्रुट-फोर्स सूचकांक बीचको यो व्यापार-अफले लोकीलाई प्रणालीको लागत नियन्त्रण गर्न अनुमति दिन्छ। यो लचिलो कन्फिगर र आवश्यकता अनुसार विस्तार गर्न सकिन्छ।

लोकी स्ट्याकमा तीन कम्पोनेन्टहरू हुन्छन्: प्रोमटेल, लोकी, ग्राफाना। Promtail ले लगहरू सङ्कलन गर्छ, तिनीहरूलाई प्रशोधन गर्छ र Loki मा पठाउँछ। लोकीले तिनीहरूलाई राख्छ। र Grafana Loki बाट डाटा अनुरोध गर्न र यसलाई प्रदर्शन गर्न सक्नुहुन्छ। सामान्यतया, Loki लगहरू भण्डारण गर्न र तिनीहरू मार्फत खोजी गर्नका लागि मात्र प्रयोग गर्न सकिँदैन। सम्पूर्ण स्ट्याकले प्रोमेथियस मार्ग प्रयोग गरेर आगमन डेटा प्रशोधन र विश्लेषणको लागि उत्कृष्ट अवसरहरू प्रदान गर्दछ।
स्थापना प्रक्रियाको विवरण पाउन सकिन्छ यहाँ.

लग खोज

तपाईंले विशेष ग्राफाना इन्टरफेसमा लगहरू खोज्न सक्नुहुन्छ - एक्सप्लोरर। प्रश्नहरूले LogQL भाषा प्रयोग गर्दछ, जुन Prometheus मा प्रयोग गरिएको PromQL सँग मिल्दोजुल्दो छ। सिद्धान्तमा, यसलाई वितरित grep को रूपमा सोच्न सकिन्छ।

खोजी इन्टरफेस यस्तो देखिन्छ:

अनुरोध आफैंमा दुई भागहरू हुन्छन्: चयनकर्ता र फिल्टर। चयनकर्ता अनुक्रमित मेटाडेटा (लेबलहरू) प्रयोग गरी खोज हो जुन लगहरूमा तोकिएको हुन्छ, र फिल्टर एक खोज स्ट्रिङ वा regexp हो जसले चयनकर्ताद्वारा परिभाषित रेकर्डहरू फिल्टर गर्दछ। दिइएको उदाहरणमा: घुमाउरो कोष्ठकहरूमा एक चयनकर्ता छ, त्यसपछि सबै फिल्टर हो।

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

लोकीले काम गर्ने तरिकाको कारणले, तपाइँ चयनकर्ता बिना प्रश्नहरू बनाउन सक्नुहुन्न, तर लेबलहरू तपाइँलाई मनपर्ने रूपमा सामान्य बनाउन सकिन्छ।

चयनकर्ता घुमाउरो कोष्ठकहरूमा मुख्य-मान मान हो। तपाईं चयनकर्ताहरू संयोजन गर्न सक्नुहुन्छ र अपरेटरहरू =, != वा नियमित अभिव्यक्तिहरू प्रयोग गरेर विभिन्न खोज अवस्थाहरू निर्दिष्ट गर्न सक्नुहुन्छ:

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

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

मेट्रिक्स मोडमा प्राप्त डाटाको आधारमा एड-हक ग्राफहरू प्राप्त गर्न सम्भव छ। उदाहरणका लागि, तपाईंले nginx लगहरूमा स्ट्रिङ अनुक्रमणिका भएको प्रविष्टि कति पटक देखा पर्दछ भनेर पत्ता लगाउन सक्नुहुन्छ:

क्षमताहरूको पूर्ण विवरण कागजातमा फेला पार्न सकिन्छ LogQL.

लग पार्सिङ

त्यहाँ लगहरू सङ्कलन गर्न धेरै तरिकाहरू छन्:

लगहरू सङ्कलनका लागि स्ट्याकको मानक कम्पोनेन्ट प्रोमटेल प्रयोग गर्दै।
सिधै डकर कन्टेनर प्रयोग गरेर लोकी डकर लगिङ चालक।
Fluentd वा Fluent Bit प्रयोग गर्नुहोस्, जसले Loki लाई डेटा पठाउन सक्छ। Promtail को विपरीत, तिनीहरूसँग लगभग कुनै पनि प्रकारको लगको लागि तयार पार्सरहरू छन् र बहुलाइन लगहरू पनि ह्यान्डल गर्न सक्छन्।

सामान्यतया Promtail पार्सिङको लागि प्रयोग गरिन्छ। यसले तीनवटा कुरा गर्छ:

डाटा स्रोतहरू फेला पार्छ।
तिनीहरूलाई लेबलहरू संलग्न गर्दछ।
Loki लाई डेटा पठाउँछ।

हाल Promtail ले स्थानीय फाइलहरू र systemd जर्नलबाट लगहरू पढ्न सक्छ। यो प्रत्येक मेसिनमा स्थापित हुनुपर्छ जसबाट लगहरू सङ्कलन गरिन्छ।

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

तपाईं पाइपलाइन प्रयोग गरेर लगबाट डाटामा आधारित लेबलहरू ह्याङ्ग गर्न सक्नुहुन्छ। पाइपलाइन प्रोमटेलले चार प्रकारका चरणहरू समावेश गर्न सक्छन्। थप विवरण मा आधिकारिक दस्तावेज, म तुरुन्तै केहि सूक्ष्मताहरू नोट गर्नेछु।

पार्सिङ चरणहरू। यो RegEx र JSON चरण हो। यस चरणमा, हामी लगहरूबाट तथाकथित निकालिएको नक्सामा डेटा निकाल्छौं। हामीले एक्स्ट्र्याक्ट गरिएको नक्सामा वा रेगुलर एक्सप्रेशन (RegEx) मार्फत आवश्यक पर्ने फिल्डहरू प्रतिलिपि गरेर JSON बाट निकाल्न सक्छौं, जहाँ नाम गरिएका समूहहरूलाई निकालिएको नक्सामा "म्याप" गरिन्छ। निकालिएको नक्सा कुञ्जी-मान भण्डार हो, जहाँ कुञ्जी फिल्डको नाम हो, र मान लगहरूबाट यसको मान हो।
चरणहरू रूपान्तरण गर्नुहोस्। यस चरणमा दुई विकल्पहरू छन्: रूपान्तरण, जहाँ हामीले रूपान्तरण नियमहरू सेट गर्छौं, र स्रोत - निकालिएको नक्साबाट रूपान्तरणको लागि डेटा स्रोत। यदि निकालिएको नक्सामा त्यस्तो फिल्ड छैन भने, यो सिर्जना गरिनेछ। यसरी निकालिएको नक्सामा आधारित नभएका लेबलहरू सिर्जना गर्न सम्भव छ। यस चरणमा हामी एक्स्ट्र्याक्टेड नक्सामा पर्याप्त शक्तिशाली प्रयोग गरेर डाटा हेरफेर गर्न सक्छौं Golang टेम्प्लेट। थप रूपमा, हामीले यो याद गर्नुपर्दछ कि निकालिएको नक्सा पार्सिङको क्रममा पूर्ण रूपमा लोड हुन्छ, जसले यसलाई सम्भव बनाउँछ, उदाहरणका लागि, यसमा मान जाँच गर्न: “{{if .tag}ट्याग मान अवस्थित छ{end}}”। टेम्प्लेटले सर्तहरू, लूपहरू, र केही स्ट्रिङ प्रकार्यहरू जस्तै प्रतिस्थापन र ट्रिम समर्थन गर्दछ।
कार्य चरणहरू। यस बिन्दुमा तपाईले निकालिएको सामग्रीको साथ केहि गर्न सक्नुहुन्छ:
- निकालिएको डाटाबाट एउटा लेबल सिर्जना गर्नुहोस्, जुन लोकीद्वारा अनुक्रमित हुनेछ।
- लगबाट घटना समय परिवर्तन गर्नुहोस् वा सेट गर्नुहोस्।
- Loki मा जाने डेटा (लग पाठ) परिवर्तन गर्नुहोस्।
- मेट्रिक्स सिर्जना गर्नुहोस्।
फिल्टरिङ चरणहरू। म्याच चरण, जहाँ हामी या त प्रविष्टिहरू पठाउन सक्छौं जुन हामीलाई /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

सबै लगहरूका लागि जसको image_name 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>[^/?.]+).*$

अनुरोध_url पार्स गरौं। regexp प्रयोग गरेर हामी अनुरोधको उद्देश्य निर्धारण गर्छौं: स्थिर डाटामा, फोटोहरूमा, API मा र निकालिएको नक्सामा सम्बन्धित कुञ्जी सेट गर्नुहोस्।

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

टेम्प्लेटमा सशर्त अपरेटरहरू प्रयोग गरेर, हामी निकालिएको नक्सामा स्थापित क्षेत्रहरू जाँच गर्छौं र अनुरोध_प्रकार क्षेत्रका लागि आवश्यक मानहरू सेट गर्छौं: फोटो, स्थिर, API। यदि यो असफल भयो भने अर्को नियुक्त गर्नुहोस्। request_type ले अब अनुरोध प्रकार समावेश गर्दछ।

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

हामीले निकालिएको नक्सामा राख्ने व्यवस्थाको आधारमा api_request, virtual_host, request_type र status (HTTP स्थिति) लेबलहरू सेट गर्छौं।

       - output:
           source: nginx_log_row

आउटपुट परिवर्तन गर्नुहोस्। अब निकालिएको नक्साबाट सफा गरिएको nginx लग लोकीमा जान्छ।

माथिको कन्फिगरेसन चलाएपछि, तपाईले देख्न सक्नुहुन्छ कि प्रत्येक प्रविष्टि लगबाट डाटाको आधारमा लेबलहरू तोकिएको छ।

ध्यानमा राख्नु पर्ने एउटा कुरा यो हो कि ठूलो संख्यामा मानहरू (कार्डिनलिटी) को साथ लेबलहरू पुन: प्राप्त गर्नाले लोकीलाई ढिलो गर्न सक्छ। त्यो हो, तपाईले राख्नु हुँदैन, उदाहरणका लागि, प्रयोगकर्ता_आईडी अनुक्रमणिकामा। यस लेखमा थप पढ्नुहोस् "कसरी Loki मा लेबलहरूले लग क्वेरीहरू छिटो र सजिलो बनाउन सक्छ" तर यसको मतलब यो होइन कि तपाइँ अनुक्रमणिका बिना user_id द्वारा खोज गर्न सक्नुहुन्न। तपाईंले खोजी गर्दा फिल्टरहरू प्रयोग गर्न आवश्यक छ (डेटा "हट्नुहोस्"), र यहाँ अनुक्रमणिकाले स्ट्रिम पहिचानकर्ताको रूपमा कार्य गर्दछ।

लगहरूको दृश्यावलोकन

Loki ले LogQL प्रयोग गरेर Grafana ग्राफहरूको लागि डेटा स्रोतको रूपमा कार्य गर्न सक्छ। निम्न सुविधाहरू समर्थित छन्:

दर - प्रति सेकेन्ड रेकर्ड संख्या;
समयसँगै गणना गर्नुहोस् — निर्दिष्ट दायरामा रेकर्डहरूको संख्या।

त्यहाँ जम्मा कार्यहरू योग, औसत र अन्य पनि छन्। तपाईले धेरै जटिल ग्राफहरू बनाउन सक्नुहुन्छ, उदाहरणका लागि HTTP त्रुटिहरूको संख्याको ग्राफ:

मानक डेटा स्रोत लोकी प्रोमिथियस डेटा स्रोतको तुलनामा कार्यक्षमतामा केही हदसम्म कम भएको छ (उदाहरणका लागि, तपाइँ लेजेन्ड परिवर्तन गर्न सक्नुहुन्न), तर लोकीलाई प्रोमेथियस प्रकारसँग स्रोतको रूपमा जडान गर्न सकिन्छ। म पक्का छैन कि यो दस्तावेज गरिएको व्यवहार हो, तर विकासकर्ताहरूको प्रतिक्रिया द्वारा न्याय गर्दै "Prometheus datasource को रूपमा लोकी कसरी कन्फिगर गर्ने? · अंक #1222 · grafana/loki", उदाहरणका लागि, पूर्ण रूपमा कानूनी छ, र Loki PromQL सँग पूर्ण रूपमा उपयुक्त छ।

Prometheus टाइपको साथ डेटा स्रोतको रूपमा Loki थप्नुहोस् र URL /loki थप्नुहोस्:

र हामी ग्राफहरू बनाउन सक्छौं, मानौं कि हामीले प्रोमेथियसको मेट्रिक्ससँग काम गरिरहेका छौं:

मलाई लाग्छ कि कार्यक्षमता मा विसंगति अस्थायी हो र विकासकर्ताहरूले भविष्यमा यसलाई सच्याउनेछन्।

मेट्रिक्स

Loki ले लगहरूबाट संख्यात्मक मेट्रिक्स निकाल्न र तिनीहरूलाई Prometheus मा पठाउने क्षमता प्रदान गर्दछ। उदाहरण को लागी, nginx लग मा प्रति प्रतिक्रिया बाइट को संख्या, साथै, मानक लग ढाँचा को एक निश्चित परिमार्जन संग, प्रतिक्रिया को लागी लिने सेकेन्ड मा समय समावेश गर्दछ। यो डाटा निकाल्न र Prometheus पठाउन सकिन्छ।

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']

र हामी ग्राफ कोर्छौं:

यस तरिकाले तपाईले पत्ता लगाउन सक्नुहुन्छ, उदाहरणका लागि, चार ढिलो प्रश्नहरू। तपाइँ यी मेट्रिक्स को लागी निगरानी पनि सेट अप गर्न सक्नुहुन्छ।

स्केलिंग

लोकी या त एकल बाइनरी मोडमा वा शार्डेड मोडमा हुन सक्छ (तेर्सो-स्केलेबल मोड)। दोस्रो अवस्थामा, यसले क्लाउडमा डाटा बचत गर्न सक्छ, र भागहरू र अनुक्रमणिकाहरू अलग-अलग भण्डारण गरिएका छन्। संस्करण १.५ ले एकै ठाउँमा भण्डारण गर्ने क्षमता प्रस्तुत गर्दछ, तर यसलाई उत्पादनमा प्रयोग गर्न सिफारिस गरिएको छैन।

भागहरू S3-संगत भण्डारणमा भण्डारण गर्न सकिन्छ, र तेर्सो मापनयोग्य डाटाबेसहरू अनुक्रमणिकाहरू भण्डारण गर्न प्रयोग गर्न सकिन्छ: क्यासान्ड्रा, बिगटेबल वा डायनामोडीबी। लोकीको अन्य भागहरू - वितरकहरू (लेखनको लागि) र क्वेरियर (क्वेरीहरूका लागि) - राज्यविहीन छन् र तेर्सो मापन पनि छन्।

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

लोकी र ELK को तुलना

सूचकांक आकार

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

लगबाट दुई रेखाहरूको उदाहरण:

ELK द्वारा अनुक्रमित गर्दा, यसले 30,3 MB को सूचकांक आकार दियो:

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

मेमोरी खपत

यदि हामीले सम्पूर्ण प्रोमेथियस र ELK स्ट्याक तुलना गर्छौं भने, लोकीले धेरै पटक कम "खान्छ"। यो स्पष्ट छ कि Go सेवाले Java सेवा भन्दा कम खपत गर्छ, र JVM Heap Elasticsearch को आकार र Loki को लागि आवंटित मेमोरी गलत छ, तर यो ध्यान दिन लायक छ कि Loki ले धेरै कम मेमोरी प्रयोग गर्दछ। यसको CPU फाइदा यति स्पष्ट छैन, तर यो पनि अवस्थित छ।

गति

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

लग खोज

Loki लग खोज क्षमताहरूको सन्दर्भमा ELK भन्दा महत्त्वपूर्ण रूपमा कम छ। नियमित अभिव्यक्तिको साथ ग्रेप शक्तिशाली छ, तर यो परिपक्व डाटाबेस भन्दा कम छ। दायरा प्रश्नहरूको अभाव, लेबलहरूद्वारा मात्र सङ्कलन, लेबलहरू बिना खोजी गर्न असक्षमता - यी सबैले हामीलाई लोकीमा रुचिको जानकारी खोज्न सीमित गर्दछ। यसको मतलब यो होइन कि लोकी प्रयोग गरेर केहि पनि फेला पार्न सकिँदैन, तर यसले लगहरूसँग काम गर्ने प्रवाहलाई परिभाषित गर्दछ जब तपाइँ पहिलो पटक प्रोमेथियस चार्टहरूमा समस्या फेला पार्नुहुन्छ, र त्यसपछि लगहरूमा के भयो भनेर हेर्न यी लेबलहरू प्रयोग गर्नुहोस्।

इन्टरफेस

सबै भन्दा पहिले, यो सुन्दर छ (माफ गर्नुहोस्, प्रतिरोध गर्न सकेन)। Grafana एक राम्रो देखिने इन्टरफेस छ, तर Kibana धेरै अधिक सुविधा सम्पन्न छ।

लोकीको फाइदा र बेफाइदा

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

नकारात्मक पक्ष कमजोर दस्तावेज हो। केहि चीजहरू, उदाहरणका लागि, Promtail को सुविधाहरू र क्षमताहरू, मैले कोड अध्ययन गर्ने प्रक्रियामा मात्र पत्ता लगाए, सौभाग्य देखि यो खुला स्रोत हो। अर्को हानि कमजोर पार्सिङ क्षमताहरु छ। उदाहरणका लागि, लोकीले बहुलाइन लगहरू पार्स गर्न सक्दैन। अर्को हानि यो हो कि लोकी एक अपेक्षाकृत युवा प्रविधि हो (रिलिज 1.0 नोभेम्बर 2019 मा थियो)।

निष्कर्षमा

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

हामी Badoo मा लोकी प्रयोग गर्दैनौं किनभने हामीसँग ELK स्ट्याक छ जुन हामीलाई उपयुक्त छ र जुन वर्षौंदेखि विभिन्न अनुकूलन समाधानहरूको साथ बढेको छ। हाम्रो लागि, ठेस लाग्ने अवरोध लगहरू मार्फत खोजी गर्दैछ। प्रति दिन लगभग 100 GB लग संग, यो हाम्रो लागि सबै कुरा र अलि बढी फेला पार्न र छिटो गर्न सक्षम हुनु महत्त्वपूर्ण छ। चार्टिङ र अनुगमनको लागि, हामी हाम्रा आवश्यकताहरू अनुरूप र एकअर्कासँग एकीकृत अन्य समाधानहरू प्रयोग गर्छौं। लोकी स्ट्याकमा ठोस फाइदाहरू छन्, तर यसले हामीलाई पहिले नै भएको भन्दा बढी दिनेछैन, र यसको फाइदाहरू निश्चित रूपमा माइग्रेसनको लागतभन्दा बढी हुने छैनन्।

र यद्यपि अनुसन्धान पछि यो स्पष्ट भयो कि हामी लोकी प्रयोग गर्न सक्दैनौं, हामी आशा गर्छौं कि यो पोष्टले तपाइँको छनौटमा मद्दत गर्नेछ।

लेखमा प्रयोग गरिएको कोडको साथ भण्डार अवस्थित छ यहाँ.

स्रोत: www.habr.com

Loki बाट लगहरू सङ्कलन गर्दै