Изучаем описание метрик, мониторинга и системы оповещений под руководством старшего системного инженера Logrocon Ивана Худорожкова. В конце страницы вы найдете видео с лекцией по нижеизложенным материалам.

Рассматриваемые вопросы:

• Что такое метрики и зачем их собирать?
• Что такое мониторинг?
• Программное обеспечение для мониторинга
• Что такое система оповещений?
• Какие данные нужно отслеживать?
• 5 ошибок в настройке и процессе сбора данных
• А что если не мониторить и не проверять свои данные?
• Список литератур

Что такое метрики и зачем их собирать?

Метрика – это стандарт для измерения ресурса. Метрики могут ссылаться либо на ресурс и его единицы измерения, либо на данные, собранные об этом ресурсе.

Сбор метрик делится на несколько типов. Есть 3 основных типа метода сбора метрик:

1. Метод сбора и анализа проблем с производительностью инфраструктуры (железо, сеть).
2. Метод сбора высокоуровневых данных и анализа (веб сервисы, базы данных, очереди и тд).
3. Метод сбора и анализа бизнес-метрик.

Что такое метрики и зачем их собирать?

Метрика процесса – количественная мера степени достижения процессом своей цели.
Она должна включать как меры эффективности процесса, так рейтинги уровней зрелости
Целевая точка – желаемое значение метрики процесса
Текущее измерение процесса – значение метрики процесса до реализации мероприятия по усовершенствованию
Результат усовершенствования процесса – значение метрики процесса после осуществления мероприятий по усовершенствованию

Что такое мониторинг?

• Мониторинг — это постоянный сбор и анализ различных параметров (метрик) поведения системы. С его помощью можно описать и измерить в числовом выражении каждый важный аспект проекта.
• Данные из разных точек среды собираются системой мониторинга, которая отвечает за хранение, агрегацию, визуализацию данных и автоматические реагирует на изменения, когда значения соответствует заданным условиям.
• Системы мониторинга выполняют множество взаимосвязанных функций. Их первая обязанность – принимать и хранить входящие данные и историю. Текущие значения более полезно видеть в сравнении с прошлыми значениями, чтобы сформировать контекст изменений и тенденций. Это означает, что система мониторинга должна быть способна управлять данными в течение определенного периода времени, а так же визуализировать.
• Помните, задача мониторинга — предоставлять информацию о сбоях в работе. Она не выполняется разово, изменения должны внедряться вместе с изменениями самого приложения.

Программное обеспечение для мониторинга:

1. Grafana — универсальная обертка для работы с аналитическими данными, которые хранятся в разных источниках. Она сама ничего не хранит и не собирает, а является лишь универсальным клиентом для систем хранения метрик. Например, с помощью нее можно ходить за цифрами как в традиционную базу PostgreSQL, так и в специализированные аналитические системы типа Prometheus.
2. Prometheus — Система сбора данных временных рядов, разработанная музыкальной компанией SoundCloud для решения внутренних потребностей в быстрой и гибкой обработке продуктовых метрик. Продукт с задачей справился настолько хорошо, что был выпущен за границы SoundCloud и теперь доступен как opensource для всех желающих.
3. Zabbix — свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования, написанная Алексеем Владышевым.
4. Nagios — программа с открытым кодом, предназначенная для мониторинга компьютерных систем и сетей: наблюдения, контроля состояния вычислительных узлов и служб, оповещения администратора в том случае, если какие-то из служб прекращают свою работу.

USE Method:

Grafana

Nagios

RED Method:

• RED Method — подход, предложенный Tom Wilkie и является акронимом от (Requests) Rate, Errors, Duration (Запросы) Скорость, Ошибки, Продолжительность). Он рассчитан на сбор метрик с самих приложений.
• RED нужно использовать для более высокоуровневых сервисов, которые обслуживают запросы. Например различные веб сервисы, запросы базы данных, очереди и т.д.
• RED предлагает способ взглянуть на функционирование и производительность услуг, согласованных для разных сервисов. Таким образом снижается когнитивная нагрузка на дежурных инженеров, что очень важно во время простоев.
• Преимущество метода RED в том, что он помогает вам подумать о том, как отображать информацию на ваших информационных панелях. С помощью только этих трех показателей вы можете стандартизировать макет ваших информационных панелей, чтобы упростить их чтение и создание предупреждений при возникновении проблемы.
• Справедливо сказать, что этот метод работает только для сервисов, управляемых запросами – например, он не работает для сервисов, ориентированных на пакетную обработку или потоковых данных.
• https://grafana.com/author/tom/

Метод RED следует принципам, изложенным в Четырех золотых сигналах, разработанных инженерами по надежности сайтов Google или SRE, которые фокусируются на измерении того, что волнует конечных пользователей при использовании ваших веб-сервисов. В методе RED используются три ключевых показателя, которые отслеживают каждый микросервис в вашей архитектуре:

• (Запрос) Rate – количество запросов в секунду, обслуживаемых вашими сервисами.
• (Запрос) Errors – количество неудачных запросов в секунду.
• (Запрос) Duration – Количество времени , каждый запрос принимает выражаются в виде временного интервала

Rate, Errors и Duration пытаются охватить наиболее очевидные проблемы веб-сервисов. Эти метрики также фиксируют частоту ошибок, которая выражается как доля от частоты запросов (rps).

Для каждого приложения отслеживайте:

• Задержка - время затраченное на запрос
• Трафик - какой объём сети занимает приложение от доступного
• Ошибки - прогнозирование и оценка количества ошибок
• Насыщенность - на какую часть загружена система

Grafana + Prometheus

UCA method:

• UCA акроним от Users, Conversions, Activity (Пользователи, Преобразования, Деятельность) и он нацелен на измерение бизнес метрик сервиса. Его предложил Mike Julian и рассмотрел его в своем курсе Monitor Anything.
• Для того чтобы определить какие бизнес метрики согласно UCA можно собирать, нужно понимать как работает сервис, кто является его пользователями (Users). Для различных отраслей это могут быть количество активных пользователей, посетителей на сайте, количество звонков, количество покупателей сейчас/среднее в день/месяц и т.д.
• Далее, Conversions. Это про то, что пользователь из предыдущего пункта каким-либо образом принес доход вашему сервису. Например, пользователь купил платную подписку на сервис, забронировал номер в отеле, купил товар в интернет-магазине, сделал заказ.
• Activity показывает, что пользователи продолжают пользоваться вашим продуктом. Например, это могут быть входы на сайт, просмотры товаров, поиски, добавления в корзину, запросы дополнительных сервисов, время проведенное на сайте и прочее.
• UCA позволяет собирать метрики, которые показывают как бизнес себя чувствует. И, отталкиваясь от этих метрик, можно искать и собирать инфраструктурные метрики с помощью USE и RED и понимать, из-за ухудшения каких показателей нужно поднимать в первую очередь инженеров (алертить).
• https://mikejulian.com/

Google Analytics

Что такое система оповещений?

• Система оповещений является компонентом системы мониторинга, который выполняет действия на основе изменений метрических значений.
• Определения системы оповещений состоят из двух компонентов: условия (или порога), основанного на метриках, и действия, которое нужно выполнить, когда значения выходят за пределы приемлемых условий.
• Основная цель системы оповещений – это привлечь внимание человека к текущему состоянию системы. Предупреждение должно содержать информацию о том, что пошло не так и где найти дополнительную информацию. Затем пользователь, отвечающий на предупреждение, может использовать систему мониторинга и связанные с ней инструменты (например, логи) для изучения причины проблемы и ее устранения.
• Так же в систему оповещений может входить автоматическое реагирование на проблемы, заложенные заранее определенным шаблоном действий.
• Пример настройки системы оповещения в Zabbix:

1. Мониторинг оборудования:

• нагрузка на процессор;
• свободное место в оперативной памяти;
• свободное место на жестком диске;
• нагрузка на сеть;
• нагрузка на жесткий диск — количество операций на запись и чтение;
• количество задач, запущенных на исполнение.

2. Мониторинг состояния приложений:

• Количество запросов в единицу времени: час, секунду, день, минуту — зависит от обилия трафика в вашей программе.
• Количество активных пользователей в системе в единицу времени.
• Количество различных записей в СУБД — в целом и новых в единицу времени.
• Количество ошибок в сервисе, которые вы успешно отловили и зарегистрировали.

3. Мониторинг бизнес-метрик:

• Сколько пользователей зарегистрировано в системе и сколько пользуется приложением раз в день/неделю/месяц?
• Какой процент людей после регистрации умудряется дойти до формы оплаты и оплатить подписку на ваши услуги? Сколько они платят?
• Как люди пользуются вашими услугами? Какие фичи используют почти все, а какие — единицы клиентов?
• Как много денег вы зарабатываете на вашей программе? Сколько человек оплатили подписку? Какие средние и медианные чеки на клиента? Какова общая выручка и прибыль?

5 ошибок в настройке и процессе сбора данных

1. Человеческий фактор.
2. Отсутствие связи между бизнес-задачами и настройкой аналитики.
3. «Плавающее» руководство по сбору данных.
4. Разрозненные данные.
5. Отсутствие проверок.

Комплексный мониторинг – преимущества

1. Оперативно обнаруживать и решать проблемы в работе приложений до того, как они повлияют на пользователей;
2. Оценивать качество работы приложений на основе объективного мониторинга работы пользователей с приложением;
3. Анализировать клиентский опыт на протяжении всего процесса взаимодействия пользователя с системой;
4. Оценивать работу подрядчиков. Сравнивать их по количеству пользователей, которые выбирают данную платформу;
5. Получить единую точку доступа к общей картине состояния ИТ, возможность исследования «вглубь» – до сырых данных, а также анализировать корреляции.

Комплексный мониторинг – вывод

1. Система комплексного мониторинга является зонтичным решением для существующих систем мониторинга. Она объединяет агрегированные данные из других узкоспециализированных систем.
2. Комплексное решение закрывает все «слепые зоны», не покрытые существующими в компании системами мониторингами – сбор сырых данных из систем источников в комплексный мониторинг.
3. Появляется единая точка для анализа данных и расследования причин инцидентов.
4. Бизнес-аналитики, маркетологи, администраторы и руководители подразделений смотрят на одни и те же данные.
5. Все события имеют корреляцию по времени.

А что если не мониторить и не проверять свои данные?

• Исправление ошибок «по факту» стоит дороже

Профилактика — всегда дешевле лечения. Здесь та же логика. На то, чтобы распутать клубок ошибок на уровне отчета, когда не понятно откуда взялась та или иная цифра, уйдет много времени. И главное, ситуация с ошибкой заставит пройти той же дорогой тестирования, только уже с потерянными нервами и ресурсами.

Список литературы

Реферальные ссылки:

• http://www.brendangregg.com/usemethod.html
• https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/
• https://www.facebook.com/otusru/posts/979380988866993
• https://blog.okmeter.io/use-red-and-real-world-pgbouncer-monitoring-61b34ebeebb8
• https://www.datadoghq.com/blog/monitoring-101-collecting-data/
• https://ppc.world/articles/sobiray-no-proveryay-monitoring-kachestva-dannyh-kak-profilaktika-biznes-oshibok/
• https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals
• https://www.youtube.com/watch?v=zk77VS98
• https://m.habr.com/ru/company/accenture/blog/549610/