# 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. **Поздравляю!**