Перейти к основному содержимому

Как организован мониторинг системы?

Мониторинг — одна из трех частей концепции Observability (наблюдаемость), в которой описаны методы получения доступа к информации о внутреннем состоянии системы. Мониторинг системы состоит из 4 этапов:

  • Сбор метрик
  • Хранение метрик
  • Визуализация и дашборды
  • Уведомления и алертинг

Почему это важно?

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

О чём стоит поговорить?

  1. Какие метрики собираются?
  2. Где хранятся метрики?
  3. Как устроена визуализация?
  4. Как устроено информирование?
    • Куда летят алёрты по мониторингу, кто их чекает?
    • Какие уровни строгости выделяете?
      • ошибки нет
      • ошибка на стороне клиента
      • ошибка на нашей стороне, не теряем денег, не несём риски
      • ошибка на нашей стороне, теряем деньги
    • Каково содержание алёртов?
      • Критичность: warning
      • php процесс потребляет слишком много памяти: имя процесса
      • Потребляет: 1.075G
      • Сервер: имя сервера
      • График: ссылка на график
      • Вики: ссылка на вики

Что делать?

Шаг 1. Договоритесь о метриках

Существую стандартные методики мониторинга, можно начать с них.

USE расшифровывается как Utilization, Saturation, Error. Подходит для мониторинга ограниченных ресурсов, например, оборудования. В общих чертах это выглядит так:

  • Utilization — работа под нагрузкой.
  • Saturation — работа под сверхнагрузкой (задачи в очереди).
  • Errors — количество ошибок.

RED означает Rate, Errors, Duration. Лучше всего подходит в кейсах с неограниченными ресурсами, особенно для приложений в режиме request-response:

  • Rate — количество запросов к ресурсу в единицу времени
  • Errors — количество запросов в единицу времени, закончившихся ошибкой
  • Duration — время выполнения запроса (в виде гистограммы)

The Four Golden Signals рекомендуют для использования с фронтендом:

  • Latency — задержки. Здесь важно разделять задержи успешных и неудачных запросов; последние могут испортить общую статистику.
  • Traffic — загруженность системы. В веб-сервисах, например, обычно измеряется в количестве HTTP-запросов в секунду.
  • Errors — ошибки. Доля запросов, которые по разным причинам завершились ошибками.
  • Saturation — уровень загруженности системы. Особое внимание здесь стоит уделить ресурсам, которые ограничены. Также, производительность некоторых систем падает еще до достижения полной загрузки, поэтому стоит заранее определить целевой уровень.

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

Шаг 2. Определите место хранения метрик

Например, Elasticsearch, YTsaurus, Prometheus или ClickHouse.

Шаг 3. Подберите сервис визуализации данных

Например, Datadog, Newrelic, Grafana.

Шаг 4. Договоритесь о правилах информирования

См. Incident Management

Ссылки

Как мы мониторим заказы. ГдеМатериал

Как бороться с багами? Часть вторая: отслеживание ошибок. Дизайн-бюро Артёма Горбунова

Органы чувств в инфраструктуре. Фёдор Борщёв

Мониторинг: смысл, цели и универсальные рецепты. Хабр

Тулзы

Geckoboard

Datadog

Sentry

UptimeRobot