Ответ 1
Это вопрос, который не имеет окончательного ответа, но здесь, как мы это делаем на Datadog (мы являемся размещенной службой мониторинга, поэтому мы склонны одержимы этими вещами).
1. Какие показатели необходимы? Это зависит от наблюдателя. Но на высоком уровне для каждой команды любой показатель, максимально приближенный к их целям (который может быть не самым простым для сбора).
Системные метрики (например, загрузка системы, память и т.д.) являются тривиальными для сбора, но редкодействующими, потому что они слишком сложны, чтобы надежно связать их с вероятной причиной.
С другой стороны, количество завершенных путешествий по продуктам имеет значение для тех, кому поручено убедиться, что новые пользователи счастливы с первой минуты, когда они используют этот продукт. StatsD делает этот материал тривиально легким для сбора.
Мы также обнаружили, что основной набор ключевых показателей для любых командных изменений в качестве продукта развивается, поэтому существует непрерывный редакторский процесс.
Это, в свою очередь, означает, что любой человек в компании должен иметь возможность выбирать, какие показатели имеют для них значение. Никаких разрешений, никаких трений, чтобы добраться до данных.
2. Структура именования Наивысший уровень иерархии - это производственная линия или процесс. Наш веб-интерфейс внутренне называется dogweb, поэтому все метрики из этого компонента имеют префикс dogweb.. Следующим уровнем иерархии является подкомпонент, например. dogweb.db., dogweb.http. и т.д.
Последним уровнем иерархии является измеряемая вещь (например, renderTime или responseTime).
Неразрешенная проблема в графите - это кодирование метрических метаданных в имени метрики (и выбор с использованием *, например dogweb.http.browser.*.renderTime). Он умный, но может мешать.
Мы завершили реализацию явных метаданных в нашей модели данных, но это не в statsd/graphite, поэтому я оставлю детали. Если вы хотите узнать больше, свяжитесь со мной напрямую.