Гистограмма с кластерами, где кластеры нормализованы, поэтому выбросы очевидны.

Предположим, у меня есть кластеризованная гистограмма, и я хочу найти выбросы в каждом кластере... это легче объяснить на примере, так что вот он:

введите здесь описание изображения

Здесь у нас есть количество кодов ошибок (ось X: коды, ось Y: количество), а кластеры — это, скажем, отдельные машины, на которых эти ошибки были зарегистрированы. Вы можете видеть, что 1001 регистрируется на всех этих машинах, а 897 не так много. Я хочу найти, где определенные машины являются выбросами (высокими) по сравнению с остальными машинами для каждого кластера кода ошибки.

Это шаблон, который я мог бы легко распознать своим глазом ... но тот факт, что так много ошибок 1001 записано, нанесено на график против всех других кодов ошибок с линейной осью Y, означает, что различия в 897 или 176 слишком малы, чтобы пятно.

Итак: есть ли способ «нормализовать» каждый кластер, чтобы для кластеров с небольшими подсчетами их подсчеты были завышены/расширены, чтобы занимать больше оси Y?


splunk data-visualization
person davidbak    schedule 07.07.2016    source источник
comment
Я думаю, что Cross Validated, stats.stackexchange.com, будет лучше для этого.   -  person xan    schedule 10.07.2016
comment
хорошо, я не знал, что визуализация данных была частью их сферы деятельности, но теперь я вижу, что это так, спасибо!   -  person davidbak    schedule 10.07.2016
comment
Кроме того, с тех пор я решил установить ось Y в логарифмическом масштабе, и это в значительной степени сработало. Дело в том, что я сейчас не уверен, отвечать ли на это своим собственным ответом, удалять ли его или что.   -  person davidbak    schedule 10.07.2016
comment
Забавно — я только что сделал запись в блоге против использования логарифмических шкал с полосами, потому что полосам нужна нулевая точка, чтобы длина имела смысл. blogs.sas .com/content/jmp/2016/06/29/ Что касается первоначального вопроса, я подумал, что у специалистов по статистике есть мнение, как измерить, являются ли различия значительными.   -  person xan    schedule 11.07.2016
comment
@xan Это хороший пост - я согласен с тем, что использование логарифмических шкал должно быть оправдано, но я рассматриваю случай, когда логарифмические шкалы наиболее полезны, когда исходные данные сильно искажены или различаются на много порядков. В этом случае некоторые ошибки (например, 1001) регистрируются со скоростью 1000/ч, а другие (например, 309) — 10/ч (или меньше). Это устаревшая система, поэтому ведение журнала — это то, что есть, а ошибки — это то, что они есть, и я пытаюсь найти, если новое развертывание, которое сначала развертывается на одной ферме в течение дня, показывает другую ошибку тенденция: например, мы как-то ухудшили ситуацию?   -  person davidbak    schedule 11.07.2016
comment
... а затем мы копаемся, чтобы выяснить, действительно ли это проблема или нет.   -  person davidbak    schedule 11.07.2016
comment
Я вижу ценность поиска вещей, которые на порядок больше. Также может помочь просмотр процента от общего числа в группе ошибок.   -  person xan    schedule 11.07.2016
comment
@xan - процент от общего числа кластера звучит хорошо ... Я хотел бы знать, как заставить splunk вычислить это ...   -  person davidbak    schedule 11.07.2016

Ответы (1)


arrow_upward
0
arrow_downward

вы можете попытаться сначала установить среднее количество ошибок на всех хостах, а затем наметить разницу

search ...
| stats count by host error
| eventstats avg(count) as error_avg by error
| eval diff = (count-error_avg)/error_avg*100
| chart max(diff) as diff by host error

оттуда вы можете отфильтровать, где diff находится за пределами определенного процента

person Peter McIntyre    schedule 16.10.2016