Соглашения о присвоении имен StatsD/Graphite для показателей

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

http.responseTime
http.status.4xx
http.status.5xx
view.renderTime
oauth.begin.facebook
oauth.complete.facebook
oauth.time.facebook
users.active

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

Мой вопрос в два раза:

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

ОТВЕТЫ

Ответ 1

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

1. Какие показатели необходимы? Это зависит от наблюдателя. Но на высоком уровне для каждой команды любой показатель, максимально приближенный к их целям (который может быть не самым простым для сбора).

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

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

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

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

2. Структура именования Наивысший уровень иерархии - это производственная линия или процесс. Наш веб-интерфейс внутренне называется dogweb, поэтому все метрики из этого компонента имеют префикс dogweb.. Следующим уровнем иерархии является подкомпонент, например. dogweb.db., dogweb.http. и т.д. Последним уровнем иерархии является измеряемая вещь (например, renderTime или responseTime).

Неразрешенная проблема в графите - это кодирование метрических метаданных в имени метрики (и выбор с использованием *, например dogweb.http.browser.*.renderTime). Он умный, но может мешать.

Мы завершили реализацию явных метаданных в нашей модели данных, но это не в statsd/graphite, поэтому я оставлю детали. Если вы хотите узнать больше, свяжитесь со мной напрямую.