В оперативном контексте важно отслеживать системные показатели на предмет значительных колебаний стоимости. Такие колебания, будь то вверх («хлопки») или вниз («капли»), часто указывают на проблему либо на горизонте, либо в процессе.
Это может быть немного сложно в тех случаях, когда у нас есть вектор тесно связанных метрик, которые конкурируют за внимание, потому что мы должны решить, как решить эту конкуренцию. Рассмотрим для примера события приложения. У нас может быть сотни или даже тысячи кодов событий. Если у одного из них громадные всплывающие сообщения в течение всего дня, то это просто — код события входит в первую десятку. Если другой код события стабилен, то это тоже просто — он не входит в список. Но что происходит, когда у нас есть код события, который имеет большие всплывающие окна весь день, и другой код события, который имеет один огромный скачок в объеме? Который выигрывает?
Этот пост является первым в серии из двух частей, в которой объясняется, как определить наиболее изменчивые компоненты в векторе, а затем визуализировать их соответствующие временные ряды. В этом первом посте мы сфокусируемся на части идентификации, а во втором мы сделаем визуализацию временных рядов. В конечном итоге нам нужен отдельный график, который показывает для каждого из десяти лучших соответствующих временных рядов всплывающих / выпадающих данных (например, по отношению к часу дня) следующим образом:
Мы также хотим иметь возможность сосредоточиться на любом данном событии:
(В приведенных выше таблицах я исключил ярлыки из легенды.)
Давайте погрузимся в.
Измерение изменений
В конечном итоге мы хотим измерить волатильность , которая является примерно совокупным изменением, восходящим или нисходящим, за определенный период времени. Но чтобы попасть туда, нам нужно начать с измерения изменений в единичной форме.
Для конкретизации рассмотрим ежедневные изменения с разбивкой по часам. Но одни и те же понятия применяются независимо от сроков и сроков.
Также для конкретности, мы сосредоточимся на векторе кодов событий. Но опять же, концепции гораздо более общие. Вот некоторые примеры:
- представление имеет значение для набора веб-страниц
- время ответа для набора сервисных вызовов
- количество заявок на лидерство для ряда ведущих поставщиков
Мы можем измерить изменение для любого количества, которое нам нравится. Чтобы сделать вещи захватывающими (не то, что это уже недостаточно захватывающе), мы пройдемся по различным попыткам, которые я предпринял здесь, так как причины отклонения предыдущих попыток мотивируют окончательный подход.
Попытка № 1: Соотношения. Отношения являются хорошей отправной точкой для измерения изменений: каково, например, соотношение событий (определенного типа) сегодня в течение часа ночи по сравнению со вчерашним днем? Соотношения здесь лучше, чем необработанные, потому что они оказывают нормализующее воздействие.
Проблема с коэффициентами заключается в том, что они асимметричны относительно r = 1,0. Попсы начинаются с r> 1.0, и они могут расти без ограничений. С другой стороны, капли ограничены интервалом (0, 1). Таким образом, когда вы видите r = 23,0 и r = 0,0435, не сразу понятно, что изменения отличаются по направлению, но не по величине.
Попытка № 2: логарифмические отношения. Одним из возможных решений является использование логарифмических отношений, скажем, log base 2, так как мы здесь компьютерные люди. Отношения log фиксируют асимметрию: log_2 (23) = 4,5236, тогда как log_2 (1/23) = -4,5236.
Логарифмические пропорции тоже не идеальны. Большинству из нас, несмотря на то, что мы компьютерные люди, вероятно, более удобно рассуждать с коэффициентами, чем с логарифмическими коэффициентами. Если вы скажете мне, что логарифм для некоторого кода события равен 5, я, вероятно, смогу довольно легко перевести его в коэффициент 32/1. Но если вы скажете мне, что логарифм равен 13,2, я лично не смогу получить реальное соотношение так быстро, как хотелось бы.
Использование базы 10 может немного облегчить задачу, но суть в том, что интуитивно понятнее говорить о самих коэффициентах.
Окончательное решение: модифицированные соотношения. Наш подход будет использовать подписанные, неограниченные отношения. Числитель всегда больше. Например, если вчера было 100 событий одного типа, а сегодня их было 500, тогда оценка изменения равна 5,0 (популярность). Если вместо этого было 500 событий вчера и только 100 сегодня, тогда оценка изменения составляет -5.0 (падение).
Этот подход довольно интуитивно понятен. Если я скажу вам, что показатель изменения был -238,5, сразу станет ясно, что это значит: вчера было в 238,5 раза больше событий за определенный час, чем было сегодня. Довольно большое падение в соотношении.
Теперь у нас есть оценка изменения. В следующем разделе мы рассмотрим агрегирование оценок почасовых изменений в общую меру волатильности.
Измерение волатильности
Напомним, что у нас есть вектор оценок изменений, и он может быть довольно большим. Нам нужно знать, какие десять или около того из сотен или тысяч возможных заслуживают нашего внимания.
Подход снова заключается в оценке каждого кода события. Мы создадим показатель волатильности здесь, так как мы хотим видеть коды событий с «большим изменением» в некотором определенном смысле. В некоторых случаях мы можем больше заботиться о всплесках (или падениях), чем о волатильности в целом. Время отклика является хорошим примером. Это хорошо — подход, описанный ниже, легко адаптировать к таким случаям.
Для волатильности мы будем использовать сумму квадратов . Подход прост: для любого данного кода события возведите в квадрат каждую из его оценок почасовых изменений, а затем сложите их все. Это волатильность.
Сумма квадратов хороша по нескольким причинам:
- Всплывающие и выбрасывающие значения в равной степени способствуют общей волатильности, поскольку оценки изменений для всплывающих и пропадающих значений симметричны, а квадрат оценки изменений всегда положительный.
- Возведение в квадрат оценок изменений усиливает эффект больших оценок изменений. (Если бы у нас были изменения в интервале (-1,0, 1,0), то это также уменьшило бы их эффект, что иногда полезно. Но в нашем случае таких изменений нет.) Так что огромная популярность, которая произошла только один раз, все еще скорее всего попадет в первую десятку.
Это подход. Пришло время увидеть запрос Splunk и результат.
Выложи это
Вот поисковый запрос Splunk, который выдает десятку самых изменчивых кодов событий сегодняшнего дня, измеряя изменения за день:
index=summary reporttype=eventcount reporttime=hourly earliest=-1d@d latest=now
| eval marker = if(_time < relative_time(now(), "@d"), "yesterday", "today")
| stats sum(count) as jfreq by date_hour EventCode marker
| eval tmp_yesterday = if(marker == "yesterday", jfreq, 0)
| eval tmp_today = if(marker == "today", jfreq, 0)
| stats max(tmp_yesterday) as yesterday, max(tmp_today) as today by date_hour EventCode
| eval change = if(today >= yesterday, today / yesterday, -(yesterday / today))
| stats sumsq(change) as volatility by EventCode
| sort volatility desc
| head 10
Обратите внимание, что здесь мы используем сводный индекс Splunk . Это важно, так как в противном случае запрос займет слишком много времени.
Технически, вот что делает запрос:
- Возьмите (тривариатное) объединенное распределение частот по переменным (1) час дня, (2) код события и (3) сегодня-против-вчера.
- Извлекайте оценки изменений по отношению к часу дня и коду события, рассматриваемым совместно. Напомним, что это наше модифицированное соотношение с учетом сегодняшнего и вчерашнего.
- Для каждого кода события агрегируйте оценки изменений в оценку волатильности, как мы описали выше.
- Покажите десять кодов событий, имеющих наибольшую волатильность.
Вы можете увидеть эффект отдельных фильтров, сняв их с конца запроса. См. Splunk Search Reference для получения дополнительной информации о том, что происходит выше.
Если посмотреть на график, получится следующее:
Вдоль оси х у нас есть куча кодов событий (я подавил метки), а на оси у мы имеем волатильность. Эта диаграмма сразу показывает, какие из сотен кодов событий видят больше всего действий.
Вывод
Хотя это еще не вся история, то, что мы имеем до сих пор, уже довольно полезно. Он сообщает нам в любой данный момент времени, какие коды событий наиболее заслуживают нашего внимания с точки зрения волатильности. Это важно для операций в реальном времени.
Напомним, что мы можем обобщить это и на другие виды метрик, а также на разные временные и временные рамки.
Geek в сторону: есть связь между тем, что мы здесь делаем, и линейной регрессией из статистики. С помощью линейной регрессии мы начинаем с группы точек данных и ищем линейную модель, которая минимизирует сумму квадратов ошибок. Здесь мы делаем что-то похожее, но в противоположном направлении. Мы начинаем с линейной базовой линии (оценка изменения = 1, что означает отсутствие изменений — это не совсем правильно, но это основная идея, к которой мы стремимся), а затем обрабатываем каждый код события как набор точек данных (оценка изменения против час дня) против этого базового уровня. Коды событий, которые максимизируют сумму квадратов, являются наиболее подходящими кодами событий и, следовательно, наиболее достойными нашего внимания.
В следующем посте мы увидим, как визуализировать фактические временные ряды всплесков и падений для первой десятки.
Подтверждения
Спасибо Аману Бутани за то, что он предложил подход «попса и капли» в первую очередь, и Аману Бутани и Малкольму Джамалу Андерсону за полезные обсуждения и код, ведущий к работе выше.