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

Во Badoo, ние постојано ги следиме новите технологии и оценуваме дали вреди да се користат во нашиот систем. Би сакале да споделиме една од овие студии со заедницата. Тој е посветен на Локи, систем за агрегација на дневници.

Локи е решение за складирање и прегледување логови, а овој стек обезбедува и флексибилен систем за нивна анализа и испраќање податоци до Прометеј. Во мај беше објавено уште едно ажурирање, кое активно го промовираат креаторите. Бевме заинтересирани за тоа што може да направи Loki, какви способности обезбедува и до кој степен може да дејствува како алтернатива на ELK, стекот што го користиме сега.

Што е Локи

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

Почетна страница, GitHub

Пред да влеземе во тоа што можете да направите со Локи, сакам да разјаснам што подразбираме под „идејата за индексирање само метаподатоци“. Ајде да го споредиме пристапот на Локи и пристапот кон индексирање во традиционалните решенија како што е Elasticsearch, користејќи го примерот на линија од дневникот nginx:

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 се состои од три компоненти: Promtail, Loki, Grafana. Promtail собира логови, ги обработува и ги испраќа до Локи. Локи ги чува. И Графана може да бара податоци од Локи и да ги прикаже. Општо земено, Loki може да се користи не само за складирање на дневници и пребарување низ нив. Целиот оџак дава одлични можности за обработка и анализа на дојдовните податоци користејќи го начинот на Прометеј.
Може да се најде опис на процесот на инсталација тука.

Пребарување по дневници

Можете да ги пребарувате дневниците во посебен интерфејс на Grafana - Explorer. Прашањата го користат јазикот LogQL, кој е многу сличен со PromQL што се користи во Prometheus. Во принцип, може да се смета како дистрибуиран грип.

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

Самото барање се состои од два дела: избирач и филтер. Селекторот е пребарување со помош на индексирани метаподатоци (етикети) кои се доделени на дневници, а филтерот е низа за пребарување или regexp што ги филтрира записите дефинирани од избирачот. Во дадениот пример: Во кадравите загради има избирач, сè потоа е филтер.

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

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

Избирачот е клучна вредност во кадрава заграда. Можете да комбинирате избирачи и да наведете различни услови за пребарување користејќи ги операторите =, != или регуларни изрази:

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

Филтер е текст или regexp што ќе ги филтрира сите податоци добиени од избирачот.

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

Целосен опис на можностите може да се најде во документацијата LogQL.

Парсирање на дневникот

Постојат неколку начини за собирање трупци:

• Користење на Promtail, стандардна компонента на оџакот за собирање логови.
• Директно од докер контејнерот користејќи Возач за сеча на Loki Docker.
• Користете Fluentd или Fluent Bit, кои можат да испраќаат податоци до Loki. За разлика од Promtail, тие имаат готови парсери за речиси секаков вид дневници и можат да ракуваат и со повеќелиниски дневници.

Обично Promtail се користи за парсирање. Прави три работи:

• Наоѓа извори на податоци.
• Закачува етикети за нив.
• Испраќа податоци до Локи.

Во моментов Promtail може да чита дневници од локални датотеки и од системски дневник. Мора да се инсталира на секоја машина од која се собираат дневниците.

Има интеграција со Kubernetes: Promtail автоматски, преку Kubernetes REST API, ја препознава состојбата на кластерот и собира дневници од јазол, услуга или pod, веднаш објавувајќи етикети врз основа на метаподатоци од Kubernetes (име на pod, име на датотека, итн.) .

Можете исто така да обесувате етикети врз основа на податоци од дневникот со помош на Pipeline. Pipeline Promtail може да се состои од четири типа на фази. Повеќе детали во официјална документација, веднаш ќе забележам некои нијанси.

1. Фази на парсирање. Ова е фазата RegEx и JSON. Во оваа фаза, ние извлекуваме податоци од дневниците во таканаречената извлечена карта. Можеме да извлечеме од JSON со едноставно копирање на полињата што ни се потребни во извлечената карта или преку регуларни изрази (RegEx), каде именуваните групи се „мапираат“ во извлечената карта. Извлечената мапа е складиште за вредност на клучеви, каде што клучот е името на полето, а вредноста е неговата вредност од дневниците.
2. Трансформирајте фази. Оваа фаза има две опции: трансформација, каде што ги поставуваме правилата за трансформација и извор - извор на податоци за трансформација од извлечената карта. Доколку нема такво поле во извлечената карта, таа ќе се креира. На овој начин е можно да се креираат етикети кои не се базираат на извлечената карта. Во оваа фаза можеме да манипулираме со податоците во извлечената карта користејќи прилично моќен Шаблон Голанг. Покрај тоа, мораме да запомниме дека извлечената карта е целосно вчитана за време на парсирањето, што овозможува, на пример, да се провери вредноста во неа: „{{ако .tag}вредноста на ознаката постои{крај}}“. Шаблонот поддржува услови, јамки и некои функции на низа како што се Replace и Trim.
3. Фази на акција. Во овој момент можете да направите нешто со извлечената содржина:
   • Направете ознака од извлечените податоци, кои ќе бидат индексирани од Локи.
   • Променете го или поставете го времето на настанот од дневникот.
   • Променете ги податоците (текст на дневникот) што ќе одат во Локи.
   • Создадете метрика.
4. Фази на филтрирање. Фаза на натпревар, каде што можеме или да испратиме записи што не ни требаат да ги /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 (има опција „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

Ги извлекуваме полињата stream, 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

За сите дневници чие име_име е 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 користејќи регуларни изрази.

    - 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 од извлечената мапа оди на Локи.

Откако ќе ја извршите горната конфигурација, можете да видите дека на секој запис му се доделуваат етикети врз основа на податоците од дневникот.

Едно нешто што треба да се има на ум е дека преземањето етикети со голем број вредности (кардиналност) може значително да го забави Локи. Тоа е, не треба да ставате, на пример, user_id во индексот. Прочитајте повеќе за ова во статијата “Како етикетите во Loki можат да ги направат барањата за дневници побрзи и полесни" Но, тоа не значи дека не можете да пребарувате по user_id без индекси. Треба да користите филтри кога пребарувате („зграпчете“ податоци), а индексот овде делува како идентификатор на поток.

Визуелизација на трупци

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

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

Постојат и функции за агрегација Sum, Avg и други. Можете да изградите доста сложени графикони, на пример графикон за бројот на грешки во HTTP:

Стандардниот извор на податоци Loki е малку намален во функционалноста во споредба со изворот на податоци Prometheus (на пример, не можете да ја промените легендата), но Loki може да се поврзе како извор со типот Prometheus. Не сум сигурен дали ова е документирано однесување, но судејќи според одговорот на програмерите “Како да го конфигурирате Локи како извор на податоци на Прометеј? · Број #1222 · графана/локи“, на пример, е целосно легален, а Loki е целосно компатибилен со PromQL.

Додадете Loki како извор на податоци со тип Prometheus и додадете 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

Опцијата ви овозможува да дефинирате и ажурирате метрика врз основа на податоците од извлечената карта. Овие метрики не се испраќаат до 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:

Поставување на Прометеј. Додајте промотивна работа за работа:

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

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

На овој начин можете да ги дознаете, на пример, четирите најбавни прашања. Можете исто така да поставите мониторинг за овие метрики.

Скалирање

Локи може да биде или во единечен бинарен режим или во скршен режим (хоризонтално-скалабилен режим). Во вториот случај, може да зачува податоци во облакот, а деловите и индексот се складираат одделно. Верзијата 1.5 воведува можност за складирање на едно место, но сè уште не е препорачливо да се користи во производството.

Парчињата може да се складираат во складиште што е компатибилно со S3, а хоризонтално скалабилните бази на податоци може да се користат за складирање на индекси: Cassandra, BigTable или DynamoDB. Другите делови на Loki - Дистрибутери (за пишување) и Querier (за прашања) - се без државјанство, а исто така се скалираат хоризонтално.

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

Споредба на Локи и ЕЛК

Големина на индекс

За да ја тестирам добиената големина на индексот, зедов логови од контејнерот nginx за кој беше конфигуриран гасоводот погоре. Датотеката за евиденција содржеше 406 линии со вкупен волумен од 624 MB. Дневниците беа генерирани во рок од еден час, приближно 109 записи во секунда.

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

Кога се индексира од ELK, ова даде големина на индекс од 30,3 MB:

Во случајот на Loki, ова резултираше со приближно 128 KB индекс и приближно 3,8 MB податоци во парчиња. Вреди да се напомене дека дневникот беше вештачки генериран и немаше голема разновидност на податоци. Едноставен gzip на оригиналниот дневник на Docker JSON со податоци даде компресија од 95,4%, а земајќи го предвид фактот дека само исчистениот дневник на nginx беше испратен до самиот Loki, разбирлива е компресија до 4 MB. Вкупниот број на уникатни вредности за етикетите Локи беше 35, што ја објаснува малата големина на индексот. За ЕЛК и дневникот е исчистен. Така, Локи ги компресира оригиналните податоци за 96%, а ELK за 70%.

Потрошувачка на меморија

Ако го споредиме целиот оџак Прометеј и ЕЛК, тогаш Локи „јаде“ неколку пати помалку. Јасно е дека услугата Go троши помалку од Java услугата, а споредувањето на големината на JVM Heap Elasticsearch и доделената меморија за Loki е неточно, но сепак вреди да се напомене дека Loki користи многу помалку меморија. Неговата предност на процесорот не е толку очигледна, но исто така е присутна.

Брзина

Локи побрзо ги „голта“ дневниците. Брзината зависи од многу фактори - какви се логови, колку сме софистицирани во нивното парсирање, мрежа, диск итн. - но дефинитивно е поголема од ELK (во мојот тест - околу двојно повеќе). Ова се објаснува со фактот дека Локи става многу помалку податоци во индексот и, соодветно, троши помалку време на индексирање. Со брзината на пребарување, ситуацијата е спротивна: Loki значително успорува на податоци поголеми од неколку гигабајти, додека брзината на пребарување на ELK не зависи од големината на податоците.

Пребарување по дневници

Локи е значително инфериорен во однос на ELK во однос на можностите за пребарување на дневници. Grep со регуларни изрази е моќен, но е инфериорен во однос на зрела база на податоци. Недостатокот на прашања за опсег, агрегација само по етикети, неможноста за пребарување без етикети - сето тоа нè ограничува во барањето информации од интерес во Локи. Ова не значи дека ништо не може да се најде со користење на Loki, но го дефинира текот на работа со дневници кога прво ќе најдете проблем во графиконите на Prometheus, а потоа ги користите овие ознаки за да побарате што се случило во дневниците.

интерфејс

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

Добрите и лошите страни на Локи

Една од предностите е што Локи се интегрира со Прометеј, така што добиваме метрика и предупредување надвор од кутијата. Погодно е за собирање трупци и нивно складирање од Kubernetes Pods, бидејќи има откривање на услуги наследено од Прометеј и автоматски прикачува етикети.

Негативна страна е слабата документација. Некои работи, на пример, карактеристиките и можностите на Promtail, ги открив само во процесот на проучување на кодот, за среќа тој е со отворен код. Друг недостаток се слабите способности за парсирање. На пример, Loki не може да анализира повеќелиниски дневници. Друг недостаток е тоа што Loki е релативно млада технологија (изданието 1.0 беше во ноември 2019 година).

Заклучок

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

Не користиме Loki во Badoo затоа што имаме ELK стек што ни одговара и кој е обраснат со различни сопствени решенија со текот на годините. За нас камен на сопнување е пребарувањето низ трупците. Со речиси 100 GB дневници дневно, за нас е важно да можеме да најдеме сè и малку повеќе и да го направиме тоа брзо. За цртање и мониторинг користиме други решенија кои се прилагодени на нашите потреби и интегрирани едни со други. Локи оџакот има опипливи придобивки, но нема да ни даде повеќе отколку што веќе имаме, а неговите придобивки сигурно нема да ги надминат трошоците за миграција.

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

Се наоѓа складиштето со кодот што се користи во статијата тука.

Извор: www.habr.com