Събиране на трупи от Локи

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

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

Какво е Локи

Grafana Loki е набор от компоненти за цялостна система за дърводобив. За разлика от други подобни системи, Loki се основава на идеята за индексиране само на метаданни на регистрационни файлове - етикети (точно както в 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 се състои от три компонента: Promtail, Loki, Grafana. Promtail събира регистрационни файлове, обработва ги и ги изпраща на Loki. Локи ги пази. И Графана може да поиска данни от Локи и да ги покаже. Като цяло Loki може да се използва не само за съхраняване на регистрационни файлове и търсене в тях. Целият стек предоставя големи възможности за обработка и анализ на входящите данни, използвайки начина на Prometheus.
Можете да намерите описание на инсталационния процес тук.

Търсене в регистрационния файл

Можете да търсите в регистрационните файлове в специален интерфейс 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 графики въз основа на получените данни в режим на метрика. Например, можете да разберете честотата на срещане в регистрационните файлове на 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. Етапи на трансформация. Този етап има две опции: transform, където задаваме правилата за трансформация, и source - източникът на данни за трансформацията от извлечената карта. Ако в извлечената карта няма такова поле, то ще бъде създадено. По този начин е възможно да се създават етикети, които не са базирани на извлечената карта. На този етап можем да манипулираме данните в извлечената карта, като използваме доста мощен голанг шаблон. Освен това трябва да запомним, че извлечената карта е напълно заредена по време на анализиране, което прави възможно например да се провери стойността в нея: „{{if .tag}tag value exists{end}}“. Шаблонът поддържа условия, цикли и някои низови функции като Replace и Trim.
3. Етапи на действие. На този етап можете да направите нещо с извлеченото:
   • Създайте етикет от извлечените данни, който ще бъде индексиран от Loki.
   • Променете или задайте часа на събитието от дневника.
   • Променете данните (лог текст), които ще отидат до Loki.
   • Създайте показатели.
4. Етапи на филтриране. Етапът на съпоставяне, където можем или да изпратим записи, които не са ни необходими в /dev/null, или да ги изпратим за допълнителна обработка.

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

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

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

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

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

Използвайки условни оператори в Template, ние проверяваме инсталираните полета в извлечената карта и задаваме необходимите стойности за полето request_type: photo, static, API. Задайте друго, ако не успеете. Сега request_type съдържа типа заявка.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Задаваме етикетите api_request, virtual_host, request_type и status (HTTP status) въз основа на това, което успяхме да поставим в извлечената карта.

       - output:
           source: nginx_log_row

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

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

Имайте предвид, че извличането на етикети с голям брой стойности (кардиналност) може значително да забави 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: "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. 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_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

И начертайте графика:

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

мащабиране

Loki може да бъде както в единичен двоичен режим, така и в разделен (хоризонтално мащабируем режим). Във втория случай може да записва данни в облака, а частите и индексът се съхраняват отделно. Във версия 1.5 е реализирана възможността за съхраняване на едно място, но все още не се препоръчва използването му в производството.

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

На конференцията DevOpsDays Vancouver 2019, един от участниците Callum Styan обяви, че заедно с Loki неговият проект има петабайти журнали с индекс по-малък от 1% от общия размер: „Как Локи свързва показатели и регистрационни файлове - и ви спестява пари".

Сравнение на Локи и ELK

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

За да тествам получения размер на индекса, взех регистрационни файлове от контейнера nginx, за който беше конфигуриран тръбопроводът по-горе. Регистрационният файл съдържа 406 624 реда с общ обем от 109 MB. Дневниците бяха генерирани в рамките на един час, приблизително 100 записа в секунда.

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

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

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

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

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

Скорост

Локи "поглъща" трупи по-бързо. Скоростта зависи от много фактори - какви логове, колко сложни ги анализираме, мрежа, диск и т.н. - но определено е по-висока от тази на ELK (в моя тест - около два пъти). Това се обяснява с факта, че Локи поставя много по-малко данни в индекса и съответно отделя по-малко време за индексиране. В този случай ситуацията е обратна със скоростта на търсене: Loki значително се забавя при данни, по-големи от няколко гигабайта, докато при ELK скоростта на търсене не зависи от размера на данните.

Търсене в регистрационния файл

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

интерфейс

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

Локи плюсове и минуси

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

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

Заключение

Loki е 100% интересна технология, която е подходяща за малки и средни проекти, позволявайки ви да решите много проблеми с агрегирането на журнали, търсенето на журнали, наблюдението и анализа на журнали.

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

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

Намира се хранилището с кода, използван в статията тук.

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