Linuxoid.pro

Сообщество разработчиков программного обеспечения и IT-специалистов

Мониторинг процессов Linux с помощью Prometheus и Grafana

Независимо от того, являетесь ли вы системным администратором Linux или инженером DevOps, вы тратите много времени на отслеживание показателей производительности на своих серверах .

Иногда у вас могут быть экземпляры, которые работают очень медленно, без каких-либо реальных подсказок о том, в чем могут быть проблемы. У вас могут быть неотвечающие экземпляры, которые могут блокировать выполнение вами удаленных команд, таких как top или htop.

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

Что, если бы у нас была полная панель инструментов, которая помогла бы нам отслеживать общую производительность, а также отдельные процессы?

Цель этого руководства — создать полную панель мониторинга для системных администраторов Linux .

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

Что вы узнаете

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

  • Понимание современных способов мониторинга производительности процессов в системах Unix;
  • Узнайте, как установить последние версии Prometheus v2.9.2 , Pushgateway v0.8.0 и Grafana v6.2 ;
  • Создайте простой сценарий bash, который экспортирует метрики в Pushgateway;
  • Создайте полную приборную панель Grafana, включая новейшие доступные панели, такие как «Датчик» и «Барный датчик»;
  • Бонус: реализация специальных фильтров для отслеживания отдельных процессов или экземпляров.

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

Основы мониторинга процессов Unix

Когда дело доходит до мониторинга процессов для систем Unix, у вас есть несколько вариантов.

Самым популярным, наверное, является «top».

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

Эта команда широко используется системными администраторами и, вероятно, является первой командой, запускаемой при обнаружении узкого места производительности в системе (если вы, конечно, можете получить к нему доступ!)

Команда top уже хорошо читается, но есть команда, которая делает все еще более читаемым, чем эта: htop .

Htop предоставляет тот же набор функций (процессор, память, время безотказной работы …), что и top, но в красочной и приятной форме.

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

Зная, что эти две команды существуют, зачем нам создавать еще один способ мониторинга процессов?

Основная причина — доступность системы : в случае перегрузки системы у вас может не быть физического или удаленного доступа к вашему экземпляру.

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

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

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

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

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

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

Детализация нашей архитектуры мониторинга

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

  • Дешевый ресурс : то есть не потребляет много ресурсов на нашем хосте;
  • Просто внедрить : решение, не требующее много времени для создания экземпляра;
  • Масштабируемость : если бы мы контролировали другой хост, мы могли бы сделать это быстро и эффективно.

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

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

Наша архитектура использует четыре различных компонента:

  • Сценарий bash, используемый для периодической отправки метрик в Pushgateway;
  • Pushgateway : кэш метрик, используемый отдельными скриптами в качестве цели;
  • Prometheus:, который создает базу данных временных рядов, используемую для хранения показателей. Прометей будет очищать Pushgateway как цель, чтобы получить и сохранить метрики;
  • Grafana : инструмент мониторинга приборной панели, который извлекает данные из Prometheus через запросы PromQL и строит их.

Тем, кто хорошо знаком с Prometheus, вы уже знаете, что Prometheus извлекает метрики, предоставляемые экземплярами HTTP, и сохраняет их.

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

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

 

Установка различных инструментов

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

а — Установка Pushgateway

Чтобы установить Pushgateway , запустите простую команду wget, чтобы получить последние доступные двоичные файлы.

wget https://github.com/prometheus/pushgateway/releases/download/v0.8.0/pushgateway-0.8.0.linux-amd64.tar.gz

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

> tar xvzf pushgateway-0.8.0.linux-amd64.tar.gz 
> cd pushgateway-0.8.0.linux-amd64 / 
> ./pushgateway &

В результате ваш Pushgateway должен запуститься в фоновом режиме .

me@schkn-ubuntu:~/softs/pushgateway/pushgateway-0.8.0.linux-amd64$ ./pushgateway &

[1] 22806
me@schkn-ubuntu:~/softs/pushgateway/pushgateway-0.8.0.linux-amd64$ 
INFO[0000] Starting pushgateway (version=0.8.0, branch=HEAD, revision=d90bf3239c5ca08d72ccc9e2e2ff3a62b99a122e) source="main.go:65"INFO[0000] Build context (go=go1.11.8, user=root@00855c3ed64f, date=20190413-11:29:19) source="main.go:66"INFO[0000] Listening on :9091. source="main.go:108"

Оттуда Pushgateway прослушивает входящие метрики на порт 9091 .

б — Установка Prometheus

Как описано в разделе «Начало работы» на веб-сайте Prometheus, перейдите по адресу https://prometheus.io/download/ и выполните простую команду wget, чтобы получить архив Prometheus для вашей ОС.

wget https://github.com/prometheus/prometheus/releases/download/v2.9.2/prometheus-2.9.2.linux -amd64.tar.gz

Теперь, когда у вас есть архив, распакуйте его и перейдите в основную папку:

> tar xvzf prometheus-2.9.2.linux-amd64.tar.gz 
> cd prometheus-2.9.2.linux-amd64 /

Как указывалось ранее, Prometheus периодически сбрасывает «цели», чтобы собрать с них метрики. Цели (в нашем случае Pushgateway) необходимо настроить с помощью файла конфигурации Prometheus.

> vi prometheus.yml

В разделе «global» измените значение свойства scrape_interval до одной секунды.

global: 
scrape_interval: 1s # Установить интервал очистки каждую 1 секунду.

В разделе scrape_configs добавьте запись в свойство target в разделе static_configs.

static_configs:
- targets: ['localhost:9090', 'localhost:9091']

Выйдите из vi и запустите исполняемый файл prometheus в папке.

Prometheus должен запуститься при запуске последней команды Prometheus. Чтобы убедиться, что все прошло правильно, вы можете перейти на http: // localhost: 9090 / graph.

Если у вас есть доступ к веб-консоли Prometheus, значит, все прошло нормально.

Вы также можете убедиться, что Pushgateway правильно настроен как цель в «Статус»> «Цели» в веб-интерфейсе.

c — Установка Grafana

Если вы ищете руководство по установке Grafana на Ubuntu 18.04, просто перейдите по ссылке!

И последнее, но не менее важное: мы собираемся установить Grafana v6.2 . Перейдите на https://grafana.com/grafana/download/beta.

Как и раньше, запустите простую команду wget, чтобы получить ее.

> wget https://dl.grafana.com/oss/release/grafana_6.2.0-beta1_amd64.deb> sudo dpkg -i grafana_6.2.0-beta1_amd64.deb

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

Вы можете проверить это, выполнив следующую команду:

> sudo systemctl status grafana-server
● grafana-server.service - Grafana instance
Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled)
Active: active (running) since Thu 2019-05-09 10:44:49 UTC; 5 days ago
Docs: http://docs.grafana.org

Вы также можете проверить http: // localhost: 3000, который является адресом по умолчанию для веб-интерфейса Grafana.

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

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

Вот и все!

Нажмите «Сохранить и проверить» и убедитесь, что ваш источник данных работает правильно.

Создание сценария bash для получения показателей

Ваша следующая задача — создать простой сценарий bash, который извлекает такие показатели, как использование ЦП и использование памяти для отдельных процессов.

Ваш скрипт можно определить как задачу cron, которая будет запускаться каждую секунду позже.

Для выполнения этой задачи у вас есть несколько кандидатов.

Вы можете запускать топ-команды каждую секунду, анализировать их с помощью sed и отправлять метрики в Pushgateway.

Сложность с top заключается в том, что он работает на нескольких итерациях, обеспечивая средние показатели с течением времени. Это не совсем то, что мы ищем.

Вместо этого мы собираемся использовать команду ps, а точнее команду ps aux .

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

Это именно то, что мы ищем.

Но прежде чем идти дальше, давайте посмотрим, что ожидает Pushgateway в качестве входных данных.

Pushgateway, как и Prometheus, работает с парами ключ-значение : ключ описывает отслеживаемую метрику, а значение не требует пояснений.

Вот некоторые примеры:

Как вы можете заметить, первая форма просто описывает использование ЦП, а вторая описывает использование ЦП для процесса java.

Добавление ярлыков — это способ более точно указать, что описывает ваша метрика.

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

Напоминаем, что наш скрипт выполнит команду ps aux, проанализирует результат, преобразует его и отправит в Pushgateway с помощью синтаксиса, который мы описали ранее.

Создайте файл сценария, дайте ему права и перейдите к нему.

> touch better-top
> chmod u+x better-top
> vi better-top

Вот сценарий:

#!/bin/bash
z=$(ps aux)
while read -r z
do
var=$var$(awk '{print "cpu_usage{process=\""$11"\", pid=\""$2"\"}", $3z}');
done <<< "$z"
curl -X POST -H "Content-Type: text/plain" --data "$var
" http://localhost:9091/metrics/job/top/instance/machine

Если вам нужен тот же сценарий для использования памяти, просто измените метку cpu_usage на memory_usage и $ 3z на $ 4z

Итак, что делает этот сценарий?

Во-первых, он выполняет команду ps aux, которую мы описали ранее.

Затем он выполняет итерацию по различным строкам и форматирует их в соответствии с форматом пары значений с меткой ключа, который мы описали ранее.

Наконец, все объединяется и отправляется в Pushgateway с помощью простой команды curl.

Просто, не правда ли?

Как видите, этот скрипт собирает все метрики для наших процессов, но выполняет только одну итерацию.

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

Позже вы можете создать службу, которая будет запускать ее каждую секунду с помощью таймера (по крайней мере, с помощью systemd).

Заинтересованы в systemd? Я сделал полное руководство по их мониторингу с помощью Chronograf.

> while sleep 1; do ./better-top; done;

Мониторинг системных сервисов в реальном времени с помощью Chronograf

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

Перейдите по адресу http: // localhost: 9090. В поле «Выражение» просто введите cpu_usage . Теперь вы должны увидеть все показатели в своем браузере.

Поздравляю! Ваши показатели ЦП теперь хранятся в Prometheus TSDB.

.

 

Создание отличной приборной панели с Grafana

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

Мы будем использовать новейшие панели, доступные в Grafana v6.2: вертикальные и горизонтальные шкалы , закругленные шкалы и классические линейные диаграммы.

Для вашего удобства я снабдил последнюю сводку цифрами от 1 до 4.

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

1 — Строительство круглых датчиков

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

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

С помощью этих панелей мы собираемся отслеживать два показателя: текущее использование ЦП всеми нашими процессами и среднее использование ЦП.

Чтобы получить эти метрики, мы собираемся выполнять запросы PromQL в нашем экземпляре Prometheus?

Итак .. что такое PromQL?

PromQL — это язык запросов, разработанный для Prometheus .

Аналогично тому, что вы нашли в экземплярах InfluxDB с InfluxQL (или IFQL), запросы PromQL могут агрегировать данные с использованием таких функций, как сумма, среднее значение и стандартное отклонение.

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

a — Получение текущего общего использования ЦП

Чтобы получить текущее общее использование ЦП, мы собираемся использовать функцию суммы PromQL.

В данный момент общее использование ЦП — это просто сумма отдельных использований.

Вот шпаргалка:

b — Получение средней загрузки ЦП

Не так много работы для среднего использования ЦП, вы просто собираетесь использовать  функцию avg в PromQL . Вы можете найти шпаргалку ниже.

2 — Построение горизонтальных манометров

Горизонтальные датчики — одно из последних дополнений Grafana v6.2.

Наша цель с этой панелью — выявить 10 самых ресурсоемких процессов нашей системы.

Для этого мы собираемся использовать функцию topk, которая извлекает верхние k элементов для метрики.

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

3 — Строительство вертикальных датчиков

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

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

Вот шпаргалка :

Потрясающе ! Пока мы добились большого прогресса, осталось провести одну панель.

4 — Построение линейных графиков

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

Этот график может быть особенно полезен, когда:

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

Когда дело доходит до исследования по устранению неполадок, честно говоря, потребуется целая статья (особенно с недавним добавлением Grafana Loki).

Хорошо, вот последняя шпаргалка !

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

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

Бонус: исследуйте данные с помощью специальных фильтров

Данные в реальном времени интересно видеть, но настоящая ценность приходит тогда, когда вы можете исследовать свои данные.

В этом бонусном разделе мы не будем использовать функцию «Исследовать» (может быть, в другой статье?), Мы будем использовать специальные фильтры.

С Grafana вы можете определять переменные, связанные с графиком . У вас есть много разных вариантов переменных: вы можете, например, определить переменную для вашего источника данных, которая позволит динамически переключать источник данных в запросе.

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

Оттуда просто нажмите «Переменные» в левом меню, затем нажмите «Создать».

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

Взгляните на верхний левый угол приборной панели.

Фильтры!

Теперь предположим, что вам нужна производительность определенного процесса в вашей системе: возьмем, к примеру, сам Прометей.

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

Теперь у вас есть прямой взгляд на то, как Prometheus ведет себя в вашем экземпляре.

Вы даже можете вернуться в прошлое и посмотреть, как ведет себя процесс, независимо от его pid!

Короткое слово в заключение

Из этого урока вы лучше понимаете, что могут предложить Prometheus и Grafana .

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

DevOps-мониторинг — определенно интересная тема, но если вы сделаете это неправильно, он может превратиться в кошмар.

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

Мы считаем, что отличные технологии можно улучшить с помощью полезных демонстраций.

А Ты?

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