В этой заметке собрана информация про мониторинг информационных систем и популярные методологии.

Любая система имеет тенденцию меняться. Как под воздействием внешних условий, например увеличением или уменьшением потока трафика, так и внутренних, например изменение кодовой базы.

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

В индустрии закрепились термины - monitoring and observability .

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

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

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

Для эффективной работы системы ее развитие должно идти параллельно с развитием системы мониторинга (доклад ). Таким образом реализуя подход continuous monitoring .

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

  • Получение быстрой обратной связи на этапах разработки и развертывания систем
  • Создание информационных панелей для отражения текущего/прошлого состояния системы
  • Прогнозирование поведения системы в будущем
  • Сравнение с предыдущими версиями
  • Оповещение об инцидентах
  • Формирование отчетов и последующий ретроспективный анализ данных
  • Вопросы безопасности и аудита

Виды мониторинговых систем

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

Условно такие системы можно поделить согласно уровневой модели BSA (Base, Service, Application):

  • Инфраструктурный слой(Base)
    • Виртуальные машины, физические хосты, сеть, уровень оркестрации и т.д.
  • Сервисный слой(Service)
    • Балансировщики нагрузки, базы данныз, очереди сообщений и т.д.
  • Слой приложения(Application)
    • Производительность приложения (garbage collector, метрики runtime)
    • Взаимодействие микросервисов между собой, с инфраструктурными сервисами, с внешними сервисами
  • Бизнес-метрики
    • Высокоуровневые показатели (кол-во пользователей, совершенных покупок, трассировка бизнес-процессов и т.д.)

Проектирование системы мониторинга

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

Примерный алгоритм может выглядить так:

  • Определить задачи решаемые приложением
    • для чего оно разрабатывается, кто его пользователь
    • кто будет поддерживать системы в дальнейшем
  • Определить требования предъявляемые к системам приложения
    • какие существуют ограничения к его функционированию
    • требования к надежности
  • Определить области требующие внедрения мониторинга
  • Определить допустимые значения метрик
  • Разработать runbook’и для решения возникающих проблем

The USE method

USE (Utilization, Saturation, Errors) - метод анализа производительности любой системы, представленный Бренданом Греггом , известным инженером и автором книг из Netflix. Он описывает создание контрольных списоков вопросов, которые могут использоваться для анализа производительности сервера, выявления узких мест и ошибок в ресурсах.

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

Метод USE успешно использовался бесчисленное количество раз в различных корпоративных средах, учебных средах (как инструмент обучения), а в последнее время - в средах облачных вычислений.

Метод USE можно резюмироватьь как:

Для каждого ресурса проверьте утилизацию, насыщение и ошибки.

  • Resource – все функциональные компоненты физического сервера (ЦП, диски, сеть, …)
  • Utilization – среднее время, в течение которого ресурс был занят полезной работой. Либо, процент занятого “места” ресурса на данный момент
  • Saturation – мера количества “отложенной” в очередь работы
  • Errors – количество ошибок

The RED method

RED (Requests, Errors, Durations) - методология от Тома Уилки . Методология RED определяет три ключевых показателя, которые вы должны измерять для каждого микросервиса в вашей архитектуре. Эти показатели:

  • Requests rate – количество запросов в интервал времени
  • Errors – количество ошибок в интервал времени
  • Duration – измерение времени запросов

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

Четыре золотых сигнала мониторинга

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

  • Время отклика (Latency) – время, которое требуется для выполнения запроса.
  • Величина трафика (Traffic) – величина нагрузки, которая приходится на систему.
  • Ошибки (Errors) – количество (или частота) неуспешного выполнения запросов (явно и неявно).
  • Загруженность (Saturation) – показатель того, насколько полно загружен сервис.

Выводы

  • Хорошая система мониторинга должна отвечать на два вопроса: что сломалось и почему.
  • Построение любой системы начинается со сбора требований предъявляемых ей. Инструменты вторичны.

Дополнительные материалы