ProHoster > Օրագիր > Վարչակազմը > Լոկիից տեղեկամատյանների հավաքում

Լոկիից տեղեկամատյանների հավաքում

Լոկիից տեղեկամատյանների հավաքում

Մենք Badoo-ում մշտապես վերահսկում ենք նոր տեխնոլոգիաները և գնահատում դրանք մեր համակարգում օգտագործել, թե ոչ: Մենք ցանկանում ենք այս ուսումնասիրություններից մեկը կիսել համայնքի հետ: Այն նվիրված է Loki-ին՝ լոգերի ագրեգացման համակարգին:

Loki-ն լուծում է տեղեկամատյանները պահելու և դիտելու համար, և այս փաթեթը նաև տրամադրում է ճկուն համակարգ՝ դրանք վերլուծելու և տվյալներ Պրոմեթևսին ուղարկելու համար: Մայիսին թողարկվեց ևս մեկ թարմացում, որն ակտիվորեն գովազդվում է ստեղծողների կողմից։ Մեզ հետաքրքրում էր, թե ինչ կարող է անել Loki-ն, ինչ հնարավորություններ է տալիս, և որքանով այն կարող է հանդես գալ որպես այլընտրանք ELK-ին, որը մենք այժմ օգտագործում ենք:

Ինչ է Լոկին

Grafana Loki-ն ամբողջական հատման համակարգի բաղադրիչների հավաքածու է: Ի տարբերություն այլ նմանատիպ համակարգերի, Loki-ն հիմնված է միայն մատյանների մետատվյալների՝ պիտակների ինդեքսավորման գաղափարի վրա (ինչպես Պրոմեթևսում), և տեղեկամատյանները կողք կողքի սեղմելով առանձին կտորների:

Գլխավոր էջ, GitHub

Նախքան մտնեմ, թե ինչ կարող եք անել Loki-ի հետ, ես ուզում եմ պարզաբանել, թե ինչ է նշանակում «միայն մետատվյալների ինդեքսավորման գաղափարը»: Եկեք համեմատենք Loki մոտեցումը և ինդեքսավորման մոտեցումը ավանդական լուծումներում, ինչպիսին է Elasticsearch-ը, օգտագործելով nginx log-ի տողի օրինակը.

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

Ավանդական համակարգերը վերլուծում են ամբողջ տողը, ներառյալ բազմաթիվ եզակի user_id և item_id արժեքներով դաշտերը, և ամեն ինչ պահում են մեծ ինդեքսներում: Այս մոտեցման առավելությունն այն է, որ դուք կարող եք արագ կատարել բարդ հարցումներ, քանի որ գրեթե բոլոր տվյալները գտնվում են ինդեքսում: Բայց դրա համար պետք է վճարել, քանի որ ինդեքսը մեծանում է, ինչը վերածվում է հիշողության պահանջների: Արդյունքում, տեղեկամատյանների ամբողջական տեքստային ինդեքսը չափերով համեմատելի է հենց տեղեկամատյանների հետ: Դրա միջոցով արագ որոնելու համար ինդեքսը պետք է բեռնվի հիշողության մեջ: Եվ որքան շատ տեղեկամատյաններ, այնքան ավելի արագ է աճում ցուցանիշը և այնքան ավելի շատ հիշողություն է սպառում:

Loki-ի մոտեցումը պահանջում է, որ միայն անհրաժեշտ տվյալները հանվեն տողից, որոնց արժեքների թիվը փոքր է: Այս կերպ մենք ստանում ենք փոքր ցուցանիշ և կարող ենք որոնել տվյալները՝ զտելով դրանք ըստ ժամանակի և ինդեքսավորված դաշտերի, իսկ մնացածը սկանավորելով կանոնավոր արտահայտություններով կամ ենթալարի որոնումներով։ Գործընթացն ամենաարագը չի թվում, սակայն Լոկին հարցումը բաժանում է մի քանի մասերի և կատարում դրանք զուգահեռ՝ կարճ ժամանակում մշակելով մեծ քանակությամբ տվյալներ։ Դրանցում բեկորների և զուգահեռ հարցումների քանակը կարգավորելի է. Այսպիսով, տվյալների քանակությունը, որը կարող է մշակվել ժամանակի միավորի համար, գծայինորեն կախված է տրամադրված ռեսուրսների քանակից:

Այս փոխզիջումը մեծ արագ ցուցանիշի և փոքր զուգահեռ կոպիտ ուժի ինդեքսի միջև թույլ է տալիս Լոկիին վերահսկել համակարգի արժեքը: Այն կարող է ճկուն կերպով կազմաձևվել և ընդլայնվել՝ ըստ ձեր կարիքների:

Loki ստեկը բաղկացած է երեք բաղադրիչներից՝ Promtail, Loki, Grafana: Promtail-ը հավաքում է տեղեկամատյանները, մշակում դրանք և ուղարկում Loki-ին: Լոկին պահում է նրանց։ Իսկ Grafana-ն կարող է Loki-ից տվյալներ պահանջել և ցույց տալ: Ընդհանուր առմամբ, Loki-ն կարող է օգտագործվել ոչ միայն տեղեկամատյանները պահելու և դրանց միջով որոնելու համար։ Ամբողջ փաթեթը մեծ հնարավորություններ է տալիս մուտքային տվյալները մշակելու և վերլուծելու Պրոմեթևսի եղանակով:
Տեղադրման գործընթացի նկարագրությունը կարելի է գտնել այստեղ.

Մատյանների որոնում

Դուք կարող եք որոնել տեղեկամատյանները Grafana — Explorer հատուկ ինտերֆեյսում: Հարցումները օգտագործում են LogQL լեզուն, որը շատ նման է Պրոմեթևսի օգտագործած PromQL-ին: Սկզբունքորեն, այն կարելի է դիտարկել որպես բաշխված grep:

Որոնման ինտերֆեյսը ունի հետևյալ տեսքը.

Լոկիից տեղեկամատյանների հավաքում

Հարցումն ինքնին բաղկացած է երկու մասից՝ ընտրիչ և զտիչ։ Ընտրիչը որոնում է ըստ ինդեքսավորված մետատվյալների (պիտակների), որոնք վերագրված են տեղեկամատյաններին, իսկ զտիչը որոնման տող է կամ ռեգեքս, որը զտում է ընտրիչի կողմից սահմանված գրառումները: Վերոնշյալ օրինակում՝ գանգուր փակագծերում՝ ընտրիչ, ամեն ինչ հետո՝ զտիչ:

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

Քանի որ Loki-ն աշխատում է, դուք չեք կարող հարցումներ կատարել առանց ընտրիչի, բայց պիտակները կարող են կամայականորեն ընդհանուր լինել:

Ընտրիչը գանգուր փակագծերում արժեքի բանալին-արժեքն է: Դուք կարող եք միավորել ընտրիչները և նշել որոնման տարբեր պայմաններ՝ օգտագործելով =, != օպերատորները կամ կանոնավոր արտահայտությունները. 

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

Զտիչը տեքստ կամ ռեգեքս է, որը կզտի ընտրիչի կողմից ստացված բոլոր տվյալները:

Ստացված տվյալների հիման վրա հնարավոր է ստանալ ժամանակավոր գրաֆիկներ չափման ռեժիմում։ Օրինակ, դուք կարող եք պարզել առաջացման հաճախականությունը ինդեքսային տող պարունակող մուտքի nginx տեղեկամատյաններում.

Լոկիից տեղեկամատյանների հավաքում

Հատկությունների ամբողջական նկարագրությունը կարելի է գտնել փաստաթղթերում LogQL.

Մատյանների վերլուծություն

Տեղեկամատյանները հավաքելու մի քանի եղանակ կա.

  • Promtail-ի օգնությամբ, որը գերանների հավաքման ստանդարտ բաղադրիչ է:
  • Անմիջապես դոկեր կոնտեյներից օգտագործելով Loki Docker Logging Driver.
  • Օգտագործեք Fluentd կամ Fluent Bit, որոնք կարող են տվյալներ ուղարկել Loki-ին: Ի տարբերություն Promtail-ի, նրանք ունեն պատրաստի վերլուծիչներ գրեթե ցանկացած տեսակի տեղեկամատյանների համար և կարող են նաև մշակել բազմագիծ տեղեկամատյանները:

Սովորաբար Promtail-ը օգտագործվում է վերլուծության համար: Այն կատարում է երեք բան.

  • Գտնում է տվյալների աղբյուրները:
  • Դրանց վրա պիտակներ ամրացրեք:
  • Տվյալներ է ուղարկում Loki-ին:

Ներկայումս Promtail-ը կարող է կարդալ տեղեկամատյանները տեղական ֆայլերից և systemd ամսագրից: Այն պետք է տեղադրվի յուրաքանչյուր մեքենայի վրա, որտեղից հավաքվում են տեղեկամատյանները:

Կա ինտեգրում Kubernetes-ի հետ. Promtail-ը ավտոմատ կերպով պարզում է կլաստերի վիճակը Kubernetes REST API-ի միջոցով և հավաքում տեղեկամատյանները հանգույցից, ծառայությունից կամ podից՝ անմիջապես տեղադրելով պիտակներ՝ հիմնված Kubernetes-ի մետատվյալների վրա (pod անվանումը, ֆայլի անվանումը և այլն):

Դուք կարող եք նաև կախել պիտակներ՝ հիմնված մատյանից ստացված տվյալների վրա՝ օգտագործելով Pipeline: Pipeline Promtail-ը կարող է բաղկացած լինել չորս տեսակի փուլերից. Լրացուցիչ մանրամասներ - մեջ պաշտոնական փաստաթղթեր, ես անմիջապես կնշեմ որոշ նրբերանգներ.

  1. Վերլուծման փուլեր. Սա RegEx-ի և JSON-ի փուլն է: Այս փուլում մենք տվյալները տեղեկամատյաններից հանում ենք այսպես կոչված արդյունահանված քարտեզի մեջ: Դուք կարող եք հանել JSON-ից՝ պարզապես պատճենելով մեզ անհրաժեշտ դաշտերը արդյունահանված քարտեզի մեջ կամ կանոնավոր արտահայտությունների միջոցով (RegEx), որտեղ անվանված խմբերը «քարտեզագրվում» են արդյունահանված քարտեզի մեջ: Արդյունահանված քարտեզը բանալի-արժեքի պահեստ է, որտեղ բանալին դաշտի անվանումն է, իսկ արժեքը՝ դրա արժեքը տեղեկամատյաններից:
  2. Փոխակերպման փուլերը. Այս փուլն ունի երկու տարբերակ՝ փոխակերպում, որտեղ մենք սահմանում ենք փոխակերպման կանոնները, և աղբյուրը՝ արդյունահանված քարտեզից վերափոխման տվյալների աղբյուրը։ Եթե ​​արդյունահանված քարտեզում նման դաշտ չկա, ապա այն կստեղծվի։ Այսպիսով, հնարավոր է ստեղծել պիտակներ, որոնք հիմնված չեն արդյունահանված քարտեզի վրա: Այս փուլում մենք կարող ենք շահարկել արդյունահանված քարտեզի տվյալները՝ օգտագործելով բավականին հզոր Գոլանգի ձևանմուշ. Բացի այդ, պետք է հիշել, որ վերլուծության ժամանակ արդյունահանված քարտեզը լիովին բեռնված է, ինչը հնարավորություն է տալիս, օրինակ, ստուգել դրա մեջ եղած արժեքը՝ «{{if .tag}tag value is exist{end}}»: Կաղապարն աջակցում է պայմաններին, հանգույցներին և լարային որոշ գործառույթներին, ինչպիսիք են Replace և Trim:
  3. Գործողությունների փուլեր. Այս փուլում դուք կարող եք ինչ-որ բան անել արդյունահանվածի հետ.
    • Արդյունահանված տվյալներից ստեղծեք պիտակ, որը ինդեքսավորվելու է Loki-ի կողմից:
    • Փոփոխեք կամ սահմանեք միջոցառման ժամանակը գրանցամատյանից:
    • Փոխեք տվյալները (տեղեկագրի տեքստը), որոնք կգնան Loki-ին:
    • Ստեղծեք չափումներ:
  4. Զտման փուլեր. Համապատասխանության փուլը, որտեղ մենք կարող ենք կա՛մ ուղարկել գրառումներ, որոնք մեզ պետք չէ /dev/null-ի, կա՛մ ուղարկել դրանք հետագա մշակման:

Օգտագործելով սովորական nginx տեղեկամատյանների մշակման օրինակը, ես ցույց կտամ, թե ինչպես կարող եք վերլուծել տեղեկամատյանները՝ օգտագործելով Promtail-ը:

Փորձարկման համար եկեք վերցնենք փոփոխված nginx jwilder/nginx-proxy:alpine պատկերը և փոքրիկ դեյմոնը, որը կարող է հարցումներ կատարել HTTP-ի միջոցով որպես nginx-proxy: Դեյմոնն ունի մի քանի վերջնակետեր, որոնց կարող է տալ տարբեր չափերի պատասխաններ՝ տարբեր HTTP կարգավիճակներով և տարբեր ուշացումներով։

Մենք կհավաքենք տեղեկամատյանները docker բեռնարկղերից, որոնք կարելի է գտնել ճանապարհի երկայնքով /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-ին (կոնֆիգուրայում կա «docker» տարբերակ, որն անում է նույնը մեկ տողում, բայց դա այնքան էլ ակնհայտ չի լինի).

scrape_configs:
 - job_name: containers

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

Երբ այս կոնֆիգուրացիան միացված է, Loki-ն կստանա տեղեկամատյաններ բոլոր բեռնարկղերից: Սրանից խուսափելու համար մենք փոխում ենք թեստային nginx-ի կարգավորումները docker-compose.yml-ում - ավելացրեք գրանցումը պիտակի դաշտում.

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

Խմբագրել promtail.yml-ը և կարգավորել Pipeline-ը: Տեղեկամատյանները հետևյալն են.

{"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

Մենք արտահանում ենք հոսքի, attrs, attrs.tag դաշտերը (եթե այդպիսիք կան) մուտքային JSON-ից և տեղադրում ենք արդյունահանված քարտեզի մեջ: 

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

Եթե ​​արդյունահանված քարտեզի մեջ հնարավոր եղավ տեղադրել պիտակի դաշտը, ապա regexp-ի միջոցով հանում ենք պատկերի և կոնտեյների անվանումները։

 - labels:
     image_name:
     container_name:

Մենք նշանակում ենք պիտակներ: Եթե ​​արդյունահանված տվյալների մեջ գտնվեն image_name և container_name ստեղները, ապա դրանց արժեքները կհատկացվեն համապատասխան պիտակներին:

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

Մենք մերժում ենք բոլոր տեղեկամատյանները, որոնք չունեն պիտակներ image_name և container_name սահմանված:

  - 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 log տողը:

     - 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 log-ը կանոնավոր արտահայտություններով: 

    - 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}}"

Կաղապարում օգտագործելով պայմանական օպերատորներ, մենք ստուգում ենք տեղադրված դաշտերը արդյունահանված քարտեզում և սահմանում ենք պահանջվող արժեքները request_type դաշտի համար՝ լուսանկար, ստատիկ, 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:

Լոկիից տեղեկամատյանների հավաքում

Վերոնշյալ կազմաձևը գործարկելուց հետո կարող եք տեսնել, որ յուրաքանչյուր մուտքագրված է պիտակավորված՝ հիմնվելով գրանցամատյանի տվյալների վրա:

Հիշեք, որ մեծ թվով արժեքներով (կարդինալություն) պիտակներ հանելը կարող է զգալիորեն դանդաղեցնել Loki-ին: Այսինքն, դուք չպետք է ինդեքսում դնեք, օրինակ, user_id: Այս մասին ավելին կարդացեք հոդվածումԻնչպես Loki-ում պիտակները կարող են ավելի արագ և հեշտ դարձնել մատյանների հարցումները«. Բայց դա չի նշանակում, որ դուք չեք կարող որոնել ըստ user_id-ի՝ առանց ինդեքսների։ Որոնելիս անհրաժեշտ է օգտագործել զտիչներ («գրավել» ըստ տվյալների), իսկ ինդեքսն այստեղ գործում է որպես հոսքի նույնացուցիչ։

Մատյան վիզուալիզացիա

Լոկիից տեղեկամատյանների հավաքում

Loki-ն կարող է հանդես գալ որպես տվյալների աղբյուր Grafana գծապատկերների համար՝ օգտագործելով LogQL: Աջակցվում են հետևյալ հատկանիշները.

  • արագություն - մեկ վայրկյանում գրանցումների քանակը;
  • հաշվել ժամանակի ընթացքում - տվյալ տիրույթում գրանցումների քանակը:

Կան նաև ագրեգացիոն ֆունկցիաներ Sum, Avg և այլն։ Դուք կարող եք կառուցել բավականին բարդ գրաֆիկներ, օրինակ՝ HTTP սխալների քանակի գրաֆիկ.

Լոկիից տեղեկամատյանների հավաքում

Լոկիի տվյալների լռելյայն աղբյուրը մի փոքր ավելի քիչ ֆունկցիոնալ է, քան Պրոմեթևսի տվյալների աղբյուրը (օրինակ, դուք չեք կարող փոխել լեգենդը), բայց Լոկին կարող է միացված լինել որպես Պրոմեթևսի տիպի աղբյուր։ Վստահ չեմ, արդյոք սա փաստաթղթավորված վարքագիծ է, բայց դատելով մշակողների պատասխանից»:Ինչպե՞ս կարգավորել Loki-ն որպես Պրոմեթևսի տվյալների աղբյուր: · Թողարկում #1222 · grafana/loki», օրինակ, այն լիովին օրինական է, և Loki-ն լիովին համատեղելի է PromQL-ի հետ:

Ավելացնել Loki-ն որպես տվյալների աղբյուր՝ Prometheus տիպով և ավելացրեք URL /loki:

Լոկիից տեղեկամատյանների հավաքում

Եվ դուք կարող եք գրաֆիկներ կազմել, կարծես մենք աշխատում ենք Պրոմեթևսի չափումների հետ.

Լոկիից տեղեկամատյանների հավաքում

Կարծում եմ, որ ֆունկցիոնալության անհամապատասխանությունը ժամանակավոր է, և ծրագրավորողները հետագայում այն ​​կշտկեն։

Լոկիից տեղեկամատյանների հավաքում

Չափումներ

Loki-ն ապահովում է տեղեկամատյաններից թվային չափումներ հանելու և դրանք Պրոմեթևսին ուղարկելու հնարավորություն: Օրինակ, nginx log-ը պարունակում է մեկ պատասխանի բայթերի քանակը, ինչպես նաև, ստանդարտ գրանցամատյանի ձևաչափի որոշակի փոփոխությամբ, վայրկյաններով պատասխանելու համար պահանջվող ժամանակը: Այս տվյալները կարելի է հանել և ուղարկել Պրոմեթևսին։

Ավելացնել մեկ այլ բաժին 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

Ընտրանքը թույլ է տալիս սահմանել և թարմացնել չափումները՝ հիմնվելով արդյունահանված քարտեզի տվյալների վրա: Այս չափումները չեն ուղարկվում Loki-ին, դրանք հայտնվում են Promtail /metrics վերջնակետում: Պրոմեթևսը պետք է կազմաձևվի այս փուլից տվյալներ ստանալու համար: Վերոնշյալ օրինակում request_type="api"-ի համար մենք հավաքում ենք հիստոգրամի չափիչ: Այս տեսակի չափումների միջոցով հարմար է տոկոսներ ստանալ: Ստատիկների և լուսանկարների համար մենք հավաքում ենք բայթերի գումարը և տողերի քանակը, որոնցում ստացել ենք բայթ՝ միջինը հաշվարկելու համար:

Կարդացեք ավելին չափումների մասին այստեղ.

Բացեք նավահանգիստ Promtail-ում.

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

Մենք համոզվում ենք, որ promtail_custom նախածանցով չափումները հայտնվել են.

Լոկիից տեղեկամատյանների հավաքում

Պրոմեթևսի ստեղծում. Ավելացնել աշխատանքի promtail:

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

Եվ գծեք գրաֆիկ.

Լոկիից տեղեկամատյանների հավաքում

Այս կերպ դուք կարող եք պարզել, օրինակ, չորս ամենադանդաղ հարցումները: Դուք կարող եք նաև կարգավորել մոնիտորինգը այս չափումների համար:

Scaling

Loki-ն կարող է լինել ինչպես միայնակ երկուական ռեժիմում, այնպես էլ բեկորային (հորիզոնական մասշտաբային ռեժիմ): Երկրորդ դեպքում այն ​​կարող է տվյալները պահել ամպի մեջ, իսկ կտորներն ու ինդեքսը պահվում են առանձին։ 1.5 տարբերակում ներդրված է մեկ տեղում պահելու հնարավորությունը, սակայն դեռ խորհուրդ չի տրվում օգտագործել այն արտադրության մեջ։

Լոկիից տեղեկամատյանների հավաքում

Հատվածները կարող են պահվել S3-ի հետ համատեղելի պահեստում, ինդեքսները պահելու համար օգտագործեք հորիզոնական մասշտաբային տվյալների բազաներ՝ Cassandra, BigTable կամ DynamoDB: Loki-ի այլ մասեր՝ դիստրիբյուտորներ (գրելու համար) և Querier (հարցումների համար) - քաղաքացիություն չունեցող են և նաև հորիզոնական մասշտաբով:

DevOpsDays Vancouver 2019 կոնֆերանսում մասնակիցներից մեկը Քալում Ստյանը հայտարարեց, որ Լոկիի հետ իր նախագիծն ունի տեղեկամատյանների փետաբայթ՝ ընդհանուր չափի 1%-ից պակաս ինդեքսով.Ինչպես է Loki-ն փոխկապակցում չափորոշիչներին և գրանցամատյաններին և խնայում է ձեզ գումար".

Լոկիի և ELK-ի համեմատություն

Ցուցանիշի չափը

Ստացված ինդեքսի չափը ստուգելու համար ես վերցրեցի տեղեկամատյանները nginx կոնտեյներից, որի համար կազմաձևված էր վերը նշված խողովակաշարը: Մատյան ֆայլը պարունակում էր 406 տող՝ 624 ՄԲ ընդհանուր ծավալով։ Տեղեկամատյանները ստեղծվել են մեկ ժամվա ընթացքում, մոտավորապես 109 գրառում վայրկյանում:

Մատյանից երկու տողերի օրինակ.

Լոկիից տեղեկամատյանների հավաքում

ELK-ի կողմից ինդեքսավորվելիս սա ստացավ 30,3 ՄԲ ինդեքսի չափ.

Լոկիից տեղեկամատյանների հավաքում

Loki-ի դեպքում դա տվել է մոտ 128 ԿԲ ինդեքս և մոտ 3,8 ՄԲ տվյալ՝ կտորներով: Հարկ է նշել, որ գրանցամատյանը ստեղծվել է արհեստականորեն և չի ներկայացրել տվյալների լայն տեսականի: Պարզ gzip-ը նախնական Docker JSON մատյանում տվյալների հետ սեղմում է 95,4%, և հաշվի առնելով, որ միայն մաքրված nginx մատյանն ուղարկվել է հենց Loki-ին, սեղմումը մինչև 4 ՄԲ հասկանալի է: Loki պիտակների համար եզակի արժեքների ընդհանուր թիվը եղել է 35, ինչը բացատրում է ինդեքսի փոքր չափը: ԵԼՔ-ի համար էլ գերանը մաքրվել է։ Այսպիսով, Loki-ն սեղմել է սկզբնական տվյալները 96%-ով, իսկ ELK-ը՝ 70%-ով։

Հիշողության սպառում

Լոկիից տեղեկամատյանների հավաքում

Եթե ​​համեմատենք Պրոմեթևսի և ELK-ի ամբողջ ստեկը, ապա Լոկին մի քանի անգամ ավելի քիչ է «ուտում»: Հասկանալի է, որ Go ծառայությունը ավելի քիչ է սպառում, քան Java ծառայությունը, և Heap Elasticsearch JVM-ի չափը և Loki-ի համար հատկացված հիշողությունը համեմատելը սխալ է, բայց, այնուամենայնիվ, հարկ է նշել, որ Loki-ն շատ ավելի քիչ հիշողություն է օգտագործում: Նրա պրոցեսորի առավելությունն այնքան էլ ակնհայտ չէ, բայց այն նաև առկա է։

Բարեմաղթել

Լոկին ավելի արագ է «կլանում» գերանները։ Արագությունը կախված է բազմաթիվ գործոններից՝ ինչպիսի տեղեկամատյաններից, որքան բարդ ենք դրանք վերլուծում, ցանց, սկավառակ և այլն, բայց դա հաստատ ավելի բարձր է, քան ELK-ը (իմ թեստում մոտ երկու անգամ): Սա բացատրվում է նրանով, որ Loki-ն շատ ավելի քիչ տվյալներ է դնում ինդեքսի մեջ և, համապատասխանաբար, ավելի քիչ ժամանակ է ծախսում ինդեքսավորման վրա։ Այս դեպքում իրավիճակը հակադարձվում է որոնման արագության դեպքում. Loki-ն նկատելիորեն դանդաղում է մի քանի գիգաբայթից մեծ տվյալների վրա, մինչդեռ ELK-ի դեպքում որոնման արագությունը կախված չէ տվյալների չափից:

Մատյանների որոնում

Loki-ն զգալիորեն զիջում է ELK-ին լոգերի որոնման հնարավորություններով։ Կանոնավոր արտահայտություններով Grep-ը ուժեղ բան է, բայց այն զիջում է մեծահասակների տվյալների բազային: Տարածքների հարցումների բացակայությունը, միայն պիտակներով միավորումը, առանց պիտակների որոնելու անկարողությունը՝ այս ամենը մեզ սահմանափակում է Loki-ում հետաքրքրող տեղեկություններ փնտրելու հարցում: Սա չի նշանակում, որ Loki-ի միջոցով ոչինչ հնարավոր չէ գտնել, բայց այն սահմանում է տեղեկամատյանների հետ աշխատելու հոսքը, երբ դուք նախ խնդիր եք գտնում Պրոմեթևսի գծապատկերներում, այնուհետև փնտրում եք, թե ինչ է տեղի ունեցել տեղեկամատյաններում՝ օգտագործելով այս պիտակները:

ինտերֆեյս

Նախ, դա գեղեցիկ է (ներողություն, չկարողացա դիմադրել): Grafana-ն ունի գեղեցիկ արտաքին ինտերֆեյս, բայց Kibana-ն շատ ավելի ֆունկցիոնալ է:

Լոկիի դրական և բացասական կողմերը

Պլյուսներից կարելի է նշել, որ Լոկին ինտեգրվում է Պրոմեթևսի հետ, համապատասխանաբար, մենք ստանում ենք չափումներ և զգուշացումներ: Այն հարմար է տեղեկամատյաններ հավաքելու և դրանք Kubernetes Pods-ով պահելու համար, քանի որ այն ունի Պրոմեթևսից ժառանգված ծառայության հայտնագործություն և ավտոմատ կերպով կցում է պիտակներ։

Մինուսներից՝ վատ փաստաթղթեր: Որոշ բաներ, ինչպիսիք են Promtail-ի առանձնահատկություններն ու հնարավորությունները, ես հայտնաբերեցի միայն կոդը ուսումնասիրելու գործընթացում, բաց կոդով օգուտը: Մեկ այլ թերություն վերլուծության թույլ հնարավորություններն են: Օրինակ, Loki-ն չի կարող վերլուծել բազմագիծ տեղեկամատյանները: Նաև թերությունները ներառում են այն փաստը, որ Loki-ն համեմատաբար երիտասարդ տեխնոլոգիա է (1.0 թողարկումը եղել է 2019 թվականի նոյեմբերին):

Ամփոփում

Loki-ն 100% հետաքրքիր տեխնոլոգիա է, որը հարմար է փոքր և միջին նախագծերի համար, որը թույլ է տալիս լուծել տեղեկամատյանների ագրեգացման, տեղեկամատյանների որոնման, տեղեկամատյանների մոնիտորինգի և վերլուծության բազմաթիվ խնդիրներ:

Մենք չենք օգտագործում Loki-ն Badoo-ում, քանի որ մենք ունենք ELK ստեկ, որը հարմար է մեզ, և որը տարիների ընթացքում գերաճած է տարբեր մաքսային լուծումներով: Մեզ համար գայթակղությունը տեղեկամատյաններում որոնումն է։ Օրական գրեթե 100 ԳԲ տեղեկամատյանների դեպքում մեզ համար կարևոր է, որ կարողանանք գտնել ամեն ինչ և մի փոքր ավելին և դա անել արագ: Գծապատկերների և մոնիտորինգի համար մենք օգտագործում ենք այլ լուծումներ, որոնք հարմարեցված են մեր կարիքներին և ինտեգրված միմյանց հետ: Loki stack-ն ունի շոշափելի առավելություններ, բայց այն մեզ չի տա ավելին, քան մենք ունենք, և դրա առավելությունները ճշգրիտ չեն գերազանցի միգրացիայի ծախսերը:

Եվ չնայած հետազոտությունից հետո պարզ դարձավ, որ մենք չենք կարող օգտագործել Loki-ն, հուսով ենք, որ այս գրառումը կօգնի ձեզ ընտրության հարցում։

Հոդվածում օգտագործված ծածկագրով պահեստը գտնվում է այստեղ.

Source: www.habr.com

Добавить комментарий