Loki - збирання логів, використовуючи підхід Prometheus

Салют, хабрівчани! Напередодні старту нового набору на курс «DevOps практики та інструменти» підготували вам переклад цікавого матеріалу.

Ця стаття є коротким вступом до Loki. Проект Loki підтримується Grafana та спрямований на централізований збір логів (з серверів чи контейнерів).

Основним джерелом натхнення для Loki був Прометей з ідеєю застосування його підходів до управління логами:

  • використання міток (labels) для зберігання даних
  • споживання малої кількості ресурсів

Ми повернемося до принципів роботи Prometheus і наведемо кілька прикладів його використання в контексті Kubernetes.

Декілька слів про Prometheus

Щоб повністю зрозуміти, як працює Loki, важливо зробити крок назад і трохи згадати Prometheus.

Однією з відмінних характеристик Prometheus є вилучення метрик з точок збору (через експортери) та збереження їх у TSDB (Time Series Data Base, база даних часових рядів) з додаванням метаданих у вигляді міток.

Навіщо це потрібно

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

На жаль, для управління логами досі немає рішення "під ключ", і ви повинні знайти рішення для себе:

  • керований хмарний сервіс для централізації логів (AWS, Azure або Google)
  • сервіс моніторингу «моніторинг як послуга» (наприклад, Datadog)
  • створення сервісу збору логів.

Для третього варіанту я традиційно використовував Elasticsearch, незважаючи на те, що я не завжди був ним задоволений (особливо його важкістю та складністю налаштування).

Loki був спроектований з метою спрощення реалізації відповідно до наступних принципів:

  • бути простим для старту
  • споживати мало ресурсів
  • працювати самостійно без будь-якого спеціального обслуговування
  • служити доповненням до Prometheus для допомоги у розслідуванні багів

Проте це простота досягається з допомогою деяких компромісів. Один із них — не індексувати контент. Тому пошук по тексту не дуже ефективний або багатий і не дозволяє статистику за вмістом тексту. Але оскільки Loki хоче бути еквівалентом grep та доповненням до Prometheus, то це не є недоліком.

Розслідування інцидентів

Щоб краще зрозуміти, чому Loki не потрібна індексація, повернімося до методу розслідування інцидентів, який використовували розробники Loki:

Loki - збирання логів, використовуючи підхід Prometheus
1 Alert → 2 Dashboard → 3 Adhoc Query → 4 Log Aggregation → 5 Distributed Tracing → 6 Fix!
(1 Попередження → 2 Дашборд → 3 Adhoc Query → 4 Агрегація логів → 5 Розподілене трасування → 6 Виправляємо!)

Ідея полягає в тому, що ми отримуємо якийсь алерт (Slack Notification, 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
Принципи архітектури

Веб-клієнт запускає програми на сервері, 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: like Prometheus, but for logs.
loki/loki-stack 0.19.1 v0.4.0 Loki: like Prometheus, but for logs.
loki/fluent-bit 0.0.2  v0.0.1 Uses fluent-bit Loki go plugin for...
loki/promtail   0.13.1 v0.4.0 Responsible for gathering logs and...

Ці пакети мають такі функції:

  • пакет loki/loki відповідає лише серверу Loki
  • пакет loki/fluent-bit дозволяє розгортати DaemonSet, використовуючи fluent-bin для збору логів замість 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

Під час запуску цієї команди ви повинні отримати наступний висновок:

LAST DEPLOYED: Tue Nov 19 15:56:54 2019
NAMESPACE: monitoring
STATUS: DEPLOYED
RESOURCES:
==> v1/ClusterRole
NAME AGE
loki-promtail-clusterrole 189d
…
NOTES:
The Loki stack has been deployed to your cluster. Loki can now be added as a datasource in Grafana.
See <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> for more details.

Подивившись стан подів у просторі імен “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

Щоб під Kubernetes підключитися до Grafana, необхідно відкрити тунель до його поду. Нижче наведена команда для відкриття порту 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