Loki — събиране на логове, използвайки подхода на Prometheus

Здравейте, хабровци! В навечерието на старта на новия курс „DevOps практики и инструменти“ подготвихме за вас превод на интересен материал.

Тази статия е кратко въведение в Loki. Проектът Loki се поддържа от Grafana и е насочен към централизирането на събиране на логове (от сървъри или контейнери).

Основният източник на вдъхновение за Loki е Prometheus идеята да се приложат неговите подходи за управление на логовете:

  • използване на етикети (labels) за съхранение на данни
  • потребление на малко ресурси

Ще се върнем към принципите на работа на Prometheus и ще приведем няколко примера за неговото използване в контекста на Kubernetes.

Няколко думи за Prometheus

За да разберете напълно как работи Loki, е важно да направите крачка назад и да си припомните Prometheus.

Една от отличителните черти на Prometheus е извличането на метрики от точките за събиране (чрез експортери) и запазването им в TSDB (Time Series Data Base, база данни за времеви редици) с добавяне на метаданни под формата на етикети.

Защо е необходимо

В последно време Prometheus стана де-факто стандарт в света на контейнерите и Kubernetes: инсталацията му е много лесна, а в Kubernetes клъстера вече съществува крайна точка за Prometheus. Prometheus също така може да извлича метрики от приложения, разположени в контейнер, като запазва определени етикети. Затова мониторингът на приложенията е много прост за реализация.

За съжаление, все още няма решение "под ключ" за управление на логовете и вие трябва да намерите решение за себе си:

  • управляем облачен сервиз за централизация на логовете (AWS, Azure или Google)
  • сервиз за мониторинг "мониторинг като услуга" (monitoring as a service) (например, Datadog)
  • създаване на собствен сервис за събиране на логове.

За третия вариант обикновено използвах Elasticsearch, въпреки че не винаги съм бил доволен от него (особено от неговата тежест и сложността на настройването).

Loki е проектиран с цел да опрости реализацията в съответствие с следните принципи:

  • да бъде лесен за стартиране
  • да потребява малко ресурси
  • да работи независимо без каквото и да е специално обслужване
  • да служи като допълнение на Prometheus за помощ при разследването на бъгове

Въпреки това, тази простота се постига за сметка на някои компромиси. Един от тях е, че съдържанието не се индексира. Поради това търсенето по текст не е много ефективно или богато и не позволява да се води статистика за съдържанието на текста. Но тъй като Loki иска да бъде еквивалент на grep и допълнение на Prometheus, това не е недостатък.

Разследване на инциденти

За да разберем по-добре защо на Loki не му е нужна индексация, нека се върнем към метода за разследване на инциденти, който разработчиците на Loki използваха:

Loki — събиране на логове, използвайки подхода на Prometheus
1 Аларма → 2 Табло → 3 Adhoc Запитване → 4 Агрегация на логовете → 5 Разпределено проследяване → 6 Поправка!
(1 Аларма → 2 Табло → 3 Adhoc Запитване → 4 Агрегация на логовете → 5 Разпределено проследяване → 6 Поправяме!)

Идеята е, че получаваме някаква аларма (Slack нотификация, SMS и т.н.) и след това:

  • гледаме таблата на Grafana
  • гледаме метриките на услугите (например, в Prometheus)
  • гледаме записите на логовете (например, в Elasticsearch)
  • може би ще погледнем разпределените трасета (Jaeger, Zipkin и др.)
  • и накрая, поправяме първоначалния проблем.

Тук, в случая на стека Grafana + Prometheus + Elasticsearch + Zipkin, ще се наложи да се използват четири различни инструмента. За да се намали времето, би било добре да имаме възможност да извършваме всички тези стъпки с един инструмент: Grafana. Следва да се отбележи, че този подход за изследване е реализиран в Grafana от версия 6. По този начин, става възможно да се извикват данни от Prometheus директно от Grafana.

Loki — събиране на логове, използвайки подхода на Prometheus
Екранът Explorer е разделен между Prometheus и Loki

На този екран можете да гледате логовете в Loki, свързани с метриките на Prometheus, използвайки концепцията за разделен екран. От версия 6.5, Grafana позволява обработка на идентификатора на трасето (trace id) в записите на логовете на Loki за навигация към вашите любими инструменти за разпределено проследяване (Jaeger).

Локален тест на Loki

Най-лесният начин за локално тестване на Loki е да се използва docker-compose. Файлът docker-compose се намира в хранилището на Loki. Можете да получите хранилището с помощта на следната команда git:

$ git clone https://github.com/grafana/loki.git

След това трябва да преминете в каталога production:

$ cd production

След това можете да получите последната версия на Docker образите:

$ docker-compose pull

Накрая, стекът на Loki се стартира с следната команда:

$ docker-compose up

Архитектура на Loki

Ето малка диаграма с архитектурата на Loki:

Loki — събиране на логове, използвайки подхода на Prometheus
Принципи на архитектура на Loki

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

$ docker ps

В случай на ново инсталиран Docker, командата трябва да върне следния резултат:

IMAGE               PORTS                  NAMES
grafana/promtail:                          production_promtail_1
grafana/grafana: m  0.0.0.0:3000->3000/tcp production_grafana_1
grafana/loki: late  80/tcp,0.0.0.0:3100... production_loki_1

Виждаме следните компоненти:

  • Promtail: агент, отговарящ за централизацията на логовете
  • Grafana: известен инструмент за табла
  • Loki: демон за централизация на данни

В рамките на класическа инфраструктура (например, на базата на виртуални машини), на всяка машина трябва да бъде инсталиран агент Promtail. Grafana и Loki могат да бъдат инсталирани на една машина.

Разгръщане в Kubernetes

Инсталацията на компонентите на Loki в Kubernetes ще изглежда така:

  • daemonSet за разгръщане на агента Promtail на всяка от машините в клъстера от сървъри
  • разгръщане (Deployment) на Loki
  • и накрая - разгръщане на Grafana.

За щастие, Loki е наличен като пакет Helm, което улеснява разгръщането му.

Инсталиране чрез Heml

Heml вече трябва да е инсталиран на вас. Може да се изтегли от GitHub репозитория на проекта. Инсталира се чрез разопаковане на архива, който съответства на вашата архитектура, и добавяне на helm в $PATH.

Забележка: версия 3.0.0 Helm бе издадена наскоро. Поради многобройните промени е препоръчително читателят да изчака малко преди да започне да я използва.

Добавяне на източник за Helm

Първата стъпка е да добавите репозитория “loki” с помощта на следната команда:

$ helm add loki https://grafana.github.io/loki/charts

След това можете да търсите пакети с името “loki”:

$ helm search loki

Резултат:

loki/loki       0.17.2 v0.4.0 Loki: подобно на Prometheus, но за логове.
loki/loki-stack 0.19.1 v0.4.0 Loki: подобно на Prometheus, но за логове.
loki/fluent-bit 0.0.2  v0.0.1 Използва fluent-bit Loki go плъгин за...
loki/promtail   0.13.1 v0.4.0 Отговаря за събирането на логовете и...

Тези пакети имат следните функции:

  • пакет loki/loki съответства само на сървъра Loki
  • пакет loki/fluent-bit позволява ви да разгръщате DaemonSet, използвайки fluent-bit за събиране на логове вместо Promtail
  • пакет loki/promtail съдържа агент за събиране на лог файлове
  • пакет loki/loki-stack, позволява веднага да разгрънете Loki заедно с Promtail.

Инсталиране на Loki

За да разгръщате Loki в Kubernetes, изпълнете следната команда в името на пространството “monitoring”:

$ helm upgrade --install loki loki/loki-stack --namespace monitoring

За да запазите на диск, добавете параметъра --set loki.persistence.enabled = true:

$ helm upgrade --install loki loki/loki-stack 
              --namespace monitoring 
              --set loki.persistence.enabled=true

Забележка: ако искате да разположите Grafana едновременно, добавете параметъра --set grafana.enabled = true

При стартиране на тази команда трябва да получите следния изход:

ПОСЛЕДНО РАЗГОРЕН: Вт Ное 19 15:56:54 2019
НАЗВАНИЕ: наблюдение
СТАТУС: РАЗГОРЕН
РЕСУРСИ:
==> v1/ClusterRole
ИМЕ ВЪЗРАСТ
loki-promtail-clusterrole 189d
…
ЗАБЕЛЕЖКИ:
Стекът Loki е разглобен във вашия кластер. Loki може да бъде добавен като източник на данни в Grafana.
Виж <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> за повече подробности.

Ако погледнем състоянието на подовете в пространството на имената “monitoring”, ще видим, че всичко е разположено:

$ kubectl -n monitoring get pods -l release=loki

Резултат:

NAME                 READY  STATUS   RESTARTS  AGE
loki-0               1/1    Running  0         147m
loki-promtail-9zjvc  1/1    Running  0         3h25m
loki-promtail-f6brf  1/1    Running  0         11h
loki-promtail-hdcj7  1/1    Running  0         3h23m
loki-promtail-jbqhc  1/1    Running  0         11h
loki-promtail-mj642  1/1    Running  0         62m
loki-promtail-nm64g  1/1    Running  0         24m

Всички подове са стартирани. Сега е време да направим няколко теста!

Свързване с Grafana

За да се свържете с Grafana в Kubernetes, трябва да отворите тунел към неговия под. По-долу е командата за отваряне на порт 3000 за пода Grafana:

$ kubectl -n port-forward monitoring svc/loki-grafana 3000:80

Още един важен момент е нуждата от възстановяване на паролата на администратора на Grafana. Паролата се съхранява в секрет loki-grafana в полето .data.admin-user в формат base64.

За да я възстановите, е необходимо да изпълните следната команда:

$ kubectl -n monitoring get secret loki-grafana 
 --template '{{index .data "admin-password" | base64decode}}'; echo

Използвайте тази парола заедно с подразбиращата се администраторска сметка (admin).

Определяне на източника на данни Loki в Grafana

Първо, уверете се, че е създаден източник на данни Loki (Configuration / Datasource).
Ето един пример:

Loki — събиране на логове, използвайки подхода на Prometheus
Примерна конфигурация на източник на данни за Loki

Натискайки на “Test”, можете да проверите връзката с Loki.

Правим заявки към Loki

Сега преминете към Grafana в раздела “Explore”. При получаване на логовете от контейнерите, Loki добавя метаданни от Kubernetes. По този начин става възможно прегледът на логовете на определен контейнер.

Например, за да изберете логовете на контейнера promtail, можете да използвате следната заявка: {container_name = "promtail"}.
Тук също не забравяйте да изберете източника на данни Loki.

Тази заявка ще върне активността на контейнерите в следния вид:

Loki — събиране на логове, използвайки подхода на Prometheus
Резултат от заявката в Grafana

Добавяне на дашборд

Започвайки от Grafana 6.4, можете да поставите информация за логовете директно на дашборда. След това потребителят може бързо да превключва между броя на заявките на сайта си и трасетата на приложението.

По-долу е пример на дашборд, реализиращ това взаимодействие:

Loki — събиране на логове, използвайки подхода на Prometheus
Пример на дашборд с метрики Prometheus и логове Loki

Бъдещето на Loki

Започнах да използвам Loki още през май / юни с версия 0.1. Днес вече е издадена версия 1, и даже 1.1 и 1.2.

Трябва да признаем, че версия 0.1 не беше достатъчно стабилна. Но 0.3 вече показа реални признаци на зрялост, а следващите версии (0.4, след това 1.0) само усилват това впечатление.

След 1.0.0, никой вече не може да има оправдания, за да не използва този невероятен инструмент.

По-нататъшните подобрения трябва да се отнасят не толкова до Loki, а по-скоро до неговата интеграция с отличната Grafana. Всъщност, в Grafana 6.4 вече има добра интеграция с дашбордове.

Grafana 6.5, която беше издадена наскоро, още повече подобрява тази интеграция, автоматично разпознавайки съдържанието на логовете в JSON формат.

По-долу на видеото има малък пример за този механизъм:

Loki — събиране на логове, използвайки подхода на Prometheus
Използване на низове от Loki, показвани в Grafana

Става възможно да се използва едно от полетата в JSON, например, за:

  • връзка към външен инструмент
  • филтриране на съдържанието на логовете

Например, можете да кликнете върху traceId, за да преминете към Zipkin или Jaeger.

Традиционно очакваме вашите коментари и ви каним на отворен уебинар, където ще говорим за развитието на DevOps индустрията през 2019 година и ще обсъдим възможните пътища на развитие за 2020 година.

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

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster