Вы не можете выбрать более 25 тем Темы должны начинаться с буквы или цифры, могут содержать дефисы(-) и должны содержать не более 35 символов.

172 строки
16 KiB
Markdown

# LR4 Добработка сервиса предсказаний. Мониторинг
## Цель
Доработать микросервис предсказаний моделью ML, создать скрипт по тестированию сервиса и подключить мониторинг.
## Подготовка
Если вы выполняете работу на своем компьютере, то рекомендуется заранее дома скачать образы, которые потребуются для ЛР:
```
docker pull prom/prometheus
docker pull grafana/grafana
docker pull dpage/pgadmin4
docker pull postgres:17.2
```
## Задание
### Тесторование сервиса предсказаний
1. Активировать виртуальное окружение.
2. В директории `./services` создать директорию `requests`, в которой будет создан скрипт отправки запросов в основной сервис.
```
my_proj
|_____ .venv_my_proj
|_____ .git
|_____ data
|_____ eda
|_____ research
|_____ services
| |___ ml_service
| |___ requests
|
|_____ .gitignore
|_____ README.md
|_____ requirements.txt
```
3. Создать файл `requests.py`, в котором через случайные промежутки времени будут отправляться запросы к основному сервису предсказаний.
> Можно установить диапазон "случайного" времени от 0 до 5 секунд.
4. Запустить образ сервиса предсказаний. Запустить скрипт отправки в него сообщений и убедиться, что сервис предсказаниий получает запросы и выдает на них предсказаний. При необходимости - устранить ошибки.
> В качестве образа сервиса предсказаний использовать образ, полученный по итогам выполнения ЛР3. Если вы выыполняете работу за другим компьютером, то необходимо склонировать репозитарий ЛР3, и собрать образ заново.
5. Добавить в директорию `requests` необходимые для сборки образа файлы и собрать образ.
> Предусмотреть при задании адреса отправки запросов, что и сервис предсказаний, и сервис запросов в дальнейшем будут запускаться через `docker compose`. Т.е. в качестве адреса должно быть указано _имя сервиса предсказаний_.
> Обратить внимание на зависимости для этого сервиса - в файле `requirements.txt` должны быть только те зависимости, которые реально нужны при отправке запросов. Не нужно писать лишние зависимости "на всякий случай" - это будет раздувать образ и увеличивать его время сборки!
> В конец `Dockerfile` добавить закомментированные команды по сборке образа `docker build ...` и его запуску `docker run ...`
6. В директории `./services` создать файл `compose.yml` и описать сборку проекта, состоящего из сервиса предсказаний и сервиса отправки в него запросов.
7. Собрать проект через `docker compose` и убедиться, что сервис предсказаниий получает запросы и выдает на них предсказаний. При необходимости - устранить ошибки.
### Мониторинг
8. В директории `./services` создать директорию `prometheus`, `grafana`, в которых будут храниться данные соответствующих сервисов мониторинга.
```
my_proj
|_____ .venv_my_proj
|_____ .git
|_____ data
| |___ ...
|
|_____ eda
| |___ ...
|
|_____ research
| |___ ...
|
|_____ services
| |___ ml_service
| |___ requests
| |___ prometheus
| |___ grafana
|
|_____ .gitignore
|_____ README.md
|_____ requirements.txt
```
9. Настроить сервис по сбору метрик Prometheus. Для этого в директории `prometheus` создать конфигурационный файл `prometheus.yml`.
10. Модифицировать сервис предсказаний, добавив в него сбор метрики типа `histogram`, в которую сохраняются предсказания модели. Количество и размен корзин гистограмы установить таким образом, чтобы гистограма было интерпретируема и полезна.
11. Собрать образ сервиса предсказаний, установив ему версию 2.
> В прошлой ЛР ваш сервис должен быть иметь версию 1, например flat_predictions:1. Если у вас в прошлой ЛР оказалась более старшая версия (например flat_predictions:3), то в текущей ЛР установить следующий номер по порядку - 4.
12. Модифицировать файл `compose.yml`, добавив в него сборку сервиса `prometheus`
13. Собрать проект, убедиться, что после его запуска у вашего сервиса предсказаний появился endpoint `/metrics`, а в графическом интерфейсе `prometheus` в разделе `/targets` ваш сервис предсказаний находится в состоянии `UP`.
14. В интерфейсе `prometheus` добавить графики и сохранить их скриншоты:
* гистограма предсказаний модели
* частота (rate) запросов к основному сервису в минуту
* Количество запросов к сервису с кодами ошибок 4** и 5** (две линии на одном графике).
> Для проверки корректности сбора этой метрики можно вручную через Swagger UI отправить запросы с ошибками. Например, убрав запятые между параметрами или отправив пустое тело запроса.
### БД (Необязательный раздел)
**Этот раздел необязательный, и оцениваться не будет. Его можно делать по желанию (и даже после защиты ЛР), или сразу перейти к разделу "Дашборд"**
15. В директории `./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
```
16. Для папки `/pgadmin` нужно выдать права:
`sudo chown -R 5050:5050 ./pgadmin`
17. Добавить в `compose.yml` два сервиса `database` и `pgadmin` со всеми необходимыми параметрами запуска, такими как `ports`, `volumes`, `environment`. В ЛР в качестве логинов и паролей можно указать дефолтные по типу *admin:admin*.
> В продакшн системах, конечно же, пароли должны соотвествовать политике безопасности компании и\или здравому смыслу, а передаваться в контейнеры посредством переменных окружения через файлы `.env`, которые *НЕ ДОЛЖНЫ КОММИТИТЬСЯ*. Подробнее: [Docker and securing passwords](https://stackoverflow.com/questions/22651647/docker-and-securing-passwords)
17. Запустить проект, убедиться, что контейнеры postgres и pgadmin запустились.
18. Зайти в pgadmin и создать соеднинение с СУБД postgres. В качестве адреса хоста можно указать название сервиса - `database` (или так, как вы назвали этот сервис в `compose.yml`). Далее указать порт, логин и пароль, которые вы задали в `compose.yml` для сервиса `database`. Убедиться, что подключение произошло.
19. Через интерфейс `pgadmin` создать новую БД (имя можно указать любое, но желательно, соответствующее сути вашего сервиса), и создать две таблицы:
* Таблица, где будут храниться поступающие на вход сервиса данные.
* Таблица с предсказаниями модели.
> Название таблицам принято давать по тем сущностям, которые в них хранятся, во множественном числе. Например, для сервиса предсказания квартир первая таблица *flats*, а вторая - *predictions*. Названия следует писать строчными буквами, разделяя слова подчеркиванием `_` ('snake_case')
> Предполагается, что таблицы должны иметь связь по идентификатору и времени создания записи. Таким образом, в обеих таблицах должны быть поля идентификатора сущности и времени создания: `id` и `ts`.
> В рамках ЛР в таблице с поступающими данными допустимо сохранять не все признаки,а лишь часть наиболее информативынх (на ваш взгляд), но не менее 5 штук (помимо id и ts). Т.е. таблица должна состоять из не менее чем 7 столбцов.
20. Модифицировать образ основного сервиса таким образом, чтобы поступающие данные и предсказания записывались в БД. Пересобрать образ, сохранив его под новой версией. Перезапустить проект, не забыв поменять в `compose.yml` версию ml-сервиса на новую.
21. Протестировать работу, убедиться, что все данные сохраняются в БД.
### Дашборд
**Если вы не подключали БД, то пункты задания, связанные с БД, выполнять не нужно**
22. В файле `compose.yml` описать сервис `grafana`:
* Использовать образ grafana/grafana
* Перенаправить порт контенера 3000 на любой порт хоста (например, тоже 3000)
* Указать переменные окружения - логин и пароль. В учебных целях их можно оставить по-умолчанию admin:admin
- GF_SECURITY_ADMIN_USER=admin
- GF_SECURITY_ADMIN_PASSWORD=admin
23. Собрав проект и перейдя в веб-интерфейс `grafana`, создать подключение к `prometheus` и `database`
24. Создать дашборд, содержащий как минимум 5 графиков разных уровней мониторинга: прикладного, инфраструктурного и качества работы модели.
> Графики двух первых уровней можно построить по метрикам `prometheus`, в т.ч. по тем, которые были сформированы в разделе "Мониторинг" текущей ЛР. Качество работы модели (data shift) проще получить из данных, хранящихся в базе данных.
25. "Оживить" дашборд, генерируя запросы к ml-сервису, используя сервис `requests`, созданный в данной лабораторной работе, а также сгенерировав несколько запросов с ошибкой.
26. Сделать скриншот дашборда, добавить его в `README.md`, описав каждый график - что он отображает и к какому уровню мониторинга относится.
27. Сохранить и импортировать дашборд в папку `grafana`. Его нужно будет закоммитить.
### Завершающий этап
28. Актуализировать файл `README.md`:
* добавить описание разработанных сервисов (`grafana`, `prometheus`, `pgadmin` и `database`): краткое описание файлов в созданных папках, структуру БД, по какому адресу запускается веб-интерфейс.
* Указать команды для запуска compose-проекта
* Добавить скриншоты из раздела "Мониторинг" и "Дашборд" со всеми требуемыми описаниями
* Добавить в начало файла полное описание проекта со всеми использованными технологиями и библиотеками.
> Этот пункт будет полезен потенциальным работодателям для оценки ваших навыков. Поэтому, стоит уделить ему внимание и вспомнить чем вы занимались на данном проекте.
29. Актуализировать `.gitignore` и `requirements.txt` при необходиомости.
30. Запушить финальную версию проекта на github.
> Итогом выполнения цикла лабораторных работ стал проект в вашем портфолио на github. **Поздравляю!**