Как стать автором
Обновить

Prometheus + Loki + Grafana: отслеживаем состояния k8s и запущенных в нём приложении

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров14K

Введение

Мониторинг состояния серверов и приложении является одной из основных задач DevOps-инженера. Логирование помогает обнаружить проблемы, возникающие в запущенных сервисах, а также понять что на самом деле случилось в случае возникновения проблем. Методы и инструменты для мониторинга выбираются исходя из сервера, на котором разворачиваются приложения. В этой статье я бы хотел описать процесс развертвывания системы мониторинга и логирования в Kubernetes, начиная с установки кубера на свой сервер и заканчивая импортом готового дашборда.

Что и где будем отслеживать

Не важно где и как вы развернули свой K8s кластер - PaaS решение от облачного провайдера, на ВМ или даже на своём собственном ПК. Для статьи я решил развернуть кубер на своем ноутбуке. Для этого я воспользуюсь k3s - "мини" kubernetes. Установить k3s легче простого - он состоит из одного файла размером 70 мегабайт.

Перед началом

Возможно, что Loki является не самым идеальным инструментом для сбора логов. Тут я имею ввиду ELK стек (Elasticsearch+Kibana+Logstash). Дело в том, что один только Elasticsearch у меня потреблял по 8Гб оперативной памяти, что является очень высоким значением. Помимо этого, были некоторые проблемы с установкой Docker образа Elasticsearch, связанного с моей локацией. Loki, скорее всего, менее гибок, чем стек ELK, но является оптимальным решением, если у вас ограниченный бюджет.
Для дальнейшей работы нам понадобятся следующие инструменты:

  • kubectl

  • helm

Установка k3s

Если у вас уже развернут Kubernetes, то вы можете смело пропустить этот шаг. И так, начнем! Для начала установим исполняемый файл и сразу же запустим его:

$ curl -sfL https://get.k3s.io | sh -s -
[INFO]  Finding release for channel stable
[INFO]  Using v1.27.6+k3s1 as release
...
[INFO]  Installing k3s to /usr/local/bin/k3s
...
[INFO]  systemd: Starting k3s

Проверим, что k3s запущен:

$ sudo systemctl status k3s
● k3s.service - Lightweight Kubernetes
     Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2023-10-08 16:04:22 MSK; 3min 26s ago

Получим список всех узлов:

$ sudo k3s kubectl get nodes
NAME                               STATUS   ROLES                  AGE     VERSION
azamat-lenovo-ideapad-s145-15iil   Ready    control-plane,master   4m32s   v1.27.6+k3s1

k3s разворачивает на текущем устройстве узел, который одновременно является и главным, и рабочим. В случае необходимости вы можете добавить дополнительные рабочие узлы. Нам хватит одного.

Развертывание необходимых компонентов

Установим следующие компоненты:

  • Prometheus - система мониторинга, в нашем случае используемый в качестве источника данных для Grafana для отслеживания состояния k8s кластера.

  • Grafana Loki - система для сбора, хранения и анализа логов. Также как и Prometheus, используется как источник данных для Grafana.

  • Grafana - система визуализации данных. С помощью графаны можно получать различные данные в удобном виде.

Все три системы можно установить с помощью одного Helm чарта. Helm позаботиться о том, чтобы развернуть все нужные компоненты и избавит вас от лишних хлопот по развертыванию всего по отдельности.

Добавим репозитории чартов grafana:

$ helm repo add grafana https://grafana.github.io/helm-charts
"grafana" has been added to your repositories
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "grafana" chart repository
Update Complete. ⎈Happy Helming!⎈

Установим чарт loki-stack. С помощью этого чарта вы можете развернуть всё что вам необходимо при работе с Grafana. Создадим файл values.yaml, где укажем Helm установить помимо Loki и Promtail также Grafana и Prometheus:

prometheus:
  enabled: true
  isDefault: false
  url: http://{{ include "prometheus.fullname" .}}:{{ .Values.prometheus.server.service.servicePort }}{{ .Values.prometheus.server.prefixURL }}
  datasource:
    jsonData: "{}"

loki:
  enabled: true
  isDefault: true
  url: http://{{(include "loki.serviceName" .)}}:{{ .Values.loki.service.port }}
  readinessProbe:
    httpGet:
      path: /ready
      port: http-metrics
    initialDelaySeconds: 45
  livenessProbe:
    httpGet:
      path: /ready
      port: http-metrics
    initialDelaySeconds: 45
  datasource:
    jsonData: "{}"
    uid: ""

promtail:
  enabled: true
  config:
    logLevel: info
    serverPort: 3101
    clients:
      - url: http://{{ .Release.Name }}:3100/loki/api/v1/push

grafana:
  enabled: true 
  sidecar:
    datasources:
      label: ""
      labelValue: ""
      enabled: true
      maxLines: 1000
  image:
    tag: 10.0.2

Создадим отдельный namespace для всех ресурсов, касающихся мониторинга и установим чарт, указав файл values.yaml:

$ kubectl create namespace monitoring
$ helm install -n monitoring --values values.yaml loki-stack grafana/loki-stack

Убедимся, что все нужные Deployment были успешно развернуты:

$ kubectl -n monitoring get deploy
NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
loki-stack-kube-state-metrics        1/1     1            1           21m
loki-stack-grafana                   1/1     1            1           21m
loki-stack-prometheus-pushgateway    1/1     1            1           21m
loki-stack-prometheus-alertmanager   1/1     1            1           21m
loki-stack-prometheus-server         1/1     1            1           21m

Подключение источников данных (Data source)

Мы всё развернули, но теперь нам нужно зайти в Grafana. Но как? Помимо подов, Helm также создал ClusterIP сервисы:

kubectl -n monitoring get svc | grep grafana
loki-stack-grafana                    ClusterIP   10.43.184.63    <none>        80/TCP     81m

Если вы работаете в команде, то наилучшим решением будет создание балансировщика нагрузки с внутренним IP адресом с доступом только через VPN (открывать публично Grafana плохая идея). Но для нашей статьи создавать балансировщик нагрузки будет излишним, ведь можно использовать Port Forwarding, с помощью которого можно открыть доступ к сервису или поду. Для этого необходимо указать название ресурса, а также порты: порт для доступа по localhost и порт сервиса. Сервис loki-stack-grafana запущен на 80 порту. Откроем его на порту 8080:

$ kubectl -n monitoring port-forward svc/loki-stack-grafana 8080:80
Forwarding from 127.0.0.1:8080 -> 3000
Forwarding from [::1]:8080 -> 3000
Handling connection for 8080

Перейдем по адресу http://localhost:8080 и попадем на страницу логина

Юзернейм и пароль для входа хранятся в секрете в формате base64:

$ kubectl -n monitoring get secret | grep grafana
loki-stack-grafana                 Opaque               3      3h

$ kubectl -n monitoring get secret/loki-stack-grafana -o custom-columns="VALUE":.data.admin-user --no-headers | base64 --decode  
admin

$ kubectl -n monitoring get secret/loki-stack-grafana -o custom-columns="VALUE":.data.admin-password --no-headers | base64 --decode
nijST2z6eKWhhtPibUJvLWQrAgGjmTkrDNBWigud

Введём полученные значения и успешно залогинимся. Нажмем на три полоски слева вверху и перейдем в раздел Administration (Data sources)

Перейдя в данный раздел, можно увидеть список всех источников данных. Как видно из снимка экрана, Loki и Prometheus уже подключены.

Просмотр метрик

Prometheus

Теперь рассмотрим некоторые метрики. Перейдем в раздел Explore

Тут можно обнаружить много разных форм и кнопок. Разберем основные:

  1. Выбор источника данных. В нашем случае выборка между Loki или Prometheus

  2. Метрика и её метки. Метрика это параметр какого-то ресурса, тогда как метки это фильтры, для которых отображать значение метрики. Помимо выбора метрик и меток через форму, есть возможность написания запроса через код (справа вместо Builder выбрать Code). Для этого используется отдельный язык запросов PromQL Также можно применять различные функции, нажав на Operations, такие как тригонометрические, агрегационные, временные и другие.

  3. Легенда. Если на графике будет статистика о нескольких ресурсах, то вместо всех меток ресурса будет отображаться определенное значение.

  4. Окно с данными. Тут появится график после нажатия Run query (6)

  5. Временной промежуток. Можно задать в какой период времени просмотреть информацию

  6. Запуск.

Чтобы лучше понять как использовать вкладку Explore, давайте попробуем узнать потребления оперативной памяти Deployment-ами в пространстве имён monitoring. Для этого выберем источник данных Prometheus (1), выберем метрику container_memory_usage_bytes для просмотра потребление оперативной памяти контейнерами и назначим метку namespace=monitoring (2). Воспользуемся PromQL, чтобы перевести байты в мегабайты (разделить на 1048576). В легенде укажем значение {{container}} (3), выберем временный диапазон "Last 5 minutes" (5) и запустим запрос (6):

Как видим на графике (5), Prometheus потребляет больше всего оперативной памяти. Давайте внимательно изучим окно с графиком. Вы можете менять вид отображения (линий / бары / точки). Помимо этого, вы можете нажать на значение из легенды, например на loki, и затем на графике выделить нужный временный диапазон:

Таким образом, вы можете в удобном для вас формате следить за состоянием приложении, а также гибко настраивать метрики и метки.

Loki

Теперь давайте узнаем как можно просматривать логи контейнеров. Перейдем снова в Explore, но изменим источник данных на Loki

В случае с Loki, у нас нет инпута для метрик, только метки. Это связано с тем, что Loki, в отличие от Prometheus, служит только лишь для сбора логов. Давайте посмотрим логи от самой loki за последние 30 минут, при этом воспользуемся некоторыми возможностями из Operations, а именно парсингом логов в формате logfmt и дальнейшей фильтровкой по уровню логированию:

В окне Logs volume можно увидеть количество поступивших логов в определенное время (определяется исходя из временного диапозона, на фото один бар - одна минута). Пролистаем ниже и заметим окно с самими логами. Тут мы можем удобно настроить их отображение, сортировать по новизне или скачать логи и затем послать их коллеге.

Дашборды

"С одним Explore-ом не уедешь". Explore удобен тем, что можно быстро изучить какую-то метрику, поковыряться в графике и затем в полном счастье закрыть графану. Но если вы планируете просматривать одни и те же графики чаще, чем один раз в жизни, то вам будут полезны дашборды. Это полезно также для коллег, которые не будут тратить своё время на настройку метрик и меток и сразу приступят к просмотру логов.

Вы можете создавать свои собственые дашборды или же импортировать существующий. Разобраться с тем как создать свой дашборд не так сложно, если вы прочитали эту статью и узнали как работать в Explore. Давайте импортируем готовый дашборд с информацией о потреблении ресурсов Kubernetes-ом.

Перейдем во вкладку Dashboards, нажмем на New и выберем Import.

Вы можете импортировать дашборд различными способами: загрузить JSON файл или ввести ID дашборда. Импортируем дашборд "Kubernetes / Views / Namespaces", уже на протяжении полугода я активно его использую для мониторинга кластера в dev и prod средах. Зайдя на сайт с дашбордом, справа вы можете увидеть окно с двумя кнопками.

Скопируем Dashboard ID и вернемся к Grafana. Вставим ID в поле, затем выберем Data source и нажмем Import:

После нажатия на кнопку вас должно перекинуть на импортированный дашборд. Тут вы можете увидеть множество графиков.

Вы можете увидеть общее потребление CPU и оперативной памяти, количество запущенных ресурсов, количество недоступных реплик и прочее. Сверху доступны четыре переменные, через которые можно выбрать источник данных и пространство имён. Вы можете не только просматривать графики, но также и изменять их. Кстати, вы можете даже перейти в Explore!

Выводы

Таким образом, мы при помощи одной команды (спасибо Helm) развернули весь необходимый стек для полноценного мониторинга K8s и сбора логов, рассмотрели возможности вкладки Explore и импортировали готовый дашборд.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Используете ли вы описанные в статье инструменты?
34.38% Да, точно такой же стек!11
25% Для мониторинга Prometheus+Grafana, для логов ELK/smth else8
28.13% Использую для мониторинга кое-что иное9
12.5% Я не DevOps, это не моя головная боль4
Проголосовали 32 пользователя. Воздержались 5 пользователей.
Теги:
Хабы:
Всего голосов 4: ↑3 и ↓1+2
Комментарии9

Публикации

Истории

Работа

Ближайшие события

19 августа – 20 октября
RuCode.Финал. Чемпионат по алгоритмическому программированию и ИИ
МоскваНижний НовгородЕкатеринбургСтавропольНовосибрискКалининградПермьВладивостокЧитаКраснорскТомскИжевскПетрозаводскКазаньКурскТюменьВолгоградУфаМурманскБишкекСочиУльяновскСаратовИркутскДолгопрудныйОнлайн
3 – 18 октября
Kokoc Hackathon 2024
Онлайн
24 – 25 октября
One Day Offer для AQA Engineer и Developers
Онлайн
25 октября
Конференция по росту продуктов EGC’24
МоскваОнлайн
7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань