Мониторинг приложений: закрытие пробелов в наблюдаемости с помощью пользовательских метрик

Какие метрики приложения следует собирать?

Я часто взаимодействую с клиентами, которые разбивают свои монолитные приложения на более мелкие микросервисы. Многие команды также рассматривают эту миграцию как возможность сделать приложения более заметными. В результате клиенты спрашивают, какие показатели им следует отслеживать для типичного облачного приложения.

Раньше, когда клиент спрашивал меня, как настроить сервис, я указывал ему на хорошо известные [методы USE и RED] (https://grafana.com/blog/2018/08/02/the-red-method-how). -to-instrument-your-services/). Но я чувствовал, что ответ не был исчерпывающим. Список конкретных метрик для мониторинга может быть полезен для команд, разрабатывающих собственные облачные приложения. Этот пост является попыткой предоставить список метрик для сбора в типичном приложении. Не все показатели, перечисленные ниже, применимы к каждому типу приложений. Например, пакетные рабочие нагрузки редко обслуживают трафик, и, как следствие, нет необходимости вести журнал обслуживаемых запросов.

Цель этого документа — помочь разработчикам найти «золотые сигналы» для своих приложений.

Золотые сигналы — термин, впервые использованный в [руководстве Google SRE] (https://sre.google/sre-book/monitoring-distributed-systems/). Золотые сигналы — это четыре показателя, которые дадут вам очень хорошее представление о реальном состоянии и производительности вашего приложения с точки зрения субъектов, взаимодействующих с этой службой, будь то конечные пользователи или другая служба в вашем микросервисном приложении.

Наблюдаемость

Передовой опыт в области облачных вычислений рекомендует создавать системы, которые можно наблюдать. Хотя слово «наблюдаемость» (или «O11y», как его обычно называют) не имеет официального определения, оно является мерой способности системы раскрывать свое внутреннее состояние. Три столпа наблюдаемости — это журналы, метрики и трассировки.

Современные системы предназначены для создания журналов, выдачи метрик и предоставления трассировки, чтобы помочь разработчикам и операторам понять ее внутреннее состояние.

Push vs Pull

Выдача метрик путем предоставления их на доступной извне конечной точке HTTP получает более широкое распространение благодаря разработчикам, использующим Prometheus для мониторинга. В этой модели Prometheus извлекает метрики, очищая конечную точку приложения /metrics.

Когда вы запускаете Node Exporter, он публикует метрики по адресу http://localhost:9100/metrics

Инструменты наблюдения собирают и анализируют данные из разных источников, чтобы помочь вам обнаружить проблемы и выявить узкие места. Цель состоит в том, чтобы использовать эти сигналы системы для повышения ее надежности и предотвращения простоев.

Продукты AIOps, такие как Amazon DevOps Guru, также могут обнаруживать аномалии с помощью журналов, метрик и трассировок вашего приложения (и других источников) и давать вам ранние сигналы для предотвращения потенциальное нарушение.

Метрики для сбора

Чтобы приложение функционировало должным образом, оно и его базовая система должны быть исправными. Метрики хоста информируют оператора об использовании ресурсов хоста и инфраструктуры, таких как ЦП, память, ввод-вывод и т. д. Если вы используете Prometheus, Node Exporter автоматически собирает эту информацию. для тебя.

Показатели хоста редко отличаются. Независимо от того, запускаем ли мы процесс на экземпляре EC2 или Raspberry Pi, нас интересуют одни и те же показатели.

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

1. Определите будущие области улучшения, предоставив измерения для конкретного кода. Мониторинг приложений или инструменты APM обеспечивают измерения в течение отрезка времени, которые разработчики могут анализировать.

1. В случае сбоя системы предоставьте информацию для устранения неполадок и предотвращения.

1. В некоторых случаях подавайте ранние сигналы бизнесу. Например, если приложение раскрывает данные, заказы, которые оно обрабатывало за последние 60 минут, можно отслеживать с помощью системы мониторинга, а не с помощью запросов к реляционной базе данных.

Есть несколько компаний, таких как мониторинг приложений или компании APM, такие как New Relic, DataDog, у которых есть продукты для агрегирования метрик приложений с использованием SDK или агентов. Однако они не будут собирать специфические для бизнеса метрики, которые важны только для вашего приложения.

Чтобы создать список соответствующих метрик для приложения, его архитекторы должны будут определить сигнал для каждой его ключевой функции. Отличительной чертой микросервиса является то, что он делает одну вещь хорошо, поэтому у него не должно быть много ключевых функций. Начните с описания функций, реализованных в коде, и создания списка показателей, которые помогут вам оценить его производительность (или, по крайней мере, его доступность).

Большинство измерений, которые вы будете выполнять, подпадают под одну из следующих категорий:

Прилавок

Как следует из названия, это значение увеличивается при запуске функции. Пример: общее количество обработанных запросов

Гистограмма

Гистограмма отбирает наблюдения (обычно это такие вещи, как продолжительность запроса или размер ответа) и подсчитывает их в настраиваемых сегментах.

Измерять

Этот тип метрики отслеживает значение, которое увеличивается или уменьшается за период. Пример: количество потоков.

На этом фоне давайте пройдемся по списку общих пользовательских метрик, которые используют разработчики.

Сетевая активность

Это очевидные показатели для отслеживания любого приложения, которое обслуживает трафик. Сетевые метрики сообщают вам, какая нагрузка приходится на систему. Со временем эти точки данных помогут вам при разработке стратегии масштабирования системы.

Вещи, которые вы должны включить:

• Количество запросов по типу API или странице

• Всего запросов

• Транзакции

• Параллельные, просроченные и отклоненные сеансы

• Водяной знак, фиксирующий максимальное количество одновременных сеансов

• Среднее время обработки

• Количество по типу ошибки

Использование ресурсов

Рекомендуется отслеживать насыщение системы, которое является мерой потребления ресурсов вашей системы. У каждого ресурса есть предельная точка, после которой дополнительная нагрузка приводит к снижению производительности. Масштабируемые и надежные системы спроектированы таким образом, чтобы никогда не нарушать предел прочности.

Однако простого сбора данных об общей насыщенности ресурсами на уровне приложения недостаточно. Вам также необходимо глубже изучить уровень потока или пула ресурсов.

Рассмотрите возможность сбора этих показателей:

• Количество процессоров, загрузка ЦП системы, загрузка ЦП процесса, доступная память, используемая память, доступный своп, используемый своп, количество дескрипторов открытых файлов.

• Общее количество ресурсов, потребляемых пулами соединений, пулами потоков и любыми другими пулами ресурсов.

• Общее количество запущенных потоков, текущее количество потоков, текущие занятые потоки, количество поддержания активности, количество потоков опроса и количество подключений.

• Объекты созданы, уничтожены и извлечены, максимальная отметка, количество извлечений,

• Количество потоков, заблокированных в ожидании ресурса, количество раз, когда поток блокировался в ожидании

Распространенные фреймворки, такие как Tomcat, Flask и т. д., поддерживают экспорт предопределенных метрик. Например, JMX уже предоставляет кучу этих метрик. См. [документацию по AWS CloudWatch] (https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Sample-Workloads-javajmx.html).

Пользователи

Кроме того, обслуживая целевую аудиторию, боты или скрипты наводняют веб-серверы, выходящие в Интернет, запросами. Эти автоматические запросы могут перегрузить систему, если запросы, не прошедшие проверку подлинности, обрабатываются неправильно (например, не перенаправлять все запросы, не прошедшие проверку подлинности, в службу проверки подлинности и пытаться обработать запрос, не прошедший проверку подлинности).

Вот метрики, связанные с пользователями, которые нужно собирать:

• Аутентифицированные и неаутентифицированные запросы

• Демография, аутентифицированные и неаутентифицированные запросы, шаблоны использования,

• Неудачные попытки входа

Некоторые из этих показателей также могут быть получены из вашего балансировщика нагрузки или входа.

Хозяйственная операция (для каждого типа)

Если ваше приложение следует подходу микросервисов, тогда код выполняет одну функцию, по крайней мере, такова идея. Каковы ключевые показатели эффективности функции вашего приложения? Определите их и отслеживайте эти показатели.

Если будущие выпуски вызовут снижение производительности, вы сможете это обнаружить. Отслеживание этих бизнес-показателей поможет вам легко отслеживать тенденции и избегать каскадных сбоев.

Вот общие вещи, о которых заботятся сервисы:

• Заказы, сообщения, запросы, транзакции обработаны

• Показатели успеха и неудач. Для продавца это может быть коэффициент конверсии.

• Соглашения об уровне обслуживания (например, среднее время отклика транзакции)

Если вам все еще нужна помощь в определении ключевых показателей, задайте себе вопрос: каким образом мое приложение может негативно повлиять на бизнес, даже если оно может казаться здоровым?

Подключения к базе данных

Наряду с мониторингом экземпляров базы данных с помощью инструментов мониторинга базы данных рассмотрите возможность сбора показателей работоспособности подключения к базе данных в своем приложении. Это особенно полезно, если ваше приложение использует общую базу данных. Если ваше приложение сталкивается с ошибками подключения к базе данных, но база данных остается работоспособной для другого приложения, вы знаете, что проблема на стороне приложения, а не базы данных.

Рассмотрите возможность записи следующих показателей, связанных с базами данных:

• Количество выброшенных SQLException

• Количество (одновременных или максимальное) запросов

• Среднее время выполнения запроса

Потребление данных

Где бы вы ни сохраняли данные, вам необходимо убедиться, что вы собираетесь превысить свои квоты и исчерпать место. Помимо мониторинга томов данных на диске и в памяти, не забывайте отслеживать данные, которые ваше приложение хранит в базах данных и кэшах.

Состояние кэша

Говоря о кеше, рекомендуется отслеживать следующие показатели:

• Предметы в кеше

• Получить и установить задержку

• Количество попаданий и промахов

• Предметы смыты

Также рассмотрите возможность использования внешнего кеша, такого как Redis или Memcached.

Внешние сервисы

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

• Состояние автоматического выключателя

• Количество таймаутов, запросов

• Среднее время отклика или задержка

• Ответы по типу

• Сетевые ошибки, ошибки протокола

• Запросы в полете

• Верхний предел одновременных запросов.

Детализация сбора метрик

Частота публикации и сбора метрик зависит от требований вашего бизнеса. Для ритейлера знание моделей трафика по часам и дням полезно для масштабирования емкости. Точно так же на график движения туристической компании влияет расписание выходных дней.

Amazon EC2 предоставляет метрики экземпляра с интервалом в 1 минуту, что является хорошим началом для критически важных метрик.

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

Рассмотрите возможность предоставления оператору контроля над метриками, которые должен генерировать ваш код. Таким образом, вы можете включать определенные показатели, когда это необходимо.

Вывод

Выяснить, какие метрики собирать, — это ответ, на который могут ответить только самые знакомые с кодом. В этом посте представлен список показателей, которые помогут вам начать работу.

Есть ли какие-то показатели, которые я упустил из виду? Дайте мне знать на @realz.

Использованная литература

https://giedrius.blog/2019/05/11/push-vs-pull-in-monitoring-systems/

https://www.splunk.com/en_us/blog/learn/sre-metrics-four-golden-signals-of-monitoring.html

https://www.oreilly.com/library/view/learning-modern-linux/9781098108939/

https://www.oreilly.com/library/view/release-it/9781680500264/

Также опубликовано [здесь] (https://realvarez.com/closing-observability-gaps-with-custom-metrics/).