16 KiB

Исходник Вина История

LR4 Добработка сервиса предсказаний. Мониторинг

Цель

Доработать микросервис предсказаний моделью ML, создать скрипт по тестированию сервиса и подключить мониторинг.

Подготовка

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

docker pull prom/prometheus
docker pull grafana/grafana
docker pull dpage/pgadmin4
docker pull postgres:17.2

Задание

Тесторование сервиса предсказаний

Активировать виртуальное окружение.
В директории ./services создать директорию requests, в которой будет создан скрипт отправки запросов в основной сервис.

my_proj
 |_____ .venv_my_proj
 |_____ .git
 |_____ data
 |_____ eda
 |_____ research
 |_____ services
 |       |___ ml_service
 |       |___ requests
 |              
 |_____ .gitignore
 |_____ README.md
 |_____ requirements.txt

Создать файл requests.py, в котором через случайные промежутки времени будут отправляться запросы к основному сервису предсказаний.

Можно установить диапазон "случайного" времени от 0 до 5 секунд.

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

В качестве образа сервиса предсказаний использовать образ, полученный по итогам выполнения ЛР3. Если вы выыполняете работу за другим компьютером, то необходимо склонировать репозитарий ЛР3, и собрать образ заново.

Добавить в директорию requests необходимые для сборки образа файлы и собрать образ.

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

Обратить внимание на зависимости для этого сервиса - в файле requirements.txt должны быть только те зависимости, которые реально нужны при отправке запросов. Не нужно писать лишние зависимости "на всякий случай" - это будет раздувать образ и увеличивать его время сборки!

В конец Dockerfile добавить закомментированные команды по сборке образа docker build ... и его запуску docker run ...

В директории ./services создать файл compose.yml и описать сборку проекта, состоящего из сервиса предсказаний и сервиса отправки в него запросов.
Собрать проект через docker compose и убедиться, что сервис предсказаниий получает запросы и выдает на них предсказаний. При необходимости - устранить ошибки.

Мониторинг

В директории ./services создать директорию prometheus, grafana, в которых будут храниться данные соответствующих сервисов мониторинга.

my_proj
 |_____ .venv_my_proj
 |_____ .git
 |_____ data
 |       |___ ...
 |
 |_____ eda
 |       |___ ...
 |
 |_____ research
 |       |___ ...
 |
 |_____ services
 |       |___ ml_service
 |       |___ requests
 |       |___ prometheus
 |       |___ grafana
 |              
 |_____ .gitignore
 |_____ README.md
 |_____ requirements.txt

Настроить сервис по сбору метрик Prometheus. Для этого в директории prometheus создать конфигурационный файл prometheus.yml.
Модифицировать сервис предсказаний, добавив в него сбор метрики типа histogram, в которую сохраняются предсказания модели. Количество и размен корзин гистограмы установить таким образом, чтобы гистограма было интерпретируема и полезна.
Собрать образ сервиса предсказаний, установив ему версию 2.

В прошлой ЛР ваш сервис должен быть иметь версию 1, например flat_predictions:1. Если у вас в прошлой ЛР оказалась более старшая версия (например flat_predictions:3), то в текущей ЛР установить следующий номер по порядку - 4.

Модифицировать файл compose.yml, добавив в него сборку сервиса prometheus
Собрать проект, убедиться, что после его запуска у вашего сервиса предсказаний появился endpoint /metrics, а в графическом интерфейсе prometheus в разделе /targets ваш сервис предсказаний находится в состоянии UP.
В интерфейсе prometheus добавить графики и сохранить их скриншоты:

гистограма предсказаний модели
частота (rate) запросов к основному сервису в минуту
Количество запросов к сервису с кодами ошибок 4** и 5** (две линии на одном графике).

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

БД (Необязательный раздел)

Этот раздел необязательный, и оцениваться не будет. Его можно делать по желанию (и даже после защиты ЛР), или сразу перейти к разделу "Дашборд"

В директории ./services создать директорию database с поддиректориями data, pgadmin. С этими поддиректориями должны будут сопоставляться VOLUME-директории в контейнерах postgres и pgadmin соответственно.

my_proj
 |_____ .venv_my_proj
 |_____ .git
 |_____ data
 |_____ eda
 |_____ research
 |_____ services
 |       |___ ml_service
 |       |___ requests
 |       |___ prometheus
 |       |___ grafana
 |       |___ database
 |              |___ data
 |              |___ pgadmin
 |              
 |_____ .gitignore
 |_____ README.md
 |_____ requirements.txt

Для папки /pgadmin нужно выдать права:

sudo chown -R 5050:5050 ./pgadmin

Добавить в compose.yml два сервиса database и pgadmin со всеми необходимыми параметрами запуска, такими как ports, volumes, environment. В ЛР в качестве логинов и паролей можно указать дефолтные по типу admin:admin.

В продакшн системах, конечно же, пароли должны соотвествовать политике безопасности компании и\или здравому смыслу, а передаваться в контейнеры посредством переменных окружения через файлы .env, которые НЕ ДОЛЖНЫ КОММИТИТЬСЯ. Подробнее: Docker and securing passwords

Запустить проект, убедиться, что контейнеры postgres и pgadmin запустились.
Зайти в pgadmin и создать соеднинение с СУБД postgres. В качестве адреса хоста можно указать название сервиса - database (или так, как вы назвали этот сервис в compose.yml). Далее указать порт, логин и пароль, которые вы задали в compose.yml для сервиса database. Убедиться, что подключение произошло.
Через интерфейс pgadmin создать новую БД (имя можно указать любое, но желательно, соответствующее сути вашего сервиса), и создать две таблицы:

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

Название таблицам принято давать по тем сущностям, которые в них хранятся, во множественном числе. Например, для сервиса предсказания квартир первая таблица flats, а вторая - predictions. Названия следует писать строчными буквами, разделяя слова подчеркиванием _ ('snake_case')

Предполагается, что таблицы должны иметь связь по идентификатору и времени создания записи. Таким образом, в обеих таблицах должны быть поля идентификатора сущности и времени создания: id и ts.

В рамках ЛР в таблице с поступающими данными допустимо сохранять не все признаки,а лишь часть наиболее информативынх (на ваш взгляд), но не менее 5 штук (помимо id и ts). Т.е. таблица должна состоять из не менее чем 7 столбцов.

Модифицировать образ основного сервиса таким образом, чтобы поступающие данные и предсказания записывались в БД. Пересобрать образ, сохранив его под новой версией. Перезапустить проект, не забыв поменять в compose.yml версию ml-сервиса на новую.
Протестировать работу, убедиться, что все данные сохраняются в БД.

Дашборд

Если вы не подключали БД, то пункты задания, связанные с БД, выполнять не нужно

В файле compose.yml описать сервис grafana:
- Использовать образ grafana/grafana
- Перенаправить порт контенера 3000 на любой порт хоста (например, тоже 3000)
- Указать переменные окружения - логин и пароль. В учебных целях их можно оставить по-умолчанию admin:admin
  - GF_SECURITY_ADMIN_USER=admin
  - GF_SECURITY_ADMIN_PASSWORD=admin
Собрав проект и перейдя в веб-интерфейс grafana, создать подключение к prometheus и database
Создать дашборд, содержащий как минимум 5 графиков разных уровней мониторинга: прикладного, инфраструктурного и качества работы модели.

Графики двух первых уровней можно построить по метрикам prometheus, в т.ч. по тем, которые были сформированы в разделе "Мониторинг" текущей ЛР. Качество работы модели (data shift) проще получить из данных, хранящихся в базе данных.

"Оживить" дашборд, генерируя запросы к ml-сервису, используя сервис requests, созданный в данной лабораторной работе, а также сгенерировав несколько запросов с ошибкой.
Сделать скриншот дашборда, добавить его в README.md, описав каждый график - что он отображает и к какому уровню мониторинга относится.
Сохранить и импортировать дашборд в папку grafana. Его нужно будет закоммитить.

Завершающий этап

Актуализировать файл README.md:

добавить описание разработанных сервисов (grafana, prometheus, pgadmin и database): краткое описание файлов в созданных папках, структуру БД, по какому адресу запускается веб-интерфейс.
Указать команды для запуска compose-проекта
Добавить скриншоты из раздела "Мониторинг" и "Дашборд" со всеми требуемыми описаниями
Добавить в начало файла полное описание проекта со всеми использованными технологиями и библиотеками.

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

Актуализировать .gitignore и requirements.txt при необходиомости.
Запушить финальную версию проекта на github.

Итогом выполнения цикла лабораторных работ стал проект в вашем портфолио на github. Поздравляю!

16 KiB Исходник Вина История