Задачи

1. Разработать конфигурацию nginx способную с помощью определения типа устройства отдавать разные html странички (просто можно взять банальный HELLO, YOU FROM “Тип устройства”). Под типом устройства понимается Десктоп, Планшет, Смартфон.

Решение
Как реализовано:

1. Сделана мапа $http_user_agent $type
2. Для каждого юзерагента определены типы устройств с помощью регулярных выражений. Например: ~*(Windows|x86|x64|U) pc
3. Создано 3 файла с разными именами. При посещении страницы, после проверки юзерагента и присвоении переменной $type значения, начинается поиск файла с именем /$type.html с помощью try_files. Если файл не найден, выводится страница для десктопа.

2. Написать скрипт на go с возможностью проверять доступность сайта например localhost. Необходимо хранить значения доступности в виде json файла построчно. А также последнее удачное или неудачное значение, с помощью которого можно ставить метки/отправлять сообщения о даунтайме или аптайме сайта.

Решение
Как реализовано:

1. Созданы две структуры для хранения текущей информации и последнего статуса, отличающегося от текущего.
2. С помощью http.Get проверяется доступность сайта, статус код, с периодичностью раз в х секунд. Значение можно изменить.
3. Данные записываются в json, которое имеет имя формата logs_дата_время.json.
4. В случае, если изменяется доступность сайта, выводится оповещение в консоль формата:

=== NOTIFICATION ===
Время: 18_Sep_2025_21-25-26
Информация: Изменение статуса сайта. Текущее состояние: UP 
Прошло времени с последнего изменения статуса: 10с
URL: http://example.com/
================================

В прикреплённых логах можно посмотреть пример изменения доступности (во время работы скрипта физически ребуталась машина для эмуляции отказа работы сайта)

3. Написать демон для systemd, который будет поддерживать работу приложения “watch -n5 ‘du -s /var/log/’” записывать результаты в лог и восстанавливаться после падения.

Решение
Как реализовано:

1. Создан файл watch_du.service, STDOUT перенаправляется в /var/log/watchlogs.txt, STDERR в /dev/null.
2. Задана перезагрузка в случае on-success (так как watch при перезагрузке завершает работу с кодом 0, ему не подходит вариант перезапуска on-failure). Так же, задана переменная окружения TERM=linux.
3. Сервис активирован командой systemctl enable. Пример вывода можно посмотреть в прикреплённом файле watchlogs.txt.

4. Развернуть 2 докер контейнера с mysql. Один будет master, другой slave. Задать конфигурацию баз с указанием - что зачем и почему так. Базы должны быть доступны вне контейнера. Итогом задания - docker-compose с мануальной сборкой mysql и наполнением тестовых данных.

Решение
Как реализовано:

1. Создан docker compose, который запускает два сервиса -- mysql-master и mysql-slave. Сервисы объединены в сетевой бридж, у каждого сервиса свой volumes, так же прокинуты файлы конфигураций и начальных команд.
2. После запуска и сборки мастер и slave создаётся с пустой базой test_db, у мастепа создаётся пользователь replication с привелегиями. Мастер имеет id 1, слейв id 2.
3. Настраивается репликация с помощью bash скрипта

./set_slave.sh

4. Теперь можем вносить изменения в master, новые данные автоматически появятся в slave

Отображаем содержимое slave 
mysql -h 127.0.0.1 --port 3307 -u root -e 'USE test_db; SELECT * FROM users;'
Вносим изменения в master
mysql -h 127.0.0.1 --port 3306 -u root -e 'USE test_db; INSERT INTO users (name) VALUES ("1value"), ("2value");'
Отображаем содержимое slave 
mysql -h 127.0.0.1 --port 3307 -u root -e 'USE test_db; SELECT * FROM users;'

5. Сделать дикое наполнение базы данных. С помощью скрипта автогенерации данных (напишите его на python или go). Наполнение производить на скорости 1000 запросов в секунду, 20 минут, в таблице должно быть 10 int полей и 3 varchar(255) - Скрипт полностью заполняет эти поля. При этом настроить базу данных так, что бы слейв справлялся с этой нагрузкой и задержка была не более 10 секунд.

Решение
Как реализовано:

1. Для заполнения:

• используются горутины, которые создаются каждые time.Ticker(старт скрипта / time Duration(запросы в секунду))
• Всё собирается в докер контейнер для связи с запущенными базами. Все элементы выделены в один бридж flood_mysql-network, доступны по имени контейнеру

2. Для мониторинга:

• В отдельных контейнерах развёрнуты Mysql-exporter для экспорта метрик, Prometheus для сбора метрик от экспортёра, Grafana для визуализации. Визуализация происходит по следующим метрикам: mysql_global_status_queries, mysql_slave_status_second_behind_master Результат нагрузочного тестирования: Current QPS через 25 минут составил 1.92к для мастер, 1.06к для slave mysql_global_status_queries держался 20 минут назад а значении 2600 Максимальный mysql_slave_status_second_behind_master в течении первых 17 минут 3 секунды, далее поднимался до 8 секунд.

После увеличения буфера, количества потоков, максимального количества соединений и отключения подтверждения транзакции удалось повысить производительности до 2.29к для мастера, 1.41к для slave. Задержка составила 1с

Значения получены при следующих характеристиках железа: VPS с выделением 10% cpu, скорость записи на диск 25мб/с

Инструкция по развёртыванию:

1. В папке flood запустить docker compose run -d
2. Настроить слейв с помощью ./set_slave.sh
3. Добавить новый data sources в Grafana (Prometheus, http://prometheus:9090)
4. Импортировать дашборд grafs.json из корня проекта
5. В графиках запросы в секунду и задержка слейва нажать edit - run queries для отображения графиков
6. Собрать флудер. docker build -t flood flood/
7. Запустить флудер. docker run --network flood_mysql-network flood