Traefik – это обратный прокси с поддержкой Docker, который предоставляет встроенную панель мониторинга.

Проект Traefik предоставляет официальный образ Docker, который поможет быстро запустить Traefik в контейнере Docker.

Но прежде чем запустить контейнер Traefik, нужно создать конфигурационный файл и настроить зашифрованный пароль, чтобы получить доступ к панели мониторинга.
данные действия мы выполнили в предыдущей статье.
Панель инструментов представляет собой отдельное веб-приложение, которое будет работать в контейнере Traefik по порту 8080.

1: Настройка и запуск Traefik

Используйте утилиту htpasswd, чтобы создать зашифрованный пароль. Установите утилиту, которая входит в пакет httpd-tools.

yum install -y httpd-tools

Затем сгенерируйте пароль с помощью htpasswd. Замените secure_password паролем, который вы хотите использовать для пользователя администратора Traefik:

htpasswd -nb admin secure_password
admin:$apr1$kEG/8JKj$yEXj8vKO7HDvkUMI/SbOO.

Этот вывод используется в конфигурационном файле Traefic для настройки базовой аутентификации HTTP в панели мониторинга Traefik. Скопируйте всю строку, чтобы затем вставить ее в файл.

Чтобы настроить сервер Traefik, создайте файл traefik.toml в формате TOML. TOML – это стандартизированный язык конфигурации (аналогичный INI-файлам). Этот файл позволяет настроить сервер Traefik и дополнительные провайдеры. В этом мануале используются три доступных провайдера Traefik: api, docker и acme, который нужен для поддержки TLS сертификатов Let’s Encrypt.

Откройте файл:

vi traefik.toml

Перейдите в режим вставки, нажав i, а затем добавьте две именованные точки входа, http и https, доступ к которым будет у всех бэкендов по умолчанию.

defaultEntryPoints = ["http", "https"]

Точки http и https будут настроены немного позже.

Настройте провайдер api, который дает доступ к интерфейсу панели мониторинга. Здесь нужно использовать строку, сгенерированную командой htpasswd:

...
[entryPoints]
[entryPoints.dashboard]
address = ":8080"
[entryPoints.dashboard.auth]
[entryPoints.dashboard.auth.basic]
users = ["admin:your_encrypted_password"]
[api]
entrypoint="dashboard"

Панель инструментов представляет собой отдельное веб-приложение, которое будет работать в контейнере Traefik по порту 8080.

Раздел entrypoints.dashboard настраивает подключение с провайдером api.

Раздел entrypoints.dashboard.auth.basic настраивает базовую аутентификацию HTTP для дашборда.

Вставьте вместо your_encrypted_password строку, сгенерированную утилитой htpasswd. Вы можете указать несколько пар учетных данных, разделив их запятыми.

Итак, мы определили первую точку входа, entryPoint, но для стандартного взаимодействия HTTP и HTTPS нужны другие точки.

Раздел entryPoints настраивает адрес, который будут слушать Traefik и контейнеры. Добавьте в файл строки:

...
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
...

Точка входа http обрабатывает порт 80, а точка входа https использует порт 443 для поддержки TLS/SSL. Весь трафик, поступающий по порту 80, будет автоматически перенаправлен в точку входа https, чтобы все запросы обслуживались только по защищенным соединениям.

Затем добавьте следующий раздел, чтобы настроить сертификат Let’s Encrypt для Traefik.

...
[acme]
email = "your_email@your_domain"
storage = "acme.json"
entryPoint = "https"
onHostRule = true
[acme.httpChallenge]
entryPoint = "http"

Этот раздел называется acme, потому что ACME – это протокол, с помощью которого сервер взаимодействует с Let’s Encrypt для управления сертификатами. Чтобы Traefik создавал сертификаты для хостов, укажите в строке email свой адрес электронной почты. Затем нужно указать, что хранить информацию Let’s Encrypt нужно в файле JSON, acme.json. В строке entryPoint должен быть порт обработки точки входа 443 (в данном случае это точка входа https).

Ключ onHostRule определяет, как Traefik будет генерировать сертификаты. Сертификаты должны появиться сразу, как только будут созданы контейнеры с указанными именами хостов; за это отвечает параметр onHostRule.

В разделе acme.httpChallenge нужно указать, как Let’s Encrypt будет определять, что сертификат должен быть сгенерирован. Мы настроим его для обслуживания файла в рамках задачи через точку входа http.

Теперь добавьте настройки провайдера docker:

...
[docker]
domain = "your_domain"
watch = true
network = "web"

Провайдер Docker включает Traefik в качестве прокси-сервера для контейнеров Docker. Провайдер будет следить (строка watch) за новыми контейнерами в сети, которые мы скоро создадим, и выставлять их как субдомены your_domain.

На этом этапе файл traefik.toml должен выглядеть так:

defaultEntryPoints = ["http", "https"]
[entryPoints]
[entryPoints.dashboard]
address = ":8080"
[entryPoints.dashboard.auth]
[entryPoints.dashboard.auth.basic]
users = ["admin:your_encrypted_password"]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
[api]
entrypoint="dashboard"
[acme]
email = "your_email@your_domain"
storage = "acme.json"
entryPoint = "https"
onHostRule = true
[acme.httpChallenge]
entryPoint = "http"
[docker]
domain = "your_domain"
watch = true
network = "web"

Сохраните и закройте файл.

2: Запуск контейнера Traefik

Создайте сеть Docker для поддержки взаимодействия прокси-сервера и контейнеров. Сеть Docker необходима, так как ее можно использовать для работы с приложениями, запущенными в Docker Compose. Для примера можно назвать такую сеть web.

docker network create web

Когда контейнер Traefik будет запущен, нужно будет добавить его в эту сеть. Позже можно добавить в эту сеть дополнительные контейнеры, чтобы использовать Traefik в качестве прокси-сервера для этих контейнеров.

Затем создайте пустой файл, в котором будет храниться информация о шифровании Let’s Encrypt. Добавьте его в контейнер, чтобы Traefik мог его использовать.

touch acme.json

Затем заблокируйте доступ к файлу, чтобы только пользователь root мог читать и изменять его. Если вы этого не сделаете, Traefik не получится запустить.

chmod 600 acme.json

Когда файл будет передан Docker, права собственности автоматически перейдут пользователю root внутри контейнера.

Создайте контейнер Traefik с помощью команды:

docker run -d
-v /var/run/docker.sock:/var/run/docker.sock
-v $PWD/traefik.toml:/traefik.toml
-v $PWD/acme.json:/acme.json
-p 80:80
-p 443:443
-l traefik.frontend.rule=Host:monitor.your_domain
-l traefik.port=8080
--network web
--name traefik
traefik:1.7.6-alpine

Рассмотрим команду по частям:

• Флаг –d запускает контейнер в фоновом режиме как демон. Затем команда добавляет в контейнер файл docker.sock, благодаря чему процесс Traefik может прослушивать изменения в контейнерах. Также в контейнер можно поместить конфигурационный файл traefik.toml и acme.json.






• После этого порты 80 и 443 хоста Docker подключаются к одному и тому же порту в контейнере Traefik. Теперь Traefik получает все запросы HTTP и HTTPS.






• Затем нужно установить две метки Docker, которые будут направлять трафик на хост monitor.your_domain по порту :8080 внутри контейнера Traefik, открывая дашборд.






• В качестве сети контейнера нужно указать web. Контейнер называется traefik.






• Затем для создания контейнера используется образ traefik:1.7.6-alpine.

ENTRYPOINT образа Docker – это команда, которая запускается всегда, когда контейнер создается из образа. В этом случае команда представляет собой бинарный файл traefik внутри контейнера. Вы можете передать дополнительные аргументы этой команде при запуске контейнера, но все необходимые данные мы уже указали в файле traefik.toml.

После запуска контейнера у вас будет дашборд, с помощью которого можно просмотреть состояние контейнеров. Вы также можете использовать эту панель для визуализации интерфейсов и бэкэндов, которые зарегистрировал Traefik. Откройте панель мониторинга в браузере:

Будет предложено ввести имя пользователя и пароль администратора, и пароль (имя – admin, пароль – строка, которую вы сгенерировали в разделе 1).

После аутентификации на экране появится дашборд.

Пока что в панели еще не так много информации. Оставьте это окно открытым, и вы увидите, что содержимое дашборда изменится, когда вы добавите контейнеры для Traefik.

Теперь у вас есть прокси-сервер Traefik, настроенный для взаимодействия с Docker и готовый управлять другими контейнерами Docker.

3: Добавление контейнеров для Traefik

Контейнер Traefik запущен и готов обслуживать другие контейнеры приложений. Добавьте следующие контейнеры:

1. Блог, запущенный с помощью официального образа WordPress.






2. Сервер управления базами данных на основе официального образа Adminer.

Управлять этими приложениями можно с помощью Docker Compose, используя файл docker-compose.yml:

vi docker-compose.yml

Укажите в файле версии и сеть:

version: "3"
networks:
web:
external: true
internal:
external: false

Версия 3 Docker Compose – это новейшая версия формата файла Compose.

Чтобы сервер Traefik мог опознать приложения, они должны входить в одну сеть. Поскольку используемая сеть создана вручную, нужно указать ее имя (web ) и установить в external значение true. Затем нужно определить другую сеть, чтобы связать контейнеры с контейнером базы данных, который не будет обслуживаться контейнером Traefik. Эта внутренняя сеть будет называться internal.

Затем нужно определить все сервисы по очереди. Начать можно с контейнера blog, который основан на официальном образе WordPress. Добавьте в файл эту конфигурацию:

version: "3"
...
services:
blog:
image: wordpress:4.9.8-apache
environment:
WORDPRESS_DB_PASSWORD:
labels:
- traefik.backend=blog
- traefik.frontend.rule=Host:blog.your_domain
- traefik.docker.network=web
- traefik.port=80
networks:
- internal
- web
depends_on:
- mysql

Параметр environment позволяет указать переменные среды, которые будут установлены внутри контейнера. Если значение WORDPRESS_DB_PASSWORD не установлено, Docker Compose будет извлекать его из оболочки и передавать при создании контейнера. Определить эту переменную среды можно в оболочке перед запуском контейнеров. Таким образом пароли не попадут в конфигурационный файл.

В разделе labels указываются параметры Traefik. Метки Docker сами по себе ничего не делают, но Traefik читает их и понимает, как обращаться с контейнерами. Каждая метка выполняет такие действия:

• traefik.backend определяет имя сервиса бэкенда (который указывает на контейнер blog).






• traefik.frontend.rule=Host:blog.your_domain исследует запрашиваемый хост и, если он совпадает с шаблоном blog.your_domain, перенаправляет трафик в контейнер blog.






• traefik.docker.network=web определяет сеть, в которой Traefik может найти внутренний IP-адрес контейнера. Поскольку Traefik имеет доступ ко всей информации Docker, он может случайно выбрать IP сети internal, если сеть не указана явно.






• traefik.port указывает порт, который Traefik должен использовать для маршрутизации трафика в контейнеры.

При такой конфигурации весь трафик, отправленный на порт 80 хоста Docker, будет перенаправлен в контейнер blog.

Этот контейнер принадлежит двум различным сетям, чтобы Traefik мог найти его через сеть web и связываться с контейнером базы данных через сеть internal.

Параметр depends_on помогает Docker Compose понять, что этот контейнер нужно запускать после запуска его зависимостей. Поскольку для работы WordPress необходима запущенная БД, контейнер mysql запускается раньше, чем контейнер blog.

Теперь настройте сервис MySQL:

services:
...
mysql:
image: mysql:5.7
environment:
MYSQL_ROOT_PASSWORD:
networks:
- internal
labels:
- traefik.enable=false

Для создания этого контейнера используется официальный образ MySQL 5.7. Обратите внимание: параметр environment снова не имеет значения. Для переменных MYSQL_ROOT_PASSWORD и WORDPRESS_DB_PASSWORD необходимо установить одинаковое значение, чтобы контейнер WordPress мог связываться с MySQL. Контейнер mysql не должен взаимодействовать с Traefik или с внешним миром, потому он принадлежит только сети internal. Поскольку Traefik имеет доступ к сокету Docker, процесс по-прежнему будет открывать фронтенд контейнера mysql по умолчанию. Поэтому нужно добавить метку traefik.enable = false, чтобы Traefik не смог сделать этот контейнер доступным.

Теперь нужно добавить параметры контейнера Adminer:

services:
...
adminer:
image: adminer:4.6.3-standalone
labels:
- traefik.backend=adminer
- traefik.frontend.rule=Host:db-admin.your_domain
- traefik.docker.network=web
- traefik.port=8080
networks:
- internal
- web
depends_on:
- mysql

Этот контейнер основан на официальном образе Adminer. Параметры network и depends_on совпадают с этими же параметрами контейнера blog.

Однако поскольку весь трафик порта 80 хоста Docker направляется непосредственно в контейнер blog, нужно настроить контейнер adminer немного иначе, чтобы он получал свой трафик.

Благодаря строке traefik.frontend.rule=Host:db-admin.your_domain сервер Traefik будет проверять запрашиваемый хост. Если он соответствует шаблону db-admin.your_domain, Traefik направит трафик в контейнер adminer.

В результате файл будет выглядеть так:

version: "3"
networks:
web:
external: true
internal:
external: false
services:
blog:
image: wordpress:4.9.8-apache
environment:
WORDPRESS_DB_PASSWORD:
labels:
- traefik.backend=blog
- traefik.frontend.rule=Host:blog.your_domain
- traefik.docker.network=web
- traefik.port=80
networks:
- internal
- web
depends_on:
- mysql
mysql:
image: mysql:5.7
environment:
MYSQL_ROOT_PASSWORD:
networks:
- internal
labels:
- traefik.enable=false
adminer:
image: adminer:4.6.3-standalone
labels:
- traefik.backend=adminer
- traefik.frontend.rule=Host:db-admin.your_domain
- traefik.docker.network=web
- traefik.port=8080
networks:
- internal
- web
depends_on:
- mysql

Сохраните и закройте файл.

Теперь нужно задать значения переменных WORDPRESS_DB_PASSWORD и MYSQL_ROOT_PASSWORD, прежде чем запустить контейнеры.

export WORDPRESS_DB_PASSWORD=secure_database_password
export MYSQL_ROOT_PASSWORD=secure_database_password

Вместо secure_database_password укажите надежный пароль БД. В WORDPRESS_DB_PASSWORD и MYSQL_ROOT_PASSWORD нужно использовать один и тот же пароль.

Теперь запустите контейнеры:

docker-compose up -d

Снова откройте панель Traefik. Вы увидите, что в ней появились новые контейнеры, а также backend и frontend.

Откройте в браузере blog.your_domain (где your_domain – ваш домен). Соединение будет перенаправлено на зашифрованный порт 443. Теперь можно закончить установку WordPress.

После этого откройте в браузере db-admin.your_domain. Контейнер mysql не доступен в интернете, но контейнер adminer имеет доступ к нему через внутреннюю сеть Docker (internal).

На экране появится форма входа Adminer. Используйте имя пользователя root, укажите mysql в поле server, в поле пароля введите значение переменной MYSQL_ROOT_PASSWORD. После этого вы получите доступ к интерфейсу Adminer.

Оба сайта теперь работают. Чтобы получить доступ к дашборду, введите monitor.your_domain.

Заключение

Теперь сервер Traefik проксирует запросы в контейнеры приложений Docker.

Traefik позволяет легко настраивать большое количество сервисов и устраняет необходимость перезапускать контейнер traefik при добавлении новых приложений в контейнер traefik. Traefik незамедлительно получает все сведения об изменениях через файл сокета Docker.

Установка пакетов

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

а) на системах Red Hat:

yum install git wget

б) для систем на основе Debian:

apt-get install git wget

Установка Go

Для компиляции исходника, нам необходимо установить Golang. Для этого переходим на страницу загрузки и копируем ссылку на архив с его последней версией:

* по умолчанию, страница предлагает загрузить Go для нашей операционной системы, поэтому, если мы открыли сайт на компьютере Windows, ниже под кнопкой загрузки выбираем Linux.

Воспользовавшись ссылкой, скачиваем архив на наш сервер:

wget https://golang.org/dl/go1.15.6.linux-amd64.tar.gz

* на момент написания инструкции, последняя версия была 1.15.6.

Распаковываем архив в каталог /usr/local:

tar -v -C /usr/local -xzf go*.tar.gz

Открываем файл:

vi /etc/profile

Добавляем в самый низ строку:

export PATH=$PATH:/usr/local/go/bin

Один раз выполняем данную команду:

export PATH=$PATH:/usr/local/go/bin

Проверяем, что go установлен и готов выполнять команды:

go version

Мы должны увидеть версию скачанного пакета.

Настройка безопасности

1. Брандмауэр

В зависимости от используемого брандмауэра, необходимо выполнить следующие настройки.

а) если используем iptables (по умолчанию, в системах на базе Debian):

iptables -I INPUT 1 -p tcp —dport 3100 -j ACCEPT

* данная команда добавит правило на разрешение порта 3100 (на котором, по умолчанию, запускается Grafana Loki).

Для сохранения правил устанавливаем пакет:

apt-get install iptables-persistent

Сохранение правил теперь можно выполнить командой:

netfilter-persistent save

б) если используем firewalld (по умолчанию, в системах на базе Red Hat):

firewall-cmd —permanent —add-port=3100/tcp

firewall-cmd —reload

* данная команда добавит правило на разрешение порта 3100 (на котором, по умолчанию, запускается Grafana Loki).

2. SELinux

Как правило, в системах на базе Red Hat активирована дополнительная система безопасности. В нашей инструкции мы ее отключаем командами:

setenforce 0

sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config

* первая команда вводится до разового отключения SELinux. Вторая не дает ему запуститься после перезагрузки.

Установка

Установка Grafana Loki сводится к загрузке готового бинарника или исходника с последующей компиляцией. Также мы настроим юнит в systemd для работы приложения в качестве сервиса.

Копирование бинарника и конфигурационного файла

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

cd /usr/src/

Загружаем исходные файлы проекта:

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

Переходим в каталог loki:

cd loki/

Запускаем компиляцию бинарника:

go build ./cmd/loki

В текущем каталоге появится файл loki — перенесем его в каталог /usr/local/bin:

mv loki /usr/local/bin/

Создадим каталог:

mkdir /etc/loki

… и перенесем в него конфигурационный файл:

mv cmd/loki/loki-local-config.yaml /etc/loki/

В конфиге, который идет в исходнике в качестве рабочего каталога для Grafana Loki используется /tmp — мы это исправим двумя командами:

sed -i ‘s//tmp/wal//opt/loki/wal/g’ /etc/loki/loki-local-config.yaml

* первой командой мы меняем настройку dir для wal (журнала предзаписи). 

sed -i ‘s//tmp/loki//opt/loki/g’ /etc/loki/loki-local-config.yaml

* в данном примере мы заменили путь для storage_config, working_directory и ruler storage на /opt/loki.

Создаем каталог:

mkdir /opt/loki

Выполним первый тестовый запуск сервиса:

/usr/local/bin/loki -config.file=/etc/loki/loki-local-config.yaml

Открываем браузер и переходим по адресу http://192.168.0.15:3100/metrics, где 192.168.0.15 — IP-адрес нашего сервера Grafana Loki. Мы должны увидеть страницу с метриками:

Значит наш сервис запустился и нормально работает. Можно прервать его работу на сервере комбинацией клавиш Ctrl + С и продолжать настройку.

Автозапуск

Чтобы сервис мог автоматически запускаться при старте системы, добавим его в systemd.

Для начала, создадим пользователя, под которым будет работать сервис:

useradd —no-create-home —shell /bin/false loki

* данной командой мы создадим пользователя loki. Ему нельзя будет входить в систему в качестве интерактивного пользователя, также для него не будет создана домашняя директория.

Делаем владельцем loki бинарник для запуска сервиса:

chown loki:loki /usr/local/bin/loki

Задаем владельца для рабочих каталогов Loki:

chown -R loki:loki /etc/loki

chown -R loki:loki /opt/loki

Создаем юнит в systemd:

vi /etc/systemd/system/loki.service

[Unit]

Description=Grafana Loki Service

After=network.target



[Service]

User=loki

Group=loki

Type=simple

ExecStart=/usr/local/bin/loki -config.file=/etc/loki/loki-local-config.yaml

ExecReload=/bin/kill -HUP $MAINPID

Restart=on-failure



[Install]

WantedBy=multi-user.target

Перечитываем конфигурацию systemd:

systemctl daemon-reload

Теперь можно разрешить и стартовать наш сервис:

systemctl enable loki —now

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

systemctl status loki

Установка серверной части завершена.

Отправка логов на сервер

В нашем примере мы передадим логи веб-сервера NGINX в нашу Grafana Loki. Для этого переходим на сервер с NGINX и выполним следующие действия.

Установка Promtail

Promtail — агент, который читает и отправляет логи на сервер. Его установка во многом напоминает установку сервера — получаем бинарник и добавляем его в автозагрузку. В нашем примере мы загрузим уже скомпилированный файл для запуска.

Для начала, установим следующие пакеты:

yum install unzip wget

* unzip нужен для распаковки архива с бинарником; wget — для скачивания архива.

Загружаем последнюю версию promtail для Linux:

wget https://github.com/grafana/loki/releases/latest/download/promtail-linux-amd64.zip

* в нашем примере загружается бинарник на систему 64-бит. На странице https://github.com/grafana/loki/releases можно скачать файлы для установки под Linux и Windows.

Распаковываем скачанный архив:

unzip promtail-linux-amd64.zip

Переносим бинарник в каталог /usr/local/bin:

mv promtail-linux-amd64 /usr/local/bin/promtail

* обратите внимание, что мы его сразу переименовали в promtail.

Создаем каталог для конфигурационных файлов promtail:

mkdir /etc/promtail

Создаем конфигурационный файл:

vi /etc/promtail/promtail.yaml

server:

  http_listen_port: 9080

  grpc_listen_port: 0



positions:

  filename: /tmp/positions.yaml



clients:

  - url: http://192.168.0.15:3100/loki/api/v1/push

* где 9080 — номер порта, на котором будет слушать promtail; 192.168.0.15 — IP-адрес нашего сервера Loki, куда нужно отправлять данные.

Создаем юнит в systemd для promtail:

vi /etc/systemd/system/promtail.service

[Unit]

Description=Promtail Service

After=network.target



[Service]

Type=simple

ExecStart=/usr/local/bin/promtail -config.file=/etc/promtail/promtail.yaml

ExecReload=/bin/kill -HUP $MAINPID

Restart=on-failure



[Install]

WantedBy=multi-user.target

Перечитываем конфигурацию systemd:

systemctl daemon-reload

Разрешаем запуск сервиса promtail и стартуем его:

systemctl enable promtail —now

Проверяем статус:

systemctl status promtail

На клиенте в настройки брандмауэра добавляем правило на разрешение порта 9080.

а) если используем iptables (Debian, Ubuntu):

iptables -I INPUT 1 -p tcp —dport 9080 -j ACCEPT

apt-get install iptables-persistent

netfilter-persistent save

б) если используем firewalld (CentOS, Red Hat):

firewall-cmd —permanent —add-port=9080/tcp

firewall-cmd —reload

После установки promtail открываем браузер и переходим на страницу http://192.168.0.25:9080/targets, где 192.168.0.25 — IP-адрес клиентского компьютера с NGINX. Мы должны увидеть страницу:

Promtail работает. Можно приступать к сбору логов.

Настройка сбора логов

Открываем конфигурационный файл promtail:

vi /etc/promtail/promtail.yaml

...



scrape_configs:

- job_name: nginx

  static_configs:

  - targets:

      - localhost

    labels:

      job: nginxlogs

      __path__: /var/log/nginx/*log

* где:

• job_name — имя задания для чтения лога.






• targets — компьютер, на котором читаем лог.






• job — метка для имени задания. Важный параметр для выборки данных.






• __path__ — путь до файлов с логами.

Перезапускаем сервис promtail:

systemctl restart promtail

Снова заходим по адресу http://192.168.0.25:9080/targets — мы должны увидеть настроенное нами задание:

Сбор логов настроен.

Настройка Grafana

Переходим к серверу с Grafana. Он может быть установлен на отдельном сервере или на том же сервере с Loki.

Заходим в веб-интерфейс и переходим в Configuration — Data Sources:

Добавляем новый источник, кликая по Add data source:

Среди списка возможных источников выбираем Loki:

В настройках задаем имя и указываем IP-адрес сервера Loki:

* в нашем примере задается имя Loki и подключение к серверу 192.168.0.15.

Нажимаем на Save & Test:

Если мы увидели сообщение «Data source connected and labels found.»:значит подключение выполнено и можно двигаться дальше.

Переходим в раздел Create — Dashboard:

Кликаем по кнопке Add new panel:

В открывшемся окне выбираем в качестве источника данных Loki, затем кликаем по Log labels — выбираем job и nginxlogs:

Мы увидим Unable to graph data (так как логи представляют из себя данные, на основе которых нельзя постоить график) — кликаем по Switch to table view:

Мы должны увидеть строки из логов:

Логи NGINX отображаются в Grafana.

Парсинг лога

Мы увидели логи в графане, но они представленны в неудобном для отбора и фильрации виде. Попробуем это исправить с помощью парсинга логов на стороне promtail.

Открываем файл для редактирования:

vi /etc/promtail/promtail.yaml

Дополним нашу задачу для сбора логов NGINX:

...



scrape_configs:

- job_name: nginx

  static_configs:

  - targets:

      - localhost

    labels:

      job: nginxlogs

      __path__: /var/log/nginx/*log

  pipeline_stages:

    - match:

        selector: '{job="nginxlogs"}'

        stages:

        - regex:

            expression: '^(?P<remote_addr>[w.]+) - (?P<remote_user>[^ ]*) [(?P<time_local>.*)] "(?P<method>[^ ]*) (?P<request>[^ ]*) (?P<protocol>[^ ]*)" (?P<status>[d]+) (?P<body_bytes_sent>[d]+) "(?P<http_referer>[^"]*)" "(?P<http_user_agent>[^"]*)"?'

        - labels:

            remote_addr:

            remote_user:

            time_local:

            method:

            request:

            protocol:

            status:

            body_bytes_sent:

            http_referer:

            http_user_agent:

* обратите внимание, что к имеющейся настройки мы добавили pipeline_stages:

• selector — тег для отбора логов, которые нужно парсить.






• expression — регулярное выражение для парсинга логов. 






• labels — список тегов, которые мы будем передавать в loki. Обратите внимание, что названия данных тегов соответствую названиям, которые мы задали в expression.

Перезапускаем сервис для promtail:

systemctl restart promtail

Идем в Grafana — в Log labels мы должны увидеть новые критерии для фильтра по тегам:

Пробуем добавить, например, фильтр по статусу ответа веб-сервера:

Источник: https://sidmid.ru/grafana-loki-2/

Регистрация на хостинге

Для работы с хостинг-провайдером нам заранее понадобятся авторизационные данные и идентификаторы ресурсов. Их мы будем прописывать в сценариях terraform.

Нам нужно зарегистрироваться на сервисе Yandex.Cloud (в нашем примере, мы будем работать, именно, с ним). После этого, нам нужно получить:

1. OAuth-токен. Используется в процедуре аутентификации для получения IAM-токена и нужен нам для прохождения авторизации при подключении terraform. Выдается на 1 год. Получить можно, отправив запрос со страницы документации Яндекс.

2. Идентификатор облака. После регистрации на хостинге мы заходим в контроль-панель. Мы должны увидеть наши ресурсы, в частности, облако:

А справа от него будет идентификатор.

3. Идентификатор каталога. На той же странице контроль панели, ниже облака мы увидим каталог:

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

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

Установка Terraform

Terraform является клиентом и необходимо выполнить установку на компьютер, с которого планируется управление инфраструктурой. Актуальная инструкция по развертыванию представлена на официальном сайте. На текущий момент клиент может быть установлен из репозитория, с использованием бинарника, собран из исходников, а также с помощью choco на Windows или brew на Mac OS. В нашем примере будут рассмотрены установка на Ubuntu и Rocky Linux из репозитория, а также загрузка бинарника.

Ubuntu (Debian)

Обновляем список пакетов:

apt update

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

apt install gnupg software-properties-common curl

* где:

• gnupg — программа для шифровки и дешифровки цифровых подписей. Нужна для работы с репозиториями.






• software-properties-common — утилита для работы с репозиториями.






• curl — отправка GET, POST и других запросов.

Установим в систему ключ для репозитория:

curl -fsSL https://apt.releases.hashicorp.com/gpg | apt-key add —

Добавляем репозиторий:

apt-add-repository «deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main»

Обновляем список пакетов, чтобы загрузить списки с нового репозитория:

apt update

Можно устанавливать terraform:

apt install terraform

Rocky Linux

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

yum install yum-utils

Добавляем репозиторий:

yum-config-manager —add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

Устанавливаем terraform:

yum install terraform

Скачиваем бинарник

Суть данного метода — скачать бинарный файл и перенести его в каталог /usr/local/bin.

Таким же образом устанавливаем terraform на Windows.

Для начала нам понадобятся утилиты unzip и wget. Устанавливаются они по-разному, в зависимости от дистрибутива Linux.

а) Ubuntu / Debian:

apt install unzip wget

б) Rocky Linux:

yum install unzip wget

Переходим к загрузке бинарного файла. Посмотреть ссылку на него можно на странице официального сайта:

Воспользуемся ссылкой, чтобы скачать архив:

wget https://releases.hashicorp.com/terraform/1.1.7/terraform_1.1.7_linux_amd64.zip

* в нашем примере будет загружена версия 1.1.7.

Распакуем архив командой:

unzip terraform_*_linux_amd64.zip

Перенесем распакованный бинарник в каталог:

mv terraform /usr/local/bin/

После установки

Убедимся, что terraform работает. Для этого вводим команду:

terraform -version

Мы должны получить что-то на подобие:

Terraform v1.1.7
on linux_amd64

Также рекомендуется установить автоподстановки:

terraform -install-autocomplete

Это позволит нам завершать команды terraform с помощью клавиши Tab.

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

mkdir -p /opt/terraform/yandex

* в моем примере я решил работать в каталоге /opt/terraform/yandex.

Перейдем в созданный каталог:

cd /opt/terraform/yandex

Мы готовы приступить непосредственно к работе с terraform.

Установка провайдера

Чтобы terraform мог корректно взаимодействовать с инфраструктурой провайдера, необходимо использовать набор инструкций, которые будет использовать наша утилита. В терминологии terraform это называется провайдер.

На сайте Hashicorp можно найти все поддерживаемые провайдеры. Как говорилось выше, мы будем работать с Yandex.Cloud. Рассмотрим подробнее установку провайдера для работы с ним.

В нашем рабочем каталоге создаем первый файл:

vi main.tf

terraform {

  required_version = "= 1.1.7"



  required_providers {

    yandex = {

      source  = "yandex-cloud/yandex"

      version = "= 0.73"

    }

  }

}



provider "yandex" {

  token     = "<OAuth>"

  cloud_id  = "<идентификатор облака>"

  folder_id = "<идентификатор каталога>"

  zone      = "<зона доступности по умолчанию>"

}

* где:

• terraform required_version — версия клиента terraform, для которого должен запускаться сценарий. Параметр не обязательный, но является правилом хорошего тона и может помочь избежать некоторых ошибок, которые возникнут из-за несовместимости при работе в команде.






• required_providers version — версия провайдера. Мы можем указать, как в данном примере, необходимость использовать конкретную версию, а можно с помощью знака >= или <= указать не выше или не ниже определенной.






• token — OAuth-токен для прохождения авторизации. Был нами получен после регистрации на хостинге






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






• folder_id — идентификатор каталога, который также был получен в начале инструкции.






• zone — ресурсы, которые хранятся на мощностях Яндекс разделены по зонам. Каждая зона — это определенная географическая локация центра обработки данных. Список доступных зон можно посмотреть на странице Зоны доступности.

Теперь выполним команду:

terraform init

Система загрузит нужные файлы и установит провайдер:

Initializing the backend...



Initializing provider plugins...

- Finding latest version of yandex-cloud/yandex...

- Installing yandex-cloud/yandex v0.73.0...

- Installed yandex-cloud/yandex v0.73.0 (self-signed, key ID E40F590B50BB8E40)

...

Terraform has been successfully initialized!

...

Мы готовы двигаться дальше.

Работа с ресурсами

Мы рассмотрим небольшие примеры по созданию, редактированию и удалению ресурсов. В большей степени мы будем работать с виртуальными машинами. Большую часть информации по написанию сценариев можно найти на официальном сайте хостинга или самого terraform.

Создание ресурсов

В нашем рабочем каталоге создадим новый файл:

vi infrastructure1.tf

Напишем минимально необходимый сценарий для создания виртуальной машины:

data "yandex_compute_image" "ubuntu_image" {

  family = "ubuntu-2004-lts"

}



resource "yandex_compute_instance" "vm-test1" {

  name = "test1"



  resources {

    cores  = 2

    memory = 2

  }



  boot_disk {

    initialize_params {

      image_id = data.yandex_compute_image.ubuntu_image.id

    }

  }



  network_interface {

    subnet_id = yandex_vpc_subnet.subnet_terraform.id

    nat       = true

  }



  metadata = {

    user-data = "${file("./meta.yml")}"

  }



}



resource "yandex_vpc_network" "network_terraform" {

  name = "net_terraform"

}



resource "yandex_vpc_subnet" "subnet_terraform" {

  name           = "sub_terraform"

  zone           = "ru-central1-a"

  network_id     = yandex_vpc_network.network_terraform.id

  v4_cidr_blocks = ["192.168.15.0/24"]

}

* где:

• data — позволяет запрашивать данные. В данном примере мы обращаемся к ресурсу yandex_compute_image с целью поиска идентификатора образа, с которого должна загрузиться наша машина.

  • yandex_compute_image — ресурс образа. Его название определено провайдером.

  
  
  
  

  • ubuntu_image — произвольное название ресурса. Его мы определили сами и будем использовать в нашем сценарии.

  
  
  
  

  • ubuntu-2004-lts — в нашем примере мы запрашиваем данные ресурса, который ищем по family с названием ubuntu-2004-lts. Данное название можно посмотреть в контроль панели хостинга — нужно выбрать образ и кликнуть по нему. Откроется страница с дополнительной информацией. В данном случае ubuntu-2004-lts соответствуем Ubuntu 20.04 LTS.






• resource — позволяет создавать различные ресурсы.

  • yandex_compute_instance — ресурс виртуальной машины. Его название определено провайдером.

  
  
  
  

  • vm-test1 — наше название ресурса для виртуальной машины.

  
  
  
  

  • yandex_vpc_network — ресурс сети, определенный провайдером.

  
  
  
  

  • network_terraform — наше название для ресурса сети.

  
  
  
  

  • yandex_vpc_subnet — ресурс подсети, определенный провайдером.

  
  
  
  

  • subnet_terraform — наше название для ресурса подсети.

  
  
  
  

  • metadata — обратите особое внимание на передачу метеданных. В данном примере мы передаем содержимое файла, а сам файл рассмотрим ниже.

** в нашем примере будет создана виртуальная машина с названием test1, 2 CPU, 2 Gb RAM в сети 192.168.15.0/24 на базе Ubuntu 20.04 LTS.
*** обратите внимание, что мы указали идентификатор той подсети для виртуальной машины, которую создали также с помощью нашего сценария terraform.

Создаем файл с метеданными:

meta.yml

#cloud-config

users:

  - name: test

    groups: sudo

    shell: /bin/bash

    sudo: ['ALL=(ALL) NOPASSWD:ALL']

    ssh-authorized-keys:

      - ssh-rsa AAAAB3Nza..................UXFDCb/ujrK4KbpCyvk=

* в данном файле мы опишем пользователя, под которым мы сможем подключиться к нашему серверу по SSH:

• #cloud-config — как выяснилось, этот комментарий обязательный.






• name — имя пользователя, который будет создан на виртуальной машине.






• groups — в какую группу добавить пользователя.






• shell — оболочка shell по умолчанию.






• sudo — правило повышения привилений.






• ssh-authorized-keys — список ключей, которые будут добавлены в authorized_keys.

Попробуем испытать наш сценарий. Сначала вводим:

terraform plan

Если мы не ошиблись, утилита покажет, что terraform сделает в нашей облачной инфраструктуре. Очень важно внимательно просматривать изменения.

После того, как мы убедимся в корректности действий, применяем настройку:

terraform apply

Мы еще раз увидим, что будет выполнено, а также получим запрос на подтверждение действий — вводим yes:

Enter a value: yes

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

Редактирование данных

Если необходимо внести изменения в нашу инфраструктуру, то достаточно просто открыть наш файл со сценарием:

vi infrastructure1.tf

Внести нужные изменения, например:

  ...

  resources {

    cores  = 4

    memory = 4

  }

  ...

* в нашем конкретном случае, мы увеличили количество процессоров и объем памяти для созданной виртуальной машины.

Однако, некоторые изменения требуют остановки виртуальной машины. В этом случае мы получим ошибку при попытке применить новые настройки с текстом:

Error: Changing the `secondary_disk`, `resources`, `platform_id`, `network_acceleration_type` or `network_interfaces` on an instance requires stopping it. To acknowledge this action, please set allow_stopping_for_update = true in your config file.

Мы должны явно разрешить для конкретных ресурсов выполнение остановки их работы для внесения изменений. В нашем файле для конкретного ресурса добавим:

...

resource "yandex_compute_instance" "vm-test1" {

  name = "test1"

  allow_stopping_for_update = true



...

* для нашей машины test1 мы указали опцию allow_stopping_for_update, которая говорит о том, что работу ресурса можно останавливать для внесения изменений.

Строим план:

terraform plan

Мы должны увидеть, что будет изменено в нашей инфраструктуре. В моем случае:

      ~ resources {

          ~ cores         = 2 -> 4

          ~ memory        = 2 -> 4

            # (2 unchanged attributes hidden)

        }

Применяем настройки:

terraform apply

Проверяем через контроль-панель, что изменения вступили в силу.

Удаление ресурсов

Для удаления ресурса можно использовать разные приемы.

1. Например, можно указать count = 0:

resource "yandex_compute_instance" "vm-test1" {

  count = 0

  ...

2. Можно закомментировать или удалить строки ресурса из файла tf.

3. Если мы хотим оставить содержимое файлов нетронутым, но при этом удалить все ресурсы, вводим:

terraform destroy

Утилита пройдет по всем файлам tf в директории, найдет ресурсы и выполнит их удаление.

Файл state

Очень важно уметь работать с файлом состояния terraform, а также понять, что это. Данный файл появляется после первого применения сценария в том же рабочем каталоге:

ls

terraform.tfstate

В нем содержатся все изменения, которые происходили с применением terraform. Без него последний не будет знать, что уже было сделано — на практике это приведет к дублированию инфраструктуры, то есть, если мы создали сервер, потеряли файл состояния и снова запустили terraform, он создаст еще один сервер. Для больших инфраструктур с большой историей все намного критичнее.

И так, файл состояния важен с точки зрения понимания инфраструктуры самим terraform. Также у него есть еще одна функция — блокировка параллельных выполнений. Это важно для работы в командах, где одновременные действия могут привести к неожиданным последствиям. Чтобы этого не произошло, terraform создает блокировку, которая запрещает выполнения, если уже идет процесс применения плана.

Из вышесказанного делаем выводы:

• Файлы состояния нужно бэкапить.






• Они должны находиться в надежном месте.






• У всех инженеров, которые работают с инфраструктурой должен быть доступ к файлу состояния. Они не должны его копировать на свои компьютеры и использовать индивидуально.

Рассмотрим возможность хранения данного файла состояния на облачном хранилище Яндекс.

Сначала мы должны создать хранилище. Это можно сделать через веб-интерфейс, но мы это сделаем в terraform.

Но сначала мы сделаем файл:

vi variables.tf

variable "yandex_folder_id" {

  type        = string

  default     = "<идентификатор каталога>"

}

* где yandex_folder_id — название для нашей переменной; <идентификатор каталога> — тот идентификатор, который мы указали в файле main под аргументом folder_id.

Теперь откроем файл main:

vi main.tf

И отредактируем значение folder_id на:

  ...

  folder_id = var.yandex_folder_id

  ...

* в данном примере мы теперь задаем folder_id не явно, а через созданную переменную.

Теперь создадим файл:

vi yandex_storage_bucket.tf

resource "yandex_iam_service_account" "sa" {

  folder_id = var.yandex_folder_id

  name      = "sa-test"

}



resource "yandex_resourcemanager_folder_iam_member" "sa-editor" {

  folder_id = var.yandex_folder_id

  role      = "storage.editor"

  member    = "serviceAccount:${yandex_iam_service_account.sa.id}"

}



resource "yandex_iam_service_account_static_access_key" "sa-static-key" {

  service_account_id = yandex_iam_service_account.sa.id

  description        = "Static access key for object storage"

}



resource "yandex_storage_bucket" "state" {

  bucket     = "tf-state-bucket-test"

  access_key = yandex_iam_service_account_static_access_key.sa-static-key.access_key

  secret_key = yandex_iam_service_account_static_access_key.sa-static-key.secret_key

}

* рассмотрим файл немного подробнее:

• yandex_iam_service_account — создание ресурса для учетной записи. В нашем примере она будет иметь название sa-testи входить в системный каталог yandex_folder_id (переменная, которую мы создали ранее).






• yandex_resourcemanager_folder_iam_member — создание роли. Она будет иметь доступ для редактирования хранилищ. В состав роли войдет созданная запись sa (с именем sa-test).






• yandex_iam_service_account_static_access_key — создаем ключ доступа для нашей сервисной учетной записи.






• yandex_storage_bucket — создаем хранилище с названием tf-state-bucket-test.

Создаем еще один файл:

vi outputs.tf

output "access_key" {

  value = yandex_iam_service_account_static_access_key.sa-static-key.access_key

  sensitive = true

}

output "secret_key" {

  value = yandex_iam_service_account_static_access_key.sa-static-key.secret_key

  sensitive = true

}

* это делается для получения значений аргументов access_key и secret_key и сохранения данных значений в файле состояния. Если access_key можно посмотреть в панели Яндекса, то secret_key мы увидеть не можем.

Строим план и применяем настройки:

terraform plan

terraform apply

Заходим в контроль-панель Яндекса и видим, что у нас создалось хранилище. Его мы будем использовать для хранения файлов состояний terraform.

Открываем наш файл main:

vi main.tf

Добавляем:

terraform {

  ...



  backend "s3" {

    endpoint   = "storage.yandexcloud.net"

    bucket     = "tf-state-bucket-test"

    region     = "ru-central1-a"

    key        = "terraform/infrastructure1/terraform.tfstate"

    access_key = "<access_key>"

    secret_key = "<secret_key >"



    skip_region_validation      = true

    skip_credentials_validation = true

  }

}

* в раздел terraform мы добавили инструкцию для хранения файла state. В нашем примере он будет размещен на бакете tf-state-bucket-test по пути terraform/infrastructure1/terraform.tfstate.
** особое внимание обратите на access_key и secret_key. В разделе terraform мы не можем указать переменные, как это делали при создании хранилища. Сами значения можно найти в нашем локальном файле state.

Используем команду:,

terraform init

Система снова инициализирует состояние текущего каталога и создаст файл state на удаленном хранилище. Чтобы убедиться, можно зайти в контроль панель, найти наше хранилище, а в нем — файл terraform/infrastructure1/terraform.tfstate.

Реальный пример

Мы развернем 2 веб-сервера и поместим их за Network load balancer.

Для этого мы создадим новый рабочий каталог:

mkdir -p /opt/terraform/yandex-network-load balancer

И перейдем в него:

cd /opt/terraform/yandex-network-load balancer

Подразумевается, что все инфраструктура создается с нуля, поэтому нужно либо удалить предыдущие наработки, либо создать новый сервисный аккаунт для storage.

Мы создадим 5 файлов:

1. main.tf — в нем мы опишем инструкции для init, а именно требования к версии клиента terraform, провайдера.






2. web-servers.tf — сценарий для создания 2-х веб-серверов.






3. network-load-balancer.tf — создание Network Load Balancer.






4. variables.tf — описание переменных.






5. outputs.tf — вывод значений после отработки terraform на экран и в файл состояния.

1. Создаем файл main.tf:

vi main.tf

terraform {

  required_version = "= 1.1.7"



  required_providers {

    yandex = {

      source  = "yandex-cloud/yandex"

      version = "= 0.73"

    }

  }

}

provider "yandex" {

  token     = "<OAuth>"

  cloud_id  = "<идентификатор облака>"

  folder_id = "<идентификатор каталога>"

  zone      = "<зона доступности по умолчанию>"

}

* это стандартный вариант файла main.tf, который мы разбирали в начале.

2. web-servers.tf:

vi web-servers.tf

data "yandex_compute_image" "lamp" {

  family = "lamp"

}



data "yandex_compute_image" "lemp" {

  family = "lemp"

}



resource "yandex_compute_instance" "vm-test1" {

  name                      = "vm-test1"

  allow_stopping_for_update = true



  resources {

    cores  = 2

    memory = 2

  }



  boot_disk {

    initialize_params {

      image_id = data.yandex_compute_image.lamp.id

    }

  }



  network_interface {

    subnet_id = yandex_vpc_subnet.subnet_terraform.id

    nat       = true

  }



}



resource "yandex_compute_instance" "vm-test2" {

  name                      = "vm-test2"

  allow_stopping_for_update = true



  resources {

    cores  = 2

    memory = 2

  }



  boot_disk {

    initialize_params {

      image_id = data.yandex_compute_image.lemp.id

    }

  }



  network_interface {

    subnet_id = yandex_vpc_subnet.subnet_terraform.id

    nat       = true

  }



}



resource "yandex_vpc_network" "network_terraform" {

  name = "network_terraform"

}



resource "yandex_vpc_subnet" "subnet_terraform" {

  name           = "subnet_terraform"

  zone           = "ru-central1-a"

  network_id     = yandex_vpc_network.network_terraform.id

  v4_cidr_blocks = ["192.168.15.0/24"]

}

* в данном примере мы создадим 2 виртуальные машины — одну с образом lamp (Apache), вторую на lemp (NGINX).

3. network-load-balancer.tf:

vi network-load-balancer.tf

resource "yandex_lb_network_load_balancer" "lb-test" {

  name = "lb-test"



  listener {

    name = "listener-web-servers"

    port = 80

    external_address_spec {

      ip_version = "ipv4"

    }

  }



  attached_target_group {

    target_group_id = yandex_lb_target_group.web-servers.id



    healthcheck {

      name = "http"

      http_options {

        port = 80

        path = "/"

      }

    }

  }

}



resource "yandex_lb_target_group" "web-servers" {

  name = "web-servers-target-group"



  target {

    subnet_id = yandex_vpc_subnet.subnet_terraform.id

    address   = yandex_compute_instance.vm-test1.network_interface.0.ip_address

  }



  target {

    subnet_id = yandex_vpc_subnet.subnet_terraform.id

    address   = yandex_compute_instance.vm-test2.network_interface.0.ip_address

  }

}

* в данном сценарии мы:

• создаем target_group из 2-х наших веб-серверов.






• создаем балансировщик lb-test.






• привязываем к балансировщику target_group.

4. variables.tf:

vi variables.tf

variable "yandex_folder_id" {

  type        = string

  default     = "<folder_id>"

}

* создадим переменную с folder_id, в котором мы должны работать. Выше мы уже делали такую переменную.

5. outputs.tf:

vi outputs.tf

output "lb_ip_address" {

  value = yandex_lb_network_load_balancer.lb-test.*

}

* на самом деле, это не обязательно — информацию о созданном балансировщике можно посмотреть в контроль панели, но для примера мы решили это рассмотреть.

Готово. После применения данного сценария мы получим то, что хотели — две виртуальные машины + балансировщик сети, который будет распределять запросы между данными серверами.

Источник: https://sidmid.ru/работать-с-terraform-в-yandex-облаке/

Задача – добавить дашборд для отображения различной статистики с бекенда.

Ниже описывается процесс создания дашборды, рассматриваются примеры запросов из Grafana к Prometheus для получения данных, настройки различных типов панелей, примеры метрик, которые можно использовать.

Для примеров запросов использовалась в основном борда Node Exporter Full 0.16 для метрик EC2, и борда AWS ELB Application Load Balancer для ALB.

Добавлять будем:

• вверху – статусы хоста:

  • часы (время с момента получения последней метрики)

  
  
  
  

  • CPU usage %

  
  
  
  

  • Load Average %

  
  
  
  

  • memory usage %

  
  
  
  

  • root, /data disks % usage






• статусы сервисов:

  • nginx

  
  
  
  

  • php-fpm

  
  
  
  

  • rabbitmq status

  
  
  
  

  • memcached status

  
  
  
  

  • redis status

  
  
  
  

  • RDS статус






• статистика EC2 (node_exporter):

  • CPU

    • CPU System/User/IOwait/Idle

  
  
  
  

  • Memory:

    • RAM total

    
    
    
    

    • RAM used

    
    
    
    

    • RAM free

  
  
  
  

  • Disk

    • IO time

  
  
  
  

  • Processes

    • Blocked I/O

    
    
    
    

    • Running






• статистика Load Balancer

  • RequestCount / Latency

    • TargetResponseTime_Average

    
    
    
    

    • ActiveConnectionCount_Average

  
  
  
  

  • HTTPCode

    • HTTPCode_Target_2XX_Count_Average

    
    
    
    

    • HTTPCode_Target_3XX_Count_Average

    
    
    
    

    • HTTPCode_Target_4XX_Count_Average

    
    
    
    

    • HTTPCode_Target_5XX_Count_Average

Настройки dashboard

Переходим в Settings, задаём имя дашборды:

Переменные

Документация – тут>>> и тут>>>.

У нас есть два бекеда – Dev и Production.

Соответственно – в дашборде хочется выводить статистику и того, и другого. Для этого – добавим переменную, с помощью которой сможем переключаться между ними.

Переходим в Variables:

• в Name задаём имя, которое будет использоваться в запросах






• Type – оставляем Query






• Label – имя, как оно будет отображаться в дашборде для выбора






• Data source – Prometheus






• Refresh – при загрузке дашборда






• Query – собственно, сам запрос, который вернёт нам значения, и из которого будем получать список окружений
  в данном случае Prometheus-сервер, который запущен на EC2, добавляет external_label в виде env=mobilebackend-dev, его и используем
  для получения значений – используем метрику node_boot_time_seconds, фильтруем вывод по метке job="node-exporter"
  запрос получается:
  label_values(node_boot_time_seconds{job="node-exporter"}, env)

Сохраняем – Add внизу.

Статусы хоста

Первым добавим блок, в котором убдут выводить % использования CPU, Load Avareage, память и диски.

CPU Busy

node_cpu_seconds_total

Прежде, чем заниматься настройкой отображения CPU Busy – давайте вспомним /proc/stats.

Сначала – получим время с момента запуска системы:

root@bm-backed-app-dev:/opt/prometheus-client# cat /proc/uptime

2168671.61 2147672.65

Тут:

• первая колонка – аптйам системы в секундах






• вторая – время в сукундах, проведённое в IDLE

Проверяем:

root@bm-backed-app-dev:/opt/prometheus-client# uptime

14:21:45 up 25 days,  2:37

Считаем – кол-во секунд из /proc/uptime делим на часы и кол-во часов в сутках:

root@bm-backed-app-dev:/opt/prometheus-client# echo 2168671 / 3600 / 24 | bc

25

Хорошо, тут всё сходится.

Теперь считаем stats:

root@bm-backed-app-dev:/opt/prometheus-client# cat /proc/stat

...

cpu0 1435156 1188 466232 213091141 58015 0 29879 134098 0 0

...

btime 1529657067

Тут колонки:

• user: normal processes executing in user mode






• nice: niced processes executing in user mode






• system: processes executing in kernel mode






• idle: twiddling thumbs






• iowait: waiting for I/O to complete






• irq: servicing interrupts






• softirq: servicing softirqs

Время в сотых секунды.

btime – время загрузки системы в секундах с момента January 1, 1970 (UNIX epoch).

Теперь попробуем посчитать:

root@bm-backed-app-dev:/opt/prometheus-client# echo "(1435156+1188+466232+213091141+58015+0+29879+134098) / 100 / 3600 / 24" | bc

24

Выполняем сложение всех счётчиков, делим на 100 – получаем общее кол-во секунд.

Потом, аналогично вычислениям с uptime – получаем кол-во дней, вышло 24 – один день (точнее 4 часа) “потерялся”, но не критично – в целом значения сошлись.

Теперь выведем метрики node_exporter, и сравним их с данными из /proc/stat (на самом деле метрики я вывел немного раньше, поэтому будет разница):

root@bm-backed-app-dev:/opt/prometheus-client# curl -s localhost:9100/metrics | grep node_cpu_seconds_total

HELP node_cpu_seconds_total Seconds the cpus spent in each mode.

TYPE node_cpu_seconds_total counter

node_cpu_seconds_total{cpu="0",mode="idle"} 2.13035164e+06

node_cpu_seconds_total{cpu="0",mode="iowait"} 579.98

node_cpu_seconds_total{cpu="0",mode="irq"} 0

node_cpu_seconds_total{cpu="0",mode="nice"} 11.88

node_cpu_seconds_total{cpu="0",mode="softirq"} 298.71

node_cpu_seconds_total{cpu="0",mode="steal"} 1340.68

node_cpu_seconds_total{cpu="0",mode="system"} 4660.78

node_cpu_seconds_total{cpu="0",mode="user"} 14346.37

И сравниваем с stat:

• user: stat = 14351.56, exporter = 14346.37






• system: stat = 4662.32, exporter = 4660.78

Окей – тут тоже всё более-менее сходится, и значение данных из node_cpu_seconds_total понятно.

Запрос

Теперь рассмотрим запрос, который будем использовать для получения CPU Busy %:

(((count(count(node_cpu_seconds_total{env="$environment"}) by (cpu))) - avg(sum by (mode)(irate(node_cpu_seconds_total{mode='idle',env="$environment"}[5m])))) * 100) / count(count(node_cpu_seconds_total{env="$environment"}) by (cpu))

Тут:

• count – считаем кол-во элементов, полученных из запроса






• avg: общее среднее значение, документация тут>>>






• irate –  считает значение в секунду, основываясь на двух последних данных






• node_cpu_seconds_total – секунды в каждом режиме (system, user, idle etc)






• {env=~"$environment"} – выборка по значению переменной $environment

Подсчёт кол-ва ядер

Кол-во ядер мы получаем запросом ((count(count(node_cpu_seconds_total{env="$environment"}) by (cpu))).

Рассмотрим его детальнее.

Сначала сделаем выборку по node_cpu_seconds_total{env=~"mobilebackend-dev"}:

Так мы получим значения node_cpu_seconds_total по каждому типу – iowait, user, system, nice etc.

В count(node_cpu_seconds_total{env=~"mobilebackend-dev"}) считаем общее кол-во элементов (iowait, user, system, nice etc), хотя оно нам не надо – мы просто используем этот массив для следующего запроса.

А следующий запрос – count(node_cpu_seconds_total{env=~"mobilebackend-dev"}) by (cpu) возвращает нам общее кол-во node_cpu_seconds_total по типам для каждого ядра:

Например для Production это будет выглядеть так:

И в конце-концов добавив ещё один счётчик – count, и превратив запрос в count(count(node_cpu_seconds_total{env=~"mobilebackend-dev"}) by (cpu)) – мы получим кол-во ядер:

Production

Для наглядности – проверяем на серверах:

root@bm-backed-app-dev:/opt/prometheus-client# grep -c ^processor /proc/cpuinfo

1

И прод:

root@mobilebackend-production:/data/projects# grep -c ^processor /proc/cpuinfo

8

Время ядер в idle

По теме – Understanding Machine CPU usage.

Следующая часть запроса – avg(sum by (mode) (irate(node_cpu_seconds_total{mode='idle',env="$environment"}[5m]))).

Сначала выполняем irate(node_cpu_seconds_total{mode='idle',env="mobilebackend-dev"}[5m]):

Так мы получаем среднее значение времени в секундах, которое cpu0 провёл в статусе idle, т.е. бездельничал.

А “завернув” этот запрос в avg(sum by (mode)() – получим среднее значение для всех ядер:

И если для Dev разницы нет, то на Prod с его 8-ю ядрами значение будет более наглядным:

Т.е. вместе все 8 ядер провели 7.95 секунд в режиме idle.

Если принять 8 за 100%, то вычислим %, который ядра провели не в idle за 1 секунду:

>>> (8.0 - 7.95) * 100 / 8.0

0.6249999999999978

0.6% времени проведено в других режимах – system, user etc.

Если бы, к примеру, все ядра вместе провели 8 секунд в idle (т.е. каждое ядро за 1 целую секунду провело 1 целую секунду в idle):

>>> (8.0 - 8.0) * 100 / 8.0

0.0

То нагрузка на ЦПУ была бы 0%.

И наоборот, если бы половина времени, т.е. 4 секунды в общем, были бы потрачены в idle, то результат:

>>> (8.0 - 4.0) * 100 / 8.0

50.0

50% idle, 50% – остальные режимы.

Вообще есть хорошая страничка тут – Как найти процент от числа для тех, кто как я не силён в математике 

Настройка панели

Теперь переходим к панели.

Жмём на зголовок панели – Edit:

В General задаём имя:

В Metrics добавляем наш запрос:

В Options настраиваем вид:

• Gauge – включаем отображение шкалы






• Spark lines – строка “истории”






• Coloring – включаем красивую подсветку по значениям, и в Thresholds задаём значения, при которых цвет будет меняться – на оранжевый при 75%, и на красный – при 90%






• Stat – Current






• Unit – выбираем None > percent 1-100

Получается такое:

Возвращаемся к дашборе, добавляем ещё один елемент – Row:

Задаём имя, меняем размер панельки с CPU Busy:

Load Average

Следующая панелька будет выводить Load Average.

Можно было бы вывести просто значение node_load1{env=~"$environment"} – но на Dev сервере одно ядро, и значение node_load1 == 1 будет являться условными 100% для одного ядра, а на Production с его 8 ядрами node_load1 == 1 будет всего:

>>> 1.0 / 8 * 100

12.5

12.5%

Значит, что бы корректно отрисовывать шкалу – нам потребуется получить значение LA, поделить его на кол-во ядер и умножить на 100 – получим % от “максимального” (в кавычках, потому что LA может быть и выше 1 для 1 ядра или 8 для 8 ядер) значения.

Следовательно – используем такой запрос:

avg(node_load1{env=~"$environment"}) / count(count(node_cpu_seconds_total{env=~"$environment"}) by (cpu)) * 100

Настраиваем шкалу аналогично CPU Busy:

Перетаскиваем её в Row, меняем размер:

Проверим поведение.

Устанавливаем стресс-тест для CPU:

root@bm-backed-app-dev:/opt/prometheus-client# apt install stress

Запускаем его:

root@bm-backed-app-dev:/opt/prometheus-client# stress —cpu 8 —timeout 20

И данные из uptime:

root@bm-backed-app-dev:/opt/prometheus-client# uptime

18:03:18 up 25 days,  6:18,  1 user,  load average: 1.65, 1.13, 0.64

Memory usage

Далее добавим шкалу с отображением занятой памяти.

Проверим free на проде:

root@mobilebackend-production:/data/projects# free -h

total        used        free      shared  buff/cache   available

Mem:            15G        2.8G        7.5G         93M        4.8G         11G

15 ГБ всего, 2.8 занято активными процессами, 4.8 – кеш, свободной памяти 7.5. ОК.

Составим запрос:

((node_memory_MemTotal_bytes{env="$environment"} - node_memory_MemFree_bytes{env="$environment"}) / (node_memory_MemTotal_bytes{env="$environment"} )) * 100

• в (node_memory_MemTotal_bytes{env="$environment"} - node_memory_MemFree_bytes{env="$environment"})  считаем общее кол-во занятой памяти (active + cache), назовём её busy






• и считаем busy / total * 100 – получаем % от свободной памяти

В Options включаем шкалу, настраиваем аналогично примерам выше:

Получается теперь:

Disk usage

В Prometheus выполняем запрос для проверки:

node_filesystem_avail_bytes{env="mobilebackend-dev",fstype="ext4"}

Добавляем панель, добавляем в неё запрос на получение метрик о /rootfs и вычисляем % занятого места:

100 - ((node_filesystem_avail_bytes{env="$environment",mountpoint="/rootfs",fstype="ext4"} * 100) / node_filesystem_size_bytes{env="$environment",mountpoint="/rootfs",fstype="ext4"})

Настраиваем шкалу аналогично предыдущим:

Повторяем для второго диска – /rootfs/data, получаем такую картинку в дашборде:

Текущеее время

Следующим – добавим отображение текущего времени. Во-первых – просто удобно на экране (в комнате висит большой телевизор, на котором выводится борда) видеть текущее время, во-вторых – такая себе проверка на то, что браузер/дашборда не зависли, и обновляются.

Для вывода времени – опять используем Singlestat панели, и функцию timestamp(), которой передадим метрику up (можно любую – нам только требуется получить из метрики время).

Создаём панель, в Metrics указываем:

timestamp(up{instance="localhost:9090",job="prometheus"}) * 1000

В Options в Units выбираем YYYY-MM-DD HH:mm:ss и получаем текущее время (правда дата не выводится, но она и не нужна):

Сортируем по желанию, и получаем первую часть дашборды:

Статусы сервисов

Теперь – добавим простое отображение стаусов Up/Down для сервисов, которые работают на хосте и необходимы для работы приложения.

У нас это:

• nginx






• php-fpm






• memcahed






• redis






• rabbitmq






• AWS RDS






• AWS ALB

Memcahed статус

Начнём с вывода статуса memcahed.

Создаём новую Row, в ней – новую Singlestat панель.

На сервере запущен quay.io/prometheus/memcached-exporter, который среди прочих метрик возвращает memcahed_up:

...

  memcached-exporter:

    image: quay.io/prometheus/memcached-exporter

    network_mode: "host"

...

memcahed на сервере один, потому можем создать простой запрос на получение кол-ва сервисов в up:

memcached_up{env="$environment",instance="localhost:9150",job="memcached-exporter"}

В Value mappings добавляем отображение статуса – Up, если memcahed_up == 1, или DOWN – если ноль:

В Options > Threshold задаём значения 1,1 (меньше одного – сразу красным) и Stat Current, получаем симпатичный статус:

RabbitMQ статус

Запущен https://github.com/kbudde/rabbitmq_exporter.

Создаём пользователя для доступа експортёра:

root@bm-backed-app-dev:/opt/prometheus-client# rabbitmqctl add_user prometheus password

Creating user "prometheus" ...

Добавляем ему тег “мониторинг”:

root@bm-backed-app-dev:/opt/prometheus-client# rabbitmqctl set_user_tags prometheus monitoring

Добавим его в переменные контейнера:

...

  rabbitmq-exporter:

    image: kbudde/rabbitmq-exporter

    network_mode: "host"

    environment:

    - PUBLISH_PORT=9419

    - RABBIT_USER=prometheus

    - RABBIT_PASSWORD=password

...

Перезапускаем сервис:

root@bm-backed-app-dev:/opt/prometheus-client# systemctl restart prometheus-client.service

Проверяем метрики:

root@bm-backed-app-dev:/home/admin# curl -s localhost:9419/metrics | grep -v # | grep _up

rabbitmq_up 1

И добавляем ещё одну Singlestat панель:

PHP-FPM stats

Повторяем для NGINX – для него всё, как в примерах выше, и добавляем ещё один статус – для PHP-FPM.

Единственное отличие тут – это количество.

Если все сервисы запущены по одному на дев/прод сервер, то php-fpm запущено 6 пулов:

root@bm-backed-app-dev:/opt/prometheus-client# ps aux | grep fpm: | grep -v grep | grep -v master | awk '{print $11, $12, $13}' | uniq

php-fpm: pool dev.admin.domain1.com

php-fpm: pool dev.admin.domain2.com

php-fpm: pool dev.domain1.com

php-fpm: pool dev.domain2.com

php-fpm: pool dev.domain3.com

php-fpm: pool dev.admin.domain3.com

Соответственно, php_fpm_up вернёт не 1, а 6 результатов – по 1 на каждый пул.

Учитывая это – формируем запрос в Metrics и используем count():

count(php_fpm_up{env="$environment",instance="localhost:9253",job="php-fpm-exporter"})

В Value mappings в Type вместо Value to text выбираем range to text:

MySQL stats

Т.к. mysql_exporter ещё не запущен – то тут кратенько пример его запуска.

В роли серверов баз данных используется AWS RDS, два мастер-инстанса.

Значит – надо запустить два експортёра, по одному на каждый RDS. В Ansible шаблон Compose файл добавляем их:

...

  mysql_exporter_db1:

    image: prom/mysqld-exporter

    networks:

    - prometheus-client

    ports:

    - 9104:9104

    environment:

    - DATA_SOURCE_NAME={{ mysql_monitoring_db1_user }}:{{ mysql_monitoring_db1_pass }}@({{ mysql_monitoring_db1_host }}:3306)/



  mysql_exporter_db2:

    image: prom/mysqld-exporter

    networks:

    - prometheus-client

    ports:

    - 9105:9104

    environment:

    - DATA_SOURCE_NAME={{ mysql_monitoring_db2_user }}:{{ mysql_monitoring_db2_pass }}@({{ mysql_monitoring_db2_host }}:3306)/

Переменные берутся из Ansible vault с зашифрованными паролями.

Добавляем джобы в конфиг Прометеус сервера:

...

  - job_name: 'mysql_exporter_db1'

    static_configs:

      - targets:

        - 'localhost:9104'



  - job_name: 'mysql_exporter_db2'

    static_configs:

      - targets:

        - 'localhost:9105'

Деплоим, проверяем DB1:

root@mobilebackend-dev:/opt/prometheus-client# curl -s localhost:9104/metrics | grep -v # | grep -w mysql_up

mysql_up 1

И DB2 (второй екпортёр слушает на порту 9105):

root@mobilebackend-dev:/opt/prometheus-client# curl -s localhost:9105/metrics | grep -v # | grep -w mysql_up

mysql_up 1

Добавляем в Grafana:

mysql_up{env="$environment",instance="localhost:9104",job="mysql_exporter_db1"}

Load Balancer statistics

Добавим ещё несколько графиков – статистику с AWS Application Load Balancer.

Тут надо добавить ещё одну переменную – Load balancer.

К сожалению – cloudformation_exporter не умеет получать теги, поэтому пока придётся использовать просто имена ALB (надо будет посмотреть – может на стороне Prometheus можно будет сделать им relabel).

Добавляем переменную, в запросе указываем:

aws_applicationelb_request_count_sum{job="aws_applicationelb"}

В регулярном выражении – получаем только имя ALB:

/.*app/(.*)"/

Добавляем Row, и в ней – новую панель, но на этот раз типа Graph, в Metrics добавим четыре запроса – на коды 2хх, 3хх, 4хх и 5хх от targets:

aws_applicationelb_httpcode_target_2_xx_count_sum{load_balancer="app/$load_balancer"}

Аналогично можно добавить статистику по времени ответа бекенда.

Добавляем панель Connections/response time – тут будем выводить кол-во активный сессий и время ответа targets.

Добавляем метрики:

aws_applicationelb_target_response_time_sum{load_balancer="app/$load_balancer"}

И активные сессии:

aws_applicationelb_active_connection_count_sum{load_balancer="app/$load_balancer"}

Series overrides

Сейчас на графике отображаются юниты по оси Y слева и внизу.

Но – на этом графике используются метрики двух типов – в одном выводится count – кол-во сессий, а на втором – время ответа от бекенда до ALB в мс.

Хочется, что слева в шкале выводились числа, снизу время получения метрики, а слева – кол-во милисекнуд ответа бекенда.

Для этого – используем ещё одну интересную возможность Grafana – Series overrides. Интересный пост на эту тему есть тут – Advanced Graphing (Part1): Style Overrides.

Переходим в Axes, и включаем отображение шкалы Y справа, в юнитах используем милисекунды:

Далее переходим в Display > Series overrides > Add override, и в Alias or regex указываем алиас метрики, в данном случае мы хотим выводить время, основываясь на данных из `aws_applicationelb_target_response_time_sum`, который в метриках указывается как response_time ms:

Кликаем на “+” – добавляем желамое действие. Тут указываем отображание времени в Y Right и заодно – можно поиграть со цветом: 

И всё вместе теперь выглядит так: 

EC2 statistics

И последним – добавим графики EC2.

В принципе – тут ничего такого, что уже не рассматривалось выше.

CPU

Сначала – статистика использования CPU – System, User, IOwait, idle.

В самом простом виде запросы выглядел бы так:

sum by (instance)(rate(node_cpu_seconds_total{mode="system",env="$environment"}[5m])) * 100

Получаем % от времени, которое CPU проёвл в режиме system/user/idle и т.д.

Но в случае, когда у нас несколько ядер – добавляем вычисление % от кол-ва ядер, аналоигчно тому, как мы это делали для отрисовки шкалы с % LA и CPU Busy:

(avg(sum by (instance)(rate(node_cpu_seconds_total{mode="idle",env="$environment"}[5m])) * 100)) / count(count(node_cpu_seconds_total{env="$environment",instance="localhost:9100"}) by (cpu))

Memory

Добавляем панель RAM.

Выводим память всего:

https://sidmid.ru/wp-content/uploads/2021/12/41-1024x494.png

Использованной памяти:

node_memory_MemTotal_bytes{env="$environment"} - node_memory_MemFree_bytes{env="$environment"} - (node_memory_Cached_bytes{env="$environment"} + node_memory_Buffers_bytes{env="$environment"})

Свободной памяти:

node_memory_MemFree_bytes{env="$environment"}

Диск

Добавим отображение времени на read-write операции:

irate(node_disk_read_time_seconds_total{env="$environment"}[5m])

irate(node_disk_write_time_seconds_total{env="$environment"}[5m])

В Legend используем {{device}}, куда будет подставлено значение из label “device“:

Получается так: 

Процессы

И последняя уже таблица – процессы в системе.

Выводим кол-во процессов в статусе run:

node_procs_running{env="$environment"}

И blocked:

node_procs_blocked{env="$environment"}

И всё вместе теперь выглядит так:

Источник: https://sidmid.ru/grafana-создание-dashboard/