Я не оповещаю об Apdex. Это меня смущает

Я не оповещаю об Apdex. Это меня смущает

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

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

Это мой личный взгляд на то, что считается стандартным, но я просто не понимаю Итак, приступим — Apdex, что это такое и почему я не понимаю. т использовать его!

Что такое апдекс

Apdex — это число, которое пытается представить удовлетворенность пользователя системой.

Это стандарт для измерения производительности. Он смотрит на системы с точки зрения конечного пользователя, распределяя запросы, обслуживаемые системой, по трем группам — удовлетворенные / допустимые / неудовлетворенные, взвешивая их все в единое числовое значение, называемое «оценкой Apdex».

Он делает это, определяя пороговое значение, называемое «Tvalue», которое представляет собой максимальную задержку, которая считается «хорошей», а группирование работает следующим образом:

Также неявно подразумевается, что неудачные запросы считаются неудовлетворенными (независимо от задержки).

Звучит неплохо, верно? Мне это не нравится.
В оставшейся части этого поста я постараюсь объяснить, почему.

1. Никто не знает, что такое Apdex

Прежде всего, никто не знает, что такое Apdex.

Я буквально узнал об этом в 3 часа ночи, когда оценка Apdex опустилась ниже порога оповещения. Если наблюдаемость в целом является областью, которую трудно освоить, то Apdex обычно находится очень далеко в программе обучения.

Кроме того, даже если вы знаете его определение — Оценка Apdex неосязаема! Что означает оценка 0,87?! Вы можете себе это представить? Можете ли вы построить график работоспособности системы и Apdex — какая будет между ними корреляция? Сможете ли вы с учетом оценки составить мысленную модель состояния вашей системы?

Это абстракция или резюме, которое ничего не упрощает, а только добавляет путаницы!

Как сказал @nukemberg, когда мы это обсуждали: у людей нет для этого интуиции, нет конкретного примера, нет симулятора.

2. Трудно установить осмысленный порог оповещения

Поскольку числовое значение оценки трудно представить и понять, как именно мы будем устанавливать порог оповещения? Будет ли это оценка ниже 0,9? 0,8? Я считаю, что порог оповещения является произвольным значением! (Все мы знаем, что это лучший способ довести вашу команду до усталости).

3. Это «кажется» произвольным

Он пытается упростить понимание распределения задержки. Он берет распределение, которое с самого начала не является тривиальной концепцией, и разбивает его на 3 чрезмерно упрощенных сегмента, которые всегда кажутся мне произвольными (Почему 4*T разочарован? Почему не 1,5 или 8?).

4. Это «по умолчанию», а не оптимум

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

Более того, разные варианты использования или клиенты могут иметь разные значения T. т.е. разные определения удовлетворенных и неудовлетворенных запросов. Например, удовлетворенность пользователей Freemium может составлять 1 секунду, а для корпоративных пользователей — 400 мс.

Я считаю это попыткой создать «один пакет», который на самом деле не подходит ни к одному

5. Он имеет несколько измерений

Наконец, и здесь это полностью мое личное предпочтение. Он имеет несколько параметров — задержку и частоту ошибок. Они суммируются в одно число, поэтому предупреждение о низком балле Apdex не говорит о том, в чем именно заключается проблема — это задержка? или ошибки?

Я предпочитаю, чтобы оповещения были с одним измерением — так будет очень ясно, что является источником оповещения.

Если не Apdex, о чем мы должны предупреждать?

Appdex имеет 2 измерения — ошибки и задержку, поэтому я просто предупреждаю о них… это намного проще понять и понять — оповещение раскрывает, что происходит.

Можно создать эффективный SLO, который сочетает в себе несколько параметров, но это делается путем определения согласованных пороговых значений, а не двусмысленных оценок. Например — % запросов с задержкой выше 500 мс или процент отказов. Это похоже на использование только корзин Satisfied или Frustrated Apdex.

Последние мысли

В приложениях, ориентированных на пользователя, оценка Apdex может иметь некоторое значение как своего рода «инженерная догадка» — получение общего «ощущения» производительности системы.

В сервисных приложениях (то есть системах, которые не взаимодействуют напрямую с пользователем-человеком) я действительно не вижу смысла в использовании Apdex — нет понятия «удовлетворенность» — SLA либо выполняется, либо нет. Никаких золотых середин.

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

Некоторые заслуги:
@nukemberg, с которым я обсуждал идеи, лежащие в основе этого поста, и помог их отточить.
Пост @Eladleev, автора глубокой проблемы с терраформированием, вдохновил меня написать то, что я думаю об Apdex (который пролежал в ящике стола более года).

Как всегда, мысли и комментарии приветствуются в твиттере @cherkaskyb.