Как организован мониторинг системы?
Мониторинг — одна из трех частей концепции Observability (наблюдаемость), в которой описаны методы получения доступа к информации о внутреннем состоянии системы. Мониторинг системы состоит из 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 (отдельно по количеству запросов, отдельно — по затраченному машинному времени) и состоянии серверов.