🥇लोकी कडून नोंदी गोळा करणे

Badoo वर, आम्ही सतत नवीन तंत्रज्ञानाचे निरीक्षण करतो आणि ते आमच्या सिस्टममध्ये वापरण्यास योग्य आहेत की नाही याचे मूल्यांकन करतो. आम्ही यापैकी एक अभ्यास समुदायासह सामायिक करू इच्छितो. हे लोकी, लॉग एकत्रीकरण प्रणालीला समर्पित आहे.

लोकी हे लॉग संग्रहित करण्यासाठी आणि पाहण्यासाठी एक उपाय आहे आणि हे स्टॅक त्यांचे विश्लेषण करण्यासाठी आणि प्रोमिथियसला डेटा पाठवण्यासाठी एक लवचिक प्रणाली देखील प्रदान करते. मे मध्ये, आणखी एक अद्यतन जारी केले गेले, जे निर्मात्यांद्वारे सक्रियपणे प्रोत्साहन दिले जाते. लोकी काय करू शकते, ते कोणत्या क्षमता प्रदान करते आणि आम्ही आता वापरत असलेल्या ELK, स्टॅकला पर्याय म्हणून ते किती प्रमाणात कार्य करू शकते याबद्दल आम्हाला स्वारस्य होते.

लोकी म्हणजे काय

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

मुख्यपृष्ठ, GitHub

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

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 व्हॅल्यू असलेल्या फील्डसह संपूर्ण पंक्तीचे विश्लेषण करतात आणि सर्व काही मोठ्या निर्देशांकांमध्ये संग्रहित करतात. या पध्दतीचा फायदा असा आहे की जवळजवळ सर्व डेटा इंडेक्समध्ये असल्याने तुम्ही जटिल क्वेरी त्वरीत चालवू शकता. परंतु याची किंमत मोजावी लागते कारण निर्देशांक मोठा होतो, जे मेमरी आवश्यकतांमध्ये अनुवादित होते. परिणामी, पूर्ण-मजकूर लॉग इंडेक्स आकारात स्वतः लॉगशी तुलना करता येतो. त्यातून द्रुतपणे शोधण्यासाठी, निर्देशांक मेमरीमध्ये लोड करणे आवश्यक आहे. आणि जितके जास्त लॉग, तितक्या वेगाने निर्देशांक वाढतो आणि अधिक मेमरी वापरतो.

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

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

लोकी स्टॅकमध्ये तीन घटक असतात: प्रॉमटेल, लोकी, ग्राफाना. प्रॉमटेल लॉग गोळा करते, त्यावर प्रक्रिया करते आणि लोकीला पाठवते. लोकी त्यांना ठेवतो. आणि Grafana 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.

लॉग पार्सिंग

नोंदी गोळा करण्याचे अनेक मार्ग आहेत:

लॉग गोळा करण्यासाठी स्टॅकचा एक मानक घटक, Promtail वापरणे.
वापरून डॉकर कंटेनरमधून थेट लोकी डॉकर लॉगिंग ड्रायव्हर.
Fluentd किंवा Fluent Bit वापरा, जे लोकीला डेटा पाठवू शकतात. प्रॉमटेलच्या विपरीत, त्यांच्याकडे जवळजवळ कोणत्याही प्रकारच्या लॉगसाठी रेडीमेड पार्सर आहेत आणि ते मल्टीलाइन लॉग देखील हाताळू शकतात.

सहसा Promtail पार्सिंगसाठी वापरले जाते. हे तीन गोष्टी करते:

डेटा स्रोत शोधतो.
त्यांना लेबले जोडते.
लोकीला डेटा पाठवते.

सध्या Promtail स्थानिक फाइल्स आणि systemd जर्नलमधील लॉग वाचू शकते. हे प्रत्येक मशीनवर स्थापित केले जाणे आवश्यक आहे ज्यामधून लॉग गोळा केले जातात.

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

आपण पाइपलाइन वापरून लॉगमधील डेटावर आधारित लेबले देखील हँग करू शकता. पाइपलाइन प्रॉमटेलमध्ये चार प्रकारचे टप्पे असू शकतात. मध्ये अधिक तपशील अधिकृत दस्तऐवजीकरण, मी लगेच काही बारकावे लक्षात घेईन.

पार्सिंग चरण. हा RegEx आणि JSON स्टेज आहे. या टप्प्यावर, आम्ही लॉगमधून तथाकथित काढलेल्या नकाशामध्ये डेटा काढतो. आम्ही जेएसओएन मधून फक्त काढलेल्या नकाशामध्ये आवश्यक फील्ड कॉपी करून किंवा रेग्युलर एक्सप्रेशन्स (RegEx) द्वारे काढू शकतो, जेथे नामांकित गट काढलेल्या नकाशामध्ये "मॅप केलेले" असतात. काढलेला नकाशा एक की-व्हॅल्यू स्टोअर आहे, जिथे की हे फील्डचे नाव आहे आणि मूल्य हे लॉगमधील त्याचे मूल्य आहे.
टप्पे बदला. या स्टेजमध्ये दोन पर्याय आहेत: ट्रान्सफॉर्म, जिथे आम्ही ट्रान्सफॉर्मेशन नियम सेट करतो आणि स्त्रोत - काढलेल्या नकाशावरून ट्रान्सफॉर्मेशनसाठी डेटा स्रोत. काढलेल्या नकाशामध्ये असे कोणतेही फील्ड नसल्यास, ते तयार केले जाईल. अशा प्रकारे काढलेल्या नकाशावर आधारित नसलेली लेबले तयार करणे शक्य आहे. या स्टेजवर आपण काढलेल्या नकाशातील डेटा बऱ्यापैकी शक्तिशाली वापरून हाताळू शकतो गोलंग टेम्पलेट. याव्यतिरिक्त, आम्ही हे लक्षात ठेवले पाहिजे की काढलेला नकाशा पार्सिंग दरम्यान पूर्णपणे लोड केला जातो, ज्यामुळे ते शक्य होते, उदाहरणार्थ, त्यातील मूल्य तपासणे: “{{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>[^/?.]+).*$

चला 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 आणि स्थिती (HTTP स्थिती) लेबले सेट केली.

       - output:
           source: nginx_log_row

आउटपुट बदला. आता काढलेल्या नकाशावरून साफ केलेला nginx लॉग लोकीला जातो.

वरील कॉन्फिगरेशन चालवल्यानंतर, तुम्ही पाहू शकता की प्रत्येक एंट्रीला लॉगमधील डेटावर आधारित लेबले नियुक्त केली आहेत.

एक गोष्ट लक्षात ठेवण्यासारखी आहे की मोठ्या संख्येने मूल्ये (कार्डिनॅलिटी) असलेली लेबले पुनर्प्राप्त केल्याने लोकीची गती कमी होऊ शकते. म्हणजेच, आपण अनुक्रमणिकेमध्ये उदाहरणार्थ user_id टाकू नये. लेखात याबद्दल अधिक वाचा "लोकी मधील लेबल लॉग क्वेरी जलद आणि सुलभ कसे बनवू शकतात" परंतु याचा अर्थ असा नाही की तुम्ही इंडेक्सशिवाय user_id द्वारे शोधू शकत नाही. शोधताना (डेटा "पडून घ्या") तुम्हाला फिल्टर वापरण्याची आवश्यकता आहे आणि येथे अनुक्रमणिका प्रवाह ओळखकर्ता म्हणून कार्य करते.

लॉगचे व्हिज्युअलायझेशन

Loki LogQL वापरून Grafana आलेखांसाठी डेटा स्रोत म्हणून काम करू शकते. खालील वैशिष्ट्ये समर्थित आहेत:

दर - प्रति सेकंद रेकॉर्डची संख्या;
कालांतराने मोजा — निर्दिष्ट श्रेणीतील रेकॉर्डची संख्या.

सम, सरासरी आणि इतर एकत्रीकरण कार्ये देखील आहेत. तुम्ही बरेच जटिल आलेख तयार करू शकता, उदाहरणार्थ HTTP त्रुटींच्या संख्येचा आलेख:

प्रोमिथियस डेटा स्त्रोताच्या तुलनेत लोकी हा मानक डेटा स्त्रोत कार्यक्षमतेमध्ये काही प्रमाणात कमी झाला आहे (उदाहरणार्थ, आपण आख्यायिका बदलू शकत नाही), परंतु लोकी प्रोमिथियस प्रकारासह स्त्रोत म्हणून कनेक्ट केले जाऊ शकते. हे दस्तऐवजीकरण केलेले वर्तन आहे की नाही याची मला खात्री नाही, परंतु विकासकांच्या प्रतिसादानुसारप्रोमिथियस डेटासोर्स म्हणून लोकी कसे कॉन्फिगर करावे? · अंक #1222 · grafana/loki”, उदाहरणार्थ, पूर्णपणे कायदेशीर आहे आणि लोकी PromQL शी पूर्णपणे सुसंगत आहे.

Prometheus प्रकारासह Loki ला डेटा स्रोत म्हणून जोडा आणि URL /loki जोडा:

आणि आम्ही आलेख बनवू शकतो, जसे की आम्ही प्रोमिथियसच्या मेट्रिक्ससह काम करत आहोत:

मला वाटते की कार्यक्षमतेतील विसंगती तात्पुरती आहे आणि विकासक भविष्यात हे दुरुस्त करतील.

मेट्रिक्स

लोकी लॉगमधून संख्यात्मक मेट्रिक्स काढण्याची आणि प्रोमिथियसला पाठवण्याची क्षमता प्रदान करते. उदाहरणार्थ, 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

पर्याय तुम्हाला काढलेल्या नकाशावरील डेटावर आधारित मेट्रिक्स परिभाषित आणि अद्यतनित करण्याची परवानगी देतो. हे मेट्रिक्स लोकीला पाठवले जात नाहीत - ते Promtail/metrics endpoint मध्ये दिसतात. या टप्प्यावर प्राप्त डेटा प्राप्त करण्यासाठी प्रोमिथियस कॉन्फिगर करणे आवश्यक आहे. वरील उदाहरणामध्ये, 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-सुसंगत स्टोरेजमध्ये संग्रहित केले जाऊ शकतात आणि अनुक्रमणिका संचयित करण्यासाठी क्षैतिजरित्या स्केलेबल डेटाबेसचा वापर केला जाऊ शकतो: Cassandra, BigTable किंवा DynamoDB. लोकीचे इतर भाग - वितरक (लेखनासाठी) आणि क्वेरियर (क्वेरीसाठी) - स्टेटलेस आहेत आणि क्षैतिज प्रमाणात देखील आहेत.

DevOpsDays Vancouver 2019 परिषदेत, Callum Styan या सहभागींपैकी एकाने जाहीर केले की लोकीसह त्याच्या प्रकल्पात एकूण आकाराच्या 1% पेक्षा कमी निर्देशांकासह पेटाबाइट्स लॉग आहेत: “लोकी मेट्रिक्स आणि लॉग कसे संबंधित करते — आणि तुमचे पैसे वाचवते".

लोकी आणि ELK ची तुलना

निर्देशांक आकार

परिणामी निर्देशांक आकार तपासण्यासाठी, मी nginx कंटेनरमधून लॉग घेतले ज्यासाठी वरील पाइपलाइन कॉन्फिगर केली होती. लॉग फाइलमध्ये एकूण 406 MB च्या व्हॉल्यूमसह 624 ओळी आहेत. नोंदी एका तासाच्या आत तयार झाल्या, प्रति सेकंद अंदाजे 109 नोंदी.

लॉगमधील दोन ओळींचे उदाहरण:

ELK द्वारे अनुक्रमित केल्यावर, याने 30,3 MB चा अनुक्रमणिका आकार दिला:

लोकीच्या बाबतीत, याचा परिणाम अंदाजे 128 KB इंडेक्स आणि अंदाजे 3,8 MB डेटा भागांमध्ये झाला. हे लक्षात घेण्यासारखे आहे की लॉग कृत्रिमरित्या व्युत्पन्न केले गेले होते आणि त्यात मोठ्या प्रमाणात डेटा नव्हता. डेटासह मूळ डॉकर JSON लॉगवरील एक साध्या gzip ने 95,4% ची कॉम्प्रेशन दिली आणि केवळ साफ केलेला nginx लॉग लोकीलाच पाठविला गेला हे लक्षात घेऊन, 4 MB पर्यंतचे कॉम्प्रेशन समजण्यासारखे आहे. लोकी लेबल्ससाठी अद्वितीय मूल्यांची एकूण संख्या 35 होती, जी निर्देशांकाच्या लहान आकाराचे स्पष्टीकरण देते. ELK साठी लॉग देखील साफ केला गेला. अशा प्रकारे, लोकीने मूळ डेटा 96% आणि ELK ने 70% संकुचित केला.

मेमरी वापर

जर आपण संपूर्ण प्रोमिथियस आणि ELK स्टॅकची तुलना केली तर लोकी कित्येक पट कमी “खातो”. हे स्पष्ट आहे की गो सेवा Java सेवेपेक्षा कमी वापरते आणि JVM Heap Elasticsearch चा आकार आणि लोकीसाठी वाटप केलेली मेमरी यांची तुलना करणे चुकीचे आहे, परंतु असे असले तरी लोकी खूप कमी मेमरी वापरते हे लक्षात घेण्यासारखे आहे. त्याचा CPU फायदा इतका स्पष्ट नाही, परंतु तो देखील उपस्थित आहे.

गती

लोकी जलद लॉग “खाऊन टाकतो”. वेग अनेक घटकांवर अवलंबून असतो - कोणत्या प्रकारचे लॉग आहेत, आम्ही त्यांचे विश्लेषण करताना किती अत्याधुनिक आहोत, नेटवर्क, डिस्क इ. - परंतु ते निश्चितपणे ELK पेक्षा जास्त आहे (माझ्या चाचणीत - सुमारे दुप्पट). लोकी इंडेक्समध्ये खूप कमी डेटा ठेवते आणि त्यानुसार, इंडेक्सिंगवर कमी वेळ घालवते या वस्तुस्थितीद्वारे हे स्पष्ट केले आहे. शोध गतीसह, परिस्थिती उलट आहे: लोकी अनेक गीगाबाइट्सपेक्षा मोठ्या डेटावर लक्षणीयपणे कमी करते, तर ELK चा शोध गती डेटाच्या आकारावर अवलंबून नाही.

लॉग शोध

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

संवाद

सर्व प्रथम, ते सुंदर आहे (क्षमस्व, प्रतिकार करू शकत नाही). Grafana मध्ये एक छान दिसणारा इंटरफेस आहे, परंतु Kibana अधिक वैशिष्ट्यपूर्ण आहे.

लोकीचे फायदे आणि तोटे

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

कमतरता म्हणजे कमकुवत दस्तऐवजीकरण. काही गोष्टी, उदाहरणार्थ, Promtail ची वैशिष्ट्ये आणि क्षमता, मी फक्त कोडच्या अभ्यासाच्या प्रक्रियेत शोधले, सुदैवाने ते ओपन-सोर्स आहे. आणखी एक तोटा म्हणजे कमकुवत पार्सिंग क्षमता. उदाहरणार्थ, लोकी मल्टीलाइन लॉगचे विश्लेषण करू शकत नाही. आणखी एक तोटा म्हणजे लोकी हे तुलनेने तरुण तंत्रज्ञान आहे (रिलीझ 1.0 नोव्हेंबर 2019 मध्ये होते).

निष्कर्ष

लोकी हे 100% मनोरंजक तंत्रज्ञान आहे जे लहान आणि मध्यम आकाराच्या प्रकल्पांसाठी योग्य आहे, जे तुम्हाला लॉग एकत्रीकरण, लॉग शोध, निरीक्षण आणि लॉग विश्लेषणाच्या अनेक समस्या सोडविण्यास अनुमती देते.

आम्ही Badoo मध्ये लोकी वापरत नाही कारण आमच्याकडे एक ELK स्टॅक आहे जो आमच्यासाठी अनुकूल आहे आणि जो वर्षानुवर्षे विविध सानुकूल उपायांसह वाढलेला आहे. आमच्यासाठी, अडखळणारा अडथळा लॉगमधून शोधत आहे. दररोज जवळजवळ 100 GB लॉगसह, आमच्यासाठी सर्वकाही आणि थोडे अधिक शोधण्यात सक्षम असणे आणि ते द्रुतपणे करणे महत्त्वाचे आहे. चार्टिंग आणि मॉनिटरिंगसाठी, आम्ही आमच्या गरजेनुसार तयार केलेली आणि एकमेकांशी समाकलित केलेली इतर उपाय वापरतो. लोकी स्टॅकचे मूर्त फायदे आहेत, परंतु ते आम्हाला आमच्याकडे आधीपासून असलेल्यापेक्षा जास्त देणार नाही आणि त्याचे फायदे निश्चितपणे स्थलांतराच्या खर्चापेक्षा जास्त होणार नाहीत.

आणि जरी संशोधनानंतर हे स्पष्ट झाले की आम्ही लोकी वापरू शकत नाही, आम्हाला आशा आहे की हे पोस्ट तुम्हाला तुमच्या निवडीमध्ये मदत करेल.

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

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

लोकी कडून नोंदी गोळा करत आहे