Събиране на логове с Loki

Ние в Badoo постоянно следим за новите технологии и оценяваме дали да ги използваме в нашата система. Едно от тези изследвания искаме да споделим с общността. То е посветено на Loki — система за агрегиране на лога.

Loki е решение за съхранение и преглед на логовете, също така този стек предоставя гъвкава система за тяхния анализ и изпращане на данни в Prometheus. През май излезе поредната актуализация, която активно промотират създателите. Нас ни заинтересува какво може да прави Loki, какви възможности предлага и в каква степен може да бъде алтернатива на ELK — стека, който в момента използваме.

Какво е Loki

Grafana Loki е набор от компоненти за цялостна система за работа с лога. В отличие от други подобни системи, Loki е основан на идеята да индексира само метаданните на логовете — labels (като в Prometheus), а самите лога компресира в отделни чанкове.

Начална страница, GitHub

Преди да преминем към описанието на това, което може да се прави с помощта на Loki, искам да обясня какво се подразбира под „идеята да индексираме само метаданните“. Да сравним подхода на Loki и подхода за индексиране в традиционните решения, като 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 е да извлече само необходимите данни от низовете, броят на които е малък. По този начин получаваме малък индекс и можем да търсим данни, филтрирайки ги по време и по индексирани полета, а след това да сканираме остатъка с регулярни изрази или чрез търсене на подстрока. Процесът не изглежда най-бърз, но Loki разделя заявката на няколко части и ги изпълнява паралелно, обработвайки голямо количество данни за кратко време. Броят на шардовете и паралелните заявки в тях може да се конфигурира; следователно количеството данни, което може да се обработи за единица време, линейно зависи от предоставените ресурси.

Този компромис между голям бърз индекс и малък индекс с паралелно пълно перебиране позволява на Loki да контролира разходите на системата. Тя може да бъде гъвкаво настроена и разширена в съответствие с нуждите.

Стекът на Loki се състои от три компонента: Promtail, Loki и Grafana. Promtail събира логовете, обработва ги и ги изпраща в Loki. Loki ги съхранява. А Grafana може да запитва данни от Loki и да ги показва. Всъщност Loki може да се използва не само за съхранение на логове и търсене в тях. Целият стек предлага големи възможности за обработка и анализ на постъпващите данни, използвайки Prometheus way.
Описание на процеса на инсталиране можете да намерите тук..

Търсене на логове

Търсенето на логове може да се извършва в специалния интерфейс на Grafana — Explorer. За заявките се използва езикът LogQL, много подобен на PromQL, използван в Prometheus. В принципе, може да се разглежда като разпределен grep.

Интерфейсът за търсене изглежда така:

Самата заявка се състои от две части: селектор и филтър. Селекторът е търсенето по индексирани метаданни (етикети), които са присвоени на логовете, а филтърът — търсачка или регекс, с помощта на който се филтрират записите, определени от селектора. В представения пример: В фигурните скоби — селекторът, всичко след — филтър.

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

Поради принципа на работа на Loki не е възможно да се правят заявки без селектор, но етикетите могат да бъдат достатъчно общи.

Селекторът е ключ-стойност в фигурни скоби. Можете да комбинирате селектори и да задавате различни условия за търсене, използвайки оператори =, != или регулярни изрази:

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

Филтърът е текст или регекс, който ще филтрира всички данни, получени от селектора.

Има възможност за получаване на ad-hoc графики на базата на получените данни в режим metrics. Например, можете да разберете честотата на появяване в логовете на nginx запис, съдържащ стринга index:

Пълно описание на възможностите можете да намерите в документацията LogQL.

Парсинг на логовете

Има няколко начина за събиране на логове:

• Чрез Promtail, стандартен компонент от стека за събиране на логове.
• Направо от Docker контейнера с помощта на Loki Docker Logging Driver.
• Използвайте Fluentd или Fluent Bit, които могат да изпращат данни в Loki. В отличие от Promtail, те разполагат с готови парсъри почти за всеки вид лог и се справят и с мултилтайнови логове.

Обикновено за парсинг използват Promtail. Той извършва три неща:

• Намира източниците на данни.
• Прикрепя към тях етикети.
• Изпраща данните в Loki.

В момента Promtail може да чете логове от локални файлове и от systemd journal. Той трябва да бъде инсталиран на всяка машина, от която се събират логове.

Има интеграция с Kubernetes: Promtail автоматично чрез Kubernetes REST API разбира състоянието на клъстера и събира логове от нода, сървиса или пода, веднага закрепвайки етикети на базата на метаданни от Kubernetes (име на пода, име на файла и т.н.).

Също така, можете да закрепвате етикети на базата на данни от логовете с помощта на Pipeline. Pipeline на Promtail може да се състои от четири типа етапи. По-подробно — в официалната документация, тук също отбелязвам някои нюанси.

1. Етапи на парсинг. Това е етапът RegEx и JSON. На този етап извличаме данни от логовете в така наречената extracted map. Можете да извлечете от JSON, просто копирайки нужните полета в extracted map, или чрез регулярни изрази (RegEx), където в extracted map се “мапват” именувани групи. Extracted map представлява хранилище key-value, където key е името на полето, а value е неговата стойност от логовете.
2. Етапи на трансформация. Този етап има две опции: трансформация, където задаваме правила за трансформация, и source — източник на данни за трансформация от extracted map. Ако такова поле в extracted map няма, ще бъде създадено. По този начин можем да създадем етикети, които не са базирани на extracted map. На този етап можем да манипулираме данните в extracted map, като използваме достатъчно мощен Golang Template. Освен това, трябва да се помни, че extracted map се зарежда напълно при парсинг, което позволява, например, да се провери стойността в него: “{{if .tag}tag value exists{end}}”. Template поддържа условия, цикли и някои стрингови функции, като Replace и Trim.
3. Етапи на действието. На този етап можете да направите нещо с извлеченото:
   • Да създадете етикет от extracted data, който ще се индексира в Loki.
   • Да промените или зададете времето на събитие от лога.
   • Да промените данните (текста на лога), които ще отидат в Loki.
   • Да създадете метрики.
4. Етапи на филтриране. Стадията match, в която можете или да изпратите в /dev/null записите, от които нямате нужда, или да ги насочите за по-нататъшна обработка.

Ще покажа с пример за обработка на обикновени nginx лога, как можете да парсите логовете с помощта на Promtail.

За тест ще вземем модифициран образ на nginx jwilder/nginx-proxy:alpine като nginx-proxy и малък демон, който може да запитва сам себе си по HTTP. На демона са зададени няколко крайни точки, на които може да дава отговори с различен размер, различни 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  # само за linux

Когато включите такава конфигурация, в Loki ще попадат логовете от всички контейнери. За да избегнем това, променяме настройките на тестовия nginx в docker-compose.yml — добавяме логиране с поле tag:

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

Етап на Pipeline:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Извличаме полета stream, attrs, attrs.tag (ако съществуват) от входящия JSON и ги поставяме в extracted map.

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

Ако сме успели да поставим полето tag в extracted map, използваме регулярни изрази, за да извлечем имената на образа и контейнера.

 - labels:
     image_name:
     container_name:

Назначаваме етикети. Ако в extracted data се открият ключовете 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, извличаме полето log от изходния лог и го поставяме в extracted map с ключ row.

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

Почистваме входната строка с регулярни изрази и извличаме nginx virtual host и строката лог на nginx.

     - regex:
         source: nginxlog
         expression: ^(?P[w.]+) - (?P[^ ]*) [(?P[^ ]+).*] "(?P[^ ]*) (?P[^ ]*) (?P[^ ]*)" (?P[d]+) (?P[d]+) "(?P[^"]*)" "(?P[^"]*)"( "(?P[d.]+)")?

Парсираме nginx лога с регулярни изрази.

    - regex:
           source: request_url
           expression: ^.+.(?Pjpg|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[^/?]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P[^/?]+).*$

Разглеждаме request_url. С помощта на регекспи определяме назначението на заявката: за статични ресурси, снимки, API и задаваме съответния ключ в extracted map.

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

С помощта на условни оператори в Template проверяваме зададените полета в extracted map и задаваме нужните стойности за полето request_type: photo, static, API. Присвояваме other, ако не успеем. Сега request_type съдържа типа на заявката.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Установяваме етикетите api_request, virtual_host, request_type и статус (HTTP status) на база това, което успяхме да поставим в extracted map.

       - output:
           source: nginx_log_row

Променяме изхода. Сега в Loki излиза почистеният nginx лог от extracted map.

След стартиране на предоставената конфигурация може да се види, че на всяка запис е присвоен етикет на база данните от лога.

Трябва да имате предвид, че извличането на етикети с голямо количество стойности (кардиналност) може значително да забави работата на Loki. Тоест, не бива да добавяте в индекса например user_id. Повече по темата можете да прочетете в статията “Как етикетите в Loki могат да направят запитванията по логовете по-бързи и лесни”. Но това не означава, че не можете да търсите по user_id без индекси. Трябва да използвате филтри при търсене (да 'грепите' по данните), а индексът тук служи като идентификатор на потока.

Визуализация на логовете

Loki може да служи като източник на данни за графики в Grafana, използвайки LogQL. Поддържат се следните функции:

• rate — брой записи в секунда;
• count over time — брой записи в зададен диапазон.

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

Стандартният източник на данни Loki е малко ограничен по функционалност в сравнение с източника на данни Prometheus (например, не може да се промени легендата), но Loki може да се свърже като източник с тип Prometheus. Не съм сигурен, че това е документирано поведение, но, судя по отговора на разработчиците “Как да конфигурирате Loki като източник на данни Prometheus? · Проблем #1222 · grafana/loki”, например, това е напълно законно и Loki е напълно съвместим с PromQL.

Добавяме Loki като източник на данни с тип Prometheus и добавяме URL /loki:

И можете да правите графики, както ако работехте с метрики от Prometheus:

Мисля, че несъответствието във функционалността е временно и разработчиците в бъдеще ще го поправят.

Метрики

В Loki е налична възможността за извличане на числови метрики от логовете и изпращането им в Prometheus. Например, в логовете на nginx присъства броят на байтовете в отговор, а също така, при определена модификация на стандартния формат на лога, и времето в секунди, необходимо за отговора. Тези данни могат да бъдат извлечени и изпратени в Prometheus.

Добавяйте още една секция в promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "време за отговор в 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: "сума на байтовете в отговор"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "броя на байтовете в отговор"
           source: bytes_out
           config:
             action: inc

Опцията позволява да определяте и обновявате метрики на базата на данни от extracted map. Тези метрики не се изпращат в Loki — те се появяват в Promtail /metrics endpoint. Prometheus трябва да бъде конфигуриран по такъв начин, че да получава данните, получавани на тази фаза. В предоставения пример за request_type="api" събираме метрика-хистограма. С този тип метрики е удобно да се получават перцентили. За статиката и снимките събираме сумата на байтовете и броя редове, в които сме получили байтове, за да изчислим средната стойност.

По-подробно за метриките четете тук..

Отваряме порт на Promtail:

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

Убедете се, че метриките с префикс promtail_custom са се появили:

Настройваме Prometheus. Добавяме job promtail:

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

И рисуваме график:

По този начин можете да разберете, например, четирите най-бавни запитвания. Освен това на тези метрики може да се настрои мониторинг.

Мащабиране

Loki може да бъде както в единичен режим (single binary mode), така и в шардируем (horizontally-scalable mode). Във втория случай той може да съхранява данни в облака, като чанковете и индексите се съхраняват отделно. В версия 1.5 е реализирана възможността за съхранение на едно място, но все още не се препоръчва да се използва в продукцията.

Чанковете могат да се съхраняват в S3-съвместимо хранилище, за съхраняване на индексите - да се използват хоризонтално мащабируеми бази данни: Cassandra, BigTable или DynamoDB. Другите части на Loki - Distributors (за запис) и Querier (за запитвания) - са stateless и също се мащабират хоризонтално.

На конференцията DevOpsDays Vancouver 2019 един от участниците Callum Styan спомена, че с Loki неговият проект разполага с петабайти логове с индекс под 1% от общия размер: "How Loki Correlates Metrics and Logs — And Saves You Money".

Сравнение на Loki и ELK

Размер на индекса

За тестване на получения размер на индекса взех логовете от контейнера nginx, за който се настройваше Pipeline, предоставен по-горе. Файлът с логовете съдържаше 406 624 реда с общ обем 109 Мб. Логовете се генерираха за един час, приблизително по 100 записа в секунда.

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

При индексацията в ELK това дало размер на индекса 30,3 Мб:

В случая с Loki това дава около 128 Кб индекс и около 3,8 Мб данни в чанк. Трябва да се отбележи, че логът е бил генериран изкуствено и не се е отличавал с голямо разнообразие от данни. Обикновен gzip на оригиналния docker JSON лог с данни дава компресия от 95,4%, а предвид, че в самия Loki се е изпращал само почистен nginx лог, компресията до 4 Мб е обяснима. Общият брой уникални стойности за етикетите на Loki е бил 35, което обяснява малкия размер на индекса. За ELK логът също е бил почистен. Така че, Loki е компресирал оригиналните данни с 96%, а ELK – с 70%.

Консумация на памет

Ако сравняваме целия стек Prometheus и ELK, то Loki „яде“ няколко пъти по-малко. Ясно е, че услугата на Go консумира по-малко от услугата на Java, и сравнението на размера на JVM Heap Elasticsearch и определената памет за Loki не е коректно, но все пак трябва да се отбележи, че Loki използва много по-малко памет. Неговото предимство по CPU не е толкова очевидно, но също така присъства.

Скорост

Loki по-бързо „изяжда“ логовете. Скоростта зависи от много фактори – какви са логовете, колко сложни са парсинга, мрежата, диска и т.н. – но определено е по-висока от тази на ELK (в теста ми – около два пъти). Това се обяснява с факта, че Loki поставя много по-малко данни в индекса и следователно отделя по-малко време за индексиране. По отношение на скоростта на търсене обаче ситуацията е обратна: Loki значително забавя на данни с размер над няколко гигабайта, при ELK скоростта на търсене не зависи от размера на данните.

Търсене на логове

Loki значително изостава от ELK по възможности за търсене на логове. Grep с регулярни изрази е мощен инструмент, но отстъпва на зряла база данни. Липсата на range-запитвания, агрегация само по етикети, невъзможността да се търси без етикети – всичко това ни ограничава в търсенето на интересна информация в Loki. Това не означава, че с помощта на Loki не може да се намери нищо, но определя потока на работа с логовете, при който първо намирате проблема в графиките на Prometheus, а след това по тези етикети търсите какво се е случило в логовете.

Интерфейс

На първо място, това е красиво (извинете, не можех да се сдържа). Grafana има приятен за очите интерфейс, но Kibana е много по-функционална.

Плюсове и минуси на Loki

От положителните страни можем да подчертаем, че Loki се интегрира с Prometheus, което означава, че получаваме метрики и алертиране готови за употреба. Удобен е за събиране и съхранение на логове от Kubernetes Pods, тъй като има наследена от Prometheus функция за откриване на услуги и автоматично добавя етикети.

От отрицателните страни - слаба документация. Някои неща, например особеностите и възможностите на Promtail, открих само по време на проучване на кода, за щастие е с отворен код. Още един недостатък - слаби възможности за парсинг. Например, Loki не може да парсва многоредови логове. Към недостатъците може да се добави, че Loki е сравнително нова технология (релиз 1.0 беше през ноември 2019 г.).

Заключение

Loki е изцяло интересна технология, която подхожда за малки и средни проекти, позволявайки решаването на множество задачи за агрегация на логове, търсене в логове, мониторинг и анализ на логове.

Не използваме Loki в Badoo, тъй като имаме ELK стек, който ни удовлетворява и който през годините е натрупал различни персонализирани решения. Проблематично за нас е търсенето в логовете. С почти 100 Гб логове на ден, важно е да можем да намираме всичко и още малко и да го правим бързо. За изграждане на графики и мониторинг използваме други решения, които са настроени за нашите нужди и са интегрирани помежду си. Стекът на Loki има осезаеми предимства, но той не може да ни предложи повече, отколкото вече имаме, и неговите предимства определено няма да покрият разходите за миграция.

И въпреки че след проучването стана ясно, че не можем да използваме Loki, се надяваме, че този пост ще ви помогне при избора.

Репозиториумът с кода, използван в статията, се намира тук.

Източник: habr.com