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

Установка и настройка 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&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 может состоять из четырёх типов стадий. Более подробно — в официальной документации, тут же отмечу некоторые нюансы.




  1. Parsing stages. Это стадия RegEx и JSON. На этом этапе мы извлекаем данные из логов в так называемую extracted map. Извлекать можно из JSON, просто копируя нужные нам поля в extracted map, или через регулярные выражения (RegEx), где в extracted map “мапятся” named groups. Extracted map представляет собой key-value хранилище, где key — имя поля, а value — его значение из логов.
  2. 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.
  3. Action stages. На этом этапе можно сделать что-нибудь с извлечённым:
    • Создать лейбл из extracted data, который проиндексируется Loki.
    • Изменить или установить время события из лога.
    • Изменить данные (текст лога), которые уйдут в Loki.
    • Создать метрики.
  4. 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 использовать не можем, надеемся, что данный пост поможет вам в выборе.




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










Источник: 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







# 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. Оригиналы источников информации.




  1. prometheus.io «Download».
  2. dmosk.ru «Установка и настройка Pushgateway для Prometheus».
  3. 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 от разработчика Prometheusprometheus.io.




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




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




# yum -y install mc




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




Ссылка на установку репозитория от разработчика Grafanagrafana.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 для каждой новой версии.




Заходим на сайт разработчика Grafanagrafana.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. Основные компоненты.




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







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




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




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




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







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

# firewall-cmd --complete-reload







Открываем файл конфигурации 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 Fullgrafana.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. Оригиналы источников информации.




  1. prometheus.io «Grafana | Prometheus».
  2. grafana.com«Install on RPM-based Linux (CentOS, Fedora, OpenSuse, Red Hat)».
  3. grafana.com«Node Exporter Fullby idealista».
  4. laurvas.ru «Осваиваем мониторинг с Prometheus. Часть 1. Знакомство и установка.».
  5. eax.me «Устанавливаем связку из Prometheus и Grafana».
  6. 8host.com «Установка и защита Grafana в Ubuntu 16.04».
  7. 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 СУБД, таким, как GraphiteInfluxDBPrometheus. В общем, Grafana рисует для вас красивые графики, используя информацию из Prometheus. Характерно, что у Prometheus есть и собственный web-интерфейс. Однако он предельно прост и довольно неудобен. Поэтому даже сами разработчики Prometheus рекомендуют использовать Grafana.




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




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




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




Ссылки разработчика на GitHubhttps://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/.




Ссылки разработчика на GitHubhttps://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 ExporterNode Exporter предоставляет подробную информацию о системе, включая использование процессора, диска и памяти.




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







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




Ссылки разработчика на GitHubhttps://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 будет генерировать метрики, используя только коллекторы meminfoloadavg и 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.




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




Откроем порт 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







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




Внимание! Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе 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/.




Ссылки разработчика на GitHubhttps://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), использование памяти и так далее.




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




Откроем порт 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







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




Если вы получили сообщение об ошибке, убедитесь, что не допустили ошибок в синтаксисе 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




В выводе должна быть строка Activeactive (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. Оригиналы источников информации.




  1. prometheus.io «Configuration».
  2. fosslinux.com «How to install and configure Prometheus on CentOS 7».
  3. laurvas.ru «Осваиваем мониторинг с Prometheus. Часть 1. Знакомство и установка.».
  4. github.com «No datapoints found. #1022».
  5. eax.me «Устанавливаем связку из Prometheus и Grafana».
  6. habr.com «Мониторинг сервисов с Prometheus».
  7. 8host.com «Установка Prometheus в Ubuntu».
  8. stackoverflow.com «mysqld_exporter DATA SOURCE NAME in mysqld_exporter.service».
  9. dmosk.ru «Установка Prometheus + Alertmanager + node_exporter на Linux».




Источник: https://hamsterden.ru/prometheus/



2021-08-15T20:21:55
Software

Установка и использование Grafana Loki на Linux

В нашей инструкции мы рассмотрим процесс установки и настройки Grafana Loki в качестве сервера сбора логов. Есть несколько способов ее установки — Helm chart, в качестве контейнера Docker, скачать готовый бинарник или собрать его из исходника. Мы выполним установку из последнего на систему Linux. Также, в качестве примера, мы прочитаем лог веб-сервера nginx и сделаем его вывод в Grafana.




Подготовка




Прежде чем устанавливать Loki, подготовим наш сервер для работы.




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




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




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




yum install git wget




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




apt-get install git wget




Установка Go




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







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




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




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




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




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




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




vi /etc/profile




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




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




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




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




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




go version




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




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




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




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




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




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




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




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




apt-get install iptables-persistent




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




netfilter-persistent save




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




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

firewall-cmd --reload




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




2. SELinux




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




setenforce 0

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




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




Установка




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




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




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




cd /usr/src/




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




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




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




cd loki/




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




go build ./cmd/loki




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




mv loki /usr/local/bin/




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




mkdir /etc/loki




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




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




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




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




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




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




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




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




mkdir /opt/loki




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




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




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







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




Автозапуск




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




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




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




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




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




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




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




chown -R loki:loki /etc/loki

chown -R loki:loki /opt/loki




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




vi /etc/systemd/system/loki.service




[Unit]

Description=Grafana Loki Service

After=network.target



[Service]

User=loki

Group=loki

Type=simple

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

ExecReload=/bin/kill -HUP $MAINPID

Restart=on-failure



[Install]

WantedBy=multi-user.target




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




systemctl daemon-reload




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




systemctl enable loki --now




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




systemctl status loki




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




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




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




Установка Promtail




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




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




yum install unzip wget




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




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




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




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




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




unzip promtail-linux-amd64.zip




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




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




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




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




mkdir /etc/promtail




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




vi /etc/promtail/promtail.yaml




server:

  http_listen_port: 9080

  grpc_listen_port: 0



positions:

  filename: /tmp/positions.yaml



clients:

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




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




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




vi /etc/systemd/system/promtail.service




[Unit]

Description=Promtail Service

After=network.target



[Service]

Type=simple

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

ExecReload=/bin/kill -HUP $MAINPID

Restart=on-failure



[Install]

WantedBy=multi-user.target




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




systemctl daemon-reload




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




systemctl enable promtail --now




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




systemctl status promtail




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




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




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




apt-get install iptables-persistent




netfilter-persistent save




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




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




firewall-cmd --reload




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







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




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




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




vi /etc/promtail/promtail.yaml




… и добавляем:




...



scrape_configs:

- job_name: nginx

  static_configs:

  - targets:

      - localhost

    labels:

      job: nginxlogs

      __path__: /var/log/nginx/*log




* где:







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




systemctl restart promtail




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







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




Настройка Grafana




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




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







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







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







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







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




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







Если мы увидели сообщение «Data source connected and labels found.»:







… значит подключение выполнено и можно двигаться дальше.




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







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







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







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







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







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




Парсинг лога




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




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




vi /etc/promtail/promtail.yaml




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




...



scrape_configs:

- job_name: nginx

  static_configs:

  - targets:

      - localhost

    labels:

      job: nginxlogs

      __path__: /var/log/nginx/*log

  pipeline_stages:

    - match:

        selector: '{job="nginxlogs"}'

        stages:

        - regex:

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

        - labels:

            remote_addr:

            remote_user:

            time_local:

            method:

            request:

            protocol:

            status:

            body_bytes_sent:

            http_referer:

            http_user_agent:




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







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




systemctl restart promtail




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







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







Источник: https://www.dmosk.ru/instruktions.php?object=grafana-loki



2021-08-15T19:31:52
Software