🥇Скупљање трупаца из Локија

Ми у Бадоо-у стално пратимо нове технологије и процењујемо да ли да их користимо у нашем систему или не. Желимо да поделимо једну од ових студија са заједницом. Посвећен је Локију, систему агрегације дневника.

Локи је решење за чување и преглед логова, а овај стек такође пружа флексибилан систем за њихову анализу и слање података Прометеју. У мају је објављено још једно ажурирање, које креатори активно промовишу. Занимало нас је шта Локи може да уради, које могућности пружа и у којој мери може да делује као алтернатива ЕЛК-у, стеку који сада користимо.

Шта је Локи

Графана Локи је скуп компоненти за комплетан систем сече. За разлику од других сличних система, Локи се заснива на идеји индексирања само метаподатака дневника - ознака (баш као у Прометеју), и компресовања самих дневника један поред другог у засебне делове.

Почетна страница, ГитХуб

Пре него што уђем у то шта можете да урадите са Локијем, желим да разјасним шта се подразумева под „идејом индексирања само метаподатака“. Хајде да упоредимо Локи приступ и приступ индексирању у традиционалним решењима, као што је Еластицсеарцх, користећи пример линије из нгинк дневника:

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"

Традиционални системи анализирају цео ред, укључујући поља са много јединствених вредности усер_ид и итем_ид, и све чувају у великим индексима. Предност овог приступа је што можете брзо да покренете сложене упите, пошто се скоро сви подаци налазе у индексу. Али морате да платите за ово јер индекс постаје велики, што се претвара у меморијске захтеве. Као резултат тога, индекс целог текста дневника је упоредив по величини са самим евиденцијама. Да бисте брзо претражили по њему, индекс се мора учитати у меморију. И што је више евиденција, индекс се брже повећава и више меморије троши.

Локи приступ захтева да се из стринга издвоје само потребни подаци, чији је број вредности мали. На овај начин добијамо мали индекс и можемо претраживати податке тако што ћемо их филтрирати по времену и индексираним пољима, а затим скенирати остатак помоћу регуларних израза или претрага подстрингова. Процес се не чини најбржим, али Локи дели захтев на неколико делова и извршава их паралелно, обрађујући велику количину података за кратко време. Број фрагмената и паралелних захтева у њима се може конфигурисати; дакле, количина података која се може обрадити у јединици времена линеарно зависи од количине обезбеђених ресурса.

Овај компромис између великог брзог индекса и малог паралелног индекса грубе силе омогућава Локију да контролише цену система. Може се флексибилно конфигурисати и проширити према вашим потребама.

Локи стек се састоји од три компоненте: Промтаил, Локи, Графана. Промтаил прикупља дневнике, обрађује их и шаље Локију. Локи их чува. А Графана може тражити податке од Локија и показати их. Уопштено, Локи се може користити не само за чување дневника и претраживање по њима. Читав стек пружа велике могућности за обраду и анализу долазних података на Прометејев начин.
Опис процеса инсталације можете пронаћи овде.

Лог Сеарцх

Дневнике можете претраживати у посебном интерфејсу Графана — Екплорер. Упити користе језик ЛогКЛ, који је веома сличан ПромКЛ-у који користи Прометхеус. У принципу, може се сматрати дистрибуираним греп.

Интерфејс за претрагу изгледа овако:

Сам упит се састоји из два дела: селектора и филтера. Селектор је претрага по индексираним метаподацима (ознакама) који су додељени евиденцијама, а филтер је стринг за претрагу или регекп који филтрира записе дефинисане селектором. У датом примеру: У витичастим заградама - селектор, све после - филтер.

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

Због начина на који Локи функционише, не можете да постављате захтеве без селектора, али ознаке могу бити произвољно генеричке.

Селектор је кључ/вредност вредности у витичастим заградама. Можете комбиновати селекторе и специфицирати различите услове претраге користећи =, != операторе или регуларне изразе:

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

Филтер је текст или регекп који ће филтрирати све податке које прима селектор.

Могуће је добити ад-хоц графиконе на основу примљених података у режиму метрике. На пример, можете сазнати учесталост појављивања у нгинк евиденцијама уноса који садржи низ индекса:

Комплетан опис карактеристика може се наћи у документацији ЛогКЛ.

Парсинг дневника

Постоји неколико начина за прикупљање дневника:

Уз помоћ Промтаил-а, стандардне компоненте стека за прикупљање трупаца.
Директно из доцкер контејнера користећи Локи Доцкер драјвер за евидентирање.
Користите Флуентд или Флуент Бит који може слати податке Локију. За разлику од Промтаил-а, они имају готове парсере за скоро сваку врсту дневника и могу да обрађују и вишелинијске евиденције.

Обично се Промтаил користи за рашчлањивање. Ради три ствари:

Проналази изворе података.
Причврстите етикете на њих.
Шаље податке Локију.

Тренутно Промтаил може да чита евиденције из локалних датотека и из системског дневника. Мора бити инсталиран на свакој машини са које се прикупљају трупци.

Постоји интеграција са Кубернетес-ом: Промтаил аутоматски сазнаје стање кластера преко Кубернетес РЕСТ АПИ-ја и прикупља евиденције са чвора, услуге или под-а, одмах постављајући ознаке на основу метаподатака из Кубернетес-а (име под, име датотеке, итд.).

Такође можете да окачите налепнице на основу података из евиденције користећи Пипелине. Пипелине Промтаил се може састојати од четири врсте фаза. Више детаља - у званична документација, одмах ћу приметити неке нијансе.

Парсинг стагес. Ово је фаза РегЕк-а и ЈСОН-а. У овој фази извлачимо податке из дневника у такозвану екстраховану мапу. Можете извући из ЈСОН-а једноставним копирањем поља која су нам потребна у екстраховану мапу или путем регуларних израза (РегЕк), где су именоване групе „мапиране“ у екстраховану мапу. Извучена мапа је складиште кључ/вредност, где је кључ име поља, а вредност његова вредност из евиденције.
Трансформ стагес. Ова фаза има две опције: трансформ, где постављамо правила трансформације, и извор - извор података за трансформацију из екстраховане мапе. Ако у екстрахованој мапи нема таквог поља, биће креирано. Тако је могуће креирати ознаке које нису засноване на екстрахованој мапи. У овој фази можемо манипулисати подацима у екстрахованој мапи користећи прилично моћну голанг темплате. Поред тога, морамо имати на уму да је екстрахована мапа у потпуности учитана током рашчлањивања, што омогућава, на пример, проверу вредности у њој: „{{иф .таг}вредност ознаке постоји{енд}}“. Шаблон подржава услове, петље и неке функције стрингова као што су Замени и Трим.
Фазе акције. У овој фази, можете учинити нешто са екстрахованим:
- Направите ознаку од екстрахованих података, коју ће Локи индексирати.
- Промените или подесите време догађаја из евиденције.
- Промените податке (текст дневника) који ће ићи Локију.
- Креирајте метрику.
Фазе филтрирања. Фаза подударања, где можемо или да пошаљемо записе које не требамо да /дев/нулл, или да их пошаљемо на даљу обраду.

На примеру обраде обичних нгинк дневника, показаћу како можете рашчланити дневнике користећи Промтаил.

За тест, узмимо модификовану нгинк слику јвилдер/нгинк-проки:алпине као нгинк-проки и мали демон који може да поставља упите преко ХТТП-а. Даемон има неколико крајњих тачака на које може дати одговоре различитих величина, са различитим ХТТП статусима и са различитим кашњењима.

Сакупљаћемо дневнике из доцкер контејнера, који се могу наћи дуж путање /вар/либ/доцкер/цонтаинерс/ / -јсон.лог

У доцкер-цомпосе.имл постављамо Промтаил и наводимо путању до конфигурације:

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'
 // ...

Додајте путању до евиденције у промтаил.имл (постоји „доцкер“ опција у конфигурацији која ради исто у једном реду, али то не би било тако очигледно):

scrape_configs:
 - job_name: containers

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

Када је ова конфигурација омогућена, Локи ће примати евиденције из свих контејнера. Да бисмо ово избегли, мењамо подешавања тестног нгинк-а у доцкер-цомпосе.имл - додамо евиденцију у поље ознаке:

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

Уредите промтаил.имл и подесите Пипелине. Дневници су следећи:

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

Извлачимо поља стреам, аттрс, аттрс.таг (ако их има) из долазног ЈСОН-а и стављамо их у екстраховану мапу.

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

Ако је било могуће ставити поље ознаке у екстраховану мапу, онда помоћу редовног израза издвајамо имена слике и контејнера.

 - 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

За све евиденције чије је име_имаге једнако нгинк.промтаил.тест, издвојите поље дневника из изворног дневника и ставите га у екстраховану мапу помоћу кључа реда.

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

Чистимо улазни низ са регуларним изразима и извлачимо нгинк виртуелни хост и нгинк лог линију.

     - 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.]+)")?

Парсирајте нгинк дневник са регуларним изразима.

    - 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>[^/?.]+).*$

Парсе рекуест_урл. Уз помоћ регекп-а одређујемо сврху захтева: на статику, на фотографије, на АПИ и постављамо одговарајући кључ у екстрахованој мапи.

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

Користећи условне операторе у шаблону, проверавамо инсталирана поља у екстрахованој мапи и постављамо потребне вредности за поље рекуест_типе: пхото, статиц, АПИ. Додели друго ако није успело. Сада рекуест_типе садржи тип захтева.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Поставили смо ознаке апи_рекуест, виртуал_хост, рекуест_типе и статус (ХТТП статус) на основу онога што смо успели да ставимо у екстраховану мапу.

       - output:
           source: nginx_log_row

Промените излаз. Сада очишћени нгинк дневник из екстраховане мапе иде Локију.

Након покретања горње конфигурације, можете видети да је сваки унос означен на основу података из евиденције.

Имајте на уму да издвајање ознака са великим бројем вредности (кардиналности) може значајно успорити Локија. То јест, не би требало да стављате у индекс, на пример, усер_ид. Прочитајте више о овоме у чланкуКако ознаке у Локију могу да учине упите дневника бржим и лакшим„. Али то не значи да не можете претраживати по усер_ид без индекса. Приликом претраживања потребно је користити филтере („граби” према подацима), а индекс овде делује као идентификатор тока.

Визуелизација дневника

Локи може да делује као извор података за Графана графиконе користећи ЛогКЛ. Подржане су следеће функције:

стопа - број записа у секунди;
цоунт овер тиме - број записа у датом опсегу.

Постоје и функције агрегирања Сум, Авг и друге. Можете да направите прилично сложене графиконе, на пример, графикон броја ХТТП грешака:

Локијев подразумевани извор података је мало мање функционалан од Прометејевог извора података (на пример, не можете да промените легенду), али Локи се може повезати као извор Прометејовог типа. Нисам сигуран да ли је ово документовано понашање, али судећи по одговору програмера “Како да конфигуришем Локија као Прометејев извор података? · Иссуе #1222 · графана/локи“, на пример, савршено је легалан и Локи је потпуно компатибилан са ПромКЛ-ом.

Додајте Локи као извор података са типом Прометхеус и додајте УРЛ /локи:

И можете да правите графиконе, као да радимо са метрикама из Прометеја:

Мислим да је неусклађеност у функционалности привремена и програмери ће то поправити у будућности.

метрике

Локи пружа могућност издвајања нумеричких метрика из дневника и слања их Прометеју. На пример, нгинк дневник садржи број бајтова по одговору, а такође, уз одређену модификацију стандардног формата дневника, време у секундама које је било потребно да се одговори. Ови подаци се могу издвојити и послати Прометеју.

Додајте још један одељак у промтаил.имл:

- 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:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Уверавамо се да су се метрика са промтаил_цустом префиксом појавила:

Постављање Прометеја. Додајте промтаил посла:

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

И нацртајте графикон:

На овај начин можете сазнати, на пример, четири најспорија захтева. Такође можете да конфигуришете праћење за ове метрике.

Skaliranje

Локи може бити и у појединачном бинарном режиму и у подељеном (хоризонтално скалабилан режим). У другом случају, може да сачува податке у облаку, а делови и индекс се чувају одвојено. У верзији 1.5 имплементирана је могућност складиштења на једном месту, али се још увек не препоручује да се користи у производњи.

Комадићи могу да се чувају у С3-компатибилном складишту, за складиштење индекса користите хоризонтално скалабилне базе података: Цассандра, БигТабле или ДинамоДБ. Остали делови Локија - Дистрибутери (за писање) и Куериер (за упите) - су без држављанства и такође су хоризонтално скалирани.

На конференцији ДевОпсДаис Ванцоувер 2019, један од учесника Цаллум Стиан је најавио да са Локијем његов пројекат има петабајте дневника са индексом мањим од 1% укупне величине: „Како Локи повезује метрике и евиденције - и штеди вам новац".

Поређење Локија и ЕЛК-а

Величина индекса

Да бих тестирао резултујућу величину индекса, узео сам евиденције из нгинк контејнера за који је конфигурисан горњи цевовод. Датотека евиденције је садржала 406 реда са укупном запремином од 624 МБ. Дневници су генерисани у року од сат времена, отприлике 109 записа у секунди.

Пример два реда из дневника:

Када га је ЕЛК индексирао, ово је дало величину индекса од 30,3 МБ:

У случају Локија, ово је дало око 128 КБ индекса и око 3,8 МБ података у комадима. Вреди напоменути да је дневник вештачки генерисан и да није садржао широк спектар података. Једноставан гзип на оригиналном Доцкер ЈСОН дневнику са подацима дао је компресију од 95,4%, а с обзиром да је само очишћени нгинк дневник послат самом Локију, компресија на 4 МБ је разумљива. Укупан број јединствених вредности за Локи ознаке је био 35, што објашњава малу величину индекса. За ЕЛК, дневник је такође очишћен. Тако је Локи компресовао оригиналне податке за 96%, а ЕЛК за 70%.

Потрошња меморије

Ако упоредимо целу гомилу Прометеја и ЕЛК-а, онда Локи "једе" неколико пута мање. Јасно је да услуга Го троши мање од услуге Јава, а поређење величине Хеап Еластицсеарцх ЈВМ-а и додељене меморије за Локи је нетачно, али ипак, вреди напоменути да Локи користи много мање меморије. Његова ЦПУ предност није толико очигледна, али је такође присутна.

Брзина

Локи брже "прождире" трупце. Брзина зависи од много фактора - какве евиденције, колико их софистицирано анализирамо, мрежа, диск итд. - али је дефинитивно већа од ЕЛК-а (у мом тесту - око два пута). Ово се објашњава чињеницом да Локи ставља много мање података у индекс и, сходно томе, троши мање времена на индексирање. У овом случају, ситуација је обрнута са брзином претраживања: Локи приметно успорава на подацима већим од неколико гигабајта, док за ЕЛК брзина претраге не зависи од величине података.

Лог Сеарцх

Локи је значајно инфериоран у односу на ЕЛК у погледу могућности претраживања дневника. Греп са регуларним изразима је јака ствар, али је инфериоран у односу на базу података за одрасле. Недостатак упита опсега, агрегација само по ознакама, немогућност претраживања без ознака - све нас то ограничава у потрази за информацијама од интереса у Локију. Ово не значи да се ништа не може пронаћи помоћу Локија, али дефинише ток рада са евиденцијама, када прво нађете проблем на Прометхеус графиконима, а затим потражите шта се догодило у евиденцији користећи ове ознаке.

interfejs

Као прво, прелепо је (извини, нисам могао да одолим). Графана има леп интерфејс, али Кибана је много функционалнија.

Локи за и против

Од плуса, може се приметити да се Локи интегрише са Прометејем, односно добијамо метрику и упозорења из кутије. Погодан је за прикупљање дневника и њихово складиштење са Кубернетес Подс-овима, јер има откривање услуге наслеђено од Прометхеуса и аутоматски причвршћује етикете.

Од минуса - лоша документација. Неке ствари, као што су карактеристике и могућности Промтаил-а, открио сам тек у процесу проучавања кода, у корист отвореног кода. Још један недостатак су слабе могућности рашчлањивања. На пример, Локи не може да анализира вишелинијске евиденције. Такође, недостаци укључују чињеницу да је Локи релативно млада технологија (издање 1.0 је било у новембру 2019.).

Закључак

Локи је 100% занимљива технологија која је погодна за мале и средње пројекте, омогућавајући вам да решите многе проблеме агрегације дневника, претраживања дневника, праћења и анализе дневника.

Локи не користимо на Бадоо-у, јер имамо ЕЛК стек који нам одговара и који је годинама обрастао разним прилагођеним решењима. За нас је камен спотицања потрага у балванима. Са скоро 100 ГБ дневника дневно, важно нам је да можемо да пронађемо све и још мало и то брзо. За цртање и праћење користимо друга решења која су прилагођена нашим потребама и интегрисана једно са другим. Локи стацк има опипљиве предности, али нам неће дати више од онога што имамо, а његове користи неће баш надмашити трошкове миграције.

И иако је након истраживања постало јасно да не можемо користити Локи, надамо се да ће вам овај пост помоћи у избору.

Репозиторијум са кодом коришћеним у чланку се налази овде.

Извор: ввв.хабр.цом

Сакупљање трупаца од Локија