Архив автора: admin

Осваиваем мониторинг с Prometheus. Часть 1. Знакомство и установка

Мониторинг — это сбор метрик и представление этих метрик в удобном виде (таблицы, графики, шкалы, уведомления, отчёты). Концептуально его можно изобразить в таком виде:

Метрики — это абстракция, с которой мы имеем дело, когда говорим о мониторинге. Это какие-то числа, описывающие состояние интересующей нас штуковины. Самый простой и понятный мониторинг следит за ресурсами компьютера: загрузкой процессора, памяти, диска, сети. Аналогично можно следить за чем-то более высокоуровневым, вроде количества посетителей на сайте или среднего времени ответа сервера. Для компьютера это один хрен безликие числа.

Мониторинг — это инструмент анализа того, что происходит/происходило в системе. Следовательно, без понимания смысла собранных данных мониторинг вам не особо поможет. И наоборот: в умелых руках это мощный инструмент.

Чем больше компонентов в вашей системе (микросервисов), чем больше нагрузка на неё, чем дороже время простоя, тем важнее иметь хорошую систему мониторинга.

То, что не метрики — то логи. Их тоже надо собирать и анализировать, но это отдельная история со своими инструментами.

Сейчас модно делать мониторинг на основе Prometheus. Так ли он хорош на самом деле? На мой взгляд это лучшее, что сейчас есть из мониторинга. Оговорюсь сразу для тех, кто хочет с этим поспорить: я понимаю, что разным задачам — разные инструменты и где-то больше подходит старый проверенный Nagios. Но в целом лидирует Prometheus.

Prometheus — это не готовое решение в духе “поставил и работает” (привет, Netdata). Это платформа, набор инструментов, позволяющий сделать себе такой мониторинг, какой надо. Фреймворк, если хотите.

Эта статья про знакомство с Prometheus’ом и установку. Потом будет интереснее — про настройку непосредственно мониторинга.

Архитектура Prometheus

Prometheus состоит из отдельных компонентов, которые общаются друг с другом по http. Всё модно-молодёжно, с веб-интерфейсами и настраивается в yaml-конфигах.

Prometheus server — центральное звено. Здесь хранятся собранные метрики, плюс имеется простенький веб-интерфейс, чтобы на них смотреть (Prometheus web UI).
Агенты, собирающие метрики и предоставляющие их в понятном для Prometheus’а виде. В зависимости от контекста называются экспортерами (exporter) или таргетами (target). Устанавливаются на целевые машины. Типичный представитель — node_exporter — собирает данные о вычислительных ресурсах: загрузку процессора, памяти, диска и т.п. Есть куча других экспортеров. Например, cadvisor собирает данные о контейнерах. Есть экспортеры для Postgres’а, для Nginx’а и т.д. С точки зрения самого Prometheus’а они ничем принципиально не отличаются друг от друга, просто каждый собирает какие-то свои метрики. Можно писать свои экспортеры, если ничего из готового вам не подходит.
Alertmanager — уведомлятор. Это он отправит письмо вам на почту, если что-то сломается. Из коробки умеет в почту, Slack, Hipchat, Pagerduty. Сторонними средствами можно прикрутить Telegram и наверное что-то ещё.
Grafana строго говоря не является частью Prometheus’а, но все её ставят и официальная документация рекомендует поступать именно так. Показывает красивые графики. Кучка графиков, собранных на одном экране, называется дашбордом (dashboard). Типа такого:

Установка

Все компоненты Prometheus’а написаны на Go и представляют собой статически скомпиленные бинари, не требующие никаких зависимостей кроме libc и готовые запускаться на любой платформе, будь то Debian, Arch или Centos. Установить их можно аж тремя способами:

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

Разумеется, у каждого способа есть свои преимущества и недостатки.

Если ставить через пакетный менеджер, то через него же вы будете получать обновления и сможете всё удалить. Однако есть нюанс. У Prometheus’а нет своих собственных репозиториев для популярных дистрибутивов, а официальные репозитории Debian/Ubuntu как всегда отстают от апстрима. Например, сейчас в Debian доступна версия 2.7.1, когда Prometheus уже 2.11.1. Arch Linux — молодец, идёт в ногу со временем.

При установке вручную Prometheus не будет числиться в списках установленного софта и с точки зрения пакетного менеджера его в системе нет. Зато вы сможете обновлять Prometheus отдельно от пакетов. При ручной установке придётся немного побывать в роли установочного скрипта (который есть в пакете), поэтому, если у вас серьёзные намерения — автоматизируйте установку/обновление через какой-нибудь Ansible. Рекомендую взять за основу готовые роли для Prometheus, Alertmanager, Node exporter, Grafana.

Если ставить Prometheus в докере, то всё про мониторинг будет лежать в одном месте. Можно это хозяйство положить под Git и иметь возможность поднять мониторинг в две команды: git clone, docker-compose up. Но надо писать правильный docker-compose.yml, париться при возникновении сетевых проблем… Короче, вы от одних проблем избавляетесь, а взамен получаете другие. В зависимости от того, с какими вам больше нравится возиться, выбирайте тот или иной вариант установки. Вам понадобятся контейнеры prom/prometheus, prom/node_exporter, prom/alertmanager. За основу рекомендую взять docker-compose.yml из репозитория docprom.

В продакшене я бы поднимал мониторинг в докере как минимум в целях безопасности. Свой личный мониторинг я устанавливал по-старинке вручную.

Установка вручную

Расскажу про ручную установку, потому что в основе других способов установки лежат те же действия, только завёрнутые в дополнительную обёртку. Этот способ подойдёт для любых дистрибутивов Linux под управлением systemd (Ubuntu, Debian, Centos, Arch и т.д.)

Установка Prometheus server

Идём на https://github.com/prometheus/prometheus/releases, находим билд под свою платформу (скорее всего это будет linux-amd64). Копипастим ссылку, качаем:

$ wget https://github.com/.../prometheus-2.11.1.linux-amd64.tar.gz
$ tar xf prometheus-*.tar.gz

Раскидываем файлы по ФС, заводим пользователя:

# cd prometheus-*
# cp prometheus promtool /usr/local/bin
# mkdir /etc/prometheus /var/lib/prometheus
# cp prometheus.yml /etc/prometheus
# useradd --no-create-home --home-dir / --shell /bin/false prometheus
# chown -R prometheus:prometheus /var/lib/prometheus

В архиве будут два ненужных каталога: console_libraries/ и consoles/. Их не трогаем.

Создаём systemd-юнит:/etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Restart=on-failure
ExecStart=/usr/local/bin/prometheus 
  --config.file /etc/prometheus/prometheus.yml 
  --storage.tsdb.path /var/lib/prometheus/
ExecReload=/bin/kill -HUP $MAINPID
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=default.target

Запускаем Prometheus server:

# systemctl daemon-reload
# systemctl start prometheus
# systemctl status prometheus

В статусе должно быть написано “active (running)” — значит работает. Теперь можно сходить на http://localhost:9090 и полюбоваться на интерфейс Prometheus’а. Пока что он бесполезен, но уже можно потыкать.

Установка node exporter

Node exporter надо раскатать на всех машинах, которые вы хотите мониторить. Устанавливается он аналогично серверу. Берём последний билд с https://github.com/prometheus/node_exporter/releases.

$ wget https://github.com/.../node_exporter-0.18.1.linux-amd64.tar.gz
$ tar xf node_exporter-*.tar.gz
# cd node_exporter-*
# cp node_exporter /usr/local/bin
# useradd --no-create-home --home-dir / --shell /bin/false node_exporter

/etc/systemd/system/node_exporter.service

[Unit]
Description=Prometheus Node Exporter
After=network.target

[Service]
Type=simple
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter

SyslogIdentifier=node_exporter
Restart=always

PrivateTmp=yes
ProtectHome=yes
NoNewPrivileges=yes

ProtectSystem=strict
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=yes

[Install]
WantedBy=multi-user.target

Важно! Если у вас /home вынесен на отдельный раздел, директиву ProtectHome=yes надо убрать, иначе node exporter будет неправильно показывать оставшееся место на разделе /home.

Запускаем node exporter:

# systemctl daemon-reload
# systemctl start node_exporter
# systemctl status node_exporter

Можно посмотреть как node exporter отдаёт метрики:

$ curl -s http://localhost:9100/metrics
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 7.9825e-05
go_gc_duration_seconds{quantile="0.25"} 7.9825e-05
go_gc_duration_seconds{quantile="0.5"} 7.9825e-05
go_gc_duration_seconds{quantile="0.75"} 7.9825e-05
go_gc_duration_seconds{quantile="1"} 7.9825e-05
go_gc_duration_seconds_sum 7.9825e-05
go_gc_duration_seconds_count 1
...

Пока не пытайтесь что-то понять в выводе. Отдаёт и ладно.

Установка alertmanager

Alertmanager — это про алерты. Первое время алертов у вас не будет, поэтому сейчас его можно не ставить. Но лучше всё-таки поставить, чтобы всё необходимое уже было подготовлено. Идём за дистрибутивом на https://github.com/prometheus/alertmanager/releases.

$ wget https://github.com/.../alertmanager-0.18.0.linux-amd64.tar.gz
$ tar xf alertmanager-*.tar.gz
# cd alertmanager-*
# cp alertmanager /usr/local/bin
# mkdir /etc/alertmanager /var/lib/alertmanager
# cp alertmanager.yml /etc/alertmanager
# useradd --no-create-home --home-dir / --shell /bin/false alertmanager
# chown -R alertmanager:alertmanager /var/lib/alertmanager

/etc/systemd/system/alertmanager.service

[Unit]
Description=Alertmanager for prometheus
After=network.target

[Service]
User=alertmanager
ExecStart=/usr/local/bin/alertmanager 
  --config.file=/etc/alertmanager/alertmanager.yml 
  --storage.path=/var/lib/alertmanager/
ExecReload=/bin/kill -HUP $MAINPID

NoNewPrivileges=true
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Запускаем alertmanager:

# systemctl daemon-reload
# systemctl start alertmanager
# systemctl status alertmanager

Веб-интерфейс alertmanager’а доступен на http://localhost:9093. Пока в нём нет ничего интересного.

Установка Grafana

Если у вас Debian/Ubuntu или Redhat/Centos, лучше установить Grafana из пакета. Ссылочки найдёте в ~~описании под видео~~ на https://grafana.com/grafana/download.

$ wget https://dl.grafana.com/oss/release/grafana_6.3.2_amd64.deb
# dpkg -i grafana_6.3.2_amd64.deb

Запускаем grafana:

# systemctl start grafana
# systemctl status grafana

Prometheus, Node exporter, Alertmanager и Grafana по умолчанию слушают на всех сетевых интерфейсах. При необходимости прикрывайтесь фаерволлом от посторонних глаз.

Первичная настройка

Теперь, когда все компоненты установлены, надо подружить их друг с другом. Сперва минимально настроим Prometheus server:/etc/prometheus/prometheus.yml

global:
  scrape_interval:     15s
  evaluation_interval: 15s

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
       - localhost:9093

scrape_configs:
  - job_name: 'node'
    static_configs:
    - targets:
       - localhost:9100
     # - anotherhost:9100

Пока не буду вдаваться в подробности настройки, этим займёмся в следующих статьях. На текущем этапе надо получить пусть примитивный, но работающий мониторинг. Основное что сейчас стоит знать:

Отступы в yml — два пробела. Всегда и везде.
scrape_interval — с какой периодичностью Prometheus server будет забирать (scrape) метрики с экспортеров.
localhost:9093 и localhost:9100 — адреса alertmanager’а и node exporter’а соответственно. Если у вас другие, замените на правильные. Если у вас node exporter установлен на несколько машин, впишите их все.

Теперь попросим prometheus перечитать конфигурационный файл:

# systemctl reload prometheus

В веб-интерфейсе на странице http://localhost:9090/targets появился первый таргет. Он должен быть в состоянии “UP”.

Поздравляю, мониторинг начал мониторить! Теперь можно пойти на вкладку Graph и запросить какую-нибудь метрику, например node_load1 — это одноминутный load average. Там же можно временной график посмотреть:

В повседневной жизни вы вряд ли будете смотреть графики в этом интерфейсе. Гораздо приятнее смотреть графики в Grafana.

Открываем интерфейс Grafana по адресу http://localhost:3000. Логинимся (admin:admin), при желании меняем пароль. Практически всё в Графане настраивается тут же, через веб-интерфейс. Нажимаем на боковой панели Configuration (шестерёнка) → Preferences:

Идём на вкладку Data Sources, добавляем наш Prometheus:

Теперь добавим готовый дашборд Node exporter full. Это лучший дашборд для старта из всех, что я пересмотрел. Идём Dashboards (квадрат) → Manage → Import.

Вписываем 1860 и убираем курсор из поля ввода, иначе не начнёт импортировать. Дальше указываем data source и жмём import.

Поздравляю, самая скучная часть работы проделана! Теперь вы можете наблюдать за жизнью своих серверов в Графане.

Если у вас серьёзные намерения и вы хотите, чтобы все компоненты автоматически запускались после перезагрузки машины, не забудьте сообщить об этом systemd:

# systemctl enable prometheus
# systemctl enable grafana
# systemctl enable alertmanager
# systemctl enable node_exporter

И это всё?

У нас пока нет алертов, не заведены пользователи в Grafana, мы ничего не понимаем в настройке. Да, наш мониторинг пока очень сырой. Но надо же с чего-то начать! Позже я напишу про настройку, про алерты и многое другое. Всё будет, друзья. Всё будет.

Куда копать дальше?

Официальная документация Prometheus. Да, она не супер-подробная, и лично мне многое было непонятно вначале, но заглянуть стоит.
Блог Robust Perseption, который ведёт Brian Brazil — один из разработчиков Prometheus’а. Статьи короткие и, на мой взгляд, слишком лаконичные. Хочется больше подробностей, больше примеров.
Книга Prometheus up and running за авторством всё того же Brian Brazil. Во многом повторяет статьи блога.

Источник: https://laurvas.ru/prometheus-p1/

2021-08-16T10:23:10

Software

Установка и настройка Grafana

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

Grafana — инструмент с открытым исходным кодом для визуализации данных из различных систем сбора статистики. Используется для представления в графическом виде временных рядов и текстовых данных.

Grafana поддерживает установку на самые популярные операционные системы: Linux (Debian, Ubuntu, CentOS, Fedora, OpenSuse, RedHat), Mac и Windows. Допустимыми базами данных, в которых возможно хранение данных о пользователях и дашбордах, являются SQLite (используется по умолчанию), MySQL и PostgreSQL. В качестве демонстрационных серверов будем использовать «Облачные серверы» с операционными системами CentOS Stream и Ubuntu, на которые установим Grafana с базой данных SQLite.

Перед началом установки Grafana, подготовим серверы. В консоли управления Selectel перейдём в раздел Облачная платформа и нажмём кнопку Создать сервер.

На следующем представлении выберем готовую конфигурацию сервера с 1 vCPU и 1 ГБ RAM с операционной системой CentOS 8 64-bit.

Наш сервер будет иметь 10 ГБ на жестком диске. Для целей демонстрации этого достаточно. Прокручиваем вниз и нажимаем кнопку Создать. Аналогичным образом создадим сервер с Ubuntu 20.04 LTS 64-bit.

После проделанных манипуляций оба сервера появятся в списке доступных. Приступим к установке Grafana.

Установка Grafana на CentOS Stream

Установка Grafana на CentOS Stream выполняется из репозитория разработчиков. Скачать дистрибутив можно также с официального сайта. Создадим новую конфигурацию репозитория:

sudo nano /etc/yum.repos.d/grafana.repo

Впишем в этот файл следующие переменные со значениями:

[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt

Далее установим Grafana:

sudo yum install grafana -y

После установки включаем автозагрузку и запускаем демон Grafana:

sudo systemctl enable grafana-server

sudo systemctl start grafana-server

Установка завершена. Grafana на Ubuntu 20.04 готова к использованию. Проверим текущий статус сервиса:

sudo systemctl status grafana-server

В результате получим вывод:

grafana-server.service - Grafana instance
   Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-01-25 09:48:04 MSK; 5s ago

Установка Grafana на Ubuntu 20.04

На Ubuntu Grafana устанавливается из репозитория производителя. Скачаем GPG-ключ и добавим его в список надежных:

wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -

После этого добавим в систему репозиторий Grafana:

sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"

Далее обновляем кэш APT и установим Grafana:

sudo apt update

sudo apt install grafana

После установки включаем автозагрузку и запускаем демон Grafana:

sudo systemctl enable grafana-server

sudo systemctl start grafana-server

Установка завершена. Grafana на Ubuntu 20.04 готова к использованию. Проверим текущий статус сервиса:

sudo systemctl status grafana-server

В результате получим вывод:

grafana-server.service - Grafana instance
   Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-01-25 09:44:26 MSK; 10s ago

Настройка брандмауэра для доступа к Grafana

По умолчанию Grafana доступна на порту 3000. При использовании firewalld или iptables, необходимо разрешить сетевой доступ к этому порту из внешнего мира.

Набор команд для firewalld (добавление нового правила и перезагрузка сервиса firewalld для применения конфигурации):

firewall-cmd --zone=public --add-port=3000/tcp --permanent

systemctl reload firewalld

Набор команд для iptables:

nano /etc/sysconfig/iptables

Вписываем в раздел OUTPUT ACCEPT следующую строку:

-A INPUT -p tcp -m tcp --dport 3000 -m state --state NEW -j ACCEPT

И перезапускаем iptables:

sudo systemctl restart iptables

После выполнения описанных в этом разделе манипуляций, сетевой экран будет разрешать подключения по порту 3000. В этом можно убедиться, открыв в браузере интерфейс Grafana. Логин и пароль по умолчанию admin.

Если не удается войти в Grafana или вы поменяли пароль и не можете его вспомнить, через CLI административный пароль Web-интерфейса можно сбросить:

grafana-cli admin reset-admin-password --homepath "/usr/share/grafana" новый_пароль

После выполнения команды выше, можно входить с новым паролем.

Источники данных Grafana и установка плагинов

Grafana поддерживает из коробки различные источники данных:

Prometheus,
Graphite,
OpenTSDB,
InfluxDB,
Elasticsearch и другие.

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

Установим этот плагин и добавим его в Grafana.

grafana-cli plugins install alexanderzobnin-zabbix-app

Теперь перезагрузим сервис Grafana:

systemctl restart grafana-server

В интерфейсе Grafana перейдём в Configuration -> Plugins и обнаружим здесь плагин для Zabbix.

Перейдем к настройке плагина и нажмём на кнопку Enable.

С момента включения плагина, в меню Data Sources появится новый источник данных — Zabbix. Нажмём на кнопку Select и настроим источник данных.

В настройках плагина укажем URL-адрес, имя пользователя и пароль для доступа по API к Zabbix.

Нажимаем на кнопку Save & Test и получаем подтверждение корректности настроек.

С этого момента данных из Zabbix могут быть использованы для создания визуализаций.

Создание и настройка панелей и дашбордов

Панели и дашборды — основные сущности представлений внутри Grafana. Каждый дашборд состоит из набора панелей. Для создания дашбордов перейдём в представление Dashboards и нажмём на кнопку New Dashboard.

На следующем шаге будет предложено добавить на дашборд новую панель.

Grafana имеет встроенные панели, которые можно сразу начинать использовать. По умолчанию представлены следующие типы:

Graph — панель с графиками с возможностью комбинировать несколько метрик на одной панели.
Stat (ранее SingleStat) — панель с одиночным графиком и возможностью отображения моментального значения метрики.
Gauge — панель в формате спидометра, есть возможность ограничить верхнее значение на шкале.
Bar Gauge — панель с возможностью отображения нескольких метрик на вертикальной гистограмме.
Table — панель с представлением в виде таблицы, на которой можно отображать значения нескольких метрик.
Text — панель для отображения произвольного текста (подписи).
Heatmap — панель для отображения тепловой карты значений метрик.
Alert list — панель для отображения событий из внешних систем.
Dashboard list — комбинированная панель для отображения дашбордов, добавленных в избранное.
News — панель для отображения новостной ленты из внешних источников.
Zabbix problems — панель для отображения событий из системы мониторинга Zabbix.
Logs — панель для отображения строчек лога, которые собираются одной из внешних систем.

Далее выберем в выпадающем меню источник данных Zabbix и укажем группу, хост, приложение и элемент данных. Если всё выполнено правильно — на графике появятся данные.

Grafana поддерживает различные типы визуализаций:

графические,
табличные,
гистограммы,
тепловые карты,
карты сетевого взаимодействия в Grafana и другие.

При создании новой панели, в правой части экрана в разделе Visualization есть возможность выбрать тип визуализации. Перейдем к созданию SingleStat (отображается как Stat) — панели с комбинацией численного и графического представлений. После ввода специфических данных для Zabbix, нажмём кнопку Apply.

В результате выполненных действий, увидим на дашборде две панели.

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

На изображении ниже показаны настройки дашборда.

Импорт и экспорт дашбордов

В Grafana можно импортировать и экспортировать дашборды. Для импорта нужно перейти в представление Dashboards и нажать кнопку Import.

Для импорта доступны две опции: загрузка произвольного JSON и импорт готовых дашбордов с grafana.com. Во втором случае нужно указывать ID дашборда.

Для экспорта любого дашборда, необходимо нажать на специальную иконку в верхней части экрана и далее нажать Save to file. Дашборд будет сохранен в формате JSON.

Обратный прокси-сервер и SSL

Для настройки SSL в Grafana необходимо использовать обратный прокси-сервер. В этом разделе мы расскажем как настроить такой прокси на базе Nginx. Для целей демонстрации мы зарегистрировали домен grafana.tk, для которого выпустили специальный сертификат Let’s Encrypt.

После создания сервера мы настроили веб-сервер Nginx для работы через SSL. Осталось перенаправить трафик с него на порт 3000, по которому доступна Grafana. Для этого откроем конфигурационный файл веб-сервера.

sudo nano /etc/nginx/sites-available/grafana.tk

В этом файле будем работать с этим блоком конфигурации:

...
        location / {
                try_files $uri $uri/ =404;
        }
...

Заменим его на следующий:

...
    location / {
        proxy_pass http://127.0.0.1:3000;
    }
...

Таким образом мы настроили переадресацию на локальный порт 3000. Теперь можно проверить корректность конфигурации Nginx:

sudo nginx -t

Осталось перезапустить Nginx:

sudo systemctl reload nginx

Теперь наша тестовая Grafana доступна по URL https://grafana.tk. Проверим:

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

Конфигурационный файл Grafana

Для тонкой настройки Grafana, можно использовать конфигурационный файл (по умолчанию /etc/grafana/grafana.ini). Здесь хранятся параметры, которые можно менять при необходимости. Рассмотрим основные блоки этого файла.

[paths]

data

Директория, в которой Grafana хранит базу данных sqlite3 и другие данные. Эта директория обычно задаётся в стартовом скрипте init.d.

logs

Директория, в которой Grafana хранит логи. Эта директория обычно задаётся в стартовом скрипте init.d.

[server]

http_addr

IP-адрес, на котором будет доступен веб-интерфейс Grafana. Если параметр не указан, то интерфейс будет доступен по всем сетевым интерфейсам сервера.

http_port

Порт, на котором будет доступен веб-интерфейс Grafana. По умолчанию номер порта 3000. Если нужно использовать порт 80, можно настроить переадресацию в iptables:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000

Для переадресации можно также использовать веб-сервер Nginx или Apache.

protocol

Протокол, по которому будет доступна Grafana. Варианты http или https.

domain

Может использоваться только вместе с опцией root_url (см. ниже). Важно, если вы используете аутентификацию через GitHub или Google OAuth.

enforce_domain

Переадресация на корректный домен, если заголовок хоста не соответствует домену. По умолчанию в значении false.

root_url

Полный URL-адрес для доступа к Grafana через веб-браузер. Важно, если вы используете аутентификацию через GitHub или Google OAuth.

static_root_path

Путь к директории, в которой находятся файлы HTML, JS и CSS.

cert_file

Директория с файлом сертификата (если доступ к Grafana — https).

cert_key

Директория с файлом ключа (если доступ к Grafana осуществляется по протоколу https).

[database]

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

type

Поддерживаются mysql, postgres или sqlite3 на выбор.

path

Параметр применим только к базе данных sqlite3. Путь к файлу данных.

host

Параметр применим только к MySQL или Postgres. Включает IP-адрес или hostname и номер порта. Например, для MySQL запущенной на одном сервере с Grafana: host = 127.0.0.1:3306

name

Имя базы данных Grafana.

user

Имя пользователя базы данных (не применимо к sqlite3).

password

Пароль пользователя базы данных (не применимо к sqlite3).

ssl_mode

Применимо только к postgres. Доступны опции: disable, require или verify-full.

[security]

admin_user

Имя привилегированного пользователя Grafana. По умолчанию admin.

admin_password

Пароль привилегированного пользователя Grafana. По умолчанию admin.

login_remember_days

Количество дней, в течении которых не требуется повторный ввод логина и пароля.

disable_gravatar

Отключение пользовательской иконки. Устанавливается в true для отключения. По умолчанию имеет значение false.

[users]

allow_sign_up

Устанавливается в false для предотвращения создания новых учетных записей действующими пользователями.

allow_org_create

Устанавливается в false для предотвращения создания новых организаций действующими пользователями. По умолчанию имеет значение true.

auto_assign_org

Устанавливается в true для автоматического добавления новых пользователей в основную организацию (id 1). Когда установлено в false, новые пользователи добавляются в новые организации, которые создаются автоматически.

auto_assign_org_role

Роль новых пользователей будет привязана к основной организации.

[auth.anonymous]

enabled

Устанавливается в true для включения анонимного доступа. По умолчанию находится в значении false

org_name

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

org_role

Указывает роль для анонимных пользователей. По умолчанию Viewer, а другие доступные Editor и Admin.

[auth.basic]

enabled

Когда установлено значение true (по умолчанию) http api будет принимать соединения с флагом basic authentication.

[auth.ldap]

enabled

Устанавливается в true для включения интеграции с LDAP (по умолчанию: false).

config_file

Путь к конфигурационному файлу LDAP (по умолчанию: /etc/grafana/ldap.toml).

[auth.proxy]

Эта функция разрешает аутентифицироваться в обратном прокси.

enabled

По умолчанию установлено в false.

header_name

По умолчанию установлено в X-WEBAUTH-USER.

header_property

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

auto_sign_up

Устанавливается в значение true для включения автоматического входа пользователей, которые отсутствуют в Grafana DB. По умолчанию установлено значение true.

[session]

provider

Валидные значения: memory, file, mysql, postgres. По умолчанию установлено значение file.

provider_config

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

file: путь к файлу с сессиями, например, data/sessions.
mysql: go-sql-driver/mysql dsn config string, например, user:password@tcp(127.0.0.1:3306)/database_name
postgres: ex: user=a password=b host=localhost port=5432 dbname=c sslmode=disable

cookie_name

Имя сессионного cookie в Grafana.

cookie_secure

Устанавливается в true если Grafana находится только за HTTPS-прокси. По умолчанию установлено в значение false.

session_life_time

Как долго длится сессия в секундах. По умолчанию 86400 секунд (24 часа).

[analytics]

reporting_enabled

Когда опция включена, Grafana будет отправлять анонимную статистику на stats.grafana.org. Никакие IP-адреса не записываются. Данные отправляются каждые 24 часа. По умолчанию установлено в true.

google_analytics_ua_id

Если вы хотите отслеживать активности в Grafana при помощи Google analytics, укажите ваш Universal Analytics ID. По умолчанию эта функция отключена.

[dashboards.json]

Если у вас есть система, которая автоматически строит дашборды из JSON-файлов, вы можете включить эту опцию, чтобы новые дашборды были доступны через поиск в Grafana.

enabled

Значение true или false. По умолчанию выключено.

path

Полный путь к директории, содержащей JSON-файлы с дашбордами.

Заключение

Мы рассмотрели подходы к установке, настройке и работе с Grafana. Этот популярный инструмент имеет большое сообщество разработчиков, которые поддерживают проект и разрабатывают новые плагины, дашборды и развивают продукт. У Grafana регулярно выходят обновления и улучшения, поэтому можно без опасений использовать этот инструмент в продакшн средах.

Источник: https://selectel.ru/blog/install-and-setup-grafana/

2021-08-15T21:15:55

Software

Собираем логи с Loki

Мы в Badoo постоянно мониторим свежие технологии и оцениваем, стоит ли использовать их в нашей системе. Одним из таких исследований и хотим поделиться с сообществом. Оно посвящено Loki — системе агрегирования логов.

Loki — это решение для хранения и просмотра логов, также этот стек предоставляет гибкую систему для их анализа и отправки данных в Prometheus. В мае вышло очередное обновление, которое активно продвигают создатели. Нас заинтересовало, что умеет Loki, какие возможности предоставляет и в какой степени может выступать в качестве альтернативы ELK — стека, который мы используем сейчас.

Что такое Loki

Grafana Loki — это набор компонентов для полноценной системы работы с логами. В отличие от других подобных систем Loki основан на идее индексировать только метаданные логов — labels (так же, как и в Prometheus), a сами логи сжимать рядом в отдельные чанки.

Домашняя страница, GitHub

Прежде чем перейти к описанию того, что можно делать при помощи Loki, хочу пояснить, что подразумевается под «идеей индексировать только метаданные». Сравним подход Loki и подход к индексированию в традиционных решениях, таких как Elasticsearch, на примере строки из лога nginx:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&amp;item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

Традиционные системы парсят строку целиком, включая поля с большим количеством уникальных значений user_id и item_id, и сохраняют всё в большие индексы. Преимуществом данного подхода является то, что можно выполнять сложные запросы быстро, так как почти все данные — в индексе. Но за это приходится платить тем, что индекс становится большим, что выливается в требования к памяти. В итоге полнотекстовый индекс логов сопоставим по размеру с самими логами. Для того чтобы по нему быстро искать, индекс должен быть загружен в память. И чем больше логов, тем быстрее индекс увеличивается и тем больше памяти он потребляет.

Подход Loki требует, чтобы из строки были извлечены только необходимые данные, количество значений которых невелико. Таким образом, мы получаем небольшой индекс и можем искать данные, фильтруя их по времени и по проиндексированным полям, а затем сканируя оставшееся регулярными выражениями или поиском подстроки. Процесс кажется не самым быстрым, но Loki разделяет запрос на несколько частей и выполняет их параллельно, обрабатывая большое количество данных за короткое время. Количество шардов и параллельных запросов в них конфигурируется; таким образом, количество данных, которое можно обработать за единицу времени, линейно зависит от количества предоставленных ресурсов.

Этот компромисс между большим быстрым индексом и маленьким индексом с параллельным полным перебором позволяет Loki контролировать стоимость системы. Её можно гибко настраивать и расширять в соответствии с потребностями.

Loki-стек состоит из трёх компонентов: Promtail, Loki, Grafana. Promtail собирает логи, обрабатывает их и отправляет в Loki. Loki их хранит. А Grafana умеет запрашивать данные из Loki и показывать их. Вообще Loki можно использовать не только для хранения логов и поиска по ним. Весь стек даёт большие возможности по обработке и анализу поступающих данных, используя Prometheus way.
Описание процесса установки можно найти здесь.

Поиск по логам

Искать по логам можно в специальном интерфейсе Grafana — Explorer. Для запросов используется язык LogQL, очень похожий на PromQL, использующийся в Prometheus. В принципе, его можно рассматривать как распределённый grep.

Интерфейс поиска выглядит так:

Сам запрос состоит из двух частей: selector и filter. Selector — это поиск по индексированным метаданным (лейблам), которые присвоены логам, а filter — поисковая строка или регэксп, с помощью которого отфильтровываются записи, определённые селектором. В приведенном примере: В фигурных скобках — селектор, все что после — фильтр.

{image_name="nginx.promtail.test"} |= "index"

Из-за принципа работы Loki нельзя делать запросы без селектора, но лейблы можно делать сколь угодно общими.

Селектор — это key-value значения в фигурных скобках. Можно комбинировать селекторы и задавать разные условия поиска, используя операторы =, != или регулярные выражения:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev

Фильтр — это текст или регэксп, который отфильтрует все данные, полученные селектором.

Есть возможность получения ad-hoc-графиков по полученным данным в режиме metrics. Например, можно узнать частоту появления в логах nginx записи, содержащей строку index:

Полное описание возможностей можно найти в документации LogQL.

Парсинг логов

Есть несколько способов собрать логи:

С помощью Promtail, стандартного компонента стека для сбора логов.
Напрямую с докер-контейнера при помощи Loki Docker Logging Driver.
Использовать Fluentd или Fluent Bit, которые умеют отправлять данные в Loki. В отличие от Promtail они имеют готовые парсеры практически для любого вида лога и справляются в том числе с multiline-логами.

Обычно для парсинга используют Promtail. Он делает три вещи:

Находит источники данных.
Прикрепляет к ним лейблы.
Отправляет данные в Loki.

В настоящий момент Promtail может читать логи с локальных файлов и с systemd journal. Он должен быть установлен на каждую машину, с которой собираются логи.

Есть интеграция с Kubernetes: Promtail автоматически через Kubernetes REST API узнаёт состояние кластера и собирает логи с ноды, сервиса или пода, сразу развешивая лейблы на основе метаданных из Kubernetes (имя пода, имя файла и т. д.).

Также можно развешивать лейблы на основе данных из лога при помощи Pipeline. Pipeline Promtail может состоять из четырёх типов стадий. Более подробно — в официальной документации, тут же отмечу некоторые нюансы.

Parsing stages. Это стадия RegEx и JSON. На этом этапе мы извлекаем данные из логов в так называемую extracted map. Извлекать можно из JSON, просто копируя нужные нам поля в extracted map, или через регулярные выражения (RegEx), где в extracted map “мапятся” named groups. Extracted map представляет собой key-value хранилище, где key — имя поля, а value — его значение из логов.
Transform stages. У этой стадии есть две опции: transform, где мы задаем правила трансформации, и source — источник данных для трансформации из extracted map. Если в extracted map такого поля нет, то оно будет создано. Таким образом, можно создавать лейблы, которые не основаны на extracted map. На этом этапе мы можем манипулировать данными в extracted map, используя достаточно мощный Golang Template. Кроме того, надо помнить, что extracted map целиком загружается при парсинге, что даёт возможность, например, проверять значение в ней: “{{if .tag}tag value exists{end}}”. Template поддерживает условия, циклы и некоторые строковые функции, такие как Replace и Trim.
Action stages. На этом этапе можно сделать что-нибудь с извлечённым:
- Создать лейбл из extracted data, который проиндексируется Loki.
- Изменить или установить время события из лога.
- Изменить данные (текст лога), которые уйдут в Loki.
- Создать метрики.
Filtering stages. Стадия match, на которой можно либо отправить в /dev/null записи, которые нам не нужны, либо направить их на дальнейшую обработку.

Покажу на примере обработки обычных nginx-логов, как можно парсить логи при помощи Promtail.

Для теста возьмём в качестве nginx-proxy модифицированный образ nginx jwilder/nginx-proxy:alpine и небольшой демон, который умеет спрашивать сам себя по HTTP. У демона задано несколько эндпоинтов, на которые он может давать ответы разного размера, с разными HTTP-статусами и с разной задержкой.

Собирать логи будем с докер-контейнеров, которые можно найти по пути /var/lib/docker/containers/<container_id>/<container_id>-json.log

В docker-compose.yml настраиваем Promtail и указываем путь до конфига:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

Добавляем в promtail.yml путь до логов (в конфиге есть опция «docker», которая делает то же самое одной строчкой, но это было бы не так наглядно):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

При включении такой конфигурации в Loki будут попадать логи со всех контейнеров. Чтобы этого избежать, меняем настройки тестового nginx в docker-compose.yml — добавляем логирование поле tag:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

Правим promtail.yml и настраиваем Pipeline. На вход попадают логи следующего вида:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

Pipeline stage:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Извлекаем из входящего JSON поля stream, attrs, attrs.tag (если они есть) и кладём их в extracted map.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

Если удалось положить поле tag в extracted map, то при помощи регэкспа извлекаем имена образа и контейнера.

 - labels:
     image_name:
     container_name:

Назначаем лейблы. Если в extracted data будут обнаружены ключи image_name и container_name, то их значения будут присвоены соотвестующим лейблам.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

Отбрасываем все логи, у которых не обнаружены установленные labels image_name и container_name.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

Для всех логов, у которых image_name равен nginx.promtail.test, извлекаем из исходного лога поле log и кладём его в extracted map с ключом row.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

Очищаем входную строку регулярными выражениями и вытаскиваем nginx virtual host и строку лога nginx.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

Парсим nginx-лог регулярными выражениями.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

Разбираем request_url. С помощью регэкспа определяем назначение запроса: к статике, к фоткам, к API и устанавливаем в extracted map соответствующий ключ.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

При помощи условных операторов в Template проверяем установленные поля в extracted map и устанавливаем для поля request_type нужные значения: photo, static, API. Назначаем other, если не удалось. Теперь request_type содержит тип запроса.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Устанавливаем лейблы api_request, virtual_host, request_type и статус (HTTP status) на основании того, что удалось положить в extracted map.

       - output:
           source: nginx_log_row

Меняем output. Теперь в Loki уходит очищенный nginx-лог из extracted map.

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

Нужно иметь в виду, что извлечение меток с большим количеством значений (cardinality) может существенно замедлить работу Loki. То есть не стоит помещать в индекс, например, user_id. Подробнее об этом читайте в статье “How labels in Loki can make log queries faster and easier”. Но это не значит, что нельзя искать по user_id без индексов. Нужно использовать фильтры при поиске («грепать» по данным), а индекс здесь выступает как идентификатор потока.

Визуализация логов

Loki может выступать в роли источника данных для графиков Grafana, используя LogQL. Поддерживаются следующие функции:

rate — количество записей в секунду;
count over time — количество записей в заданном диапазоне.

Ещё присутствуют агрегирующие функции Sum, Avg и другие. Можно строить достаточно сложные графики, например график количества HTTP-ошибок:

Стандартный data source Loki несколько урезан по функциональности по сравнению с data source Prometheus (например, нельзя изменить легенду), но Loki можно подключить как источник с типом Prometheus. Я не уверен, что это документированное поведение, но, судя по ответу разработчиков “How to configure Loki as Prometheus datasource? · Issue #1222 · grafana/loki”, например, это вполне законно, и Loki полностью совместим с PromQL.

Добавляем Loki как data source с типом Prometheus и дописываем URL /loki:

И можно делать графики, как в том случае, если бы мы работали с метриками из Prometheus:

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

Метрики

В Loki доступны возможность извлечения числовых метрик из логов и отправка их в Prometheus. Например, в логе nginx присутствует количество байтов на ответ, а также, при определённой модификации стандартного формата лога, и время в секундах, которое потребовалось на ответ. Эти данные можно извлечь и отправить в Prometheus.

Добавляем ещё одну секцию в promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

Опция позволяет определять и обновлять метрики на основе данных из extracted map. Эти метрики не отправляются в Loki — они появляются в Promtail /metrics endpoint. Prometheus должен быть сконфигурирован таким образом, чтобы получить данные, полученные на этой стадии. В приведённом примере для request_type=“api” мы собираем метрику-гистограмму. С этим типом метрик удобно получать перцентили. Для статики и фото мы собираем сумму байтов и количество строк, в которых мы получили байты, чтобы вычислить среднее значение.

Более подробно о метриках читайте здесь.

Открываем порт на Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Убеждаемся, что метрики с префиксом promtail_custom появились:

Настраиваем Prometheus. Добавляем job promtail:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

И рисуем график:

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

Масштабирование

Loki может быть как в одиночном режиме (single binary mode), так и в шардируемом (horizontally-scalable mode). Во втором случае он может сохранять данные в облако, причём чанки и индекс хранятся отдельно. В версии 1.5 реализована возможность хранения в одном месте, но пока не рекомендуется использовать её в продакшене.

Чанки можно хранить в S3-совместимом хранилище, для хранения индексов — использовать горизонтально масштабируемые базы данных: Cassandra, BigTable или DynamoDB. Другие части Loki — Distributors (для записи) и Querier (для запросов) — stateless и также масштабируются горизонтально.

На конференции DevOpsDays Vancouver 2019 один из участников Callum Styan озвучил, что с Loki его проект имеет петабайты логов с индексом меньше 1% от общего размера: “How Loki Correlates Metrics and Logs — And Saves You Money”.

Сравнение Loki и ELK

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

Для тестирования получаемого размера индекса я взял логи с контейнера nginx, для которого настраивался Pipeline, приведённый выше. Файл с логами содержал 406 624 строки суммарным объёмом 109 Мб. Генерировались логи в течение часа, примерно по 100 записей в секунду.

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

При индексации ELK это дало размер индекса 30,3 Мб:

В случае с Loki это дало примерно 128 Кб индекса и примерно 3,8 Мб данных в чанках. Стоит отметить, что лог был искусственно сгенерирован и не отличался большим разнообразием данных. Простой gzip на исходном докеровском JSON-логе с данными давал компрессию 95,4%, а с учётом того, что в сам Loki посылался только очищенный nginx-лог, то сжатие до 4 Мб объяснимо. Суммарное количество уникальных значений для лейблов Loki было 35, что объясняет небольшой размер индекса. Для ELK лог также очищался. Таким образом, Loki сжал исходные данные на 96%, а ELK — на 70%.

Потребление памяти

Если сравнивать весь стек Prometheus и ELK, то Loki «ест» в несколько раз меньше. Понятно, что сервис на Go потребляет меньше, чем сервис на Java, и сравнение размера JVM Heap Elasticsearch и выделенной памяти для Loki некорректно, но тем не менее стоит отметить, что Loki использует гораздо меньше памяти. Его преимущество по CPU не так очевидно, но также присутствует.

Скорость

Loki быстрее «пожирает» логи. Скорость зависит от многих факторов — что за логи, как изощрённо мы их парсим, сеть, диск и т. д. — но она однозначно выше, чем у ELK (в моём тесте — примерно в два раза). Объясняется это тем, что Loki кладёт гораздо меньше данных в индекс и, соответственно, меньше времени тратит на индексирование. Со скоростью поиска при этом ситуация обратная: Loki ощутимо притормаживает на данных размером более нескольких гигабайтов, у ELK же скорость поиска от размера данных не зависит.

Поиск по логам

Loki существенно уступает ELK по возможностям поиска по логам. Grep с регулярными выражениями — это сильная вещь, но он уступает взрослой базе данных. Отсутствие range-запросов, агрегация только по лейблам, невозможность искать без лейблов — всё это ограничивает нас в поисках интересующей информации в Loki. Это не подразумевает, что с помощью Loki ничего нельзя найти, но определяет флоу работы с логами, когда вы сначала находите проблему на графиках Prometheus, а потом по этим лейблам ищете, что случилось в логах.

Интерфейс

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

Плюсы и минусы Loki

Из плюсов можно отметить, что Loki интегрируется с Prometheus, соответственно, метрики и алертинг мы получаем из коробки. Он удобен для сбора логов и их хранения с Kubernetes Pods, так как имеет унаследованный от Prometheus service discovery и автоматически навешивает лейблы.

Из минусов — слабая документация. Некоторые вещи, например особенности и возможности Promtail, я обнаружил только в процессе изучения кода, благо open-source. Ещё один минус — слабые возможности парсинга. Например, Loki не умеет парсить multiline-логи. Также к недостаткам можно отнести то, что Loki — относительно молодая технология (релиз 1.0 был в ноябре 2019 года).

Заключение

Loki — на 100% интересная технология, которая подходит для небольших и средних проектов, позволяя решать множество задач агрегирования логов, поиска по логам, мониторинга и анализа логов.

Мы не используем Loki в Badoo, так как имеем ELK-стек, который нас устраивает и который за много лет оброс различными кастомными решениями. Для нас камнем преткновения является поиск по логам. Имея почти 100 Гб логов в день, нам важно уметь находить всё и чуть-чуть больше и делать это быстро. Для построения графиков и мониторинга мы используем другие решения, которые заточены под наши нужды и интегрированы между собой. У стека Loki есть ощутимые плюсы, но он не даст нам больше, чем у нас есть, и его преимущества точно не перекроют стоимость миграции.

И хотя после исследования стало понятно, что мы Loki использовать не можем, надеемся, что данный пост поможет вам в выборе.

Репозиторий с кодом, использованным в статье, находится тут.

loki-nginx-master

Источник: https://github.com/black-rosary/loki-nginx

2021-08-15T20:59:14

Software

Prometheus: Визуализация произвольных метрик и значений в Grafana через Pushgateway.

1. Введение.

По умолчанию, метрики в Prometheus попадают методом pull — система обращается к агентам (exporter) и забирает данные. Это рекомендованный способ, но мы можем настроить получение метрик методом push с помощью Pushgateway.

Схема работы следующая: метрика отправляется скриптом на сервер с помощью Pushgateway, а Prometheus забирает данные уже с него.

Предполагается, что у нас уже установлен сервер Prometheus.

Ссылка на инструкцию по установке: «Prometheus: Установка и настройка Prometheus Server.»

Установку Pushgateway можно выполнить на тот же сервер, что и Prometheus, либо на выделенный. В этой инструкции установим на тот же и под управлением CentOS 7.

2. Установка Pushgateway.

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

Переходим на официальную страницу загрузки Pushgateway.

Ссылка на официальную страницу: prometheus.io.

Копируем и используем ссылку для скачивания бинарного файла под CentOS 7:

# yum -y install wget tar mc

# wget https://github.com/prometheus/pushgateway/releases/download/v1.4.0/pushgateway-1.4.0.linux-amd64.tar.gz

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

# tar zxvf pushgateway-*.tar.gz

Копируем бинарный файл в каталог /usr/local/bin:

# cp /root/pushgateway-1.4.0.linux-amd64/pushgateway /usr/local/bin/

Создаем пользователя Pushgateway:

# useradd --no-create-home --shell /bin/false pushgateway

Задаем владельца для нашего бинарного файла:

# chown pushgateway:pushgateway /usr/local/bin/pushgateway

Для возможности запуска Pushgateway в качестве сервиса, создаем юнит-файл:

# mcedit /etc/systemd/system/pushgateway.service

И размещаем там строки:

[Unit]
Description=Pushgateway
Wants=network-online.target
After=network.target

[Service]
User=pushgateway
Group=pushgateway
Type=simple
ExecStart=/usr/local/bin/pushgateway 
--web.listen-address=:9091 
--web.telemetry-path=/metrics 
--persistence.file=/tmp/metric.store 
--persistence.interval=5m 
--log.level=info 
--web.enable-admin-api 
--log.format=json

ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

В данном примете мы запустим Pushgateway на порту 9091 c режимом администратора --web.enable-admin-api.

Также мы указали уровень и формат логов — сами логи можно будет увидеть в /var/log/messages в CentOS 7.

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

# systemctl daemon-reload

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

# systemctl enable pushgateway

# systemctl start pushgateway

Проверяем состояние:

# systemctl status pushgateway

Если состояние сервиса не active, следуйте инструкциям на экране и повторите предыдущие действия, чтобы устранить проблему, прежде чем продолжить.

Откроем порт 9091.

Если firewalld:

# firewall-cmd --zone=public --add-port=9091/tcp --permanent
# systemctl reload firewalld

Если iptables:

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

# mcedit /etc/sysconfig/iptables

В разделе ‘OUTPUT ACCEPT‘, добавляем строку:

-A INPUT -p tcp -m tcp --dport 9091 -m state --state NEW -j ACCEPT

Перезапускаем iptables:

# sudo systemctl restart iptables

Проверяем, что метрики отдаются:

# curl 'localhost:9091/metrics'

Открываем браузер и вводим адрес:

# http://<IP-адрес сервера pushgateway>:9091

Вы должны увидеть меню портала:

Pushgateway готов к работе.

Переходим к настройке Prometheus.

3. Настройка Prometheus.

Необходимо добавить задание в Prometheus для подключения к серверу Pushgateway и получения с него метрик. Это делается по такому же принципу, что и получение метрик с экспортеров.

Ссылка на официальную документацию: github.com/prometheus/pushgateway.

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

# mcedit /etc/prometheus/prometheus.yml

В секцию scrape_configs добавим задание:

…
scrape_configs:
…
  - job_name: 'pushgateway'
    honor_labels: true
    static_configs:
    - targets: ['localhost:9091']

Сохраним файл и выйдем из тестового редактора.

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

# promtool check config /etc/prometheus/prometheus.yml

Ответ:

В данном задании мы говорим серверу Prometheus забирать метрики с сервера localhost (локальный сервер) на порту 9091.

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

# systemctl restart prometheus

Проверяем, что сервис работает корректно:

# systemctl status prometheus

Можно попробовать отправить метрики в Pushgateway.

4. Отправка метрик методом push, put, delete в Pushgateway.

Отправку данных можно выполнить http-запросом из bash, например, с помощью пакета curl.

Синтаксис следующий:

# echo "<Название для метрики> <Значение метрики>" | curl --data-binary @- http://<IP-адрес сервера pushgateway>:9091/metrics/job/<Тег для job>/instance/<Тег для instance>

Например:

# echo "Temperature +15" | curl --data-binary @- http://localhost:9091/metrics/job/emachines_custom_metrics/instance/localhost

В данном примере мы передадим на локальный сервер Pushgateway (localhost:9091) метрику Temperature со значением +15.

Теперь мы можем перейти в браузере по адресу:

# http://<IP-адрес сервера pushgateway>:9091/metrics

И увидеть отправленную ранее метрику:

Если вам больше не нужны ваши самодельные метрики, то их можно и убрать.

Заходим на web-портал Pushgateway:

# http://Ваш-IP:9091

И просто нажимаем Delete Group для деактивации сбора метрик:

или вот так:

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

# curl -X DELETE http://localhost:9091/metrics/job/emachines_custom_metrics/instance/localhost

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

# curl -X DELETE http://localhost:9091/metrics/job/emachines_custom_metrics

Удалите все метрики во всех группах (требуется включить API администратора с помощью флага командной строки --web.enable-admin-api в конфигурации systemd):

# curl -X PUT http://localhost:9091/api/v1/admin/wipe

5. Отправка метрик методом скрипта на Python.

В качестве примера, рассмотрим скрипт, написанный на Python.

Для начала, необходимо установить модуль prometheus_client:

# pip3 install prometheus_client

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

#!/usr/bin/env python3
# -*- encoding: utf-8 -*-

from prometheus_client import CollectorRegistry, Gauge, push_to_gateway

registry = CollectorRegistry()
g = Gauge('temperature_metrics', 'Description metric', registry=registry)
g.set(22)
push_to_gateway('localhost:9091', job='temperature_lobby', registry=registry)

В данном примере мы отправим в Prometheus через Pushgateway метрику temperature_metrics со значением 22 и job-тегом temperature_lobby.

6. Практическое применение Pushgateway.

Для операционной системы CentOS 7 есть отличная утилита hddtemp — инструмент для измерения температуры жестких дисков. Она проста в использовании и установке.

Ссылка на инструкцию: «CentOS 7: Мониторинг температуры жестких дисков. Утилита hddtemp.»

Так же с помощью Pushgateway можно организовать сбор метрик ssl-cert-check и сделать простой мониторинг SSL.

7. Оригиналы источников информации.

prometheus.io «Download».
dmosk.ru «Установка и настройка Pushgateway для Prometheus».
github.com «pushgateway».

Источник: https://hamsterden.ru/prometheus-forwarding-of-arbitrary-metrics-and-values-via-pushgateway/

2021-08-15T20:43:53

Software

Grafana: Установка и настройка Grafana Server.

В предыдущей статье мы настраивали Prometheus Server. Пришло время настроить красивое графическое отображение с помощью Grafana Server.

1. Установка программы.

Белые классические графики — это классика, а хочется, чтоб всё было как на приборной панели современного самолёта! Чтоб приборчики всякие и экраны красивые.

За такую красоту отвечает графическая оболочка Grafana Server. Его сейчас и поставим.

Официальная ссылка на руководство по установке и настройке Grafana от разработчика Prometheus: prometheus.io.

Всё можно поставить вручную или через репозиторий.

Установим файловый менеджер и текстовый редактор в одном лице — Midnight Commander:

# yum -y install mc

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

Ссылка на установку репозитория от разработчика Grafana: grafana.com.

Создадим файл репозитория:

# mcedit /etc/yum.repos.d/grafana.repo

Внесём в него тест:

[grafana]
name=grafana
baseurl=https://packages.grafana.com/enterprise/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt

Установим программное обеспечение:

# yum -y install grafana-enterprise

1.2. Установка вручную.

Если вы устанавливаете вручную с помощью YUM, то вам нужно будет вручную обновить Grafana для каждой новой версии.

Заходим на сайт разработчика Grafana: grafana.com.

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

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

# cd ~

Скачаем данный пакет установщика на сервер CentOS 7, в локальную папку пользователя:

# wget https://dl.grafana.com/oss/release/grafana-6.7.2-1.x86_64.rpm

Проверим, что он в папке:

# ls

Ответ: список содержимого папки + файл grafana-6.7.2-1.x86_64.rpm.

grafana-6.7.2-1.x86_64.rpm

Установим пакет из локальной папки, в которой мы находимся:

# sudo yum -y localinstall grafana-6.7.2-1.x86_64.rpm

В итоге получится вот это:

Дополнительную информацию смотрите в руководстве по установке Centos 7. Кому привычнее ставить из репозитория, то имеется официальный репозиторий пакетов YUM от разработчика Grafana. Ссылки на подробные ресурсы упоминались выше по тексту инструкции.

2. Запуск системной службы.

Чтобы запустить службу и убедиться, что она запущена:

# systemctl daemon-reload
# systemctl start grafana-server

Настройка Grafana Server для запуска при загрузке CentOS 7:

# systemctl enable grafana-server.service

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

# systemctl status grafana-server

Ответ:

3. Основные компоненты.

Основные компоненты, которые могут пригодиться:

Бинарные файлы:
- /usr/sbin/grafana-server
- /usr/sbin/grafana-cli
Копии init.d скрипта:
- /etc/rc.d/init.d
Конфигурационный файл:
- /etc/grafana/grafana.ini
Сервис systemd с именем:
- grafana-server
Расположение log-файла по умолчанию:
- /var/log/grafana/grafana.log
Расположение sqlite3 database файла по умолчанию:
- /var/lib/grafana/grafana.db

Теперь можно переходить к настройке Grafana Server в web-интерфейсе.

4. Открытие 3000 порта.

Web-интерфейс расположен по адресу http://localhost:3000/. Если вам потребуется сменить 3000 порт на свой, то это можно будет сделать в файлах конфигурации позднее.

Откроем порт 3000:

Если firewalld:

# firewall-cmd --zone=public --add-port=3000/tcp --permanent
# firewall-cmd --complete-reload

Если iptables:

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

# mcedit /etc/sysconfig/iptables

В разделе ‘OUTPUT ACCEPT‘, добавляем строку:

-A INPUT -p tcp -m tcp --dport 3000 -m state --state NEW -j ACCEPT

Перезапускаем iptables:

# systemctl restart iptables

5. Отключение регистрации и анонимного доступа.

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

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

# cp /etc/grafana/grafana.ini /etc/grafana/grafana.ini.original

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

# mcedit /etc/grafana/grafana.ini

Найдите директиву allow_sign_up под заголовком [users].

...
[users]
# disable user signup / registration
;allow_sign_up = true
...

Если директива имеет значение true, она добавляет на экран входа в систему кнопку Sign Up, что позволяет пользователям регистрироваться и получать доступ к Grafana.

Значение false удаляет кнопку Sign Up и повышает безопасность и конфиденциальность Grafana.

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

...
[users]
# disable user signup / registration
allow_sign_up = false
...

Найдите директиву enabled под заголовком [auth.anonymous].

...
[auth.anonymous]
# enable anonymous access
;enabled = false
...

Значение true в этой директиве дает незарегистрированным пользователям возможность получить доступ к вашим панелям мониторинга. Значение false ограничивает доступ, и панели мониторинга смогут использовать только зарегистрированные пользователи.

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

...
[auth.anonymous]
# enable anonymous access
enabled = false
...

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

Перезапустите Grafana:

# systemctl restart grafana-server

Чтобы убедиться, что все работает, проверьте состояние Grafana:

# systemctl status grafana-server

Как и раньше, в выводе вы увидите active (running).

Если это не так, просмотрите сообщения терминала для получения дополнительной справки.

На данный момент Grafana полностью настроена и готова к использованию.

6. Grafana Server web-интерфейс.

Проследуем:

# http://IP-адрес:3000/

Если вы видите кнопку Sign Up или можете анонимно войти в систему, повторите предыдущие действия, чтобы устранить проблему, прежде чем продолжить работу.

Если кнопки Sign Up нет, то можете смело продолжать настройку дальше.

По умолчанию логин admin и пароль тоже admin.

После первого успешного ввода технического пароля и логина, Grafana Server предложит вам придумать и ввести свои рабочий пароль.

Воспользуемся этим и поменяем пароль на свой.

Внимание! Потом не забудьте поменять логин администратора Grafana Server и настроить анкету учетной записи администратора, настроить электронную почту, название организации и прочие мелочи.

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

Чтобы начать что-то мониторить, нам нужен источник данных. Нажимаем Add data source.

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

Примечание: Каждый сервер Prometheus – отдельный источник данных. Чтобы добавить несколько серверов Prometheus, нужно повторить инструкции данного раздела.

Здесь же в анкете есть вкладка Dashboards — это заранее сделанные для нас панели мониторинга от разработчиков Grafana. Позднее вы сами можете добавить или разработать свои панели мониторинга. Добавлять то, что предлагается в настройке по умолчанию не надо. Далее по инструкции мы добавим отличную панель Node Exporter Full.

Вернемся в анкету Settings, которую следует заполнить согласно тем параметрам, которые мы указывали для Prometheus Server по тексту инструкции выше. Возвращаемся на вкладку Settings и нажимаем кнопку зеленую кнопку Save & Test. Если все параметры введены верно, то тест будет пройден исправно и сохранение параметров засчитывается.

6.1. Создание панели мониторинга.

Для начала мониторинга, логично, создадим Панель мониторинга:

1. Нажмите кнопку Home —> New dashboard.

2. Нажмите кнопку Add Query. Grafana создает базовую графическую панель со сценарием Random Walk. Заполним анкету запросов по образцу из картинки. Источником Query выберем наш Prometheus Server. В качестве запроса используем запрос node_memory_MemFree_bytes.

Сохраните приборную панель. Щелкните значок дискетки Save dashboard в верхнем правом углу экрана.

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

Поздравляю, вы начали что-то измерять с Grafana! У вас есть панель мониторинга и отображаются результаты. Не стесняйтесь экспериментировать с тем, что вы построили, продолжать добавлять другие источники данных.

Если вы знаете что вам нужно, создайте свою панель мониторинга. Если еще не знаете, предлагаю подключить готовые.

6.2. Подключение готовой панели мониторинга.

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

Ссылка на портал полезной Панелью: grafana.com.

Среди них есть она очень полезная панель. Называется она Node Exporter Full. В ней есть мониторинг всех важных параметров сервера.

Проследуем по ссылке на портале до Node Exporter Full: grafana.com.

Скачаем файл последней ревизии с панелью мониторинга Node Exporter Full. После скачивания файл будет называться node-exporter-full_rev16.json.

Теперь этот файл импортируем в Grafana.

Выходим на Главную страницу приветствия —> нажимаем Home:

Выбираем импорт панели Import dashboard:

Переходим в окно импорта и нажимаем Upload .json file и импортируем файл node-exporter-full_rev16.json.

Заполняем анкету панели своими данными и подключаем свой сервер для мониторинга по аналогии:

Нажимаем Import и панель мониторинга начинает отображать метрики нашего Prometheus Server:

Внимание! Панель мониторинга может минут 5 ничего не отображать или отображать что-то частично. Ничего страшного. Просто подождите пока все метрики наработают свою базу данных, чтобы вам что-то начать показывать на графиках. Через некоторое время зайдите в панель мониторинга и все панельки будет отображать информацию исправно.

Слева у каждой подпанели есть значок «птичка-галочка» (слева от начала заголовка каждой вкладки) за который можно свернуть или развернуть нужную вкладку общей панели мониторинга.

После всего этого нажимаем значок дискеты Сохранить (1) и наша панель мониторинга будет сохранена и привязана к Prometheus Server. Пометим ее в закладки значком Звездочки (2). Выйдем на Главную страницу (3) экрана приветствия Grafana Server.

Теперь у нас организован мониторинг основных параметров сервера на котором развернуты Prometheus Server с графической оболочкой Grafana Server.

Как ботать дальше с этими системами можно легко узнать в Интернете. Информации очень много. Системы достаточно популярные.

Если что-то появится интересное, то я обязательно добавлю эти готовые решения на свой сайт и ссылку на них в эту инструкцию.

7. Grafana Server через Nginx.

Если на сервере установлен Nginx и имеется доменное имя, можно пробросить пробросить через него вход в интерфейс Grafana Server.

Если у вас не поднят web-сервер, то вы можете создать его по инструкции: «CentOS 7: Настройка web-сервера Nginx и выход в Интернет со своим доменным именем.»

Приступим к написанию файла конфигурации:

# mcedit /etc/nginx/conf.d/grafana_server.conf

Для этого в папке с конфигурациями Nginx создаем конфигурацию вот с таким текстом:

server {
    listen 80;
    server_name grafana-server.name.ru;
    access_log /grafana-server/log/access.log;
    error_log /grafana-server/log/error.log;
    return 301 https://$server_name$request_uri;
    }

server {
    listen 443 ssl http2;
    server_name mt.hamsterden.ru;
    access_log /grafana-server/log/access.log;
    error_log /grafana-server/log/error.log;
    ssl_certificate		/etc/letsencrypt/live/grafana-server.name.ru/fullchain.pem;
    ssl_certificate_key		/etc/letsencrypt/live/grafana-server.name.ru/privkey.pem;
    ssl_trusted_certificate	/etc/letsencrypt/live/grafana-server.name.ru/fullchain.pem;

    location / {
#       auth_basic "Воинское звание? Цель прибытия?";
#       auth_basic_user_file /etc/nginx/htpasswd;
        proxy_pass http://localhost:3000/;    
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Real-IP $remote_addr;
    }
}

Как его модифицировать и усилить вы можете почитать в руководствах для Nginx.

Перезапустим Nginx:

# systemctl restart nginx

Заходим в браузере:

# https://grafana-server.name.ru

8. Сброс до заводских настроек.

Для того, чтобы сбросить Grafana Server до заводских настроек, достаточно удалить файл grafana.db, в каталоге /var/lib/grafana.

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

# rm -Rf /var/lib/grafana/grafana.db

Перезапустите Grafana:

# sudo systemctl restart grafana-server

Теперь при входе в Grafana Server вы должны будете проходить все этапы настройки заново.

9. Смена порта программы по умолчанию.

По умолчанию программа использует 3000 порт. Но его можно легко поменять в главном файле настроек программы grafana.ini в каталоге /etc/grafana.

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

# mcedit /etc/grafana/grafana.ini

Найдите директиву http_port под заголовком [server].

[server]
...
# The http port to use
;http_port = 3000
...

Расскоментируйте ее и внесите правки номера своего порта:

[server]
...
# The http port to use
http_port = 3333
...

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

Перезапустите Grafana:

# sudo systemctl restart grafana-server

Чтобы убедиться, что все работает, проверьте состояние Grafana:

# sudo systemctl status grafana-server

Как и раньше, в выводе вы увидите active (running).

Прежде чем переходить в web-интерфейс Grafana по новому порту не забудьте открыть новый порт, а так же внести правки в конфигурацию Nginx, иначе web-интерфейс будет недоступен.

Проследуем:

# http://IP-адрес:3333/

10. Список доступных метрик.

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

# http://<your_server_ip>:9090/metrics

Все эти метрики можно скопировать и вставить в редактор запросов Grafana.

Чтобы изменения настроек вступили в силу, нужно сохранить дашборд.

11. Оригиналы источников информации.

prometheus.io «Grafana | Prometheus».
grafana.com«Install on RPM-based Linux (CentOS, Fedora, OpenSuse, Red Hat)».
grafana.com«Node Exporter Fullby idealista».
laurvas.ru «Осваиваем мониторинг с Prometheus. Часть 1. Знакомство и установка.».
eax.me «Устанавливаем связку из Prometheus и Grafana».
8host.com «Установка и защита Grafana в Ubuntu 16.04».
8host.com «Добавление дашборда Prometheus в Grafana».

Источник: https://hamsterden.ru/grafana-server/

2021-08-15T20:36:22

Software

Prometheus: Установка и настройка Prometheus Server.

1. Постановка задачи.

Задача: организовать мониторинг серверов и микросервисов, в режиме реального времени нужно отслеживать как состояние отдельных компонентов, так и состояние системы в целом.

2. Описание программ.

Prometheus server — центральное звено. Prometheus является открытой time series СУБД, написанной на языке Go и изначально разработанной в компании SoundCloud. Другими словами, эта штука хранит ваши метрики. Интересной особенностью Prometheus является то, что он сам тянет метрики с заданного множества сервисов (делает pull). За счет этого у Prometheus не могут забиться какие-то там очереди или вроде того, а значит мониторинг никогда не станет узким местом системы. Также проект интересен тем, что он принципиально не предлагает какого-либо горизонтального масштабирования или high availability. Дескать, третье тысячелетие на дворе — в случае чего просто возьмите машину помощнее, не выпендривайтесь.

Агенты, собирающие метрики и предоставляющие их в понятном для Prometheus’а виде. В зависимости от контекста называются экспортерами (exporter) или таргетами (target). Устанавливаются на целевые машины. Типичный представитель — Node Exporter — собирает данные о вычислительных ресурсах: загрузку процессора, памяти, диска и так далее. Есть куча других экспортеров. Например, cadvisor собирает данные о контейнерах. Есть экспортеры для Postgres’а, для Nginx’а и прочих сервисов. С точки зрения самого Prometheus’а они ничем принципиально не отличаются друг от друга, просто каждый собирает какие-то свои метрики. Можно писать свои экспортеры, если ничего из готового вам не подходит.

Node Exporter — сервис, задача которого заключается в экспорте информации о машине в формате, понятном Prometheus’у. Вообще, для Prometheus написано множество готовых exporter’ов практически под все существующие системы — всякие там web-серверы, СУБД, очереди сообщений, и так далее. В рамках этой заметки мы будем использовать только Node Exporter. Настройка других exporter’ов вряд ли будет сильно отличаться.

Alertmanager — менеджер уведомлений. Ни один инструмент мониторинга немыслим без компонента для рассылки уведомлений. В Prometheus для этой цели используется Alertmanager.

Grafana представляет собой открытый web-frontend к различным time series СУБД, таким, как Graphite, InfluxDB, Prometheus. В общем, Grafana рисует для вас красивые графики, используя информацию из Prometheus. Характерно, что у Prometheus есть и собственный web-интерфейс. Однако он предельно прост и довольно неудобен. Поэтому даже сами разработчики Prometheus рекомендуют использовать Grafana.

Важно! Настройки, связанные с безопасностью, в рамках этого поста не рассматриваются. За информацией о том, как настроить firewall, поднять Nginx для какой-нибудь аутентификации, а также настроить TLS, обращайтесь к соответствующим более ранним заметкам. Обращаю ваше внимание на то, что по умолчанию Prometheus слушает все сетевые интерфейсы без какой-либо аутентификации и шифрования. Grafana имеет кое-какую аутентификацию, но также слушает все интерфейсы и не имеет шифрования.

Вы можете найти более полный список официальных экспортеров и экспортеров сообщества на веб-сайте Prometheus.

Ссылка на сайт разработчика: https://prometheus.io/download/.

Ссылки разработчика на GitHub: https://github.com/prometheus/prometheus/releases/.

3. Общая подготовка системы.

Обновим систему:

# yum -y update && yum -y upgrade

Удалим SELinux:

# yum -y remove selinux*

Перезагрузим CentOS 7:

# shutdown -r now

4. Настройка синхронизации времени.

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

Если интересно узнать всё поподробнее о настройках времени и серверов NTP, то пройдите по ссылке на инструкцию «CentOS 7: Настройка даты и времени, пояса, автоматическая синхронизация мирового времени (Network Time Protocol)».

Выполним настройку не вдаваясь в подробности.

Для того, чтобы в системе были доступны часовые пояса, установите утилиту tzdata:

# yum -y install tzdata

Чтобы сменить часовой пояс, можете воспользоваться специальной утилитой timedatectl, которая входит в состав systemd.

# timedatectl set-timezone Asia/Yekaterinburg

Заменим часовой пояс на Asia/Yekaterinburg:

Делаем бэкап файла localtime:

# mv /etc/localtime /etc/localtime.bak

# ln -s /usr/share/zoneinfo/Asia/Yekaterinburg /etc/localtime

Установим chrony.

Внимание! В CentOS 7 данная утилита уже идет в комплекте даже при минимальной комплектации установщика. Устанавливать отдельно в CentOS 7 утилиту chrony не надо.

Ссылка: «CentOS 7: Настройка синхронизация времени по Network Time Protocol. Утилита ntp».

Основные преимущества chrony:

высокая скорость и точность синхронизации;
корректная работа при отсутствии доступа к эталонным часам (ntpd требуются регулярные запросы);
по умолчанию не меняет сразу время при синхронизации, чтобы не нарушить работу программ.

# yum -y install chrony

Как и любой другой сервис, после установки chrony нужно включить и добавить в автозагрузку:

# systemctl start chronyd
# systemctl enable chronyd

Для проверки статуса chrony используется следующая команда.

# systemctl status chronyd

Проверяем, нормально ли запустился:

Все в порядке, сервис настроен и работает. После запуска он автоматически синхронизирует время. Теперь наши часы будут автоматически синхронизироваться с сервером времени в интернете.

# timedatectl status

Чтобы проверить, синхронизирован ли chrony на самом деле. Как и у ntp, у chrony есть интерфейс командной строки chronyc. Мы будем использовать его программу командной строки chronyc, которая имеет опцию отслеживания для предоставления соответствующей информации.

# chronyc tracking

Чтобы проверить информацию об источниках chrony, можно выполнить следующую команду:

# chronyc sources

С временем закончили. Всё работает. Идем дальше!

5. Получение и запуск Prometheus Service.

Установим текстовый редактор mc, download-менеджер wget, архиватор tar:

# yum -y install mc wget tar

Зайдем на страничку разработчика системы Prometheus и скопируем ссылку на скачивание архива с программой:

Ссылка на сайт разработчика: https://prometheus.io/download/.

Ссылки разработчика на GitHub: https://github.com/prometheus/prometheus/releases/.

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

# cd ~

Скачаем данный архив на сервер CentOS 7, в локальный каталог пользователя:

# wget https://github.com/prometheus/prometheus/releases/download/v2.17.1/prometheus-2.17.1.linux-amd64.tar.gz

Проверим, что он в каталоге:

# ls

Ответ: список содержимого каталога + файл-архив prometheus-2.17.1.linux-amd64.tar.gz.

prometheus-2.17.1.linux-amd64.tar.gz

Создадим и добавим «бездомного» и «бесконсольного» служебного пользователя по имени prometheus.

# useradd --no-create-home --shell /bin/false prometheus

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

# mkdir /etc/prometheus
# mkdir /var/lib/prometheus

Добавим права на их использование пользователем prometheus:

# chown prometheus:prometheus /etc/prometheus
# chown prometheus:prometheus /var/lib/prometheus

Распакуем, ранее скачанный, архив с программой prometheus-2.17.1.linux-amd64.tar.gz.

# tar -xvzf prometheus-2.17.1.linux-amd64.tar.gz

Проверим результат:

# ls

Ответ: список содержимого каталога + каталог prometheus-2.17.1.linux-amd64.

prometheus-2.17.1.linux-amd64

Рассортируем содержимое каталога prometheus-2.17.1.linux-amd64.

Скопируем бинарные файлы ‘prometheus‘ and ‘promtool‘ в каталог ‘/usr/local/bin‘.

# cp prometheus-2.17.1.linux-amd64/prometheus /usr/local/bin/
# cp prometheus-2.17.1.linux-amd64/promtool /usr/local/bin/

Добавим права на их использование пользователем prometheus:

# chown prometheus:prometheus /usr/local/bin/prometheus
# chown prometheus:prometheus /usr/local/bin/promtool

# chmod -R 700 /usr/local/bin/prometheus
# chmod -R 700 /usr/local/bin/promtool

Скопируем ‘consoles‘ и ‘console_libraries‘ каталоги из каталога prometheus-2.17.1.linux-amd64 в каталог ‘/etc/prometheus‘.

# cp -r prometheus-2.17.1.linux-amd64/consoles /etc/prometheus
# cp -r prometheus-2.17.1.linux-amd64/console_libraries /etc/prometheus
# cp -r prometheus-2.17.1.linux-amd64/prometheus.yml /etc/prometheus

Добавим права на их использование пользователем prometheus:

# chown -R prometheus:prometheus /etc/prometheus/consoles
# chown -R prometheus:prometheus /etc/prometheus/console_libraries
# chown -R prometheus:prometheus /etc/prometheus/prometheus.yml

Важно! Конфигурационный файл Prometheus использует формат YAML, который строго запрещает табуляцию и требует двух пробелов для отступов. Prometheus не удастся запустить, если конфигурационный файл некорректно отформатирован.

В глобальных настройках (раздел global) задайте интервал по умолчанию для сбора метрик. Обратите внимание, что Prometheus будет применять эти настройки для каждого экспортера, если только глобальные переменные не переопределяются индивидуальными настройками отдельного экспортера.

Согласно этому значению scrape_interval Prometheus будет собирать метрики своих экспортеров каждые 15 секунд, что достаточно для большинства экспортеров.

global:
scrape_interval: 15s

Теперь добавьте Prometheus в список экспортеров, чтобы собирать его метрики. Для этого используйте директиву scrape_configs:

...
scrape_configs:
- job_name: 'prometheus_server'
scrape_interval: 5s
static_configs:
- targets: ['localhost:9090']

С помощью job_name Prometheus маркирует экспортеры в запросах и графах, потому тут лучше выбрать описательное имя.

Поскольку Prometheus экспортирует важные данные о себе, которые используются для мониторинга производительности и отладки, можно переопределить глобальную директиву scrape_interval с 15 секунд до 5 секунд, чтобы данные обновлялись чаще.

С помощью директив static_configs и targets Prometheus определяет, где запускать экспортеры. Поскольку этот конкретный экспортер запущен на том же сервере, что и Prometheus, можно использовать localhost вместо IP-адреса и порт по умолчанию — 9090 порт.

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

Настроим конфигурационный файл Prometheus /etc/prometheus/prometheus.yml под наши нужды, но перед этим копируем его, на всякий случай:

# cp /etc/prometheus/prometheus.yml /etc/prometheus/prometheus.yml.original

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

# mcedit /etc/prometheus/prometheus.yml

Добавим в него следующие строки по смыслу синтаксиса файла конфигурации:

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=` to any timeseries scraped from this config.
  - job_name: 'prometheus_server'
    scrape_interval: 5s
    metrics_path: /metrics
    static_configs:
    - targets: ['localhost:9090']

Сохраним файл и выйдем из тестового редактора.

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

# promtool check config /etc/prometheus/prometheus.yml

Ответ:

Подробнее можно узнать о правилах написания файла конфигурации на сайте разработчика программы: https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Добавим права на его использование пользователем prometheus:

# chown prometheus:prometheus /etc/prometheus/prometheus.yml

Создадим конфигурационный файл службы Prometheus Service:

# mcedit /etc/systemd/system/prometheus.service

Этот файл сообщает systemd, что Prometheus нужно запускать в качестве пользователя prometheus, его конфигурационный файл находится в каталоге /etc/prometheus/prometheus.yml, а данные и метрики хранятся в каталоге /var/lib/prometheus.

Также нелишним будет знать некоторые особенности устройства Prometheus. В частности, по умолчанию все данные хранятся в течение 15 дней, метрики собираются раз в 5-15 секунд, а одна метрика в среднем занимает два байта на сэмпл. Обладая этой информацией, и зная количество метрик, можно прикинуть, сколько дискового пространства вам понадобится для их хранения.

Внимание! Хранилище Prometheus не позиционируется, как супер надежное. Если у вас очень ценные метрики, рекомендуется сохранять их куда-то еще через адаптеры. Ещё со временем метрики Prometheus из разных источников будут занимать приличное количество места на диске, поэтому заранее продумайте, где будете хранить большие объемные файлы, которые будут расти и расти!

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

Информация как это сделать имеется в инструкции «CentOS 7: Как создать и искать символические ссылки (ln)».

Добавим в него следующие строки:

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus 
--config.file=/etc/prometheus/prometheus.yml 
--storage.tsdb.path=/var/lib/prometheus/ 
--web.console.templates=/etc/prometheus/consoles 
--web.console.libraries=/etc/prometheus/console_libraries
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

или поподробнее со всякими фишками и включенным режимом администрирования:

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
WorkingDirectory=/etc/prometheus/
# RuntimeDirectory=prometheus
# RuntimeDirectoryMode=0750
ExecStart=/usr/local/bin/prometheus 
--config.file=/etc/prometheus/prometheus.yml 
--storage.tsdb.retention=365d 
--storage.tsdb.path=/var/lib/prometheus/ 
--storage.tsdb.max-block-duration=2h 
--web.console.templates=/etc/prometheus/consoles 
--web.console.libraries=/etc/prometheus/console_libraries 
--web.enable-lifecycle 
--web.enable-admin-api 
--web.listen-address=:9090 
--log.level=info

ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
LimitNOFILE=10000
TimeoutStopSec=20

StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=prometheus

[Install]
WantedBy=multi-user.target

Сохраним файл и выйдем из тестового редактора.

Перезагрузим системные службы systemd service.

# systemctl daemon-reload

Стартуем Prometheus service:

# systemctl start prometheus

Прописываем в автозапуск CentOS 7:

# systemctl enable prometheus

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

# systemctl status prometheus

Вывод описывает состояние Prometheus, основной идентификатор процесса (PID), использование памяти и так далее.

Внимание! Бывает, что всё сделано правильно, но ничего упорно не стартует. Сверьтесь с писком возможных ошибок с вашей стороны.

1. Иногда бывает, что у пользователя prometheus теряется доступ к /usr/local/bin/prometheus. Заново выдайте права 700 на /usr/local/bin/prometheus и запустите службу снова. Пару раз так было так на других дистрибутивах Linux, хотя визуально всё хорошо и права стоят на все операции.

# chown prometheus:prometheus /usr/local/bin/prometheus

# chmod -R 700 /usr/local/bin/prometheus

2. Вы отредактировали файл etc/prometheus/prometheus.yml и сохранили его не в кодировке UTF-8. Файл существует, но не считывается. Меняйте кодировку на UTF-8.

3. Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе YAML в файле конфигурации, а затем следуйте инструкциям на экране, чтобы устранить проблему. Синтаксис этого файла очень капризный, даже один лишний пробел или перенос строки, которые вы не заметили, могут не позволять запустить службу. Не расстраивайтесь и проверьте всё внимательно.

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

Откроем порт 9090.

Если firewalld:

# firewall-cmd --zone=public --add-port=9090/tcp --permanent
# systemctl reload firewalld

Если iptables:

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

# mcedit /etc/sysconfig/iptables

В разделе ‘OUTPUT ACCEPT‘, добавляем строку:

-A INPUT -p tcp -m tcp --dport 9090 -m state --state NEW -j ACCEPT

Перезапускаем iptables:

# sudo systemctl restart iptables

Проверяем, что Prometheus отдает свои собственные метрики:

# curl 'localhost:9090/metrics'

Теперь можно установить дополнительный экспортер для создания метрик о ресурсах сервера.

6. Prometheus Server web-интерфейс.

Зайдем в web-интерфейс по адресу:

# http://Server-IP:9090/graph

Если всё было сделано правильно и проброшен порт 9090, вас встретит страница приветствия:

7. Получение и запуск Node Exporter (localhost).

Первым делом настроим Prometheus node exporter на Prometheus Server.

Чтобы расширить стандартные возможности Prometheus, установите дополнительный экспортер под названием Node Exporter. Node Exporter предоставляет подробную информацию о системе, включая использование процессора, диска и памяти.

Скопируем ссылку на соответствующий модуль с сайта разработчиков:

Ссылка на сайт разработчика: https://prometheus.io/download/.

Ссылки разработчика на GitHub: https://github.com/prometheus/prometheus/releases/.

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

# cd ~

Скачаем данный архив на сервер CentOS 7, в локальный каталог пользователя:

# wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz

Проверим, что он в каталоге:

# ls

Ответ: список содержимого каталога + файл-архив node_exporter-0.18.1.linux-amd64.tar.gz.

node_exporter-0.18.1.linux-amd64.tar.gz

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

# tar -xvzf node_exporter-0.18.1.linux-amd64.tar.gz

Создадим и добавим «бездомного» и «бесконсольного» служебного пользователя по имени ‘nodeusr‘ для Node Exporter.

# useradd --no-create-home --shell /bin/false nodeusr

Переместим бинарные файлы в каталог ‘/usr/local/bin‘ из каталога скачанного и распакованного архива.

# mv node_exporter-0.18.1.linux-amd64/node_exporter /usr/local/bin/

Добавим права на их использование пользователем nodeusr:

# chown nodeusr:nodeusr /usr/local/bin/node_exporter

Создадим конфигурационный файл службы Node Exporter:

# mcedit /etc/systemd/system/node_exporter.service

Добавим в него следующие строки:

[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=nodeusr
Group=nodeusr
Type=simple
ExecStart=/usr/local/bin/node_exporter
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

Сохраним файл и выйдем из тестового редактора.

Коллекторы определяют, какие метрики генерирует Node Exporter. Полный список коллекторов Node Exporter, включая включенные по умолчанию и устаревшие, можно найти в файле README для Node Exporter.

Чтобы переопределить список коллекторов, используйте флаг --collectors.enabled.

...
ExecStart=/usr/local/bin/node_exporter --collectors.enabled meminfo,loadavg,filesystem
...

В таком случае Node Exporter будет генерировать метрики, используя только коллекторы meminfo, loadavg и filesystem. Вы можете использовать столько коллекторов, сколько вам нужно, но обратите внимание, что при перечислении коллекторов пробелов перед запятыми или после них нет.

Перезагрузим системные службы systemd service.

# systemctl daemon-reload

Стартуем Prometheus service:

# systemctl start node_exporter

Прописываем в автозапуск CentOS 7:

# systemctl enable node_exporter

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

# systemctl status node_exporter

Здесь вы увидите состояние Node Exporter, основной идентификатор процесса (PID), использование памяти и так далее.

Внимание! Иногда бывает, что у пользователя nodeusr нет доступа к /usr/local/bin/node_exporter, хотя визуально всё хорошо и права стоят на все операции. Заново выдайте права 700 на /usr/local/bin//node_exporterи запустите службу снова. Было так на других дистрибутивах Linux.

Откроем порт 9100.

Если firewalld:

# firewall-cmd --zone=public --add-port=9100/tcp --permanent
# systemctl reload firewalld

Если iptables:

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

# mcedit /etc/sysconfig/iptables

В разделе ‘OUTPUT ACCEPT‘, добавляем строку:

-A INPUT -p tcp -m tcp --dport 9100 -m state --state NEW -j ACCEPT

Перезапускаем iptables:

# sudo systemctl restart iptables

Проверяем, что метрики отдаются:

# curl 'localhost:9100/metrics'

8. Node Exporter web-интерфейс.

Зайдем в web-интерфейс по адресу:

# http://IP-Address:9100/metrics

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

9. Настройка взаимодействия Prometheus и Node Exporter.

Добавим конфигурацию Node Exporter задачи для Prometheus Server.

Prometheus собирает только метрики экспортеров, указанных в разделе scrape_configs его конфигурационного файла. Добавьте в этот файл экспортер Node Exporter.

Зайдем на Prometheus Server и модифицируем prometheus.yml в каталоге /etc/prometheus/.

Редактируем файл:

# mcedit /etc/prometheus/prometheus.yml

Добавляем в файл конфигурации в блок scrape config в самый конец раздела:


- job_name: 'node_exporter_prometheus'
  scrape_interval: 5s
  metrics_path: /metrics
  static_configs:
  - targets: ['localhost:9100']

Сохраним файл и выйдем из тестового редактора.

Поскольку этот экспортер работает на том же сервере, что и Prometheus, можно использовать localhost вместо IP-адреса и порт по умолчанию Node Exporter — это 9100 порт.

Весь файл конфигурации должен выглядеть так:

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=` to any timeseries scraped from this config.
  - job_name: 'prometheus_server'
    scrape_interval: 5s
    metrics_path: /metrics
    static_configs:
    - targets: ['localhost:9090']

  - job_name: 'node_exporter_prometheus'
    scrape_interval: 5s
    metrics_path: /metrics
    static_configs:
    - targets: ['localhost:9100']

Сохраним и выйдем из текстового редактора.

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

# promtool check config /etc/prometheus/prometheus.yml

Ответ:

Чтобы настройки активировались, перезапустим службу:

# systemctl restart prometheus

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

# systemctl status prometheus

Внимание! Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе YAML в файле конфигурации, а затем следуйте инструкциям на экране, чтобы устранить проблему. Синтаксис этого файла очень капризный, даже один лишний пробел или перенос строки, которые вы не заметили, могут не позволять запустить службу. Не расстраивайтесь и проверьте всё внимательно.

Зайдем в web-оболочку Prometheus Server и проверим targets.

Зайдем в web-интерфейс по адресу:

# http://IP-Address:9090/targets

Примерный вид в браузере:

10. Получение и запуск MySQL Exporter (localhost).

Создадим служебного пользователя сбора метрик MySQL Server базы данных.

Войдите в свою базу данных и выполните следующие команды:

# mysql -u root -p

> CREATE USER 'mysqld_exporter'@'localhost' IDENTIFIED BY 'password' WITH MAX_USER_CONNECTIONS 3;

> GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'mysqld_exporter'@'localhost';

> FLUSH PRIVILEGES;

> exit

Скачаем mysqld_exporter с официальной странички разработчиков: https://prometheus.io/download/.

Для этого получим ссылку для закачивания архива с программой.

Ссылка на сайт разработчика: https://prometheus.io/download/.

Ссылки разработчика на GitHub: https://github.com/prometheus/prometheus/releases/.

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

# cd ~

Скачаем данный архив на сервер CentOS 7, в локальный каталог пользователя:

# wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.12.1/mysqld_exporter-0.12.1.linux-amd64.tar.gz

Проверим, что он в каталоге:

# ls

Ответ: список содержимого каталога + файл-архив mysqld_exporter-0.12.1.linux-amd64.tar.gz.

mysqld_exporter-0.12.1.linux-amd64.tar.gz

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

# tar -xvzf mysqld_exporter-0.12.1.linux-amd64.tar.gz

Создадим и добавим «бездомного» и «бесконсольного» служебного пользователя по имени ‘mysqld_exporter‘ для MySQL Exporter.

# useradd --no-create-home --shell /bin/false mysqld_exporter

Переместим бинарный файл в каталог ‘/usr/local/bin‘ из каталога скачанного и распакованного архива.

# mv mysqld_exporter-0.12.1.linux-amd64/mysqld_exporter /usr/local/bin/

Добавим права на их использование пользователем mysqld_exporter:

# chown mysqld_exporter:mysqld_exporter /usr/local/bin/mysqld_exporter

Создадим рабочий каталог для MySQL Exporter:

# mkdir -p /etc/mysql_exporter

Создадим MySQL файл с паролем для MySQL Exporter.

# touch /etc/mysql_exporter/.my.cnf

# mcedit /etc/mysql_exporter/.my.cnf

Добавим в него строки, которые будут содержать строки вашего логина и пароля из примера по созданию служебного пользователя сбора метрик MySQL Server базы данных:

[client]
user=mysqld_exporter
password=password

Сохраним и выйдем из файла.

Добавим права на каталог для пользователя mysqld_exporter:

# chown -R mysqld_exporter:mysqld_exporter /etc/mysql_exporter

Добавим свойства 600 на каталог:

# chmod 600 /etc/mysql_exporter/.my.cnf

Создадим конфигурационный файл службы MySQL Exporter:

# mcedit /etc/systemd/system/mysql_exporter.service

Добавим в него следующие строки:

[Unit]
Description=MySQL Exporter Service
Wants=network.target
After=network.target

[Service]
User=mysqld_exporter
Group=mysqld_exporter
Type=simple
Environment="DATA_SOURCE_NAME=mysqld_exporter:password@tcp(127.0.0.1:3306)/"
ExecStart=/usr/local/bin/mysqld_exporter 
--config.my-cnf /etc/mysql_exporter/.my.cnf
--collect.global_status 
--collect.info_schema.innodb_metrics 
--collect.auto_increment.columns 
--collect.info_schema_processlist 
--collect.binlog_size 
--collect.global_variables 
--collect.info_schema.tablestats 
--collect.global_variables 
--collect.info_schema.query_response_time 
--collect.info_schema.userstats 
--collect.info_schema.tables 
--collect.perf_schema.tablelocks 
--collect.perf_schema.file_events 
--collect.perf_schema.eventswaits 
--collect.perf_schema.indexiowaits 
--collect.perf_schema.tableiowaits 
--collect.slave_status 
Restart=always

[Install]
WantedBy=multi-user.target

Перезагрузим системные службы systemd service.

# systemctl daemon-reload

Стартуем MySQL Exporter service:

# systemctl start mysql_exporter

Прописываем в автозапуск CentOS 7:

# systemctl enable mysql_exporter

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

# systemctl status mysql_exporter

Здесь вы увидите состояние MySQL Exporter, основной идентификатор процесса (PID), использование памяти и так далее.

Откроем порт 9104.

Если firewalld:

# firewall-cmd --zone=public --add-port=9104/tcp --permanent
# systemctl reload firewalld

Если iptables:

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

# mcedit /etc/sysconfig/iptables

В разделе ‘OUTPUT ACCEPT‘, добавляем строку:

-A INPUT -p tcp -m tcp --dport 9104 -m state --state NEW -j ACCEPT

Перезапускаем iptables:

# sudo systemctl restart iptables

Проверяем, что метрики отдаются:

# curl 'localhost:9104/metrics'

11. MySQL Exporter web-интерфейс.

Зайдем в web-интерфейс по адресу:

# http://IP-Address:9104/metrics

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

12. Настройка взаимодействия Prometheus и MySQL Exporter.

Добавим конфигурацию MySQL Exporter задачи для Prometheus Server.

Prometheus собирает только метрики экспортеров, указанных в разделе scrape_configs его конфигурационного файла. Добавьте в этот файл экспортер MySQL Exporter.

Зайдем на Prometheus Server и модифицируем prometheus.yml в каталоге /etc/prometheus/.

Редактируем файл:

# mcedit /etc/prometheus/prometheus.yml

Добавляем в файл конфигурации в блок scrape config в самый конец раздела:

- job_name: 'mysql_exporter_prometheus'
  scrape_interval: 5s
  metrics_path: /metrics
  static_configs:
  - targets: ['localhost:9104']

Сохраним файл и выйдем из тестового редактора.

Поскольку этот экспортер работает на том же сервере, что и Prometheus, можно использовать localhost вместо IP-адреса и порт по умолчанию MySQL Exporter — это 9104 порт.

Весь файл конфигурации должен выглядеть так:

g# my global config
global:
  scrape_interval:     5s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 5s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=` to any timeseries scraped from this config.
  - job_name: 'abiturientu_ru'
    scrape_interval: 5s
    metrics_path: /metrics
    static_configs:
    - targets: ['localhost:9090']

  - job_name: 'node_exporter_abiturientu_ru'
    scrape_interval: 5s
    metrics_path: /metrics
    static_configs:
    - targets: ['localhost:9100']

  - job_name: 'mysql_exporter_abiturientu_ru'
    scrape_interval: 5s
    metrics_path: /metrics
    static_configs:
    - targets: ['localhost:9104']

Сохраним и выйдем из текстового редактора.

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

# promtool check config /etc/prometheus/prometheus.yml

Ответ:

Чтобы настройки активировались, перезапустим службу:

# systemctl restart prometheus

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

# systemctl status prometheus

Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе YAML в файле конфигурации, а затем следуйте инструкциям на экране, чтобы устранить проблему. Синтаксис этого файла очень капризный, даже один лишний пробел или перенос строки, которые вы не заметили, могут не позволять запустить службу. Не расстраивайтесь и проверьте всё внимательно.

Зайдем в web-оболочку Prometheus Server и проверим targets.

Теперь можно будет получать метрики MySQL Exporter и использовать их в Grafana.

13. Проверка работы Prometheus Server.

# http://Server-IP:9090/graph

Для начала проверьте статус Prometheus и Node Explorer, открыв меню Status в верхней части экрана, а затем выбрав Targets.

Нажимаем Status —> Targets:

Поскольку Prometheus собирает и свои данные и другие метрики, в состоянии UP вы должны увидеть все цели, которые ему ставили.

Если экспортера нет или вы видите сообщение об ошибке, проверьте состояние сервисов с помощью следующих команд:

# systemctl status prometheus
# systemctl status node_exporter
# systemctl status mysql_exporter

В выводе должна быть строка Active: active (running). Если это не так, или активный сервер работает некорректно, вернитесь на несколько шагов обратно по инструкции, чтобы исправить ошибки.

Чтобы убедиться, что экспортеры работают правильно, выполните несколько выражений Node Exporter.

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

Браузер запросов. Для примера запросим вручную параметр node_memory_MemAvailable_bytes.

Консольный выход node_memory_MemAvailable_bytes. Нажимаем клавишу Execute —>затем вкладку Graph:

В ответ получаем график метрики node_memory_MemAvailable_bytes.

Наведите указатель мыши на график, чтобы получить дополнительную информацию о какой-либо конкретной точке вдоль осей X и Y.

Если вы хотите проверить результаты, выполните команду free в терминале. Флаг -h отображает вывод free в удобочитаемом формате и выводит сумму в мегабайтах.

# free -h

Этот вывод содержит сведения об использовании памяти, включая доступную память в столбце available.

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

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

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

В повседневной жизни вы вряд ли будете смотреть графики в этом интерфейсе. Гораздо приятнее смотреть графики в Grafana.

Приглашаю проследовать к изучению следующего материала из этого цикла статей — Часть II: статья «CentOS 7: Установка и настройка Grafana Server».

14. Менеджер тревог Alertmanager.

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

15. Оригиналы источников информации.

prometheus.io «Configuration».
fosslinux.com «How to install and configure Prometheus on CentOS 7».
laurvas.ru «Осваиваем мониторинг с Prometheus. Часть 1. Знакомство и установка.».
github.com «No datapoints found. #1022».
eax.me «Устанавливаем связку из Prometheus и Grafana».
habr.com «Мониторинг сервисов с Prometheus».
8host.com «Установка Prometheus в Ubuntu».
stackoverflow.com «mysqld_exporter DATA SOURCE NAME in mysqld_exporter.service».
dmosk.ru «Установка Prometheus + Alertmanager + node_exporter на Linux».

Источник: https://hamsterden.ru/prometheus/

2021-08-15T20:21:55

Software