homework 10.1: complete main task

src/homework/10-monitoring/10.1/readme.md

@@ -0,0 +1,75 @@
+Выполнение [домашнего задания](https://github.com/netology-code/mnt-homeworks/blob/MNT-13/10-monitoring-01-base/README.md)
+по теме "10.1. Зачем и что нужно мониторить"
+
+## Q/A
+
+### Задание 1
+
+> Обязательные задания
+> 
+> 1. Вас пригласили настроить мониторинг на проект. На онбординге вам рассказали, что проект представляет собой
+> платформу для вычислений с выдачей текстовых отчетов, которые сохраняются на диск. Взаимодействие с платформой
+> осуществляется по протоколу http. Также вам отметили, что вычисления загружают ЦПУ. Какой минимальный набор метрик вы
+> выведите в мониторинг и почему?
+
+Стоит выделить несколько основных метрик для мониторинга:
+1. метрики дисков, а именно:
+    * оставшееся свободное место, чтобы иметь возможность вовремя среагировать на отсутствие места для сохранения отчётов
+    * скорость чтения/записи с заранее определённой максимально допустимой скоростью как threshold.
+    Это необходимо, чтобы понимать, в какой момент скорость работы приложения упирается в "железо",
+    а когда есть проблемы со скоростью обработки вычислений внутри самого приложения.
+2. метрики web-сервера
+    * количество входящих запросов в секунду (общая и по каждому endpoint), чтобы была возможность отследить неожиданные всплески запросов 
+    и, возможно, закрыть доступ по ip-адресу.
+    * скорость выполнения запросов по каждому endpoint для контроля скорости работы приложения.
+    В дальнейшем на основе этой метрики стоит построить мониторинг по процентилям (например, чтобы 98% запросов выполнялись в рамках определённого времени).
+3. метрики процессора
+    * загруженность ядер виртуальной машины, чтобы иметь возможность увидеть возможную проблему быстродействия приложения.
+4. метрики сетевого интерфейса
+    * скорость приёма и отдачи информации по сети
+    * общий размер принятой и отданной информации
+    
+    Данные метрики необходимы для анализа динамики сетевого взаимодействия и дальнейшего планирования 
+    апгрейда сетевых интерфейсов.
+
+> 2. Менеджер продукта посмотрев на ваши метрики сказал, что ему непонятно что такое RAM/inodes/CPUla. Также он сказал,
+> что хочет понимать, насколько мы выполняем свои обязанности перед клиентами и какое качество обслуживания. Что вы
+> можете ему предложить?
+
+В данном случае стоит определить конкретные SLA и SLO.
+
+Например, можно определить следующие SLO (цели уровня обслуживания) с обсуждаемыми в дальнейшем значениями:
+* 99.98% запросов обрабатываются успешно
+* 90% запросов обрабатываются в течение 5 секунд
+
+И возможно определение следующих SLA (соглашений об уровне обслуживания):
+* доступность системы - 99.98%
+* реагирование на инциденты:
+    * при высокой нагрузке на процессор в течение некоторого времени (н-р, загрузка всех ядер >90% в течение 1 часа)
+    команда произведёт горизонтальное масштабирование системы для распределения нагрузки в течение 3 часов.
+    * при критическом уровне свободного места (н-р <3GB) будет подключен дополнительный физический/сетевой диск в течение 3 часов.
+    * реагирование на резкий и неожиданный всплеск входящих запросов в течение 1 часа
+
+> 3. Вашей DevOps команде в этом году не выделили финансирование на построение системы сбора логов. Разработчики в свою
+> очередь хотят видеть все ошибки, которые выдают их приложения. Какое решение вы можете предпринять в этой ситуации,
+> чтобы разработчики получали ошибки приложения?
+
+Если нет финансирования, значит необходимо искать варианты среди решений с открытым исходным кодом (или свободных решений).
+Из вариантов:
+* elk-стек ([elasticsearch](https://hub.docker.com/_/elasticsearch) + [logstash](https://hub.docker.com/_/logstash) + [kibana](https://hub.docker.com/_/kibana)) + сбор логов при помощи [logstash](https://hub.docker.com/r/elastic/filebeat)/[fluentd](https://hub.docker.com/_/fluentd)
+* [clickhouse](https://hub.docker.com/r/yandex/clickhouse-server) + [grafana](https://clickhouse.com/docs/en/connect-a-ui/grafana-and-clickhouse/) + [vector](https://hub.docker.com/r/timberio/vector).
+vector используется в качестве принимающей точки, так и для непосредственно сбора логов.
+* [grafana loki](https://hub.docker.com/r/grafana/loki) + grafana + сбор логов при помощи [fluentd](https://hub.docker.com/_/fluentd).
+
+> 4. Вы, как опытный SRE, сделали мониторинг, куда вывели отображения выполнения SLA=99% по http кодам ответов.
+> Вычисляете этот параметр по следующей формуле: summ_2xx_requests/summ_all_requests. Данный параметр не поднимается выше
+> 70%, но при этом в вашей системе нет кодов ответа 5xx и 4xx. Где у вас ошибка?
+
+По всей видимости не учитываются возможные ответы со статусами `3xx` (редиректы).
+Необходимо добавить метрику `summ_3xx_requests` и изменить формулу на следующую:
+
+```text
+(summ_2xx_requests+summ_3xx_requests)/summ_all_requests
+```
+
+В данном случае считаем ответы `3xx` успешно обработанными.