Metrics & Monitoring
Metrics & Monitoring
Метрики и Мониторинг
Аббревиатуры и определения
Далее несколько подробнее рассмотрим некоторые из упомянутых аббревиатур и определений:
SLA (Service Level Agreement)
Критерии успешности тестирования.
Например :
- время отклика <= 1 sec.
- утилизация ресурсов компонентов системы < 80%
- процент допустимых ошибок < 1% (формируется из требований по доступности системы)
Корреляция и параметризация
Параметризация позволяет динамически изменять входные данные в тестах, делая их более реалистичными и вариативными.
Данные мы получаем из пула данных (например csv\txt файла), либо рандомизируем(например рандомизируем id клиента).
Корреляция же, является частным случаем параметризации при котором мы получаем данные из ответа от сервиса, для использования в дальнейших запросах (например токен сессии).
RPS & TPS
TPS (Transactions Per Second) и RPS (Requests Per Second) — это метрики, используемые для оценки производительности систем. Они помогают понять, как система справляется с нагрузкой и обрабатывает запросы или транзакции. Давайте рассмотрим их определения, объяснения и отличия.
TPS — это метрика, которая измеряет количество транзакций, которые система может обработать за одну секунду.
Транзакция обычно представляет собой сложный процесс, включающий несколько операций, таких как чтение и запись данных в базу данных, выполнение бизнес-логики и т.д.
RPS — это метрика, которая измеряет количество запросов, которые система может обработать за одну секунду.
Запрос обычно представляет собой более простой процесс, такой как HTTP-запрос к веб-серверу.
Отличия между TPS и RPS
TPS есть ни что иное как метрика транзакций в секунду, где есть запрос и финальный логичный для каждой транзакции ответ.
Транзакция может содержать как один так и несколько запросов.
Как пример можно привести авторизацию пользователя. В данной бизнес транзакции имеется множество запросов отправляемых к бэкенду нашей системы, где логическим завершением является авторизация пользователя.
RPS же это метрика общего кол-ва запросов.
Перцентиль
Перцентили — это статистические метрики, которые используются для оценки производительности системы и понимания распределения времени отклика или других параметров. Они показывают, какой процент запросов или транзакций был выполнен быстрее определенного времени.
Перцентиль - пограничное число, выраженное в процентах, выше которого происходит выход за пределы допустимых требований.
Определение перцентилей:
· 90-й перцентиль (P90): Это значение, ниже которого находится 90% всех измерений. Например, если 90-й перцентиль времени отклика составляет 100 миллисекунд, это означает, что 90% всех запросов были выполнены быстрее или за 100 миллисекунд.
· 95-й перцентиль (P95): Это значение, ниже которого находится 95% всех измерений. Например, если 95-й перцентиль времени отклика составляет 150 миллисекунд, это означает, что 95% всех запросов были выполнены быстрее или за 150 миллисекунд.
Применение перцентилей:
· Оценка производительности: Перцентили помогают понять, как система выполняет запросы и\или транзакции в реальных условиях. Они показывают не только среднее время отклика, но и как система справляется с пиковыми нагрузками.
· Идентификация проблем: Высокие значения перцентилей могут указывать на проблемы с производительностью, такие как узкие места, неэффективные алгоритмы или проблемы с ресурсами.
· Оптимизация: Анализ перцентилей помогает определить, какие части системы требуют оптимизации. Например, если 95-й перцентиль значительно выше 90-го, это может указывать на проблемы с обработкой некоторых типов запросов.
Pacing (Пэйсинг) & Delay (Дилэй, Задержка)
Pacing (Пэйсинг)
Определение:
Пэйсинг — это интервал времени между последовательными итерациями выполнения одного сценария (транзакции) виртуальным пользователем в нагрузочном тестировании.
Для чего нужен?
1) Имитирует реальное поведение пользователей (например, человек не отправляет запросы мгновенно, а делает паузы между действиями).
2) Позволяет контролировать нагрузку на систему (например, ограничить количество запросов в секунду).
3) Помогает избежать неестественной пиковой нагрузки, когда все виртуальные пользователи выполняют запросы одновременно.
Формула: Pacing = Время выполнения сценария + Задержка между итерациями
Delay (Дилэй, Задержка)
Определение:
Delay — это фиксированная или случайная пауза между отдельными шагами внутри одного сценария.
Для чего нужен?
1) Эмулирует время чтения/ввода данных пользователем (например, задержка между заполнением полей формы).
2) Позволяет разнести нагрузку (чтобы сервер не получал все запросы одновременно).
3) Используется для реалистичности теста (например, человек не кликает мгновенно по всем кнопкам).
Каким мы можем сделать из этого выводы:
Pacing контролирует общую нагрузку (сколько раз в минуту выполняется сценарий).
Delay делает отдельные запросы более реалистичными.Правильное сочетание этих параметров помогает точно имитировать поведение реальных пользователей и избегать искусственных сценариев, когда система атакуется тысячами мгновенных запросов.
СНТ (средства нагрузочного тестирования)
Определение:
К средствам нагрузочного тестирования относятся инструменты при помощи которых мы непосредственно подаем нагрузку на наш сервис\систему\продукт.
К ним относятся такие сущности как :
скрипты НТ
генераторы нагрузки
заглушки\эмуляторы и их сервера
адаптеры нагрузки (например посредник между jmeter и брокером сообщений) и их сервера
Функциональные и нефункциональные требования
Определение:
Если кратко функциональные требования отвечают на вопрос “что должна делать система”. Как пример, что и в каком формате должна отвечать тестируемая система.
Нефункциональные требования же отвечают на вопрос “как должна работать система”. Как пример, в случае НТ, какое максимальное время отклика должно быть, % утилизации ресурсов, допустимый % ошибок (% доступности системы) и тд. Именно отсюда мы получаем SLA. Могут быть НФТ, не связанные с НТ, например - требования к безопасности.
💯 Мониторинг
Метрики
Можно рассмотреть метрики с нескольких позиций:
С точки зрения системы:
Метрики тестируемой системы – для оценки ресурсов самой системы
Метрики соседних систем/интеграций/БД/заглушек – для поиска узких мест (может быть ситуация, когда тестируемая система может выдать большую производительность, но упирается в производительность интеграции и тд)
С точки зрения происхождения:
Бизнесовые метрики/прикладные метрики определяются спецификой системы (отдаются самой системой, интеграциями и/или заглушками, нагрузочными инструментами) – к ним можно отнести время отклика на запросы, кол-во запросов, пропущенных системой через себя и тд.
Аппаратные/системные метрики смотрим всегда (отдаются машинами/подами/серверами, на которых находятся части НТ стенда) – к ним можно отнести утилизацию памяти, ЦПУ, дисков и тд.
Так же отдельно следует выделить метрики БД:
Кол-во транзакций проведенных в БД (чаще всего соотносится с кол-вом отправленных запросов в систему)
Процентиль времени выполнения транзакций на БД
Кол-во подключений\коннектов к БД системы – чаще всего является узким местом (на графике выглядит как прямая линия)
Системные метрики сервера, на котором БД находится
Метрики Kafka:
Kafka lag / offset lag / consumer lag - разница topic offset / producer offset / kafka offset и consumer offset. Разница между последним сообщением записанным в топик и считанным из топика consumer или consumer group.
Позволяет взглянуть на производительность системы, которая не предполагает ответных сообщений, что означает невозможность рассчитать время отклика.
Процентиль времени отклика на сообщение - из-за асинхронности взаимодействия возникает необходимость время отправки зашить в тело сообщения или в header сообщения kafka. Далее замеряем время прихода ответа, вычитаем время отправки и получаем время отклика.
RPS/TPS - интенсивность отправки/прихода сообщений в заглушку/сервис.
Рассматриваемые метрики определяются спецификой системы и SLA, определенными заказчиком и/или эмпирическим путем (практическим опытом работы/тестирования системы). Соответственно работа системы оценивается по метрикам – насколько они попадают в SLA.
Минимально необходимый набор метрик и SLA к ним:
Утилизация ЦПУ – 80%
Утилизация памяти – 80%
Время отклика (опционально) – для http сервисов чаще всего 1-2 секунды, для кафки 500 – 1000 мс.
Метрики утилизации БД (опционально) – см пункты а, b
Кол-во запросов, подающихся в систему – SLA.
Процентиль:
n-й перцентиль является таким значением “t”, что в анализируемой выборке n% значений меньше или равны “t”, а оставшиеся—больше чем “t”. «90-й процентиль времени отклика системы составляет 600 миллисекунд».
Это означает, что 90 % запросов выполняются со временем отклика, меньшим либо равным 600 миллисекунд, а 10 % запросов выполняются более, чем за 600 мс.
Сбор/Хранение/Просмотр
Сбор метрик осуществляют агенты. Далее метрики отправляются агентами в хранилище (чаще всего в БД временных рядов – описание ниже). Из хранилища выводим в grafana (Есть и другие способы получения графиков, но они не будут рассмотрены в рамках текущего курса).
Агенты: Zabbix, Telegraf, Micrometer, FileBeat
Хранилища: Prometheus, InfluxDB, elastic
Средства просмотра: Kibana, Grafana
БД временных рядов:
Базы данных временных рядов (Time Series Databases) – что это такое и зачем вам нужно еще одно хранилище данных в своей среде.
Для чего нужны базы данных временных рядов?
Базы данных временных рядов предназначены для хранения данных, которые изменяются со временем. Это могут быть абсолютно любые данные, собранные с течением времени. Это могут быть метрические показатели, собранные из некоторых систем – все системы трендов являются примерами данных временных рядов.
Временные ряды не ограничиваются метрическими показателями базы данных. Метриками может быть что угодно – изменение потока людей, входящих в торговый центр, с течением времени, изменение трафика в городе, использование общественного транспорта в течение дня, течение воды в реке или ручье, количество энергии, вырабатываемое водной установкой – все это и все остальное, что можно измерить во времени, является примером временных рядов. Такие данные можно запросить, построить, проанализировать, чтобы найти корреляционную зависимость между различными метриками.
Структура данных в базе данных временных рядов
Как вы понимаете, самая важная составляющая данных в базе данных временных рядов – это время. Существует два основных способа хранения данных. Первый способ чем-то похож на хранилище «ключ-значение» и выглядит так:
Проще говоря, для каждой метки времени имеется некоторое значение метрики.
Второй способ подразумевает хранения большего числа показателей. Вместо того, чтобы хранить каждую метрику в отдельной таблице или коллекции, их можно хранить вместе.
Такая структура данных, когда все метрики связаны, позволяет более эффективно запрашивать данные. Вместо того, чтобы читать несколько таблиц и объединять их для получения всех метрик, достаточно прочитать лишь одну единственную таблицу, чтобы подготовить данные к обработке и представлению.
У вас может возникнуть вопрос – что же здесь нового? Чем эта база данных отличается от обычной таблицы в MySQL или в любой другой реляционной базе данных? Да, действительно, конструкция таблиц очень похожа. Однако есть существенные различия в рабочей нагрузке, которые могут существенно повысить производительность, если хранилище данных предназначено для использования такого рода таблиц.
Временные ряды, как правило, только растут. Маловероятно, что вы будете обновлять старые данные. Чаще всего строки в таблице не удаляются, однако вам может понадобиться какая-то агрегация данных с течением времени. Если принять это при проектировании внутреннего устройства базы данных, то этот факт будет иметь существенное расхождение в сравнении со «стандартными» реляционными (и не реляционными) базами данных, предназначенными для обработки транзакций в режиме реального времени. Что здесь является наиболее важным, так это способность последовательно хранить большие объемы данных, поступающих со временем.
Можно, конечно, использовать РСУБД для хранения временных рядов, но она не оптимизирована для этого. Данные и индексы, сгенерированные на ее основе, могут стать слишком большими, и запросы будут проходить очень медленно. Механизмы хранения данных, используемые в СУБД, предназначены для хранения различных типов данных. Обычно они оптимизированы для рабочей нагрузки обработки транзакций в режиме реального времени, которая включает в себя частое изменение и удаление данных. В реляционных базах данных также часто отсутствуют специализированные функции и функции, предназначенные для обработки временных рядов. Мы уже упоминали, что вы вероятно столкнетесь с необходимостью агрегировать данные, полученные ранее какой-то временной метки. Вы также можете иметь возможность легко запускать некоторые статистические функции для ваших временных рядов, чтобы сглаживать их, определять и сравнивать тренды, интерполировать данные и многое другое.
InfluxDB
Знакомство с InfluxDB и базами данных временных рядов
Установка telegraf и передача метрик в InfluxDB
InfluxDB, база данных временных рядов (TSDB), разработанная InfluxData.
Производство данных осуществляется агентами, которые нацеливаются на специальные элементы в инфраструктуре и извлекают из них метрики. Такие агенты называются «агентами мониторинга». Вы можете легко настроить их для запроса данных за определенный промежуток времени. Примерами являются Telegraf (который является официальным агентом мониторинга), CollectD или StatsD.
Язык запросов InfluxDB
(Наше целевое решение v1.9+)
Прежде чем начать, важно знать, какую версию InfluxDB вы используете в настоящее время. InfluxDB выпускается в двух версиях: v1.9+ и v2.0+.
InfluxDB v2.0+ в настоящее время использует язык Flux. InfluxDB v1.9+ оснащён языком InfluxQL (а также Flux, если его активировать).
InfluxQL — это язык запросов, который очень похож на SQL, и позволяет любому пользователю запрашивать свои данные и фильтровать их. Вот пример запроса InfluxQL:
SELECT FROM cpu_metrics WHERE time < now() - 10ms
База данных
База данных — само по себе простое для понимания понятие, потому что вы привыкли использовать этот термин в реляционных базах данных. В SQL-среде БД будет содержать набор таблиц и схем и будет представлять один экземпляр самостоятельно.
В InfluxDB БД содержит набор измерений. Однако один экземпляр InfluxDB может содержать несколько баз данных. В этом его отличие от традиционных систем. Эта логика подробно представлена на графике ниже:
Наиболее распространённые способы взаимодействия с базами данных — это либо их создание (CREATE DATABASE “devconnected”;), либо переход в них (USE devconnected;) для просмотра коллекций (вы должны быть «в базе данных», чтобы запрашивать коллекции, иначе это не сработает).
Измерение
Как показано выше, база данных хранит несколько измерений (measurement). Для простоты восприятия думайте об измерении как о таблице SQL. Она хранит данные и даже метаданные в разные моменты времени. Данные, которые должны сосуществовать вместе, должны храниться в одном измерении.
SELECT FROM cpu_metrics WHERE temperature=’40’;
Теги и поля
Обратите внимание, есть тонкая разница между тегами и полями.
Для тех, кто впервые начинает работать с InfluxDB, будет трудно понять, чем отличаются теги и поля. Они похожи на «столбцы», где вы можете хранить точно такие же данные. Определяя новый «столбец» в InfluxDB, вы можете либо объявить его как тег, либо как значение, и между ними есть различия.
Самая большая разница между ними заключается в том, что теги индексируются, а значения — нет. Теги можно рассматривать как метаданные, определяющие данные в измерении. Они отличают поля/метрики друг от друга. Это подсказки, дающие дополнительную информацию о данных, но не сами данные. В то время как поля — это сами данные, метрики. В прошлом примере столбец «температура» был бы полем.
Вернемся к примеру cpu_metrics. Допустим, вы хотите добавить столбец с именем «location», определяющий местоположение датчика.
Что вам выбрать: тег или поле?
В данном случае стоит выбрать тег. Необходимо, чтобы столбец «местоположение» индексировался и учитывался при выполнении запроса к местоположению.
Хорошей практикой будет держать измерения относительно небольшими, когда речь идёт о большом количестве полей. Большее количество полей часто связано с меньшей производительностью. Вы можете создать другие измерения\measurement, чтобы сохранить другое поле и правильно его проиндексировать.
Теперь, когда мы добавили метку местоположения в измерение, немного углубимся в таксономию.
Набор тега называется «tag set». Имя столбца в теге называется «tag key». Значения тега называются «tag values». Та же систематика повторяется для полей. Вернёмся к чертежам.
Временная метка
Временная метка (timestamp) — наверное, самое простое для определения ключевое слово. В InfluxDB — это дата и время, определённые в формате RFC3339. При использовании InfluxDB очень часто определяют столбец времени как метку в Unix-времени, выраженную в наносекундах.
Вы можете выбрать формат наносекунд для временного столбца и позже снизить точность, добавляя нули в конец значения, чтобы оно соответствовало формату наносекунд.
Политика хранения (Retention policy)
Политика хранения определяет, как долго вы собираетесь хранить ваши данные. Политики хранения определяются для каждой базы данных и их может быть несколько. По умолчанию политика хранения будет autogen и хранит ваши данные вечно. Как правило, базы данных имеют несколько политик хранения, которые используются для разных целей.
Представим, что вы используете InfluxDB для оперативного мониторинга всей инфраструктуры.
Например, вы хотите знать, когда сервер отключается. В этом случае вас интересуют данные, поступающие с этого сервера в настоящий момент или за несколько минут до этого. Вы не заинтересованы в хранении данных в течение нескольких месяцев, поэтому хотите определить небольшую политику хранения: например один или два часа.
Предположим, вы используете InfluxDB для IoT, например для сбора данных, поступающих из резервуара для воды. Позже вы захотите поделиться своими данными с группой научных специалистов, чтобы они могли их проанализировать. В этом случае вы можете хранить данные дольше: например пять лет.
Точка
Точка (point) — это просто набор полей с одинаковой отметкой времени. В SQL это будет выглядеть как строка или как уникальная запись в таблице. Здесь нет ничего особенного.
Агенты InfluxDB
Агентами/сборщиками данных для InfluxDB, могут быть:
Сами инструменты НТ (при условии реализации в них отправки метрик в нужном формате)
Заглушки (при условии реализации в них отправки метрик в нужном формате)
Telegraf - чаще всего используемый агент для сбора метрик с серверов/машин Linux и Windows (при дополнительной настройке)
Гайд по установке и настройке Telegraf + InfluxDB
Настройка сервера
Если у нас уже есть сервер баз данных, совместимый с telegraf, можно пропустить данный раздел. В противном случае, рассмотрим процесс подготовки сервера и установки InfluxDB. В данной инструкции мы будем разворачивать сервер баз данных на Linux, но при необходимости, InfluxDB может быть установлен на Windows.
Время
Для любой базы хранения временных рядов важно своевременно обновлять время на сервере.
Задаем временную зону:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
в данном примере задаем московское время. В каталоге /usr/share/zoneinfo список всех возможных вариантов.Устанавливаем и запускаем сервис для автоматической синхронизации времени.
в CentOS / Red Hat / Fedora:
yum install chrony
systemctl enable chronyd --now
Брандмауэр
Если мы используем фаервол, то необходимо открыть порт 8086, на котором по умолчанию запускается данный сервер баз данных. В зависимости от используемой утилиты управления, команды будут отличаться.
Firewalld
По умолчанию, используется в системах на базе RPM. Для открытия нужного нам порта вводим команды:
firewall-cmd --permanent --add-port=8086/tcp
firewall-cmd --reload
Iptables
Чаще всего, используется в системах на базе DEB или в ранних версиях RPM. Вводим команду:
iptables -I INPUT 1 -p tcp --dport 8086 -j ACCEPT
... и сохраняем правила:
netfilter-persistent save
если система вернет ошибку, что программа не установлена, выполним инсталляцию командой apt-get install netfilter-persistent.SELinux (на работе трогать не стоит)
По умолчанию, пакет безопасности SELinux установлен на системах RPM. Чаще всего, его выключают командами:
setenforce 0
sed -i 's/^SELINUX=./SELINUX=disabled/g' /etc/selinux/config
Установка и настройка InfluxDB
Один из способов установки, скачивание из репозитория (может быть настроен заранее на рабочем месте):
vi /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL $releasever
baseurl = https://repos.influxdata.com/rhel/$releasever/$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
Можно устанавливать InfluxDB:
yum install influxdb
Разрешаем автоматический запуск сервиса и стартуем его:
systemctl enable influxdb --now
или:
systemctl enable influxdb
systemctl start influxdb
Второй способ установки, через rpm пакет (скорее всего установка будет проводиться таким образом):
установка из пакета:
yum install influxdb-*.rpm
Разрешаем автоматический запуск сервиса и стартуем его:
systemctl enable influxdb --now
или:
systemctl enable influxdb
systemctl start influxdb
Установка Telegraf на Linux
Выполним установку Telegraf для различных операционных систем. В зависимости от текущей версии агента, команды будут разные. Поэтому мы переходим на страницу загрузки influxdata и кликаем по последней версии telegraf:
на момент написания инструкции это была v1.14.1.В открывшемся окне мы увидим конкретные команды для загрузки и установки Telegraf под различные операционные системы.
Устанавливаем утилиту для загрузки файлов:
yum install wget
Согласно инструкции на сайте influxdata.com, загружаем пакет установки, либо сразу переходим к установке, если файл уже есть (самый вероятный вариант):
wget https://dl.influxdata.com/telegraf/releases/telegraf-1.14.1-1.x86_64.rpm
напоминаю, что версия может быть другой.Устанавливаем загруженный пакет:
yum localinstall telegraf-
.rpmили
yum install telegraf-.rpm
Установка Telegraf на Windows
Скачиваем архив по ссылке на сайте. На момент написания инструкции, это было:
Для x32 (i386) — https://dl.influxdata.com/telegraf/releases/telegraf-1.14.1_windows_i386.zip.
Для x64 (amd64) — https://dl.influxdata.com/telegraf/releases/telegraf-1.14.1_windows_amd64.zip.
Создаем каталог Telegraf в папке Program Files. В моем случае, получился путь C:\Program Files\Telegraf. Распаковываем в него содержимое скачанного архива — файлы telegraf.conf и telegraf.exe.
Теперь открываем командную строку от администратора и запускаем установку Telegraf в качестве службы:
"C:\Program Files\Telegraf\telegraf.exe" --service install
Настройка telegraf и отправка данных в InfluxDB
Независимо от операционной системы, создание конфига происходит в командной строке. Рассмотрим процедуры генерирования конфигурационного файла, настройки сервера баз данных и запуска агента по сбору метрик.
Создание конфигурационного файла для telegraf
В командной строке переходим в каталог с конфигом телеграфа.
а) в Linux:
cd /etc/telegraf
б) в Windows:
cd "c:\Program Files\Telegraf"
если мы установили агент в другой каталог, переходим в него.Затем генерируем конфигурационный файл. Синтаксис для команды следующий:
telegraf -sample-config --input-filter <плагины сбора метрик через ":"> --output-filter <плагины передачи данных с метрик через ":"> > <имя конфигурационного файла>
на странице https://docs.influxdata.com/telegraf/latest/plugins/ можно найти список всех доступных плагинов.Если мы введем команду:
telegraf -sample-config > telegraf.conf
Лучше создавать конфигурационный файл с нужными нам плагинами. Например, создадим конфиг для получения метрик дисковой системы с помещением данных в InfluxDB:
telegraf -sample-config --input-filter disk:diskio:hddtemp --output-filter influxdb > telegraf.conf
перечень плагинов для получения метрик идет после ключа --input-filter; после --output-filter мы перечисляем системы, для отправки в которые будут подготовлены данные — в нашем случае это influxdb. Также это могут быть Elasticsearch, Graphite, OpenTSDB, Prometheus и другие.Проверить полученный конфигурационный файл можно командой:
telegraf --test
если путь до конфигурационного файла отличается от стандартного, его можно указать с помощью ключа --config.Если в настройках telegraf будут ошибки, мы увидим:
[telegraf] Error running agent:
Настройка адреса базы
Как правило, сервер баз данных находится на одном сервере, но по умолчанию, в telegraf создается конфигурационный файл для отправки метрик на локальный сервер баз данных. Чтобы изменить настройку, открываем созданный нами ранее конфиг.
а) в Linux с помощью текстового редактора, например:
vi /etc/telegraf/telegraf.conf
б) в Windows также текстовым редактором, например, обычным блокнотом или Notepad++.
Находим строку в разделе OUTPUT PLUGINS:
urls = ["http://127.0.0.1:8086"]
Снимаем комментарий и меняем адрес сервера, например:
urls = ["http://192.168.1.16:8086"]
где 192.168.1.16 — IP-адрес нашего сервера баз данных.Если наш сервер баз данных требует аутентификации, добавим 2 строки:
username = "username"
password = "userpass"
где username и password — соответственно, логин и пароль для подключения к базе.Запуск агента
Процедуры в Linux и Windows немного отличаются.
В Linux
Разрешаем автозапуск telegraf:
systemctl enable telegraf
Перезапускаем сервис:
systemctl restart telegraf
В Windows
Открываем службы Windows. Находим службу Telegraf Data Collector Service - открываем ее. Проверяем, чтобы тип запуска был автоматический и кликаем по Запустить:
Также запустить службу можно из командной строки:
net start telegraf
Проверка данных в базе
Чтобы завершить настройку, необходимо убедиться, что данные с метрик приходят в нашу базу. Для этого на сервере InfluxDB вводим команду:
Проверка данных в базе
Чтобы завершить настройку, необходимо убедиться, что данные с метрик приходят в нашу базу. Для этого на сервере InfluxDB вводим команду:
influx
Мы подключимся к базе. Смотрим список баз:
> show databases
если influxdb требует аутентификации, то мы получим ошибку ERR: unable to parse authentication credentials. Необходимо сначала ввести команду auth и последовательно логин и пароль.Мы должны увидеть базу telegraf:
name: databases
name
----
_internal
telegraf
Подключаемся к базе и смотрим список таблиц:
> use telegraf
> show measurements
Смотрим список значений для нужной нам метрики, например, для diskio:
> SELECT FROM diskio ORDER BY time DESC LIMIT 15
так как значений будет очень много, лучше ограничить вывод — в данном примере последних 15 записей.Чтобы получить данные для определенного хоста, вводим запрос:
SELECT FROM diskio WHERE host='server1' ORDER BY time DESC LIMIT 15
в данном примере мы получим данные, которые пришли с компьютера server1.Prometheus
Полное руководство по Prometheus в 2019 году
Система мониторинга Prometheus | Рег.ру
Federation | Prometheus
Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.
Prometheus обладает очевидной ценностью и уже используется новаторами в отрасли, вроде DigitalOcean или Docker, как часть системы полного мониторинга.
Сначала идет полный обзор Prometheus, его экосистемы и основных аспектов быстро развивающейся технологии.
Потом приводятся объяснения технических терминов Prometheus с иллюстрациями. Если вы не знаете, что такое метрики, ярлыки, экземпляры или экспортеры, вам сюда.
Наконец, мы опишем различные реальные сценарии использования Prometheus. Здесь вы вдохновитесь примерами успешных компаний.
Часть I. Что такое Prometheus?
Prometheus — это база данных временных рядов. Если вы не в курсе, что такое база данных временных рядов, почитайте первую часть руководства по InfluxDB.
Но Prometheus — не просто база данных временных рядов.
К нему можно присоединить целую экосистему инструментов, чтобы расширить функционал.
Prometheus мониторит самые разные системы: серверы, базы данных, отдельные виртуальные машины, да почти что угодно.
Для этого Prometheus периодически скрейпит (опрашивает на наличие метрик) свои целевые объекты.
Prometheus извлекает метрики через HTTP-вызовы к определенным конечным точкам, указанным в конфигурации Prometheus.
Возьмем, например, веб-приложение, расположенное по адресу http://localhost:3000
. Приложение передает метрики в текстовом формате на некоторый URL. Допустим, http://localhost:3000/metrics.
По этому адресу Prometheus с определенными интервалами извлекает данные из целевого объекта.
1. Как работает Prometheus?
Как мы уже сказали, Prometheus состоит из самых разных компонентов.
Во-первых, вам нужно, чтобы он извлекал метрики из ваших систем. Тут есть разные способы:
Инструментирование приложения, то есть ваше приложение будет предоставлять совместимые с Prometheus метрики по заданному URL. Prometheus определит его как целевой объект и будет скрейпить с указанным интервалом.
Использование готовых экспортеров. В Prometheus есть целая коллекция экспортеров для существующих технологий. Например, готовые экспортеры для мониторинга машин Linux (Node Exporter), для распространенных баз данных (SQL Exporter или MongoDB Exporter) и даже для балансировщиков нагрузки HTTP (например, HAProxy Exporter).
Использование Pushgateway. Иногда приложения или задания не предоставляют метрики напрямую. Они могут быть не предназначены для этого (например, пакетные задания) или вы сами решили не предоставлять метрики напрямую через приложение.
Как вы уже поняли, Prometheus сам собирает данные (исключая редкие случаи, когда мы используем Pushgateway).
2. Сбор vs. отправка (InfluxDB vs Prometheus)
У Prometheus есть заметное отличие от других баз данных временных рядов: он активно сканирует целевые объекты, чтобы получить у них метрики.
InfluxDB, например, работает иначе: вы сами напрямую отправляете ему данные.
Оба подхода имеют свои плюсы и минусы. На основе доступной документации мы составили список причин, по которым создатели Prometheus выбрали такую архитектуру:
Централизованный контроль. Если Prometheus отправляет запросы целевым объектам, всю настройку мы выполняем на стороне Prometheus, а не отдельных систем.
Если объекты сами отправляют данные, есть риск, что таких данных будет слишком много, и на сервере произойдет сбой. Когда система собирает данные, можно контролировать частоту сбора и создавать несколько конфигураций скрейпинга, чтобы выбирать разную частоту для разных объектов.
Prometheus хранит агрегированные метрики.
Дополнение к первой части, где мы обсуждали роль Prometheus.
Prometheus не основан на событиях и этим сильно отличается от других баз данных временных рядов. Он не перехватывает отдельные события с привязкой ко времени (например, перебои с сервисом), а собирает предварительно агрегированные метрики о ваших сервисах.
Если конкретно, веб-сервис не отправляет сообщение об ошибке 404 и сообщение с причиной ошибки. Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут.
Это главное различие между базами данных временных рядов, которые собирают агрегированные метрики, и теми, что собирают необработанные метрики.
3. Развитая экосистема Prometheus
По сути Prometheus — база данных временных рядов.
Но при работе с такими базами данных часто нужно визуализировать данные, анализировать их и настраивать по ним оповещения.
Prometheus поддерживает следующие инструменты, расширяющие его функционал:
Alertmanager. Prometheus отправляет оповещения в Alertmanager на основе кастомных правил, определенных в файлах конфигурации. Оттуда их можно экспортировать в разные конечные точки (например, Pagerduty или Slack).
Визуализация данных. Как и в Grafana, вы можете визуализировать временные ряды прямо в пользовательском веб-интерфейсе Prometheus. Вы можете фильтровать данные и составлять конкретные обзоры происходящего в разных целевых объектах.
Обнаружение сервисов. Prometheus динамически обнаруживает целевые объекты и автоматически скрейпит новые цели по запросу. Это особенно удобно, если вы работаете с контейнерами, которые динамически меняют адреса в зависимости от спроса.
Часть II. Концепции Prometheus
1. Модель данных «ключ-значение»
Прежде чем перейти к инструментам Prometheus, важно полностью разобраться в этой модели данных.
Prometheus работает с парами «ключ-значение». Ключ описывает, что мы измеряем, а значение хранит фактическую величину в виде числа.
Помните: Prometheus не создан для хранения необработанной информации, вроде обычного текста. Он хранит метрики, агрегированные за период времени.
Ключом в данном случае называется метрика. Это, например, скорость процессора или занятый объем памяти.
Но что если нужно больше деталей о метрике?
Например, у процессора 4 ядра, и нам нужно 4 отдельных метрики?
И здесь на помощь приходят ярлыки (Labels). Ярлыки дают больше сведений о метриках, добавляя дополнительные поля. Например, вы описываете не просто скорость процессора, а скорость одного ядра по определенному IP.
Потом вы сможете фильтровать метрики по ярлыкам и просматривать только нужную информацию.
2. Типы метрик
При мониторинге с Prometheus метрики можно описать четырьмя способами. Лучше дочитайте до конца, потому что здесь есть подводные камни.
Счетчик (Counter)
Это, наверное, самый простой тип метрик. Счетчик, как понятно из названия, считает элементы за период времени.
Если вы хотите посчитать, например, ошибки HTTP на серверах или посещения веб-сайта, используйте счетчик.
И по логике, разумеется, счетчик может только увеличивать или обнулять число, поэтому не подходит для значений, которые могут уменьшаться, или для отрицательных значений.
С его помощью особенно удобно считать количество наступлений определенного события за период времени, т. е. показатель изменения метрики со временем.
А если нужно измерить, допустим, используемую память за определенный период?
Эта величина может уменьшаться. Как посчитать ее с Prometheus?
Измерители (Gauge)
Измерители имеют дело со значениями, которые со временем могут уменьшаться. Их можно сравнить с термометрами — если посмотреть на термометр, увидим текущую температуру.
Но если измерители могут увеличиваться и уменьшаться и принимать положительные и отрицательные значения, то выходит, они лучше счетчиков?
Значит, счетчики — бесполезны?
Поначалу и я так думал. Раз они могут все, давайте использовать их везде.
Измерители идеально подходят для измерения текущего значения метрики, которое со временем может уменьшиться.
Вот тут-то и кроются те самые подводные камни: измеритель не показывает развитие метрики за период времени. Используя измерители, можно упустить нерегулярные изменения метрики со временем.
Почему? Вот что говорит /u/justinDavidow:
«Измеритель показывает среднее значение дельты счетчика для единицы за период времени.
Счетчик учитывает каждую использованную единицу (если это процессор, то операции, циклы или такты), а потом вы можете выбрать, показатели за какой период вам нужны.
Если вы используете измеритель, частота выборки должна быть точной. Если частота отличается хотя бы на несколько микросекунд, значение будет недостоверным. Это еще более заметно при большой нагрузке, где время между измерениями возрастает в геометрической прогрессии, потому что планировщик системы не успевает уделять внимание приложению мониторинга».
Если система отправляет метрики каждые 5 секунд, а Prometheus скрейпит целевой объект каждые 15, в процессе можно потерять некоторые метрики. Если выполнять дополнительные вычисления с этими метриками, точность результатов окажется еще ниже.
У счетчика каждое значение агрегировано. Когда Prometheus собирает его, он понимает, что значение было отправлено в определенный интервал.
Гистограмма (Histogram)
Гистограмма — это более сложный тип метрики. Она предоставляет дополнительную информацию. Например, сумму измерений и их количество.
Значения собираются в области с настраиваемой верхней границей. Поэтому гистограмма может:
Рассчитывать средние значения, то есть сумму значений, поделеную на количество значений.
Рассчитывать относительные измерения значений, и это очень удобно, если нужно узнать, сколько значений в определенной области соответствуют заданным критериям. Особенно это полезно, если нужно отслеживать пропорции или установить индикаторы качества. В том числе и процентили !!!
В реальном мире я бы хотел получать оповещение, если у 20% моих серверов отклик больше 300 мс или отклик серверов больше 300 мс более 20% времени.
Если вы имеете дело с пропорциями, вам нужны гистограммы.
Саммари (Summary)
При экспорте Summary создает несколько временных рядов:
Это означает:
50% запросов обрабатываются ≤ 0.2 сек.
90% запросов — ≤ 0.5 сек.
99% запросов — ≤ 1.2 сек.
Всего 9876 запросов, их общее время обработки — 12345.6 сек.
Когда использовать Summary?
✅ Подходит для:
Измерения латентности API, БД, RPC-вызовов.
Когда нужны точные перцентили (а не аппроксимация, как в Histogram).
Когда невозможно заранее задать границы бакетов (как в Histogram).
❌ Не подходит для:
Агрегации данных между несколькими сервисами (квантили нельзя просто сложить).
Сценариев, где важна гибкость анализа (в Histogram можно пересчитывать квантили после сбора).
Примеры запросов PromQL для Summary (могут отличаться названия метрик от проекта к проекту)
Summary — это расширенные гистограммы. Они тоже показывают сумму и количество измерений, а еще квантили за скользящий период.
Квантили, если что, — это деление плотности вероятности на отрезки равной вероятности.
Итак: гистограммы или cаммари?
Все зависит от намерения.
Гистограммы объединяют значения за период времени, предоставляя сумму и количество, по которым можно отследить развитие определенной метрики.
Сводки, с другой стороны, показывают квантили за скользящий период (т. е. непрерывное развитие во времени).
Это особенно удобно, если вам нужно узнать значение, которое представляет 95% значений, записанных за период.
3. Задание (Job) и экземпляр (Instance)
Job — это логическая группа экземпляров (сервисов, нод, контейнеров), выполняющих одну и ту же функцию.
Примеры заданий:
web-server — все инстансы веб-серверов.
database — все реплики PostgreSQL.
redis-cache — пул Redis-серверов.
Instance — это конкретная цель для сбора метрик (например, один сервер, контейнер или процесс).
Примеры экземпляров:
10.0.0.1:8080 — один веб-сервер.
db-1:5432 — мастер-нода БД.
Учитывая последние успехи в распределенных архитектурах и популярность облачных решений, вряд ли вы используете одинокий сервер, работающий сам по себе.
Серверы реплицируются и распределяются по всему миру.
Чтобы это проиллюстрировать, давайте рассмотрим классическую архитектуру из двух серверов HAProxy, которые перераспределяют нагрузку по девяти бэкенд-веб-серверам.
В этом примере из реальной жизни мы отследим число ошибок HTTP, возвращенных веб-серверами.
На языке Prometheus один веб-сервер называется экземпляром. Заданием будет тот факт, что вы измеряете число ошибок HTTP на всех экземплярах.
Прелесть в том, что задания и экземпляры — это поля в ярлыках, и вы можете фильтровать результаты по определенному экземпляру или заданию.
Как задается Job?
В конфигурации Prometheus (в scrape_configs):
Как задается Instance?
Через поле targets в конфиге Prometheus:
4. PromQL
Если вы используете базы данных на основе InfluxDB, вы, наверное, уже знакомы с InfluxQL. Или используете SQL в TimescaleDB.
У Prometheus тоже есть свой язык для запросов и извлечения данных с серверов: PromQL.
Как мы уже знаем, данные представлены в виде пар «ключ-значение». PromQL использует тот же синтаксис и возвращает результаты в виде векторов.
В Prometheus и PromQL есть два вида векторов:
Моментальные векторы, которые представляют все метрики по последней метке времени.
Векторы с диапазоном времени: если вам нужно посмотреть развитие метрики со временем, вы можете указать диапазон времени в запросе к Prometheus. В итоге получите вектор, объединяющий все значения, записанные за выбранный период.
PromQL API предоставляет набор функций для операций с данными в запросах.
Вы можете сортировать значения, применять к ним математические функции (например, рассчитывать производные или экспоненты) и даже строить прогнозы (например, по модели Хольта-Уинтерса).
5. Инструментирование
Инструментирование — это еще одна важная часть Prometheus. Вы инструментируете приложения, прежде чем извлекать из них данные.
На языке Prometheus инструментирование означает добавление клиентских библиотек в приложение, чтобы они предоставляли метрики Prometheus.
Инструментирование доступно для большинства распространенных языков программирования: например, Python, Java, Ruby, Go и даже Node или C#.
По сути, вы создаете объекты памяти (например, измерители или счетчики), которые будут динамически увеличивать или уменьшать значение.
Потом вы выбираете, где предоставлять метрики. Prometheus заберет их оттуда и сохранит в свою базу данных временных рядов.
6. Экспортеры/Агенты
В написанных вами приложениях очень удобно настраивать предоставляемые метрики и их изменение со временем с помощью инструментирования.
Для известных приложений, серверов и баз данных Prometheus предлагает экспортеры, с помощью которых можно мониторить целевые объекты.
Эти экспортеры обычно представлены в виде образов Docker и легко настраиваются. Они предоставляют готовый набор метрик и часто готовые панели мониторинга, с которыми можно настроить мониторинг за считанные минуты.
Примеры экспортеров:
Экспортеры баз данных: для баз данных MongoDB, серверов SQL и MySQL.
Экспортеры HTTP: для серверов HAProxy, Apache или NGINX.
Экспортеры Unix: производительность системы можно отслеживать с помощью встроенных экспортеров узлов, которые предоставляют все системные метрики без дополнительной настройки.
Пара слов о взаимной совместимости
Большинство баз данных временных рядов поддерживают взаимную совместимость для своих систем.
Prometheus не единственная система мониторинга со своими требованиями к предоставлению метрик. Например, у InfluxDB (через Telegraf), CollectD, StatsD и Nagios тоже есть свои стандарты.
Поэтому для взаимодействия разных систем создаются экспортеры. Даже если Telegraf отправляет метрики не в том формате, который принимает Prometheus, Telegraf может послать эти метрики в экспортер InfluxDB, откуда их потом заберет Prometheus.
7. Оповещения
При работе с базами данных временных рядов вам нужна обратная связь от данных, и за это отвечают менеджеры оповещений.
В Grafana оповещения обычное дело, но они доступны и в Prometheus через менеджер оповещений.
Менеджер оповещений — это отдельный инструмент, который присоединяется к Prometheus и запускает кастомные оповещатели.
Оповещения определяются в файле конфигурации и задают набор правил для метрик. Если во временных рядах возникает соответствие правилу, оповещение инициируется и отправляется заданным получателям.
Как и в Grafana, в качестве получателя можно указать электронный адрес, вебхук Slack, PagerDuty и кастомные HTTP-объекты.
Установка Prometheus
На официальном сайте Prometheus скопируйте ссылку на установочный пакет для Linux:
Если у вас нет wget, то перед началом работы с Prometheus установите этот пакет.
wget https://github.com/prometheus/prometheus/releases/download/v2.20.1/prometheus-2.20.1.linux-amd64.tar.gz
Распакуйте архив:
tar -xvzf prometheus-2.20.1.linux-amd64.tar.gz prometheus-2.20.1.linux-amd64/
Скопируйте исполняемые файлы в /usr/local/bin/:
cd prometheus-2.20.1.linux-amd64/
cp prometheus /usr/local/bin/
cp promtool /usr/local/bin/
Создайте папку для файлов конфигурации и скопируйте в неё конфиги:
cp -r consoles/ /etc/prometheus/consoles/
cp -r console_libraries/ /etc/prometheus/console_libraries/
cp prometheus.yml /etc/prometheus/
Создайте папку для хранения данных:
mkdir /var/lib/prometheus
Создайте пользователя и назначьте владельца файлов и папок:
useradd -M -r -s /bin/nologin prometheus
chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus
Создайте systemd-юнит, чтобы удобнее управлять сервисом/службой в Линуксе:
vim /etc/systemd/system/prometheus.service
Впишите в файл конфигурацию сервиса Prometheus:
[Unit]
Description=Prometheus systemd service unit
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=prometheus
Group=prometheus
ExecReload=/bin/kill -HUP $MAINPID
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 \
--web.listen-address=0.0.0.0:9090
SyslogIdentifier=prometheus
Restart=always
[Install]
WantedBy=multi-user.target
Обновите список юнитов:
systemctl daemon-reload
Запустите Prometheus:
systemctl start prometheus.service
Для автоматической загрузки Prometheus введите:
systemctl enable prometheus.service
Created symlink /etc/systemd/system/multi-user.target.wants/prometheus.service → /etc/systemd/system/prometheus.service
Готово, теперь Prometheus доступен по адресу Host:9090:
Установка экспортеров
Установка экспортеров для Prometheus — это процесс развертывания специальных агентов, которые собирают метрики с целевых систем (серверов, баз данных, приложений) и предоставляют их в формате, понятном Prometheus. Вот пошаговая инструкция для разных типов экспортеров.
Общий алгоритм установки
Для большинства экспортеров шаги будут одинаковыми:
1.Скачать бинарный файл или пакет экспортера.
2. Запустить экспортер на целевом хосте.
3. Настроить Prometheus на сбор метрик с этого экспортера.
(Опционально) Настроить систему управления (systemd, docker и т.д.).
Установка Node Exporter (для мониторинга Linux-серверов)
Способ 1: Вручную (бинарный файл) (bash)
Способ 2: Через systemd для автозапуска (bash)
Проверка
Откройте в браузере:
http://
Должны увидеть метрики в формате Prometheus.
Установка Windows Exporter (для мониторинга Windows)
Способ 1: Через MSI-инсталлятор
Скачайте последний .msi-файл с официального GitHub (https://github.com/prometheus-community/windows_exporter/releases).
Запустите установку (powershell, но можно через командную строку):
Экспортер запустится на порту 9182.
Способ 2: Через PowerShell (ручная установка)
Проверка
Откройте:
http://localhost:9182/metrics
Установка экспортеров для баз данных
Postgres Exporter (bash)
MySQL Exporter (bash)
Настройка Prometheus
Добавьте в prometheus.yml новые targets:
Перезапустите Prometheus (bash):
Дополнительные экспортеры
Docker-экспортеры
Для контейнеризованных приложений используйте готовые образы (bash):
Проверка работы
Откройте Prometheus UI: http://
Все targets должны быть в статусе UP.
Или выполните запрос в Grafana (promql):
Полезные команды
Поиск экспортеров: Prometheus Ecosystem https://prometheus.io/docs/instrumenting/exporters/.
Логи экспортера (bash):
Тест метрик (bash):
Micrometer
Применение Micrometer в заглушках (mock/stub) для Java Spring-приложений (с Maven и Gradle) позволяет собирать метрики даже в тестовой среде. Вот пошаговая инструкция:
1. Добавление зависимостей
Для Maven (pom.xml)
Добавьте зависимости (xml):
Для Gradle (build.gradle) (groovy):
2. Настройка Actuator (включение endpoint’ов Prometheus)
Добавьте в application-test.properties (или application.yml для тестов):
3. Создание Job см. подробно ниже (настройка конфигов Prometheus)
Настройка конфигов Prometheus
Метрики с экспортеров/агентов
Чтобы собирались данные с экспортера, исправьте /etc/prometheus/prometheus.yml (очень чувствителен к пробелам и табуляциям) так:
scrape_configs:
The job name is added as a label job= to any timeseries scraped from this config.
- job_name: 'prometheus'
metrics_path defaults to '/metrics'
scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
- job_name: 'node_localhost'
static_configs:
- targets: ['localhost:9100']
Перезагрузите Prometheus:
systemctl restart prometheus.service
В веб-интерфейсе Prometheus зайдите в рубрику Status ― Targets. Там появится новый таргет для мониторинга:
Чтобы дополнительно поставить node_exporter на другую машину и добавить её в мониторинг, внесите правки в config:
scrape_configs:
The job name is added as a label job= to any timeseries scraped from this config.
- job_name: 'prometheus'
metrics_path defaults to '/metrics'
scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
- job_name: 'node_localhost'
static_configs:
- targets: ['localhost:9100']
- job_name: 'node_exporter_clients'
static_configs:
- targets: ['194.12.345.6:9100']
Результат:
Чтобы добавить несколько серверов, которые нужно мониторить вместе, введите:
scrape_configs:
The job name is added as a label job= to any timeseries scraped from this config.
- job_name: 'prometheus'
metrics_path defaults to '/metrics'
scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
- job_name: 'node_exporter_clients'
static_configs:
- targets: ['194.12.345.6:9100','localhost:9100']
Метрики с другого Prometheus (federate)
Для получения метрик с другого Прометея используется джоба федерации или federation. В отличие от /metrics у экспортеров, путь до метрик другого прометея /federate. Конфиг выглядит таким образом:
scrape_configs:
- job_name: 'federate'
scrape_interval: 15s
honor_labels: true
metrics_path: '/federate'
params:
'match[]':
- '{job="prometheus"}'
- '{__name__=~"job:."}'
static_configs:
- targets:
- 'source-prometheus-1:9090'
- 'source-prometheus-2:9090'
- 'source-prometheus-3:9090'
Grafana
Install Grafana on RHEL or Fedora
Мониторинг с Grafana. Best practices / Хабр
Общая информация
Grafana - средство просмотра данных из хранилищ (InfluxDB и Prometheus) заключительный этап вывода метрик.
Чаще всего одна единственная на проект, может поддерживаться как самой командой тестирования, так и командой сопровождения (админы).
Установка Grafana на Linux
Пример рассмотрен при установке через RPM репозиторий и RPM пакеты на ОС RHEL (Red Hat Linux) и Fedora - тоже Linux)
Установка Grafana из репозитория RPM
Если вы устанавливаете из репозитория RPM, то Grafana автоматически обновляется каждый раз при обновлении приложений.
Чтобы установить Grafana из репозитория RPM, выполните следующие действия:
Импортируйте ключ GPG:
wget -q -O gpg.key https://rpm.grafana.com/gpg.key
sudo rpm --import gpg.key
Создайте /etc/yum.repos.d/grafana.repo со следующим содержимым:
[grafana]
name=grafana
baseurl=https://rpm.grafana.com
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://rpm.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
Чтобы установить Grafana OSS (Open Source Software), выполните следующую команду:
sudo dnf install grafana
Чтобы установить Grafana Enterprise (что-то на языке денег, платное), выполните следующую команду:
sudo dnf install grafana-enterprise
Установка Grafana RPM-пакет вручную (из файла)
Скорее всего на проекте будет именно так!! Если вы устанавливаете Grafana вручную с помощью YUM или RPM, то вам придется вручную обновлять Grafana для каждой новой версии. Этот метод зависит от того, какую ОС Linux вы используете.
Установка из пакета
sudo yum install grafana-**.rpm
Регистрация как службы и запуск
Здесь возможны два варианта в команде или просто “grafana”, или “grafana-server”
sudo systemctl enable grafana-server --now
Открытие порта “8086” и обновление правил
firewall-cmd --permanent --add-port=3000/tcp
firewall-cmd --reload
Готово, теперь можно заходить на UI Grafana на url http://localhost:3000/ - стандартные логин/пароль - admin/admin. При входе попросит их сменить.
Настройка графиков в Grafana + составляющие
Data Sources
Первым дело необходимо завести Data Sources (датасорс) - источники данных, в нашем случае Prometheus и InfluxDB, которые описаны выше в данном файле. Из названия очевидно, что именно отсюда будут браться данные для отображения графиков.
Создаем датасорс Prometheus
В итоге видим, что все работает.
Создаем датасорс InfluxDB
В итоге видим, что все работает.
Создание Dashboard
В Grafana создаются Dashboard - страница-коллекция, содержащая Panels.
Создание пустого/нового дашборда
Для импорта уже существующего дашборда - использовать кнопку “Import”. Самый часто используемый вариант, тк на проекте или в интернете с 99% вероятностью существует необходимый вам дашборд. Его лишь необходимо найти и скачать в виде dashboardName.json
Импорт готового дашборда
Сначала скачиваем дашборд из интернета/просим у коллеги/берем сами с проекта.
Делаем импорт, для этого нажимаем кнопку ”Upload JSON file” (также можно скопировать содержимое файла в поле “Import via panel json”):
Настройка дашборда Prometheus
Здесь имеем два варианта действий - создаем новую Panel - непосредственно один график, либо при импорте будем иметь некий набор Панелей, которые можем изменить/удалить - добавить к ним новые (по необходимости).
На примере созданной заранее панели рассмотрим как вывести графики:
Variables - переменные дашборда - всегда находятся сверху, позволяют использовать одинаковые значения полей в нескольких панелях одновременно, без необходимости хардкодить их в каждый запрос. Также можно быстро их изменить кликнув по ним мышью. Зависят от дашборда.
Сама панель, на которой отображаются графики.
Список графиков, выведенных на панель и их значения (настраиваемо в правой части экрана)
Агрегатная функция PromQL (вспоминаем реляционные БД)
Название метрики/вектора собранного Prometheus
Метки/Lables метрики/вектора собранного Prometheus
Указание, по какой метке сгруппировать результаты (вспоминаем реляционные БД), можно группировать по нескольким меткам, чтобы использовать их в выводе далее.
Легенда - указание по какой метке необходимо назвать графики из п.3. имеет формат {{label_name}}. Можно добавлять несколько меток
Thresholds - порог, позволяет указать для графиков крайние значения и добавить линию для визуального представления. Нужен для настройки алертинга. Удобнее всего добавить значения SLA, для быстрого понимания ситуации с производительностью.
Настройка дашборда InfluxDB
Здесь имеем два варианта действий - создаем новую Panel - непосредственно один график, либо при импорте будем иметь некий набор Панелей, которые можем изменить/удалить - добавить к ним новые (по необходимости).
На примере созданной заранее панели рассмотрим как вывести графики:
Variables - переменные дашборда - всегда находятся сверху, позволяют использовать одинаковые значения полей в нескольких панелях одновременно, без необходимости хардкодить их в каждый запрос. Также можно быстро их изменить кликнув по ним мышью. Зависят от дашборда.
Сама панель, на которой отображаются графики.
Список графиков, выведенных на панель и их значения (настраиваемо в правой части экрана)
Retention Policy - политика хранения метрик. В данном примере “Default” может быть несколько штук на выбор.
Measurement - таблица Инфлюкса, хранящая в себе поля со значениями метрик и тэги к ним. В данном примере “CPU”
Tags - тэги инфлюкса. Используется для фильтрации после ключевого слова WHERE. Позволяет выбрать только нужные для панели метрики.
Выбор поля, агрегатной функции и математических вычислений с ними (если необходимо)
Группировка по тегам и времени (для вывода в рамках заданного таймлайна).
Alias (переименование) - указание по какому тегу необходимо назвать графики из п.3. имеет формат $tag_tagName. Можно добавлять несколько тегов, указанных в п.8
Thresholds - порог, позволяет указать для графиков крайние значения и добавить линию для визуального представления. Нужен для настройки алертинга. Удобнее всего добавить значения SLA, для быстрого понимания ситуации с производительностью.
Настройка дашборда в Grafana
Кнопка создания новой Panel
Сохранить изменения в дашборде (НЕ ЗАБЫВАЕМ ПЛИЗ)
Переход в настройки дашборда (для создания переменных/удаления и тд)
Время за которое необходимо вывести графики (можно выбрать последние n-минут/часов/дней либо строго определенный интервал)
Время обновления метрик на борде (раз в минуту, раз в 30 сек - самое то) - это нагружает графану и ваши хранилища!!!!
Строка (в данном примере Resources) - позволяет объединить панели друг с другом, можно свернуть/развернуть все объединенные панели разом)
Окно настроек - будем рассматривать только настройку переменных, остальные пункты для джунов не особо нужны, так что о них кратко.
Общие настройки борды - имя, где лежит, режим редактирования/записи. Все понятно само по себе.
Переменные дашборда - см. настройка Prometheus и InfluxDB. + описание как получается переменная .
Versions - каждый раз меняя и сохраняя борду, создается новая версия, позволяет найти пользователя, изменившего её и восстановить более старую версию (до изменений)
Permissions - позволяет менять и добавлять разрешение для пользователей графана, чтобы разрабы могли посмотреть, но не могли ничего менять например.
JSON Model - см Import Dashboard.
Save dashboard - понятно из названия.
Save as … - позволяет сохранить дашборд в новый дашборд, без изменения в старом.
Создание новых variables
Имя переменной
Тип переменной
Метка переменной - если хотите, чтобы на дашборде отображалась по другому
датасорс, из которой переменная берется
Как часто обновлять переменные борды
Запрос к источнику, чтобы получить значения (если применимо к типу)
Регулярное выражение - позволяет более гибко фильтровать получаемые значения
Переключатель отображения в не/отсортированном порядке
Переключатель мультизначений (при включении позволяет в рамках одной переменной использовать 1 и её более значений, при выключении соответственно максимум одно значение)