Описание:

Ну вот вы и дошли до одного из самых интересных и важных заданий в этом практикуме! Мониторинг в PostgreSQL. Давайте приступим!

Для чего нужен мониторинг?

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

Регулярный мониторинг серверов имеет серию преимуществ.
Во-первых, он может помочь узнать о наличии проблемы до того, как об этом узнают пользователи. Таким образом, у системного администратора будет время для устранения неисправностей в работе сайта или приложения.
Во-вторых, мониторинг серверов – это замечательная возможность оценить работу IT-структуры компании.
В-третьих, переодическое наблюдение за работой серверов позволяет узнать причину сбоя, а не его последствия. Благодаря этому, IT-отдел компании сможет быстрее устранить неполадку в работе сервера.

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

Основы мониторинга. Как наблюдать?

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

Еще немного теории:

МЕСТО НАБЛЮДЕНИЯ
Если прикладная информационная система предназначена для публичного обслуживания неограниченного круга пользователей и должна быть доступна из любой точки интернета, то и проверять ее доступность нужно из разных мест, в которых могут находиться пользователи.

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

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

ПЕРИОДИЧНОСТЬ
Как часто проверять доступность наблюдаемого сервера? — Вопрос непростой. Чтобы вовремя выявить проблему, опрашивать нужно достаточно часто. Но слишком интенсивные запросы могут заметно увеличить нагрузку как на сам сервер, так и на сетевую инфраструктуру.

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

ПРОТОКОЛИРОВАНИЕ
Сведения, порождаемые системой мониторинга, крайне желательно где-то сохранять, например, в log-файлах или базе данных (желательно time series).

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

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

АВТОМАТИЗАЦИЯ — ALERTING
В системе мониторинга было бы мало смысла, если бы она только регистрировала какие-то данные. — Данные нужно автоматически анализировать, выявлять проблемы и как-то на них реагировать.

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

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

ЛОКАЛИЗАЦИЯ И ИЗОЛЯЦИЯ ПРОБЛЕМЫ
Когда под наблюдением находится сложная информационная система, нужно учитывать, что часть обнаруженных в ней проблем может быть следствием других, более общих.

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

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

Но чем мониторить информационные системы, что для этого нужно и как выбрать систему мониторинга? Давайте посмотрим!

Существующие системы мониторинга

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

Zabbix, Nagios

Наиболее популярными и узнаваемыми системами ИT-мониторинга являются такие решения, как Zabbix и Nagios. Они построены на базе программного обеспечения с открытым исходным кодом и давно зарекомендовали себя как качественные и успешно решающие целевые задачи продукты. И Zabbix, и Nagios способны осуществлять мониторинг большинства компонентов любой современной ИT-инфраструктуры, включая сетевое оборудование, ОС, различные приложения, базы данных, платформы виртуализации и т.д. Обе системы поддерживают агентский и безагентский сбор данных с целевых источников, имеют инструменты оповещения, визуализации и реагирования, а также сторонние плагины и возможность модернизации логики работы с помощью внешних скриптов (жаль только, что эти системы мониторинга «тяжелые», поэтому постепенно отходят на второй план).

Достоинства:

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

Недостатки:

• Использование РСУБД в качестве подсистемы хранения данных и, как следствие, высокая степень утилизации дисковой подсистемы.
• Ограниченный интерфейс как в части функционала, так и в части визуализации.
• Отсутствие инструментов по масштабированию и отказоустойчивости.
• Ограниченные возможности по ретроспективному анализу собираемых данных.

Это все, конечно, хорошо, но мир не стоит на месте, задачи усложняются, приложения становятся разветвленными, время теперь является важным фактором, и поэтому необходимо изменять подходы к мониторингу! Наступает эра time-series!

Prometheus, Graphite

В эту категорию входят современные решения, к которым можно отнести такие системы, как Prometheus и Graphite. Они появились сравнительно недавно и активно развиваются. Архитектура обоих решений направлена именно на работу с time-series-данными. Независимо от метода сбора (SNMP/агенты/экспортеры), итоговое представление и хранение данных в обоих решениях будет в формате временных рядов, за исключением того, что Graphite хранит данные в кольцевой СУБД Whisper, а Prometheus – в файлах (используя многомерную модель с продвинутыми механизмами индексирования и тегирования).

Поскольку рассматриваемые решения появились сравнительно недавно, разработчики учли многие недостатки предыдущих систем и постарались сделать решения более гибкими и удобными. Помимо наличия основополагающего функционала по мониторингу ИТ-метрик, Graphite и Prometheus имеют ряд преимуществ, но не обошлось и без недостатков:

Достоинства:

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

Недостатки:

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

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

Если вам нужна проверенная временем система для классического мониторинга утилизации аппаратных и программных ресурсов вашей инфраструктуры, с отличными возможностями по оповещению и наличием официальной поддержки, то Zabbix или Nagios – отличный выбор.

Если в вашей инфраструктуре ИT-мониторинг в первую очередь означает сбор узкоспециализированных метрик с различных приложений, самописных сервисов и систем, подсистемы хранения и визуализации данных в Zabbix или Nagios кажутся откровенно устаревшими, а наличие официальной поддержки для компании не является обязательным условием, то предпочтительны такие решения, как Prometheus или Graphite.

Ввиду того, что Prometheus с каждым годом становится все мощнее и стабильнее, я выбрал его в качестве достойного и гибкого решения для мониторинга PostgreSQL.

Компоненты Prometheus (Prometheus stack)

Сервер Prometheus

Prometheus имеет центральный компонент, называемый Prometheus Server. Его основная задача — хранить и мониторить определенные объекты. Объектом может стать что угодно: Linux-сервер, сервер Apache, один из процессов, сервер базы данных или любой другой компонент системы, которую вы хотите контролировать. В терминах Prometheus главная служба мониторинга называется сервером Prometheus, а объекты мониторинга — целевыми объектами или таргетами (targets). Целевым объектом может быть железный сервер, виртуальная машина, какие-либо сервисы, а иногда даже сами приложения со встроенными экспортерами (но об этом позже). По факту, это объекты для проверки конечных точек через HTTP, HTTPS, DNS, TCP и ICMP (*Black-Box Exporter) или простая конечная точка HTTP, которую выдает приложение. Важно то, что должна быть конечная точка в виде HTTP-сервера, которую Prometheus будет опрашивать, собирая метрики, которые вы хотите мониторить (статус центрального процессора, память или любой другой элемент).

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

Сервер Prometheus опрашивает целевые объекты с интервалом, который вы определяете в файле конфигурации (об этом чуть позже), и хранит их в базе данных временных рядов. Описание таргетов и правила работы с ними описываются в конфигурационном файле prometheus.yml.

Но как работать с собранными метриками? Все уже придумали за вас! Для работы с данными вы должны использовать специальный язык временных рядов — PromQL. С помощью него вы можете запросить у сервера Prometheus статус конкретного целевого объекта в данный момент времени и получите все метрики согласно запроса. Prometheus предоставляет клиентские библиотеки на нескольких языках, которые вы можете использовать для обеспечения работоспособности приложения. Но Prometheus — это не только мониторинг приложений. Вы можете использовать экспортеры (exporters) для мониторинга сторонних систем (таких как сервер Linux, СУБД PostgreSQL и т.д.). Также на схеме видно, что система алертинга, основываясь на полученных метриках, может просигнализировать о проблеме через почту, чаты и даже позвонить на телефон.

Настройка Prometheus server

Чтобы поработать с Prometheus, его нужно скачать и установить (логично).

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

mkdir prometheus && cd $_

Скачаем новую стабильную версию prometheus-server с github:

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

Распакуем:

tar -xvf prometheus-2.24.1.linux-amd64.tar.gz

Переназовем директорию для наглядности:

mv prometheus-2.24.1.linux-amd64 prometheus-files

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

sudo useradd --no-create-home --shell /bin/false prometheus
sudo mkdir /etc/prometheus
sudo mkdir /var/lib/prometheus
sudo chown prometheus:prometheus /etc/prometheus
sudo chown prometheus:prometheus /var/lib/prometheus

Теперь скопируем файлы prometheus в директорию /usr/local/bin и снова позаботимся о правах.

sudo cp prometheus-files/prometheus /usr/local/bin/
sudo cp prometheus-files/promtool /usr/local/bin/
sudo chown prometheus:prometheus /usr/local/bin/prometheus
sudo chown prometheus:prometheus /usr/local/bin/promtool

Перемещаем консоли и библиотеки консолей в /etc/prometheus и снова заботимся о правах.

sudo cp -r prometheus-files/consoles /etc/prometheus
sudo cp -r prometheus-files/console_libraries /etc/prometheus
sudo chown -R prometheus:prometheus /etc/prometheus/consoles
sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries

Настраиваем Prometheus

Вся конфигурация для Prometheus хранится в файле /etc/prometheus/prometheus.yml.

Создаем файл prometheus.yml:

sudo vi /etc/prometheus/prometheus.yml

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

global:
  scrape_interval: 10s

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

Меняем владельца для нашего файла:

sudo chown prometheus:prometheus /etc/prometheus/prometheus.yml

Устанавливаем как Prometheus сервис

Создаем файл описания сервиса:

sudo vi /etc/systemd/system/prometheus.service

И описываем его:

[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

[Install]
WantedBy=multi-user.target

Видим, что, описывая сервис, мы указали запуск нашего приложения с различными параметрами, например: место расположения файла конфигурации --config.file /etc/prometheus/prometheus.yml.

Перезагружаем systemd и запускаем наш service:

sudo systemctl daemon-reload
sudo systemctl start prometheus

Можно расширить наше представление о компонентах Prometheus (смотрим на схему):

Как уже было сказано, мы можем использовать несколько экспортеров на одном target-сервере, выделить отдельный сервер хранения метрик для Prometheus, работать с service-discovery, подключить систему отображения наших метрик в виде графиков или вообще пользоваться API, написав свой сервис для работы с метриками. Но для начала поговорим об экспортерах подробнее.

Экспортеры

Экспортер — отдельный модуль, осуществляющий сбор существующих метрик от интересующей нас системы и экспортирующий их в формат, понятный серверу Prometheus, то есть в набор текстовых ключей в raw-формате (доступ по HTTP).

Примерной метрикой с сервера Prometheus может быть текущее использование свободной памяти или файловой системы через Node Exporter. Важно знать, что Prometheus использует стандартную модель данных с метрикой на основе ключа, она может не совпадать с моделью сторонней системы. Именно поэтому вы используете экспортеры для преобразования метрик. Я не буду вдаваться в подробности каждого синтаксиса показателей Prometheus и того, как они отличаются.

Для каждого экспортера есть свое описание установки, но план обычно такой:

• вы выкачиваете экспортер (язык, на котором он написан, может быть любой, но идея одна — метрики в raw-формате, доступ по HTTP);
• устанавливаете его (как правило, в виде сервиса);
• прописываете настройки подключения к другим сервисам, если нужно (логин/пароль, токен, etc.);
• указываете в конфигурации Prometheus-server ip, порт и правила, по которым будет осуществляться сбор метрик.

Grafana

Grafana => Уровень визуализации в Prometheus-stack

Я считаю, что Grafana — лучший в своем роде визуализатор time-series данных на данный момент (можете со мной не согласиться — ваше право).

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

Настройка Grafana

Чтобы установить Grafana, нужно сначала установить необходимые пакеты:

#Для Ubuntu and Debian(64 Bit)
sudo apt-get install -y adduser libfontconfig1

Затем скачать последнюю версию Grafana:

wget https://dl.grafana.com/oss/release/grafana_7.3.7_amd64.deb

И установить пакет:

sudo dpkg -i grafana_7.3.7_amd64.deb

Далее необходимо удостовериться, что запустился сервис и ваша Grafana работает.

Перейдите на сервер, на котором установили Grafana на порт 3000. Должна появиться главная страница Grafana.

Вам предложат ввести пароль (по умолчанию: user: admin, password: admin).

Чтобы понять, как настроить источники данных или подгрузить дашборды перейдите по вот этой ссылке!

Панели мониторинга (Dashboards)

Панели мониторинга — отдельная тема! Каждая компания, в идеале, должна иметь свою конкретную панель, подходящую под ее задачи. Можно долго объяснять, как это работает и как это сделать своими руками, но для этого есть документация, а я просто покажу несколько примеров, что можно сделать с досками.

Бывают простые доски, вот такого типа (ничего лишнего, минимализм):

Бывают расширенные:

А некоторые сносят «крышу»! Сразу видно, что ребята потратили время (надеюсь — не зря):

На самом деле, главное, чтобы панели мониторинга были максимально информативными и понятными в рамках поставленной задачи, а различные красивости — это уже «сахар в кофе».

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

1. через уникальный номер официального репозитория таких панелей (для PostgreSQL вы будете в задании использовать дашдборд под номером 9628);
2. через URL;
3. скачав и подгрузив его в JSON формате.

Перейдем к мониторингу PostgreSQL.

Мониторинг в PostgreSQL, на что смотреть?

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

1. Клиенты: pg_stat_activity
2. Работа с данными: pg_stat_user_tables
3. Запросы и их адекватность: pg_stat_statements
4. Фоновые процессы: pg_stat_activity, pg_stat_bgwriter
5. Системные метрики: CPU, MEMORY + DISK and NETWORK LATENCY/UTILIZATION = good metrics

PostgreSQL monitoring stats

Если вам потребуется копнуть глубже в параметры мониторинга — добро пожаловать в документацию, вот сюда => site: postgresql-monitoring-stats

Вот для справки список обсуждаемго в документации: The Statistics Collector:

• Statistics Collection Configuration
• Viewing Statistics
• pg_stat_activity
• pg_stat_replication
• pg_stat_wal_receiver
• pg_stat_subscription
• pg_stat_ssl
• pg_stat_gssapi
• pg_stat_archiver
• pg_stat_bgwriter
• pg_stat_database
• pg_stat_database_conflicts
• pg_stat_all_tables
• pg_stat_all_indexes
• pg_statio_all_tables
• pg_statio_all_indexes
• pg_statio_all_sequences
• pg_stat_user_functions
• pg_stat_slru
• Statistics Functions

Идеальный Dashboard для PostgreSQL

Эх, дашборды! Идея следующая — «Бросил взгляд — увидел проблему».

Наша панель мониторинга для PostgreSQL будет выглядеть так (цветом затерта закрытая для публикации информация, например названия таблиц):

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

Серьезные детали нужно либо выводить в отдельные дашборды, либо уводить информацию в Drilldown links (Panel links) или Data links.

Подведем итог! Если объединить всю полезную информацию, которая должна содержаться в главном Dashboard для PostgreSQL, то это будет примерно следующее.

В идеальном Dashboard для PostgreSQL должна содержаться информация:

Клиенты (коннекты)

1. Количество коннектов к базе данных From pg_stat_activity count(*) where state = "X"
2. Активные коннекты (клиенты)
3. Простаивающие коннекты (клиенты — idle)
4. Висящие транзакции (открытые)
5. Транзакции, ожидающие коннектов (в очереди)
6. Длительность транзакции (now() - xact_start)
7. Длительность запроса (now() - query_start)

Работа с данными. Top N таблиц ("горячие" таблицы) - графики:

8. Select
9. Insert
10. Update
11. Delete
12. Size (размер таблиц)

Смотрим запросы на их адекватность (pg_stat_statements):

13. Самые частые — calls (особенно важно сюда смотреть после деплоя новой версии приложения)
14. Самые долгие — total_time, mean_time
15. Самые тяжелые — shared_blks_* (сильно нагружающие ресурсы диска и памяти)
16. Самые щедрые — rows (возвращающие большое количество строк)
17. Временные файлы — temp_blks_*
18. Временные таблицы — local_blks_*

Смотрим фоновые процессы

19. Проверяем checkpoint and IO, checkpoint_req(количество) и checkpoint_timed(время)
20. Проверяем автовакуум: сколько воркеров (штук) -> (count(*) ... WHERE query ~'^autovac')
21. Какие типы воркеров автовакуума: (графиком)

• user
• auto
• wraparound

22. Длительность работы воркеров автовакуума ( count(*) ... WHERE now() - Xact_start AND query ~'...' )
23. Проверяем лаги репликации через pg_wal_lsn_diff() -> (write|flush|replay)_lag

Ну и системный мониторинг:

24. Процессор (важно при большом количестве коннектов)
25. Память (важно при использовании memory-storage или при "тяжелых" запросах)
26. SWAP (хотя сейчас он уже не так актуален, но лишним не будет)
27. Disk Usage: troughput(iops, bps)
28. Disk LATENCY — диски не справляются, проблема
29. Disk UTILIZATION — диски не справляются — снова проблема -> нужны SSD
30. Network troughput(pps, bps), errors
31. Network LATENCY — сеть не справляется, очереди, задержки
32. Network UTILIZATION — сеть не справляется, высокая нагрузка — нужно увеличение пропускной способности

Запоминаем, что 32 параметра — норма. Теперь можете приступать к заданию =)

Полезные ссылки:

Интересное:

• Выбираем лучшую систему мониторинга и анализа IT-инфраструктуры

Установка:

• Установка и конфигурирование prometheus
• Установка и настройка node_exporter для linux систем
• Установка и конфигурирование grafana
• grafana-dashboards
• Prometheus-Node-Exporter-Full-grafana-dashboard
• Postgres-grafana-dashboard
• Git: grafana-dashboards
• Git: postgres_exporter-latest

Официальные сайты:

• site: prometheus
• prometheus: GETTING STARTED
• site: grafana oss
• site: postgresql-monitoring-stats

Правила выполнения задания:

1. Время создания окружения занимает до 5 минут.
2. После нажатия кнопки «Начать выполнение» для вас будет создано окружение для выполнения задания, состоящее из одной или более виртуальнах машин с Ubuntu Linux. К ним будут выданы IP, логин и пароль для доступа по SSH, а также при необходимости — дополнительных ресурсов.
3. Также, если необходимо, вам могут быть выданы переменные, которые в задании указаны в фигурных скобках, — их надо будет подставить при выполнении задания (например, ${base_domain}).
4. После выполнения всех пунктов задания нажмите кнопку «Проверить выполнение», и в течение 3-5 минут скрипт проверит выполнение всех условий и выставит вам оценку.
5. В случае, если вы что-то забыли, можно исправить ошибку и отправить на проверку повторно (нажав кнопку «Проверить выполнение»).
6. После получения удовлетворительной оценки нажмите кнопку «Завершить задание», чтобы созданное окружение уничтожилось и вы могли приступить к следующему заданию.
7. Если у вас закончилось время (истек таймер) — окружение будет автоматически уничтожено и вам придется начать выполнение заново.
8. Также, если вы успешно сдали задание, но у вас остались вопросы — вы всегда сможете задать их куратору после проверки (используя кнопку «Задать вопрос куратору») или в чате практикума в любое удобное для вас время. Обращаем внимание — кураторы проверяют вопросы в течение 24 часов.

Задание:

1. Установите PostgreSQL v13 на предоставленной VM c OS Ubuntu 20.04.
2. Добавьте в PostgreSQL пользователя root c правами SUPERUSER.
3. Подключитесь к PostgreSQL пользователем root.
4. Создайте базу данных "rebrain_courses_db".
5. Для работы с базой данных создайте пользователя "rebrain_admin".
6. Выдайте все права пользователю "rebrain_admin" на базу данных "rebrain_courses_db" (в том числе CONNECT).
7. Скачайте и установите prometheus-server, проверьте доступность сервиса (systemctl), посмотрите, открыт ли порт TCP/9090 (ss, netstat). Также настройте сбор данных о самом сервере [prometheus selfmonitoring] (job_name: 'prometheus').
8. Скачайте и установите в режиме сервиса последнюю версию node_exporter для OS Ubuntu 20.04 Focal, проверьте доступность сервиса (systemctl), посмотрите, открыт ли порт TCP/9100 (ss, netstat).
9. Настройте новый источник данных для prometheus-server, подключите сбор данных с node_exporter (job_name: 'node_exporter').
10. Скачайте последнюю версию Grafana для OS Ubuntu 20.04 Focal, установите ее в режиме сервиса, проверьте доступность сервиса (systemctl), посмотрите, открыт ли порт TCP/3000 (ss, netstat).
11. Подключите к Grafana сервер prometheus в качестве источника данных для панелей мониторинга.
12. Скачайте и импортируйте Dashboard 1860 для node_exporter. Выберите в качестве источника данных prometheus сервер.
13. Проверьте работоспособность node_exporter воспользовавшись импортированной панелью мониторинга 1860. Все метрики должны быть видны на графиках и в полях значений.
14. Скачайте и установите в качестве сервиса самую свежую версию postgres_exporter (можно сразу ставить через apt install prometheus-postgres-exporter), проверьте доступность сервиса (systemctl), посмотрите, открыт ли порт TCP/9187 (ss, netstat). Подключите сбор данных с prometheus-postgres-exporter (job_name: 'postgres_exporter').
15. Добавьте в PostgreSQL пользователя rebrain_monitoring c правами SUPERUSER.
16. Настройте окружение для postgres_exporter так, чтобы работало подключение к PostgreSQL к базе данных rebrain_courses_db с правами rebrain_monitoring. Для этого используйте файл "/etc/default/prometheus-postgres-exporter", в него в одну строку внесите данные о подключении (DATA_SOURCE_NAME).
17. Скачайте и импортируйте Dashboard 9628 для postgres_exporter и мониторинга PostgreSQL. Выберите в качестве источника данных prometheus-server.
18. Проверьте работоспособность postgres_exporter воспользовавшись импортированной панелью мониторинга 9628. Все метрики должны быть видны на графиках и в полях значений.
19. Проинициализируйте pgbench для базы данных rebrain_courses_db (если это необходимо, поставьте пакет postgresql-client-common).
20. Проведите нагрузочный тест с помощью pgbench (50 конкурентных клиентов в 5 потоков, 120 секунд). Метрики для PostgreSQL будут изменяться с течением времени.
21. Проанализируйте графики на обеих панелях мониторинга, убедитесть, что нагрузочный тест проведен успешно.
22. Если уверены, что все сделали правильно, сдавайте задание на проверку.